Problem: Syntax foldlevel is taken from the start of the line.
Solution: Add ":syn foldlevel" to be able to use the minimal foldlevel in the line.
e35a52aee7
With `foldmethod=syntax` the foldlevel of a line is computed based
on syntax items on the line. Previously we always used the level
of the syntax item containing the start of the line. This works
well in cases such as:
if (...) {
...
}
else if (...) {
...
}
else {
...
}
which folds like this:
+--- 3 lines: if (...) {---------------------------
+--- 3 lines: else if (...) {----------------------
+--- 3 lines: else {-------------------------------
However, the code:
if (...) {
...
} else if (...) {
...
} else {
...
}
folds like this:
+--- 7 lines: if (...) {---------------------------
We can make the latter case fold like this:
+--- 2 lines: if (...) {---------------------------
+--- 2 lines: } else if (...) {--------------------
+--- 3 lines: } else {-----------------------------
by choosing on each line the lowest fold level that is followed
by a higher fold level.
Add a syntax command
:syntax foldlevel [start | minimum]
to choose between these two methods of computing the foldlevel of
a line.
The client creates buffers on the fly to be able to apply text edits on
files that weren't previously open, which is great, but it uses the
bufadd() function, which creates unlisted buffers and can lead to a
weird experience in the text editor. Setting the buffer to buflisted
fixes this.
Closes#12488.
Co-authored-by: francisco souza <fsouza@users.noreply.github.com>
In the case of recoverymode, the headlessmode was true, causing the UI
to hang without starting. Fix this problem by setting headlessmode to
true for List swap files only.
* eval: fix assertion failure in garbage collection
fixes#12387, #12430
Lists with CopyID+1 linked only from previous_funccal may be removed in
the garbage collection. Therefore, the terms of the assertions are not
correct. This can be confirmed by the following (The l:x with CopyID+1 of
the first function call needs to be removed by garbage collection):
func! s:f()
let l:x = [1]
let g:x = l:
endfunc
for _ in range(2)
call s:f()
endfor
call garbagecollect()
" press any key
* test: add test for #12387, #12430
Problem: Moving to next sentence gets stuck on quote.
Solution: When moving to the next sentence doesn't result in moving, advance
a character and try again. (closesvim/vim#6291)
2f03e5a0a9
Problem: Number increment/decrement does not work with 'virtualedit'.
Solution: Handle coladd changing. (Christian Brabandt, closesvim/vim#6240,
closesvim/vim#923)
6c6be9e88d
Problem: 'shortmess' flag "n" not used in two places.
Solution: Make use of the "n" flag consistent. (Nick Jensen, closesvim/vim#6245,
closesvim/vim#6244)
722e505d1a
* lsp: support custom hl groups in show_line_diagnostics
Closes#12472.
* runtime: add docs for the new lsp highlight groups
Co-authored-by: francisco souza <fsouza@users.noreply.github.com>
According to the LSP spec[1], multiple edits can have the same starting
position, and if that is the case, they should be applied in the order
as they come in the array.
The implementation uses a reverse sort to not interfere with non applied
edits, but failed to take into account the spec.
[1] https://microsoft.github.io/language-server-protocol/specifications/specification-3-14/#textedit
Not sure why this was added in 94f4469638
It doesn't seem to do anything and I can't reproduce the linked issue
with this patch so I think it's all working now.
cc @justinmk
Also, kudos to @zsugabubus for fixing a related issue in #12417
This also prevents any sorting of the paths from man. We need to
respect the order we get from it otherwise you end up loading
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX.sdk/usr/share/man/man1/ls.1
on MacOS instead of /usr/share/man/man1/ls.1
Also cleaned it up a little and made it faster.
Closes#9159 and #9271
Also changes man#extract_sect_and_name_ref to only return a single
section at a time. This fixes a bug in its usage in man#goto_tag
where get_paths would be called with multiple sections and it does
not support that.
I noticed that our tagfunc doesn't obey b:man_default_sects and
I'll fix that next.
