- treat `restrict`/`_Atomic` like `const`/`volatile` => @keyword.storage.modifier
- highlight `unsigned int` as builtin => @type.builtin
- recognize `static_cast` and friends => @keyword
- `template` is a kind of entity like `typename` => @keyword.storage.type
- many declaration modifiers have nothing to do with storage/types
(explicit, friend, access specifiers, inline in C++) => @keyword
- fix floats highlighted as integer => @constant.numeric
This is an attempt to clean up the inconsistent way that keys are
written in various places. These rules require the fewest changes to the
existing text.
Use the "Key name", as defined in remapping.md, which uses
"Some-Modifiers-PascalCaseKey". The "Representation", which uses
"S-M-lowercasekey", is only used for configuration entries.
For key combinations which do not present a popup, just present the keys
one after the other, with no intervening space, like `]p`.
For key combinations which present a popup, separate them with ` + `,
like `Space + f`.
The Ctrl modifier is called Ctrl, not Control.
Undo/redo/earlier/later call `Document::apply_impl` which applies
transactions to the document. These transactions also need to be
applied to the view as in 0aedef0.
Here we separate the diagnostics by severity and then overlay the Vec
of spans for each severity on top of the highlights. The error
diagnostics end up overlaid on the warning diagnostics, which are
overlaid on the hints, overlaid on info, overlaid on any other severity
(default), then overlaid on the syntax highlights.
This fixes two things:
* Error diagnostics are now always visible when overlapped with other
diagnostics.
* Ghost text is eliminated.
* Ghost text was caused by duplicate diagnostics at the EOF:
overlaps within the merged `Vec<(usize, Range<usize>)>` violate
assumptions in `helix_core::syntax::Merge`.
* When we push a new range, we check it against the last range and
merge the two if they overlap. This is safe because they both
have the same severity and therefore highlight.
The actual merge is skipped for any of these when they are empty, so
this is very fast in practice. For some data, I threw together an FPS
counter which renders as fast as possible and logs the renders per
second.
With no diagnostics, I see an FPS gain from this change from 868 FPS
to 878 (+1.1%) on a release build on a Rust file. On an Erlang file
with 12 error diagnostics and 6 warnings in view (233 errors and 66
warnings total), I see a decrease in average FPS from 795 to 790
(-0.6%) on a release build.
It is easy to forget to call `Document::apply` and/or `View::apply` in
the correct order. This commit introduces a helper function which
closes over both calls.
This change adds View::apply calls for all Document::apply call-sites,
ensuring that changes to a document do not leave invalid entries in
the View's jumplist.
Applying a transaction to a View adjusts the ranges in the jumplist
to ensure that they remain within the text of the document and follow
regular selection invariants (for example, must be have a width of at
least one).
