Add support for underscore-separated numeric literals in Odin syntax
highlighting. This allows proper highlighting of numbers like 1_000_000,
0xFF_AA_BB, and 0b1010_1111 as specified in the Odin language.
> Numerical literals are written similar to most other programming
> languages. A useful feature in Odin is that underscores are allowed
> for better readability: 1_000_000_000 (one billion).
> https://odin-lang.org/docs/overview/#numberscloses: #18852
Signed-off-by: Maxim Kim <habamax@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- cleanup of PR for tearing and other output options
- removed `allow_tearing` from global keywords (it's only an output option)
- moved `...clockwise` directives from general to transform options
- separated `icc` highlight to correctly detect and highlight paths
- updated output bg to use the same approach as `icc` for file path
- separated all identifier-matchers into their own groups
- added support for bar identifiers
closes: #18851
Signed-off-by: Josef Litoš <54900518+litoj@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- mapped all identifier-highlighting groups to a new group `i3ConfigIdent`
- i3config bar is now split into keyword and block matches
- support `xft:` namespace in fonts
- Update maintainer information in i3config.vim
related: #18851
Signed-off-by: Josef Litoš <54900518+litoj@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Match \dE\d real literal form
- Match all string escape sequences
- Add related tests
closes: #18723
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: Erlang lexical files are not recognized
Solution: Detect *.xrl files as leex filetype, include syntax and
filetype plugins (Jon Parise).
leex is the lexical analyzer generator for Erlang. Its input file format
follows a section-based structure and uses the `.xrl` file extension.
This initial work includes file detection, an ftplugin (which inherits
the Erlang configuration), and a syntax definition.
Reference:
- https://www.erlang.org/doc/apps/parsetools/leex.html
related: #18819closes: #18832
Signed-off-by: Jon Parise <jon@indelible.org>
Signed-off-by: Csaba Hoch <csaba.hoch@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: completion: complete_match() Vim script function and
'isexpand' option are not that useful and confusing
(after v9.1.1341)
Solution: Remove function and option and clean up code and documentation
(Girish Palya).
complete_match() and 'isexpand' add no real functionality to Vim. They
duplicate what `strridx()` already does, yet pretend to be part of the
completion system. They have nothing to do with the completion mechanism.
* `f_complete_match()` in `insexpand.c` does not call any completion code.
It’s just a `STRNCMP()` wrapper with fluff logic.
* `'isexpand'` exists only as a proxy argument to that function.
It does nothing on its own and amounts to misuse of a new option.
The following Vim script function can be used to implement the same
functionality:
```vim
func CompleteMatch(triggers, sep=',')
let line = getline('.')->strpart(0, col('.') - 1)
let result = []
for trig in split(a:triggers, a:sep)
let idx = strridx(line, trig)
if l:idx >= 0
call add(result, [idx + 1, trig])
endif
endfor
return result
endfunc
```
related: #16716fixes: #18563closes: #18790
Signed-off-by: Girish Palya <girishji@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: completion: 'completefuzzycollect' option is too obscure
Solution: Deprecate the option, but don't error out for existing scripts,
behave like 'completefuzzycollect' is set when fuzzy
completion is enabled (Girish Palya).
fixes: #18498closes: #18788
Signed-off-by: Girish Palya <girishji@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Add a test for issue #18776 (allow spaces in backticked operators).
closes: #18783
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match full :debug, :breakadd, :breakdel and :breaklist commands.
closes: #18748
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
This formatting (although rare) is actually accepted by GHC, but vim
does not highlight it. This patch adds the simplest possible regex to
support the behavior.
Inconveniently, this might trigger weird formatting on lines that
contain errors, e.g. if the first backtick is removed from:
a `b` c `d` e
then `c` is going to be marked as an operator, which seems weird but is
valid.
closes: #18776
Signed-off-by: Mirek Kratochvil <exa.exa@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match the digraph tables to avoid false positive matches for helpSpecial
etc. No syntax groups should match in these tables.
closes: #18738
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match "object" and "<" ... ">" separately with dedicated syntax groups
to allow for highlighting distinct from that generally used for types.
closes: #18721
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Only terminate the :augroup END argument at whitespace, comments and
trailing bars.
closes: #18711
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Match the Ex command arg to all :*do commands.
closes: #18700
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Problem: A plugin does not know when startup scripts were already
triggered. This is useful to determine if a function is
called inside vimrc or after (like when sourcing 'plugin/'
files).
Solution: Add the v:vim_did_init variable (Evgeni Chasnovski)
closes: #18668
Signed-off-by: Evgeni Chasnovski <evgeni.chasnovski@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
- Highlight :@ as a normal Ex command rather than something special.
- Fix erroneous matching of the Ex command as a register variable.
closes: #18624
Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
This fixes a bug introduced in 2a33b499a3:
When makeTargetinDefine ends with makeIdent, makeSpecTarget or
makeComment, the following line is also matched as makeTargetinDefine.
So, add keepend to prevent that just as makeTarget does.
related: #18403closes: #18570
Signed-off-by: Yiyang Wu <xgreenlandforwyy@gmail.com>
Signed-off-by: Roland Hieber <rohieb+vim-iR0jGdkV@rohieb.name>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Fix syntax highlighting for def-style Python functions, with their
parameters spanning multiple lines. E.g. the following should match as
valid Python code in Bitbake recipes:
def myFunction(one, two, \
three, four):
pass
For this to work, use the prefix modifier "\_" before the wildcard ".",
to also match newline characters.
closes: #18565
Signed-off-by: Martin Schwan <m.schwan@phytec.de>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Minor style and whitespace changes to the reST syntax file, to sync with
the development branch.
related: #18566
Signed-off-by: Marshall Ward <marshall.ward@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Escape character support was disabled for inline literals, which are
handled separately from standard inline highlights, in that escape
characters are unsupported.
related: #18566
Signed-off-by: Marshall Ward <marshall.ward@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Previously, a comment in a directive block would incorrectly mark
all subsequent lines in the directive block as comment, because the
syn-region did not check the leading indent.
related: #18566
Signed-off-by: Antony Lee <anntzer.lee@gmail.com>
Signed-off-by: Marshall Ward <marshall.ward@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
The leading two dots of a RST directive gets matched by
rstExplicitMarkup group first, and then the directive name and directive
body will be matched by the groups contained in rstDirectives cluster in
order.
The rstExDirective group in rstDiretives matches any RST directives
other than footnote, citation and hyperlink target, therefore admonition
and code block will be matched by rstExDirective. This fix has
rstExDirective contain rstExplicitMarkup so as to enable recursive RST
directives match.
The interpreted texts enclosed in quotes are not highlighted within a
RST directive body, because the rstCruft cluster contains a non-existing
rstInterpretedText group.It should be renamed to
rstInterpretedTextOrHyperlinkReference which is defined in a
DefineInlineMarkup function call.
related: #18566
Signed-off-by: Minjie Xu <madjxatw@gmail.com>
Signed-off-by: Marshall Ward <marshall.ward@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Following the approach used in other syntax definitions, add support for
defining the "syntax sync minlines=..." values for rst files in the
users' ~/.vimrc files, to allow the users to adjust that value in case
syntax highlighting stops working for some of the files they edit.
related: #18566
Signed-off-by: Dragan Simic <dsimic@manjaro.org>
Signed-off-by: Marshall Ward <marshall.ward@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
A doctest block usually spans multiple lines, e.g.
>>> print('this is a Doctest block')
this is a Doctest block
Remove ``oneline`` argument to syntax region as this requirement is not
met. Consequently, also remove ``display`` as the prerequisite (the
syntax region is on a single line) is no longer met.
----
Recognise '>>>' inside doctest blocks
Recognise subsequent '>>>' prompts in doctest blocks, e.g.
>>> print('this is a Doctest block')
this is a Doctest block
>>> print('this is a second Doctest block')
this is a second Doctest block
A doctest block usually spans multiple lines, e.g.
>>> print('this is a Doctest block')
this is a Doctest block
related: #18566
Signed-off-by: Kirk Roemer <91125534+kirk-roemer@users.noreply.github.com>
Signed-off-by: Marshall Ward <marshall.ward@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
Previously contents in makeDefine are nearly highlighted as Define, so
comments and targets shares the same color as Define, making it hard to
distinguish if someone write large block of targets-recipes as defined
function.
Such scenario is common in building data analysis pipeline. Recipes are
reused and targets may have multiple variables, and a single % implicit
rule is not enough.
closes: #18403
Signed-off-by: Yiyang Wu <xgreenlandforwyy@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
