| Commit message (Collapse) | Author | Age |
| |
|
|
|
|
|
|
| |
Problem:
As checkhealth grows, it is increasingly hard to quickly glance through
the information.
Solution:
Show a summary of ok, warn, and error outputs per section.
|
| |
|
|
|
|
|
|
|
|
| |
Problem: Using wrong window in ll_resize_stack()
(after v9.1.1287)
Solution: Use "wp" instead of "curwin", even though they are always the
same value. Fix typos in documentation (zeertzjq).
closes: vim/vim#17080
https://github.com/vim/vim/commit/b71f1309a210bf8f61a24f4eda336de64c6f0a07
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: quickfix and location-list stack is limited to 10 items
Solution: add the 'chistory' and 'lhistory' options to configure a
larger quickfix/location list stack
(64-bitman)
closes: vim/vim#16920
https://github.com/vim/vim/commit/88d41ab270a8390a43da97a903b1a4d76b89d330
Co-authored-by: 64-bitman <60551350+64-bitman@users.noreply.github.com>
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
|
| |
|
|
|
|
|
|
| |
Problem:
`client_is_stopped(…)` is an alias for `not get_client_by_id(…)`.
And it's not used anywhere in our codebase.
Solution:
Deprecate it.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
(#33323)
Problem: inline word diff treats multibyte chars as word char
(after 9.1.1243)
Solution: treat all non-alphanumeric characters as non-word characters
(Yee Cheng Chin)
Previously inline word diff simply used Vim's definition of keyword to
determine what is a word, which leads to multi-byte character classes
such as emojis and CJK (Chinese/Japanese/Korean) characters all
classifying as word characters, leading to entire sentences being
grouped as a single word which does not provide meaningful information
in a diff highlight.
Fix this by treating all non-alphanumeric characters (with class number
above 2) as non-word characters, as there is usually no benefit in using
word diff on them. These include CJK characters, emojis, and also
subscript/superscript numbers. Meanwhile, multi-byte characters like
Cyrillic and Greek letters will still continue to considered as words.
Note that this is slightly inconsistent with how words are defined
elsewhere, as Vim usually considers any character with class >=2 to be
a "word".
related: vim/vim#16881 (diff inline highlight)
closes: vim/vim#17050
https://github.com/vim/vim/commit/9aa120f7ada592ed03b37f4de8ee413c5385f123
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
|
| |
|
|
|
|
|
| |
closes: vim/vim#17036
https://github.com/vim/vim/commit/b8d5c8509998f3a97ffe42f674352b07749cd119
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
| |
It's not used anywhere.
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
First rtp directory is unpredictable and not in line with XDG
base spec.
Solution:
Use stdpath('data')/spell as directory if 'spellfile' is not set.
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
| |
|
|
|
|
|
| |
Problem: `severity` field is recognized by
`vim.diagnostic.Opts.VirtualLines`, but it is not explicitly
documented.
Solution: document it.
|
| |
|
|
|
|
|
|
|
| |
Problem: Currently vim.hl.range only allows one timed highlight.
Creating another one, removes the old one.
Solution: vim.hl.range now returns a timer and a function. The timer
keeps track of how much time is left in the highlight and the function
allows you to clear it, letting the user decide what to do with old
highlights.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
This commits adds the extension *.whl to the list of zip extensions.
Wheel (WHL) files are binary distribution files for python packages.
Reference:
https://packaging.python.org/en/latest/specifications/binary-distribution-format/
fixes: vim/vim#17038
https://github.com/vim/vim/commit/a359c9c25e5c3c1e543fc720223aa7256e6f72cf
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
| |
file extensions
closes: vim/vim#17037
https://github.com/vim/vim/commit/8293574c8b116382ed6e0c3c709a04406f07cfd5
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
| |
Match maparg's return type.
|
| |
|
|
|
|
|
| |
These occurrences also accept string, which is used like in getline.
Also make the lnum field of vim.fn.sign_placelist.list.item optional, as it can
be omitted like vim.fn.sign_place.dict's.
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
| |
Problem:
Upon receiving a deadly signal, Nvim doesn't write buffers even if
the option 'autowriteall' is set.
Solution:
Write to all writable buffers upon SIGHUP or SIGQUIT (but not
SIGTERM), if the option 'autowriteall' is set.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
| |
|
| |
fix #33075
|
| |
|
|
|
|
|
|
|
|
| |
Problem:
Some language servers do not work properly without a workspace folder.
Solution:
Add `workspace_required`, which skips starting the lsp client if no
workspace folder is found.
Co-authored-by: Justin M. Keyes <justinkz@gmail.com>
|
| | |
|
| |
|
|
|
|
| |
Problem:
- `health#check()` seems to have been removed for a while, but `:h faq`
still refers to it.
- `news-0.11.txt` doesn't mention #33044
|
| |\
| |
| | |
vim-patch:9.1.{1250,1255,1257}: 'pummaxwidth'
|
| | |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| |
| | |
Problem: cannot set the maximum popup menu width
(Lucas Mior)
Solution: add the new global option value 'pummaxwidth'
(glepnir)
fixes: vim/vim#10901
closes: vim/vim#16943
https://github.com/vim/vim/commit/88d75934c3d5bc4c406343f106e1a61638abd3a7
Co-authored-by: glepnir <glephunter@gmail.com>
|
| |/
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
- "Demote" SecurityManager from the list of java.lang class
types to javaLangDeprecated.
- Reintroduce supported syntax-preview-feature numbers 455
and 476 as _new numbers_ 488 and 494, respectively.
References:
- https://openjdk.org/jeps/486 (Permanently Disable the Security Manager)
- https://openjdk.org/jeps/488 (Primitive Types in Patterns etc.)
- https://openjdk.org/jeps/494 (Module Import Declarations)
closes: vim/vim#16977
https://github.com/vim/vim/commit/1054b18291ce611932bc949b22b87b78f1975ca9
Co-authored-by: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: regexp: max \U and \%U value is limited by INT_MAX but gives a
confusing error message (related: v8.1.0985).
Solution: give a better error message when the value reaches INT_MAX
When searching Vim allows to get up to 8 hex characters using the /\V
and /\%V regex atoms. However, when using "/\UFFFFFFFF" the code point is
already above what an integer variable can hold, which is 2,147,483,647.
Since patch v8.1.0985, Vim already limited the max codepoint to INT_MAX
(otherwise it caused a crash in the nfa regex engine), but instead of
error'ing out it silently fell back to parse the number as a backslash
value and not as a codepoint value and as such this "/[\UFFFFFFFF]" will
happily find a "\" or an literal "F". And this "/[\d127-\UFFFFFFFF]"
will error out as "reverse range in character class).
Interestingly, the max Unicode codepoint value is U+10FFFF which still
fits into an ordinary integer value, which means, that we don't even
need to parse 8 hex characters, but 6 should have been enough.
However, let's not limit Vim to search for only max 6 hex characters
(which would be a backward incompatible change), but instead allow all 8
characters and only if the codepoint reaches INT_MAX, give a more
precise error message (about what the max unicode codepoint value is).
This allows to search for "[\U7FFFFFFE]" (will likely return "E486
Pattern not found") and "[/\U7FFFFFF]" now errors "E1517: Value too
large, max Unicode codepoint is U+10FFFF".
While this change is straight forward on architectures where long is 8
bytes, this is not so simple on Windows or 32bit architectures where long
is 4 bytes (and therefore the test fails there). To account for that,
let's make use of the vimlong_T number type and make a few corresponding
changes in the regex engine code and cast the value to the expected data
type. This however may not work correctly on systems that doesn't have
the long long datatype (e.g. OpenVMS) and probably the test will fail
there.
fixes: vim/vim#16949
closes: vim/vim#16994
https://github.com/vim/vim/commit/f2b16986a194ab839c5a23bd7fe904f9fae1526f
Co-authored-by: Christian Brabandt <cb@256bit.org>
|
| |
|
|
|
|
|
|
|
|
|
|
| |
(#33143)
Problem: Typos in code and docs related to 'diffopt' "inline:".
(after v9.1.1243)
Solution: Fix typos and slightly improve the docs.
(zeertzjq)
closes: vim/vim#16997
https://github.com/vim/vim/commit/5a307c361cbe9f7ac438a917b905378d87f8f2de
|
| |
|
|
|
|
| |
Problem: #33022 didn't update `min_version` to 3.9, therefore Python 3.7
and 3.8 are still available.
Solution: Update `min_version` to 3.9.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Diff mode's inline highlighting is lackluster. It only
performs a line-by-line comparison, and calculates a single
shortest range within a line that could encompass all the
changes. In lines with multiple changes, or those that span
multiple lines, this approach tends to end up highlighting
much more than necessary.
Solution: Implement new inline highlighting modes by doing per-character
or per-word diff within the diff block, and highlight only the
relevant parts, add "inline:simple" to the defaults (which is
the old behaviour)
This change introduces a new diffopt option "inline:<type>". Setting to
"none" will disable all inline highlighting, "simple" (the default) will
use the old behavior, "char" / "word" will perform a character/word-wise
diff of the texts within each diff block and only highlight the
differences.
The new char/word inline diff only use the internal xdiff, and will
respect diff options such as algorithm choice, icase, and misc iwhite
options. indent-heuristics is always on to perform better sliding.
For character highlight, a post-process of the diff results is first
applied before we show the highlight. This is because a naive diff will
create a result with a lot of small diff chunks and gaps, due to the
repetitive nature of individual characters. The post-process is a
heuristic-based refinement that attempts to merge adjacent diff blocks
if they are separated by a short gap (1-3 characters), and can be
further tuned in the future for better results. This process results in
more characters than necessary being highlighted but overall less visual
noise.
For word highlight, always use first buffer's iskeyword definition.
Otherwise if each buffer has different iskeyword settings we would not
be able to group words properly.
The char/word diffing is always per-diff block, not per line, meaning
that changes that span multiple lines will show up correctly.
Added/removed newlines are not shown by default, but if the user has
'list' set (with "eol" listchar defined), the eol character will be be
highlighted correctly for the specific newline characters.
Also, add a new "DiffTextAdd" highlight group linked to "DiffText" by
default. It allows color schemes to use different colors for texts that
have been added within a line versus modified.
This doesn't interact with linematch perfectly currently. The linematch
feature splits up diff blocks into multiple smaller blocks for better
visual matching, which makes inline highlight less useful especially for
multi-line change (e.g. a line is broken into two lines). This could be
addressed in the future.
As a side change, this also removes the bounds checking introduced to
diff_read() as they were added to mask existing logic bugs that were
properly fixed in vim/vim#16768.
closes: vim/vim#16881
https://github.com/vim/vim/commit/9943d4790e42721a6777da9e12637aa595ba4965
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
|
| | |
|
| |
|
|
|
|
|
|
|
|
| |
Also, do not set g:is_kornshell when g:is_posix is set. BSD shells are
POSIX but many are derived from the ash shell.
closes: vim/vim#16939
https://github.com/vim/vim/commit/51a06ecee06096672b2f10fc6cd76bd8f6dfe8c9
Co-authored-by: Mohamed Akram <mohd.akram@outlook.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: cannot :put while keeping indent (Peter Aronoff)
Solution: add the :iput ex command (64-bitman)
fixes: vim/vim#16225
closes: vim/vim#16886
https://github.com/vim/vim/commit/e08f10a55c3f15b0b4af631908551d88ec4fe502
Cherry-pick test_put.vim changes from patch 8.2.1593.
N/A patches:
vim-patch:9.1.1213: cannot :put while keeping indent
vim-patch:9.1.1215: Patch 9.1.1213 has some issues
Co-authored-by: 64-bitman <60551350+64-bitman@users.noreply.github.com>
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: Strange error with type for matchfuzzy() "camelcase".
Solution: Show the error "Invalid value for argument camelcase" instead
of "Invalid argument: camelcase" (zeertzjq).
Note that using tv_get_string() will lead to confusion, as when the
value cannot be converted to a string tv_get_string() will also give an
error about that, but "camelcase" takes a boolean, not a string. Also
don't use tv_get_string() for the "limit" argument above.
closes: vim/vim#16926
https://github.com/vim/vim/commit/c4815c157b27923001e44bfd241fb540bf1fb518
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: When searching for "Cur", CamelCase matches like "lCursor" score
higher than exact prefix matches like Cursor, which is
counter-intuitive (Maxim Kim).
Solution: Add a 'camelcase' option to matchfuzzy() that lets users disable
CamelCase bonuses when needed, making prefix matches rank higher.
(glepnir)
fixes: vim/vim#16504
closes: vim/vim#16797
https://github.com/vim/vim/commit/28e40a7b55ce471656cccc2260c11a29d5da447e
Co-authored-by: glepnir <glephunter@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: 'completefuzzycollect' does not handle dictionary correctly
Solution: check for ctrl_x_mode_dictionary (glepnir)
closes: vim/vim#16867
https://github.com/vim/vim/commit/587601671cd06ddc4d78f907d98578cdab96003f
Cherry-pick a documentation fix from later.
Co-authored-by: glepnir <glephunter@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
| |
- Fix grammar
- Use "matches" instead of "items" ("completion candidates" is used in
some other places, but it's a bit verbose)
- "When set" is a bit vague, instead use "For specified modes"
closes: vim/vim#16871
https://github.com/vim/vim/commit/1dc731a49ff5d06ead4b506afa04288a5baafc1a
|
| |
|
|
|
|
|
|
|
|
|
|
| |
Problem: process_next_cpt_value() uses wrong condition
Solution: use cfc_has_mode() instead and remove redundant else if branch
(glepnir)
closes: vim/vim#16833
https://github.com/vim/vim/commit/53b14578e03f93a53fd6eb21c00caf96484742ed
Co-authored-by: glepnir <glephunter@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
| |
Problem: No cmdline completion for the 'completefuzzycollect' option
(after v9.1.1178)
Solution: Add cmdline completion for the 'completefuzzycollect' option,
improve its description in optwin.vim (zeertzjq).
closes: vim/vim#16813
https://github.com/vim/vim/commit/53d59ecc1d93ce3a3f6d0182479d825852018ceb
No code change is needed in Nvim as Nvim uses expand_set_str_generic()
by default.
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fuzzy matching
Problem: not possible to generate completion candidates using fuzzy
matching
Solution: add the 'completefuzzycollect' option for (some) ins-completion
modes (glepnir)
fixes vim/vim#15296
fixes vim/vim#15295
fixes vim/vim#15294
closes: vim/vim#16032
https://github.com/vim/vim/commit/f31cfa29bf72b0cdf6fa1b60346ea4e187bcafd1
Co-authored-by: glepnir <glephunter@gmail.com>
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
| |
fuzzy documentation
Originally, `:set completeopt+=fuzzy` did not affect how the candidate
list is collected in default keyword completion. A comment was added to
documentation as part of vim/vim#14912 to clarify it. vim/vim#15193 later changed the
fuzzy behavior to now change the candidate collection behavior as well
so the clarification in docs is now wrong. Remove them here.
closes: vim/vim#15656
https://github.com/vim/vim/commit/26e4b000025ea0e25ea7877314d9095737431bae
Co-authored-by: Yee Cheng Chin <ychin.git@gmail.com>
|
| | |
|
| | |
|
| |
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
< |