aboutsummaryrefslogtreecommitdiff
path: root/crates/ra_ide/src/syntax_highlighting
Commit message (Collapse)AuthorAgeFilesLines
* Highlight `true` and `false` as literalsMatthew Jasper2020-05-242-0/+3
|
* Color attribute functionsGeorge Fraser2020-05-191-1/+5
|
* Color `for` as a regular keyword when it's part of impl _ for _George Fraser2020-05-101-0/+10
|
* Color `in` as a control keywordGeorge Fraser2020-05-101-0/+4
|
* Highlight mutable statics as mutableMatthew Jasper2020-05-101-1/+6
|
* Introduce new semantic highlight token for format specifierLeander Tentrup2020-04-282-0/+3
|
* CleanupsAleksey Kladov2020-04-251-8/+5
|
* Convert tests to text-sizeAleksey Kladov2020-04-251-1/+1
|
* Convert code to text-sizeAleksey Kladov2020-04-251-5/+6
|
* Merge #3998 #4006bors[bot]2020-04-241-0/+70
|\ | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | | 3998: Make add_function generate functions in other modules via qualified path r=matklad a=TimoFreiberg Additional feature for #3639 - [x] Add tests for paths with more segments - [x] Make generating the function in another file work - [x] Add `pub` or `pub(crate)` to the generated function if it's generated in a different module - [x] Make the assist jump to the edited file - [x] Enable file support in the `check_assist` helper 4006: Syntax highlighting for format strings r=matklad a=ltentrup I have an implementation for syntax highlighting for format string modifiers `{}`. The first commit refactors the changes in #3826 into a separate struct. The second commit implements the highlighting: first we check in a macro call whether the macro is a format macro from `std`. In this case, we remember the format string node. If we encounter this node during syntax highlighting, we check for the format modifiers `{}` using regular expressions. There are a few places which I am not quite sure: - Is the way I extract the macro names correct? - Is the `HighlightTag::Attribute` suitable for highlighting the `{}`? Let me know what you think, any feedback is welcome! Co-authored-by: Timo Freiberg <[email protected]> Co-authored-by: Leander Tentrup <[email protected]> Co-authored-by: Leander Tentrup <[email protected]>
| * Adapt format specifier highlighting to support escaped squences and unicode ↵Leander Tentrup2020-04-221-0/+5
| | | | | | | | identifiers
| * Implement syntax highlighting for format stringsLeander Tentrup2020-04-201-0/+65
| | | | | | | | | | | | | | Detailed changes: 1) Implement a lexer for string literals that divides the string in format specifier `{}` including the format specifier modifier. 2) Adapt syntax highlighting to add ranges for the detected sequences. 3) Add a test case for the format string syntax highlighting.
* | Add semantic tag for unresolved referencesAleksey Kladov2020-04-181-0/+2
|/ | | | | | | | | | | This is a quick way to implement unresolved reference diagnostics. For example, adding to VS Code config "editor.tokenColorCustomizationsExperimental": { "unresolvedReference": "#FF0000" }, will highlight all unresolved refs in red.
* Fix incorrect order of syntax highlight rangesLeander Tentrup2020-04-171-0/+12
|
* Merge #3826bors[bot]2020-04-082-41/+50
|\ | | | | | | | | | | | | | | | | | | | | | | | | 3826: Flatten nested highlight ranges during DFS traversal r=matklad a=ltentrup Implements the flattening of nested highlights from #3447. There is a caveat: I needed to add `Clone` to `HighlightedRange` to split highlight ranges ~and the nesting does not appear in the syntax highlighting test (it does appear in the accidental-quadratic test but there it is not checked against a ground-truth)~. I have added a test case for the example mentioned in #3447. Co-authored-by: Leander Tentrup <[email protected]>
| * Simplify HTML highlighter and add test case for highlight_injection logicLeander Tentrup2020-04-062-53/+46
| |
| * Flatten nested highlight ranges during DFS traversalLeander Tentrup2020-04-031-0/+16
| |
* | Make control token modifier less ambiguousAleksey Kladov2020-04-061-3/+3
|/ | | | | | | | | In textmate, keyword.control is used for all kinds of things; in fact, the default scope mapping for keyword is keyword.control! So let's add a less ambiguous controlFlow modifier See Microsoft/vscode#94367
* Correctly flag 'lifetime definitions as definitionsAleksey Kladov2020-02-283-8/+11
|
* Fix highlighting of const patternsAleksey Kladov2020-02-281-5/+12
|
* Fix highlighting testAleksey Kladov2020-02-283-11/+13
|
* Cleanup highlighting tagsAleksey Kladov2020-02-281-45/+47
|
* add more tagsAleksey Kladov2020-02-281-10/+16
|
* Move tests to a new fileAleksey Kladov2020-02-271-0/+127
|
* Renam moduleAleksey Kladov2020-02-271-0/+0
|
* Move html highlightig to a separate moduleAleksey Kladov2020-02-271-0/+104
|
* Better highlightign APIAleksey Kladov2020-02-272-43/+163
|
* More type safety for highlightingAleksey Kladov2020-02-261-0/+43