This adds highlighting for
- quoting operators qw, qr, and qx, like `qw< some words >`
- angle brackets after a quoting operator, like `q<string>`
- punctuation as quoting delimiter, like `q|string|`
- POD sections, which start with ^=\w and and with ^=cut
- heredocs; the marker can be a bare word, or a quoted word, like
print <<~ 'EOF'
single quoted heredoc
EOF
Closes#3736
No attempt is made to use different highlighting for interpolated (qq or
"") strings just yet. Recognizing quote boundaries is more important.
This fixes serveral shortcomings of the current implementation:
- valid recipt definitions eg
foo bar="quz":
where previously interrupted by justfile/double_string
and therefore they where not highlighted correctly
- global variable assignments where not captured at all
This commit addresses the following issues:
* highlight trailing space characters with the `meta` face, instead of
`PrimarySelection`
* make the regex more readable by using a capture group in stead of
`\K`
* specifically match space characters, not other horizontal whitespace
characters
* match two or more space characters
Reference[1]:
> When you do want to insert a <br /> break tag using Markdown, you
> end a line with two or more spaces, then type return.
[1] https://daringfireball.net/projects/markdown/syntax#p
Note that the original reproducer doesn't seem to work anymore,
probably because of changes made to how lists are highlighted.
Fixes#911
Similar to Jinja, getting `eex` highlighting in *.ex files
will require users to setup a filetype hook similar to the
following:
hook global WinSetOption filetype=elixir %{
require-module eex
add-highlighter window/eex ref eex
}
This is done both to fix a circular dependency between the `elixir`
and `eex` modules, and avoid polluting `elixir` files with false
positives from `eex` highlighting given `eex` is framework specific
This fixed a weird bug where if you were typing in the top level scope of a
program (no indentation before statements), the `end`s wouldn't be inserted
for you.
