-
Notifications
You must be signed in to change notification settings - Fork 144
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add support for loading metadata files #223
Conversation
b7b93fd
to
b3bb1fb
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Looks pretty good. Some comments. Still may want to spend some more time wrapping my head around the approach of converting the files to the final metadata in case I can see a cleaner way.
src/parsing/metadata.rs
Outdated
if !KEYS_WE_USE.contains(&key.as_str()) { | ||
continue; | ||
} | ||
//NOTE: because we can't guarantee the order that files get loaded, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Doesn't this conflict with the doc comment about last writer winning? I think Sublime just does last writer wins and loads the packages in alphabetical-ish order or something. This seems like it would be pretty unintuitive behaviour.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Comment is out of date and I agree just doing alphabetical order on the files is much simpler, will make that change.
src/parsing/syntax_set.rs
Outdated
|
||
/// The metadata items that match the given scope. The result may be empty. | ||
#[cfg(feature = "metadata")] | ||
pub fn metadata_for_scope(&self, scope: &[Scope]) -> ScopedMetadata { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This helper doesn't seem like it saves enough code to be worth it to me.
} | ||
|
||
|
||
impl Pattern { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I was going to say that it would be nice if we could refactor SyntaxDefinition
to use this as well, but I see that the fact that regex_str
is public would make that a breaking change. I may still want to do that eventually but doesn't have to be this PR.
src/parsing/metadata.rs
Outdated
.map(|score| (score, meta_set)) | ||
}).collect::<Vec<_>>(); | ||
|
||
metadata_matches.sort_by(|one, two| two.0.cmp(&one.0)); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Hint: sort_by_key
makes this cleaner
@trishume thanks for the quick look. I agree that the initial loading/conversion feels a bit over-complicated, but couldn't think of an easier approach that correctly handles adding new files. I'll do some cleanup on this a bit later on today. As an addendum: I'd like to add support for the comment-related members of
This latter is the cleanest and the easiest to use but requires us to make some assumptions and to throw away some metadata. It feels like the best approach for now, but if you have an opinion I'm happy to hear it. |
ff456ec
to
08e8978
Compare
I personally vote for:
as it is the most flexible/useful :) |
08e8978
to
09ac1bd
Compare
Okay I've updated this to simplify the merging logic and address some of the other feedback. I've noticed a probable bug here, as well: we go to pretty major effort to keep around the 'raw' metadata, so that we can correctly merge if new files are added; however we don't include the raw metadata when we do |
Okay, an issue with the raw metadata stuff: bincode doesn't support We could take this as an opportunity to simplify the overall approach; we could discard raw metadata when we build the This seems reasonable for any use-cases that I can imagine, and generally simplifies things; let me know if it makes sense to you? |
I've gone ahead and added a commit that makes the change described above. Let me know if you prefer a different approach. |
a75c4bb
to
f0d581c
Compare
examples/gendata.rs
Outdated
@@ -2,26 +2,40 @@ | |||
//! syntect, not as a helpful example for beginners. | |||
//! Although it is a valid example for serializing syntaxes, you probably won't need | |||
//! to do this yourself unless you want to cache your own compiled grammars. | |||
//! | |||
//! The standard command to generate the syntax dumps (including metadata) is: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you replace the command under make packs
in the Makefile
with this? Then maybe replace this comment with a reference to this script being used in the Makefile using make packs
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
where F: FnMut(&MetadataItems) -> Option<T> | ||
{ | ||
self.items.iter() | ||
.map(|(_, meta_set)| &meta_set.items) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Do you know that it's the case that Sublime does this trying multiple patterns thing? Seems rarely applicable and I wouldn't be surprised if Sublime only tries the matchiest, which would let you simplify a bunch of this.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I believe sublime does it this way; this is why we need the new default package, because it includes some base settings for the source
and comment
scopes. @keith-hall suggested this implementation in #183 or #179.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Just two little things, sorry I missed these on previous passes.
@@ -3,7 +3,7 @@ | |||
//! settings like selection color, `ThemeSet` for loading themes, | |||
//! as well as things starting with `Highlight` for how to highlight text. | |||
mod selector; | |||
mod settings; | |||
pub(crate) mod settings; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This was previously public and even though I think literally nobody uses it I'd rather not break semver compatibility for little reason.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this was previously private, I exposed it because I needed StackSelectors
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
er, not StackSelectors
but Settings
and SettingsObject
? because I'm loading plists.
edit: I can avoid this and just redeclare those typedefs locally, I do this already for SettingsObject
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
oops derp cool
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
looked at this again, it's because I'm using load_plist
. Could reexport manually if that makes more sense?
src/parsing/metadata.rs
Outdated
|
||
/// Generates a `MetadataSet` from a single file | ||
#[cfg(test)] | ||
pub fn quick_load(path: &str) -> Result<MetadataSet, LoadingError> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
pub fn quick_load(path: &str) -> Result<MetadataSet, LoadingError> { | |
pub(crate) fn quick_load(path: &str) -> Result<MetadataSet, LoadingError> { |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done.
This adds initial support for loading metadata from `.tmPreferences` files. The main focus of this patch is loading the patterns used to determine indentation. I expect to follow up with support for comment strings, with support for other features possible in the future. This is all gated behind a new `metadata` feature. If enabled, a top-level `Metadata` object will be included in `SyntaxSet`; this object can be queried for the metadata available for a given scope. This patch does not attempt to implement any actual indentation logic; that is left up to the consumer.
This also includes a bit of PR feedback and cleanup.
e177132
to
7381243
Compare
Oh whoops derp one last request sorry I keep forgetting things: Can you modify |
@trishume yep can do that now |
106c952
to
3fc536e
Compare
Okay, should be good to go? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for all this!
Thanks for taking the time out of your Sunday to get it merged, much appreciated. |
This adds initial support for loading metadata from
.tmPreferences
files. The main focus of this patch is loading the patterns used to
determine indentation. I expect to follow up with support for comment
strings, with support for other features possible in the future.
This is all gated behind a new
metadata
feature. If enabled, atop-level
Metadata
object will be included inSyntaxSet
; this objectcan be queried for the metadata available for a given scope.
This patch does not attempt to implement any actual indentation logic;
that is left up to the consumer.
So I've added a
DefaultPackage
package totestdata
; it's just two files, but maybe we should just put it in the repo with the other packages?I've generally tried to keep the scope of this as narrow as possible, no bells & whistles; happy to iterate from here.
I've implemented simple autoindent (just using
increaseIndentPattern
anddecreaseIndentPattern
) in xi using this, and I'm happy with the results.Some of the logic around loading is a bit gnarly right now; I was doing a bunch of logging to figure out what all metadata fields existed, etcetera. So let's call this a rough cut?