This reverts commit 4382d2ed56.
The story for this feature was left in an incomplete state. It was never
the intention to unilaterally fold all information, only the ones that
did not contain relevant information. This feature does more harm than
good in its incomplete state.
Problem: filetype: some history files are not recognized
Solution: Add some history patterns to filetype.vim
(Wu, Zhenyu)
closes: vim/vim#14513da70feabea
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: xilinx files are not recognized
Solution: Add a few xilinx specific file patterns,
inspect lpr files for being xml/pascal
(Wu, Zhenyu)
closes: vim/vim#14454614691ceef
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
Problem: filetype: some TeX files are not recognized
Solution: Add more patterns for TeX files and inspect
a few more files for being TeX files
(Wu, Zhenyu)
closes: vim/vim#1445661ee833a50
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
runtime(compiler): fix inaccuracies in pandoc compiler (vim/vim#14467)
as kindly pointed out by @Freed-Wu
6ce07edd60
Co-authored-by: Enno <Konfekt@users.noreply.github.com>
runtime(vim): Improve Vim9 and legacy-script comment highlighting (vim/vim#13104)
This is a first-pass attempt to limit matching of Vim9 and legacy-script
comments to the appropriate syntactic contexts.
Vim9-script comments are highlighted at top level in a Vim9-script file,
in all :def functions, and in all :autocmd and :commmand command blocks.
Legacy-script comments are highlighted at top level in a legacy script
file, in all :func functions and in the Vim9-script preamble before the
:vim9script marker command.
Fixesvim/vim#13047, vim/vim#11307 and vim/vim#9587.
04e5363b82
Co-authored-by: dkearns <dougkearns@gmail.com>
Problem: Patch 9.1.0296 causes too many issues
(Tony Mechelynck, chdiza, CI)
Solution: Back out the change for now
Revert "patch 9.1.0296: regexp: engines do not handle case-folding well"
This reverts commit 7a27c108e0509f3255ebdcb6558e896c223e4d23 it causes
issues with syntax highlighting and breaks the FreeBSD and MacOS CI. It
needs more work.
fixes: vim/vim#14487c97f4d61cd
Co-authored-by: Christian Brabandt <cb@256bit.org>
To avoid repeatedly requesting a buffer multiple times before a request is completed, the current implementation puts the requested buffer into the active_refreshes table before requesting.
But since we only remove the buffer from active_refreshes in the lsp-handler of textDocument/codeLens, this will cause if the user sends a request that cannot trigger lsp-handler (for example, if there is an LSP server attached to the current buffer, and especially when the user creates an autocmd which performs vim.lsp.codelens.refresh after the BufEnter event is triggered like in the document example), this buffer will be put into active_refreshes, and there is no way to remove it, which will result in all subsequent vim.lsp.codelens.refresh not requesting textDocument/codeLens.
According to the LSP specification, the CodeLens.command is optional but the CodeLens.command.command is not optional, which means the correct representation of a display-only code lens is indeed one with a command with a title to display and an empty string as command.
Problem: Regex engines do not handle case-folding well
Solution: Correctly calculate byte length of characters to skip
When the regexp engine compares two utf-8 codepoints case insensitively
it may match an adjacent character, because it assumes it can step over
as many bytes as the pattern contains.
This however is not necessarily true because of case-folding, a
multi-byte UTF-8 character can be considered equal to some single-byte
value.
Let's consider the pattern 'ſ' and the string 's'. When comparing and
ignoring case, the single character 's' matches, and since it matches
Vim will try to step over the match (by the amount of bytes of the
pattern), assuming that since it matches, the length of both strings is
the same.
However in that case, it should only step over the single byte
value 's' so by 1 byte and try to start matching after it again. So for the
backtracking engine we need to ensure:
- we try to match the correct length for the pattern and the text
- in case of a match, we step over it correctly
The same thing can happen for the NFA engine, when skipping to the next
character to test for a match. We are skipping over the regstart
pointer, however we do not consider the case that because of
case-folding we may need to adjust the number of bytes to skip over. So
this needs to be adjusted in find_match_text() as well.
A related issue turned out, when prog->match_text is actually empty. In
that case we should try to find the next match and skip this condition.
fixes: vim/vim#14294closes: vim/vim#144337a27c108e0
Co-authored-by: Christian Brabandt <cb@256bit.org>
runtime(vim): Update base-syntax, no curly-brace names in Vim9 script (vim/vim#14466)
Remove curly-brace name matching for :def functions. This is not
supported in Vim9 script.
e43ace558a
Co-authored-by: dkearns <dougkearns@gmail.com>
Problem: Wrong doc style for pandoc syntax description,
Test_diff_eob_halfpage() may fail depending on
screen size, using braces in highlight.c when
not necessary
Solution: Fix pandoc documentation, make sure the window
for the test has 7 lines, remove the braces.
a040019be6
Co-authored-by: Christian Brabandt <cb@256bit.org>
Problem: filetype: R history files are not recognized
Solution: Detect '.Rhistory' files as r filetype
(Wu, Zhenyu)
closes: vim/vim#14440fc21b6437c
Co-authored-by: Wu, Zhenyu <wuzhenyu@ustc.edu>
runtime(doc): Normalise builtin-function optional parameter formatting
These should generally be formatted as func([{arg}]) and referenced as
{arg} in the description.
closes: vim/vim#144389cd9e759ab
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
This actually won't cause "duplicate tag" errors if plugins have tags of
the same name, because E154 is only given for duplicate tags in the same
directory.
Without those tags, trying to use :h for these mappings jumps to other
places, because there are matches with higher score.
runtime: fix :compiler leaving behind a g:makeprg variable (vim/vim#14414)
Problem: :compiler may leave behind a g:makeprg variable after vim/vim#14336.
Solution: Use a script local variable.
b73faa1c02
Also apply previously omitted change to compiler/context.vim.
Design
- Enable commenting support only through `gc` mappings for simplicity.
No ability to configure, no Lua module, no user commands. Yet.
- Overall implementation is a simplified version of 'mini.comment'
module of 'echasnovski/mini.nvim' adapted to be a better suit for
core. It basically means reducing code paths which use only specific
fixed set of plugin config.
All used options are default except `pad_comment_parts = false`. This
means that 'commentstring' option is used as is without forcing single
space inner padding.
As 'tpope/vim-commentary' was considered for inclusion earlier, here is
a quick summary of how this commit differs from it:
- **User-facing features**. Both implement similar user-facing mappings.
This commit does not include `gcu` which is essentially a `gcgc`.
There are no commands, events, or configuration in this commit.
- **Size**. Both have reasonably comparable number of lines of code,
while this commit has more comments in tricky areas.
- **Maintainability**. This commit has (purely subjectively) better
readability, tests, and Lua types.
- **Configurability**. This commit has no user configuration, while
'vim-commentary' has some (partially as a counter-measure to possibly
modifying 'commentstring' option).
- **Extra features**:
- This commit supports tree-sitter by computing `'commentstring'`
option under cursor, which can matter in presence of tree-sitter
injected languages.
- This commit comments blank lines while 'tpope/vim-commentary' does
not. At the same time, blank lines are not taken into account when
deciding the toggle action.
- This commit has much better speed on larger chunks of lines (like
above 1000). This is thanks to using `nvim_buf_set_lines()` to set
all new lines at once, and not with `vim.fn.setline()`.
runtime: Remove fallback :CompilerSet definition from compiler plugins
The :CompilerSet command was added in version Vim 6.4 which was released
twenty years ago. Other runtime files do not support versions of that
vintage so it is reasonable to remove this fallback command definition
now.
closes: vim/vim#14399408281e16a
Co-authored-by: Doug Kearns <dougkearns@gmail.com>
