Decode the marker shapes in one place - #2144
Merged
Merged
Conversation
A marker specification mixes a bare file name with an (:any FILE...) clause, and each of the four consumers took that apart for itself - detection, the project-file derivation, verify-files and the doctor's renderer. The derivation is the tell: it understood a clause only in the first position, which happens to be enough for everything registered today and would not have been for the next one. projectile--marker-clauses now answers with a list whose every element is a list of names, any one of which satisfies that position. Callers stop asking what shape they were given: verify-files is an every-some over it, the doctor joins alternatives with | and positions with a space, and the derivation takes the first element whatever it contains. No behaviour change - the old decoding was correct for the shapes that reach it, this is about how many places know the shapes at all. The public marker format and the stored plist are untouched.
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.
The internal debt this cycle created. A project type's marker specification
mixes two shapes - a bare file name and an
(:any FILE...)clause - and each ofthe four consumers took that apart for itself: detection, the
:project-filederivation,
projectile-verify-files, and the doctor's renderer.The derivation is the tell. It understood a clause only in the first position,
which is enough for every type registered today and wouldn't have been for the
next one. That's the kind of thing that works until someone writes
'("composer.json" (:any "bin/console" "app/console"))and wonders why the rootfile seeding is wrong.
projectile--marker-clausesis now the one place that knows the shapes. Itanswers with a list whose every element is a list of names, any one of which
satisfies that position, and returns nil for a predicate marker. The callers
stop asking what they were handed:
projectile-verify-filesis anevery-over-somewith no shape test in it,while keeping its public contract of accepting the raw form.
|and positions with a space, noany-marker-pin sight.No behaviour change. The old decoding was correct for the shapes that
actually reach it; this is about how many places know the shapes at all. The
public marker format and the stored plist are untouched, so anything reading
projectile-project-typessees exactly what it saw before - there's a spec thatwalks every bundled type through the normalizer to confirm none of them changed
shape.