runtime(dosbatch): improve '::' comment highlighting
Added a syntax region for command blocks so that the highlighting of
`::` comments in them can be controlled. The `dosbatch_colons_comment`
variable now controls if all `::` comments in a code block are
highlighted as comments or errors. A `::` comment at the end of a
command block is always highlighted as an error.
This re-enables the highlighting of `::` comments in `.bat` files as
requested in vim/vim#13666, while allowing control of highlighting them in
command blocks requested in vim/vim#11778 and first attempted in vim/vim#11980.
related: vim/vim#11980fixes: vim/vim#13666f7f33e3719
Co-authored-by: Christian Brabandt <cb@256bit.org>
Co-authored-by: Mike Williams <mikew@globalgraphics.com>
Problem:
- `:InspectTree` was showing node ranges in 1-based indexing, i.e., in
vim cursor position (lnum, col). However, treesitter API adopts
0-based indexing to represent ranges (Range4). This can often be
confusing for developers and plugin authors when debugging code
written with treesiter APIs.
Solution:
- Change to 0-based indexing from 1-based indexing to show node ranges
in `:InspectTree`.
- Note: To make things not complicated, we do not provide an option or
keymap to configure which indexing mode to use.
runtime(vim): Update syntax file (vim/vim#13969)
Improve string interpolation highlighting.
Use the vimSep group to highlight interpolation braces as vimOperParen
has no highlighting of its own and employs vimSep via matchgroup.
Add vimNumber to the interpolation group's contained list.
7c5aeaffa2
Co-authored-by: dkearns <dougkearns@gmail.com>
Problem: vim.lsp.tagfunc() causes an infinite loop.
This is a bug happened while introducing deferred loading.
Solution: Rename the private module to `vim.lsp._tagfunc`.
The benefit of this is that users only pay for what they use. If e.g.
only `vim.lsp.buf_get_clients()` is called then they don't need to load
all modules under `vim.lsp` which could lead to significant startuptime
saving.
Also `vim.lsp.module` is a bit nicer to user compared to
`require("vim.lsp.module")`.
This isn't used for some nested modules such as `filetype` as it breaks
tests with error messages such as "attempt to index field 'detect'".
It's not entirely certain the reason for this, but it is likely it is
due to filetype being precompiled which would imply deferred loading
isn't needed for performance reasons.
Problem:
Processing non-fast events during SystemObj:wait() may cause two pieces
of code to interfere with each other, and is different from jobwait().
Solution:
Don't process non-fast events during SystemObj:wait().
runtime(vim): Improve keymap file highlighting (vim/vim#13550)
- Match :loadkeymap to EOF as a region and contain only allowed items.
- Add highlighting for <Char- notation.
- add basic syntax highlighting tests
69866449dd
N/A patches:
vim-patch:35928ee8f80ea721e92bb856c8ecde2cced46bb9
vim-patch:b5352931b354eb67eb7d223cc09c98dcf1b547b6
Co-authored-by: dkearns <dougkearns@gmail.com>
- Consistently use the variable CMAKE_BUILD_TYPE to select build type.
- Remove broken `doc_html` target.
- Remove swap files created by oldtest when cleaning.
- Only rerun `lintdoc` if any documentation files has changed.
runtime(netrw): fixing remote file removal via ssh (vim/vim#13942)
Make pattern, which retrieves the path component from e.g.
`scp://user@host//opt/program/file.ext` non-greedy.
c46c21b4ca
Co-authored-by: MiguelBarro <45819833+MiguelBarro@users.noreply.github.com>
runtime(racket): add missing space to b:undo_indent var (vim/vim#13945)
This copies commit 2a4862a (fixup! indent: only reset some options when
has vim9, 2024-01-31) from https://github.com/benknoble/vim-racket and
fixes 26b0176a9 (runtime(racket): undo some indent options only when
vim9script is available (vim/vim#13935), 2024-01-30).
83f627ff42
Co-authored-by: D. Ben Knoble <ben.knoble+github@gmail.com>
runtime(racket): undo some indent options only when vim9script is available (vim/vim#13935)
This copies commit 64edf95 (indent: only reset some options when has
vim9, 2024-01-30) from https://github.com/benknoble/vim-racket.
26b0176a98
Co-authored-by: D. Ben Knoble <ben.knoble+github@gmail.com>
Problem: UX of visual highlighting can be improved
Solution: Improve readibility of visual highlighting,
by setting better foreground and background
colors
The default visual highlighting currently is nice in that it overlays
the actual syntax highlighting by using a separate distinct background
color.
However, this can cause hard to read text, because the contrast
between the actual syntax element and the background color is way too
low. That is an issue, that has been bothering colorschemes authors for
quite some time so much, that they are defining the Visual highlighting
group to use a separate foreground and background color, so that the
syntax highlighting vanishes, but the text remains readable (ref:
vim/colorschemesvim/vim#250)
So this is an attempt to perform the same fix for the default Visual
highlighting and just use a default foreground and background color
instead of using reverse.
I also removed the hard-coded changes to the Visual highlighting in
init_highlight. It's not quite clear to me, why those were there and not
added directly to the highlighting_init_<dark|light> struct.
closes: vim/vim#13663
related: vim/colorschemes#250e6d8b4662d
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(vim): Update syntax and ftplugin files (vim/vim#13924)
Improve matching of line-continuations and interspersed comments.
These are now also matched in multiline syntax command patterns,
dictionary literals, and parenthesised expressions and argument lists.
21ce159e05
Co-authored-by: dkearns <dougkearns@gmail.com>
The "priority" field of extmarks can be used to set priorities of
extmarks which dictates which highlight group a range will actually have
when there are multiple extmarks applied. However, when multiple
extmarks have the same priority, the only way to enforce an actual
priority is through the order in which the extmarks are set.
It is not always possible or desirable to set extmarks in a specific
order, however, so we add a new "subpriority" field that explicitly
enforces the ordering of extmarks that have the same priority.
For now this will be used only to enforce priority of treesitter
highlights. A single node in a treesitter tree may match multiple
captures, in which case that node will have multiple extmarks set. The
order in which captures are returned from the treesitter API is not
_necessarily_ in the same order they are defined in a query file, so we
use the new subpriority field to force that ordering.
For now subpriorites are not documented and are not meant to be used by
external code, and it only applies to ephemeral extmarks. We indicate
the "private" nature of subpriorities by prefixing the field name with
an "_".
Problem:
If `neovim` module is not installed, python and ruby healthchecks fail:
- ERROR Failed to run healthcheck for "provider.python" plugin. Exception:
.../runtime/lua/provider/python/health.lua:348: attempt to concatenate local 'pyname' (a nil value)
- ERROR Failed to run healthcheck for "provider.ruby" plugin. Exception:
.../runtime/lua/provider/ruby/health.lua:25: attempt to index local 'host' (a nil value)
Solution:
Check for non-nil.
Problem: E95 is possible if a buffer called "[Command Line]" already
exists when opening the cmdwin. This can also happen if the
cmdwin's buffer could not be deleted when closing.
Solution: Un-name the cmdwin buffer, and give it a special name instead,
similar to what's done for quickfix buffers and for unnamed
prompt and scratch buffers. As a result, BufFilePre/Post are
no longer fired when opening the cmdwin. Add a "command" key
to the dictionary returned by getbufinfo() to differentiate
the cmdwin buffer instead. (Sean Dewar)
Cherry-pick test_normal changes from v9.0.0954.
1fb4103206
runtime(ant): Update syntax file (vim/vim#13926)
Remove invalid display option from syn-keyword commands.
Take over maintenance of this file.
0cc6108fea
Co-authored-by: dkearns <dougkearns@gmail.com>
runtime(mail): fixvim/vim#13913 (vim/vim#13917)
switch to the DFA engine for the emoji collaction range
046a0f75d0
Co-authored-by: gi1242 <gi1242+github@gmail.com>
Co-authored-by: GI <gi1242+vim@gmail.com>
Problem: Cannot map Super Keys in GTK UI
(Casey Tucker)
Solution: Enable Super Key mappings in GTK using <D-Key>
(Casey Tucker)
As a developer who works in both Mac and Linux using the same keyboard,
it can be frustrating having to remember different key combinations or
having to rely on system utilities to remap keys.
This change allows `<D-z>` `<D-x>` `<D-c>` `<D-v>` etc. to be recognized
by the `map` commands, along with the `<D-S-...>` shifted variants.
```vimrc
if has('gui_gtk')
nnoremap <D-z> u
nnoremap <D-S-Z> <C-r>
vnoremap <D-x> "+d
vnoremap <D-c> "+y
cnoremap <D-v> <C-R>+
inoremap <D-v> <C-o>"+gP
nnoremap <D-v> "+P
vnoremap <D-v> "-d"+P
nnoremap <D-s> :w<CR>
inoremap <D-s> <C-o>:w<CR>
nnoremap <D-w> :q<CR>
nnoremap <D-q> :qa<CR>
nnoremap <D-t> :tabe<CR>
nnoremap <D-S-T> :vs#<CR><C-w>T
nnoremap <D-a> ggVG
vnoremap <D-a> <ESC>ggVG
inoremap <D-a> <ESC>ggVG
nnoremap <D-f> /
nnoremap <D-g> n
nnoremap <D-S-G> N
vnoremap <D-x> "+x
endif
```
closes: vim/vim#1269892e90a1e10
Co-authored-by: Casey Tucker <dctucker@hotmail.com>
Problem: Currently default color scheme defines most of treesitter
highlight groups. This might be an issue for users defining their own
color scheme as it breaks the "fallback property" for some of groups.
Solution: Define less default treesitter groups; just enough for default
color scheme to be useful. That is:
- All first level groups (`@character`, `@string`, etc.).
- All `@xxx.builtin` groups as a most common subgroup.
- Some special cases (links/URLs, `@diff.xxx`, etc.).
Extmarks can contain URLs which can then be drawn in any supporting UI.
In the TUI, for example, URLs are "drawn" by emitting the OSC 8 control
sequence to the TTY. On terminals which support the OSC 8 sequence this
will create clickable hyperlinks.
URLs are treated as inline highlights in the decoration subsystem, so
are included in the `DecorSignHighlight` structure. However, unlike
other inline highlights they use allocated memory which must be freed,
so they set the `ext` flag in `DecorInline` so that their lifetimes are
managed along with other allocated memory like virtual text.
The decoration subsystem then adds the URLs as a new highlight
attribute. The highlight subsystem maintains a set of unique URLs to
avoid duplicating allocations for the same string. To attach a URL to an
existing highlight attribute we call `hl_add_url` which finds the URL in
the set (allocating and adding it if it does not exist) and sets the
`url` highlight attribute to the index of the URL in the set (using an
index helps keep the size of the `HlAttrs` struct small).
This has the potential to lead to an increase in highlight attributes
if a URL is used over a range that contains many different highlight
attributes, because now each existing attribute must be combined with
the URL. In practice, however, URLs typically span a range containing a
single highlight (e.g. link text in Markdown), so this is likely just a
pathological edge case.
When a new highlight attribute is defined with a URL it is copied to all
attached UIs with the `hl_attr_define` UI event. The TUI manages its own
set of URLs (just like the highlight subsystem) to minimize allocations.
The TUI keeps track of which URL is "active" for the cell it is
printing. If no URL is active and a cell containing a URL is printed,
the opening OSC 8 sequence is emitted and that URL becomes the actively
tracked URL. If the cursor is moved while in the middle of a URL span,
we emit the terminating OSC sequence to prevent the hyperlink from
spanning multiple lines.
This does not support nested hyperlinks, but that is a rare (and,
frankly, bizarre) use case. If a valid use case for nested hyperlinks
ever presents itself we can address that issue then.
runtime(netrw): Don't change global options (vim/vim#13910)
Originally reported at: https://github.com/vim-jp/issues/issues/1428
'isk' was unintentionally changed by netrw, regression
introduced in Commit: 71badf9547e8f89571b9a095183671cbb333d528
a262d3f41b
Co-authored-by: K.Takata <kentkt@csc.jp>
