Problem: defaults: 'diffopt' option value can be improved
Solution: Update diffopt defaults to include "indent-heuristic" and
"inline:char" (Yee Cheng Chin)
The default diff options have not been updated much despite new
functionality having been added to Vim.
- indent-heurstic: This has been enabled by default in Git since
33de716387 in 2017. Given that Vim uses xdiff from Git, it makes sense
to track the default configuration from Git.
- inline:char: This turns on character-wise inline highlighting which is
generally much better than the default inline:simple. It has been
implemented since vim/vim#16881 and we have not seen reports of any issues
with it, and it has received good feedbacks.
closes: vim/vim#18255976b365305
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
In Windows [/] should be escaped [\/]:
autocmd CmdlineChanged [:\/\?] call wildtrigger()
This updated example works both in Linux and Windows.
closes: vim/vim#182625a9ef93b2c
Co-authored-by: Maxim Kim <habamax@gmail.com>
Problem: completion: preinserted text highlighed using ComplMatchIns
Solution: Use highlighting group PreInsert and update the documentation
(Girish Palya).
When "preinsert" is included in 'completeopt', only the PreInsert
highlight group should be applied, whether autocompletion is active or not.
Previously, ComplMatchIns was used when autocompletion was not enabled.
Related to https://github.com/vim/vim/pull/18213.
closes: vim/vim#182542525c56e42
Co-authored-by: Girish Palya <girishji@gmail.com>
Problem: The rightleft and arabic features are disabled.
Solution: Re-enable the features, some users want to use the functionality.
ae906c8b1b
bug-reports -> bug-report
Co-authored-by: Bram Moolenaar <Bram@vim.org>
This partially reverts 0b8a72b739,
that is unreverts 15e77a56b7
"priority" is an internal neovim concept which does not occur in shared
queries. Ideally a single priority space should eventually be enough
for our needs. But as we don't want to poke at the usages of
priorities right now in the wider ecosystem,
introduce the "subpriorities" so that treesitter code can distinguish
highlights of the same priorities with different tree nesting depth.
This mainly affects `injection.combined` as parent-tree nodes might appear
in the middle of child-tree nodes which otherwise is not possible.
Continuing the work of #31400
That PR allowed the provider to be invoked multiple times per line.
We want only to do that when there actually is more data later on the
line. Additionally, we want to skip over lines which contain no new
highlight items. The TS query cursor already tells us what the next
position with more data is, so there is no need to reinvoke the range
callback before that.
NB: this removes the double buffering introduced in #32619 which
is funtamentally incompatible with this (nvim core is supposed to keep
track of long ranges by itself, without requiring a callback reinvoke
blitz). Need to adjust the priorities some other way to fix the same issue.
The ellipsis literal (`...`) can be used in multiple contexts:
- Placeholders: `class Foo: ...`
- Containers: `Tuple[int, ...]`
- Assignments: `x = ...`
This is a trickier pattern to match because we can't rely on keyword
boundaries, so we instead look for exactly three dots (`...`).
This does mean that we will match the `...` portion of `x...x`, which
isn't valid Python syntax, but I think that's an acceptable trade-off
that avoids making this pattern much more complex.
Reference:
- https://docs.python.org/3/library/constants.html#Ellipsiscloses: vim/vim#1810777cfc49060
Co-authored-by: Jon Parise <jon@indelible.org>
Problem: complete: preinsert does not work well with preinsert
Solution: Make "preinsert" completeopt value work with autocompletion
(Girish Palya)
This change extends Insert mode autocompletion so that 'preinsert' also
works when 'autocomplete' is enabled.
Try: `:set ac cot=preinsert`
See `:help 'cot'` for more details.
closes: vim/vim#18213fa6fd41a94
Co-authored-by: Girish Palya <girishji@gmail.com>
Problem:
These "foo.vim" syntax tags add 100+ useless tags to help. In
particular, "progress.vim" is the first match for "progress", which not
the result anyone is actually looking for, since Nvim 0.12 gained the
"progress-message" feature.
Solution:
Drop the "foo.vim" syntax tags. The "ft-foo" tags are more appropriately
named.
Problem: Some environment variables which are useful when working inside
a bare repository can affect any Git operation.
Solution: Explicitly unset problematic environment variables.
Problem:
There is no straightforward way to pretty-print objects as JSON.
The existing `vim.inspect` outputs LON.
Solution:
Introduce an `indent` option for `vim.json.encode()` which enables
human-readable output with configurable indentation.
Adapts PR to upstream: openresty/lua-cjson#114
Problem:
Force resolve `spec.version` overrides the information about whether
a user supplied `version` or not. Knowing it might be useful in some use
cases (like comparing to previously set `spec` to detect if it has
changed).
Solution:
Do not resolve `spec.version`. This also improves speed when triggering
events and calling `get()`.
- Place default branch first when listing all branches.
- Use correct terminology in `get_hash` helper.
- Do not return `{ '' }` if there are no tags.
Problem:
There is no way to get more information about installed plugins, like
current revision or default branch (necessary if resolving default
`spec.version` manually). As computing Git data migth take some time,
also allow `get()` to limit output to only necessary set of plugins.
Solution:
- introduce arguments to `get(names, opts)`, which follows other
`vim.pack` functions. Plugin extra info is returned by default and
should be opt-out via `opts.info = false`.
- Examples:
- Get current revision: `get({ 'plug-name' })[1].rev`
- Get default branch: `get({ 'plug_name' })[1].branches[1]`
- `update()` and `del()` act on plugins in the same order their names
are supplied. This is less surprising.
- default `opts.info` to `true` since this simplifies logic for the
common user, while still leaving the door open for a faster `get()` if
needed.
Problem: The document of nvim_buf_get_extmark currently lacks the
following:
- "details" directory: nvim_buf_get_extmarks() allows an option details
to get a "details" directory in result, but it doesn't mention where
that "details" directory is, what fields does it have.
Solution: Add docs for "details" directory in nvim_buf_get_extmarks()
Problem: Progress reports use plain `nvim_echo()` with manually
constructed messages and populate history on every call.
Solution: Use `nvim_echo()` with newly added `kind=progress` which (at
least for now) is meant to be a unified interface for showing progress
report. Also save in history only first and last progress report
messages.
Problem: filetype: .inc file detection can be improved
Solution: Update filetype detection for Pascal and BitBake code
(Martin Schwan).
Fix the detection of .inc files containing Pascal and BitBake code:
- the concatenated string, merged from three lines, only contains one
beginning and the pattern "^" would not match as expected. Use a range()
loop to iterate each line string individually. This way, the pattern "^"
works for beginning of lines.
- improve BitBake include file detection by also matching forward-slashes
"/" in variable names and assignment operators with a dot ".=" and "=.".
Valid examples, which should match, are:
PREFERRED_PROVIDER_virtual/kernel = "linux-yocto"
MACHINEOVERRIDES =. "qemuall:"
BBPATH .= ":${LAYERDIR}"
- parse twenty instead of just three lines, to accommodate for potential
comments at the beginning of files
closes: vim/vim#182029fd1a657d2
Co-authored-by: Martin Schwan <m.schwan@phytec.de>
- Problem: It's not clear for new plugin developers that `:help` uses
a help-tags file for searching the docs, generated by `:helptags`.
- Solution: Hint to the |:helptags| docs for regenerating the tags
file for their freshly written documentation.
Co-authored-by: Yochem van Rosmalen <git@yochem.nl>
Problem: filetype: vivado journal/log files are not recognized
Solution: Detect vivado*.{jou,log} as tcl filetype (Wu Zhenyu).
closes: vim/vim#181919a6cafdc1c
Also fix missing anchor in the pattern from the port of patch 9.1.1602.
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
This change does the following to the M4 syntax script:
- In M4 there are no "strings" in the usual sense. Instead, M4 has
quotes, but the text inside a quoted region is rescanned just like
outside, and quotes can be nested.
- The old m4String region was misleading and removed. A new m4Quoted
region reflects proper quoting semantics.
- Removed a duplicate highlight rule.
- Fixed a typo in a highlight group name (m4builtin → m4Builtin).
- Added a reference link to the POSIX M4 specification.
- Removed outdated maintainer URL.
closes: vim/vim#18192f165798184
Co-authored-by: Damien Lejay <damien@lejay.be>
Problem:
insert-mode ctrl-r input is treated like raw user input, which is almost
never useful. This means any newlines in the input are affected by
autoindent, etc., which is:
- slow
- usually breaks the formatting of the input
Solution:
- ctrl-r should be treated like a paste, not user-input.
- does not affect `<c-r>=`, so `<c-r>=@x` can still be used to get the
old behavior.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
No support is provided or planned for language recognition
in code snippets of documentation comments. Requesting to
load arbitrary syntax plugins with the aid of the concerned
variable is therefore wasteful in general and erroneous when
paired languages ":syn-include" one another without taking
steps to manage circularity.
related: vim/vim#17308
related: vim/vim#17220closes: vim/vim#1817271149dfec5
Co-authored-by: Aliaksei Budavei <0x000c70@gmail.com>
