Skip to content

Fix slow angle bracket matching #89

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

Merged

Conversation

MicahChalmer
Copy link
Contributor

Fix #86.

The problem was caused by the logic that made it refontify the whole buffer when "font-lock-syntactically-fontified" was set to a position before the start of the region to be potentially fontified. Unfortunately that variable is not reliably set when fontifying a large buffer. Fortunately, the new logic is much simpler, and font-lock already takes care of ensuring that everything before font-lock-beg was syntactically fontified.

The other problem was calling syntax-ppss on positions known not to be fontified yet.

This fixes both of these issues, and the angle bracket matching now works on larger buffers without pausing on every keystroke.

Also included is a patch that makes it recognize incomplete raw strings. Without this, changing a character can affect syntax before it, and font-lock can be glitchy if that happens.

The problem was caused by the logic that made it refontify the whole
buffer when "font-lock-syntactically-fontified" was set to a position
before the start of the region to be potentially fontified.
Unfortunately that variable is not reliably set when fontifying a large
buffer.  Fortunately, the new logic is much simpler, and font-lock
already takes care of ensuring that everything before font-lock-beg was
syntactically fontified.

The other problem was calling syntax-ppss on positions known not to be
fontified yet.

This fixes both of these issues, and the angle bracket matching now
works on larger buffers without pausing on every keystroke.
Recognize raw strings all the way to the end of the buffer if they are
not closed.  This is not valid rust code, but the highlighting should
show the mistake.

This also eliminates glitchy behavior that can occur in this situation.
Emacs assumes that edits can't change syntax at positions before the
edit, and raw strings without this change violated this.
@rust-highfive
Copy link

r? @pnkfelix

(rust_highfive has picked a reviewer for you, use r? to override)

@MicahChalmer
Copy link
Contributor Author

r? @nikomatsakis

nikomatsakis added a commit that referenced this pull request Jul 31, 2015
@nikomatsakis nikomatsakis merged commit 75da3b0 into rust-lang:master Jul 31, 2015
@nikomatsakis
Copy link
Contributor

Looked pretty reasonable to me. Thanks @MicahChalmer for looking into this!

ps, I'm always happy when I hit tab and things line up with the opening < :)

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Large numbers of <>'s in a file cause massive slowdown
4 participants