Match angle brackets syntactically #79
Merged
Conversation
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
|
r? @pnkfelix (rust_highfive has picked a reviewer for you, use r? to override) |
|
I think I do want to accept this. At the very least, I've noticed that the current bracket-blinking code totally messes up multiple-cursors mode. cc @nikomatsakis any thoughts here? |
Factor out the method of looking for a match for a regexp, but filtering out some of the matches with a filtering function. This will be used again for angle bracket filtering. This also fixes an issue with raw string handling.
Add angle brackets to the list of emacs matching characters. Use syntactic fontification to suppress this where it is not appropriate (in less than operators, arrows, etc.) Remove the non-syntactic version that was there previously. For electric-pair-mode, suppress the pairing for < and > characters that are not angle brackets. Because syntax is used for indentation, this fixes some problems with it, particularly when attempting to stretch type parameter lists over multiple lines.
MicahChalmer
force-pushed
the
angle-bracket-madness
branch
from
2fd4641 to
07943f0
Compare
|
Thanks @pnkfelix. I just rebased after the latest other commits to master. (Nothing else was changed.) |
|
I have no objections -- it sounds strictly better than the hack I did. I don't quite understand how it works (but I haven't tried reading it). |
nikomatsakis
added a commit
that referenced
this pull request
Jul 6, 2015
Match angle brackets syntactically
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
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.
Remove the angle bracket blinking feature, and make it actually match
<and>characters as parens in the syntax table instead. This matching is suppressed as needed, so that less-than and greater-than operators, arrow operators, etc don't throw off the matches.This has the following effects:
forward-sexpandbackward-up-listacknowledge angle brackets.electric-pair-modeworks with angle brackets (also suppressed when needed.)->#50 - angle brackets are matched in the right pairs;->and other non-angle-bracket<and>characters do not attempt to match.Macros have arbitrary syntax and therefore it's not possible to know whether a
<or>character is an angle bracket or not. So the matching is always suppressed inside macro definitions and uses.There are a few disadvantages: besides the fact that the code is rather hairy, it also has to detect the non-angle-brackets perfectly, or else it throws off the indentation for the whole rest of the file. For that reason there is still a custom variable available to disable it (though with a different name than the previous one.)
Having said that, I don't know of any cases where it gets it wrong. I tested it with this program, which compares what emacs thinks are the non-bracket
</>characters with what the rust compiler thinks. It passed for all of the rust compiler code base, as well as all the rust code in servo and as many of servo's dependencies as still compile with the latest nightly.Also included are some bug fixes for some edge case issues in the handling of raw strings and character literals. I found these while running the test script. Even if the angle bracket matching itself is deemed to be too risky or hairy to be merged (and I would understand it if that turns out to be the case), you may want to merge the other commits for the bug fixes. I've put them first to make this easy.
If this PR is accepted, close #66 (because the variable that it renames has been removed entirely) and close #74 (because post-self-insert-hook is no longer used at all.) Both of these pertain to the old angle bracket blinking code that this PR removes entirely.
And if the PR is not accepted - hey, I still had fun writing it.