-
Notifications
You must be signed in to change notification settings - Fork 143
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 hidden_file_extensions key. #419
Add support for hidden_file_extensions key. #419
Conversation
Is anyone actively working on fixing 323/adding support for the other new features? I didn't see any active PRs related to it, and no one had commented on the issue, but I figured I'd ask first. |
Not that I know of, no. Iirc I wrote a comment asking for advice on how the API might look like, but had no responses. I did have a quick look at implementing support for popping multiple contexts at once but it wasn't trivial with the current design. |
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 don't think anyone else is. However note that the real trickiness will be the backtracking support, which I believe will require a complete API overhaul, since currently you can parse in a streaming way since no line can affect a previous line, whereas with backtracking that's no longer true.
I think it might be reasonable to support everything except backtracking though, since there'll be lots of syntaxes which might use some new features but not backtracking.
Oh, see the minimum supported rust version CI error, you just need to borrow the array you're iterating. |
7cce8b4
to
725cdf4
Compare
CI error should be fixed with the latest push. As for backtracking, thanks for bringing that up. I'd only seen issue 323 and not issue 271, so I hadn't realized that was another potential pain point before bumping to ST4. It looks like a bunch of grammars are already using the backtracking-related features:
Apart from backtracking, it sounds like adding support for the 4075-specific features, such as syntax inheritance, is not as complicated and shouldn't affect the public API -- is that a fair assessment? |
also add these pending re-writes from PRs:
|
Could someone please kick-off the PR testing again? The clippy issue should be fixed, and I'm seeing a "First-time contributors need a maintainer to approve running workflows" message. |
Huh I tried re-running it and the clippy issue happened again. Did you already look into it? Looks like the problem is that the time crate updated past our MSRV, which of course isn't a problem with this PR. Perhaps we need to either bump our MSRV or constrain an older version of the time crate. |
I created a PR to bump MSRV along with a motivation of why I believe that is preferred over putting an upper limit on |
Thanks @Enselic, we can retest and land this PR after your PR lands. |
@varungandhi-src Could you merge origin/master into this branch so CI becomes green please? |
This was introduced in Sublime Text 4.
725cdf4
to
e54eef3
Compare
@Enselic rebased and force-pushed; sorry I hadn't realized that PR testing was running pre-merge instead of after locally merging into master. |
Since this has been Approved by both Tristan and Keith I will merge this now that CI is green. I took a quick look and the code looked good to me too. I will add an entry for this PR to CHANGELOG at a later point as part of #409 |
This was introduced in Sublime Text 4.
Addresses one part of #323.
As I understand it, it doesn't really matter if a file extension is "hidden" or not from the POV of syntax highlighting.