-
Notifications
You must be signed in to change notification settings - Fork 141
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
Metadata support tracking & discussion #183
Comments
regarding 4, Python is an indentation sensitive language, so the re 5: We have seen that regex rewriting is a nightmare. Better to use a in terms of settings, Sublime allows users to override the behaviors, meta data, settings etc. in a granular way - i.e. only for a specific syntax or file etc. We should probably think how we want this interaction to be achieved with syntect as a library when used without user input (i.e. syncat) and with (from an editor like Xi). Having pack dumps makes things a bit more complicated, because it may be that we need to read in user prefs and apply those on top of the premade packs from every endpoint. |
We could make our own Sublime's indentation implementation isn't necessarily correct (see the controversial |
Okay, so I've picked this back up again, and hope to PR something in the next couple of days. My current plan is to add a pretty narrow set of features to syntect that mostly just expose metadata fields to consumers, handle loading and dumping metadata, etc. Consumers can then do what they want with it; that is, I'm not currently focused on actually implementing auto-indent logic based on metadata in syntect. (I might add a basic example binary that reindents a file, but I want to be generally non-opinionated about API etc.) I will need to add some My current inclination is to only include the metadata fields related to indentation and comments, although if anyone has strong feelings I'm happy to add other stuff? |
@keith-hall so I'm playing around with I can see two immediate options: either ignore struct ShellVariables {
tm_comment_start: Option<String>,
tm_comment_end: Option<String>,
tm_comment_disable_indent: Option<bool>,
tm_comment_start_2: Option<String>,
tm_comment_end_2: Option<String>,
tm_comment_disable_indent_2: Option<bool>,
tm_comment_start_3: Option<String>,
tm_comment_end_3: Option<String>,
tm_comment_disable_indent_3: Option<bool>,
} Which maybe gets us most of the way there? |
silly question, but can't we just map it into two separate string arrays, which hopefully can be serialized?
obviously its not as nice to work with if it gets deserialized back into that form, but that should be easy to map back into a more useful datastructure, no? |
I think that could work, and we could have a custom serializer/deserializer? Will certainly complicate the code a little bit, but I'll give it a shot. |
Actually your suggestion points to a much simpler solution, which is just to keep |
Thanks Colin, I don't mean to make your life harder :) |
Always happy to have someone keeping me honest. 😉 |
Metadata part 1: initial per-line indentation adjustment
overview
My initial goal is going to be to support calculating per-line indentation changes (i.e. whether or not we should increase or decrease the indentation level after a given line). I want to do this properly, as discussed in #179: full scope selectors, matching against a line's trailing scope. Approximate TODOs:
Subsequent work:
maybe one day (not currently planned)
I'm very receptive to input/feedback if people think various of these things are more or less important
Some Qs:
I'm going to need to add the 'Default' sublime package in order for this to work correctly. Are there any possible issues with this?
Support for user settings: I'm thinking specifically of
indent_to_bracket
. A text editor using the library would probably prefer if it could hand over this setting to us, and let us handle the implementation; this would be easier than, say, having a separate check for a trailing bracket and clobbering our indentation. Are there any other settings like this?I think we'll need to support
indentParens
andindentSquareBrackets
. Is there an argument against doing this? I guess one could argue that it should be a user setting as well. We could perhaps support it being both...I've been thinking about testing a bit, and I'm getting hung up on one particular problem. The following two bits of python code are both valid indentations:
Is this handled in any way by the regex-based system, or is there some other mechanism? I took a quick look and none of the regexes seemed to be looking for whitespace; in any case to detect an indentation decrease we would need to be matching at least two lines, I think?
^
anchor?That's all that I can remember, I'm sure more things will come up.
cc @trishume @keith-hall
The text was updated successfully, but these errors were encountered: