Don't let a corrupt known projects file take the projects with it - #2135
Merged
Conversation
…#1927] An unreadable known projects file was read as an empty list. When the file went bad after load - which is what the reporter hit, another package having written propertized strings into it - that looked exactly like another Emacs having removed every project, so the merge dropped the session's projects as well and then overwrote the file with the remains. The file is now moved aside with a .corrupt suffix and the fact reported, and an unreadable file no longer contributes a removal list at all. Saving strips text properties too, so Projectile can't be the one writing a file it won't be able to read back. Also adds projectile-ignored-project-patterns, so keeping /tmp or Downloads out of the known projects is a list of regexps rather than a lambda. It sits between the existing exact-path list and the predicate.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Reading #1927's thread turned up something more interesting than the feature I
went in for. The reporter's known projects file had been corrupted by another
package writing propertized strings into it, and the visible symptom was that
projects silently stopped being tracked.
The current code reads an unreadable file as an empty list. If the file goes
bad after load, that looks exactly like another Emacs having removed every
project, so the merge drops the session's projects too - and then writes the
result back over the file. A stray byte costs you a list built up over years.
So an unreadable file is now moved aside as
<file>.corruptand reported, andit no longer contributes a removal list at all.
projectile-load-known-projectsand
projectile-merge-known-projectsboth go through one reader that tells"absent" (legitimately no projects) apart from "unreadable" (we don't know).
Saving also strips text properties, so Projectile can't be the one writing a
file it won't read back.
The spec for the post-load case is what caught a hole in my own first attempt: I
neutralized
known-on-last-syncbut leftremoved-in-other-processstillcomputing against the empty list, so the projects were dropped anyway.
Then the feature I actually came for:
projectile-ignored-project-patterns,regexps sitting between the existing exact-path
projectile-ignored-projectsand the
projectile-ignored-project-functionpredicate. Keeping/tmpandDownloadsout of the known projects is a common enough want that it shouldn'tneed a lambda.
Fixes #1927