• R/O
  • SSH

vim: Liste der Commits

Mirror of the Vim source from https://github.com/vim/vim


RSS
Rev. Zeit Autor
0dbb6f014f5e 2024-03-13 05:15:04 Christian Brabandt

Added tag v9.1.0171 for changeset c865c2f93a0460575ed3b3246bebc4c8f7ddc2c7

c865c2f93a04 v9.1.0171 2024-03-13 05:15:03 Christian Brabandt

patch 9.1.0171: Small split-move related improvements

Commit: https://github.com/vim/vim/commit/5cac1a9bee0798d70a7fd80363a1f697759638e8
Author: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Date: Tue Mar 12 21:11:39 2024 +0100

patch 9.1.0171: Small split-move related improvements

Problem: small improvements can be made to split-move related
functions.
Solution: apply them (Sean Dewar):

- Improve some doc comments (frame_flatten should still work for non-current
tabpages, despite the topframe check, which looks benign, though I'm unsure if
it's still needed; see #2467).

- f_win_splitmove should check_split_disallowed on wp, not targetwin, as that's
what win_splitmove checks (though it's probably unnecessary to check
b_locked_split at all; see #14109, which I hope to get around to finishing at
some point).

- Make winframe_restore restore window positions for the altframe, which
winframe_remove changes. This doesn't affect the prior behaviour, as we called
win_comp_pos after, but as win_comp_pos only works for curtab, and
winframe_remove supports non-current tabpages, we should undo it. Regardless,
this should mean we don't need win_comp_pos anymore; adjust tests to check
that window positions remain unchanged.

I'm not sure win_comp_pos is needed after last_status anyway if it doesn't
steal rows from another frame to make room for a new statusline, which
shouldn't be the case after winframe_remove? To be safe, I'll leave it as is.

closes: #14185

Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

6e23d69b728e 2024-03-13 05:00:12 Christian Brabandt

Added tag v9.1.0170 for changeset ad6cd802579db1596e03bc1081deb5f33fc8c994

ad6cd802579d v9.1.0170 2024-03-13 05:00:11 Christian Brabandt

patch 9.1.0170: Re-allow curwin == prevwin, but document it instead

Commit: https://github.com/vim/vim/commit/d64801e913314d2e19dbb38f60e6d285238debff
Author: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Date: Tue Mar 12 20:46:12 2024 +0100

patch 9.1.0170: Re-allow curwin == prevwin, but document it instead

Problem: more places exist where curwin == prevwin, and it may even be
expected in some cases.
Solution: revert v9.1.0001, but document that it's possible instead.
(Sean Dewar)

I've had a change of heart for the following reasons:

- A quick 'n dirty [GitHub code
search](https://github.com/search?q=%2F%28winnr%5C%28%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%7Cwinnr%5C%28%5B%27%22%5D%23%5B%27%22%5D%5C%29%5Cs*%3D%3D%5Cs*winnr%5C%28%5C%29%29%2F&type=code)
reveals some cases where it's expected in the wild.

Particularly, it made me aware `winnr() == winnr('#')` is possible when curwin
is changed temporarily during the evaluation of a &statusline expression item
(`%{...}`), and is used to show something different on the statusline
belonging to the previous window; that behaviour wasn't changed in v9.1.0001,
but it means curwin == prevwin makes sense in some cases.

- The definition and call sites of back_to_prevwin imply some expectation that
prevwin == wp (== curwin) is possible, as it's used to skip entering the
prevwin in that case.

- Prior to v9.1.0001, `:wincmd p` would not beep in the case that was patched in
v9.1.0001, but now does. That resulted in #14047 being opened, as it affected
the CtrlP plugin.

I find it odd that `:wincmd p` had cases where it wouldn't beep despite doing
nothing, but it may be preferable to keep things that way (or instead also
beep if curwin == prevwin, if that's preferred).

- After more digging, I found cases in win_free_mem, enter_tabpage,
aucmd_restbuf and qf_open_new_cwindow where curwin == prevwin is possible
(many of them from autocommands). Others probably exist too, especially in
places where curwin is changed temporarily.

fixes: #14047
closes: #14186

Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

5943a634833e 2024-03-13 05:00:10 Christian Brabandt

Added tag v9.1.0169 for changeset 239e20a09999be6ac03b97b3ddeb48a3f104b550

239e20a09999 v9.1.0169 2024-03-13 05:00:09 Christian Brabandt

patch 9.1.0169: current window number returned by tabpagewinnr may be outdated

Commit: https://github.com/vim/vim/commit/e101028a5c896480c61fef7ea16855255925709b
Author: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Date: Tue Mar 12 20:42:25 2024 +0100

patch 9.1.0169: current window number returned by tabpagewinnr may be outdated

Problem: current window number returned by tabpagewinnr may be outdated
when called from win_execute for the original tabpage.
Solution: update the original tabpage's tp_curwin in switch_win; use
{un}use_tabpage instead. Don't do it in restore_win to ensure
tp_curwin of the temporarily visited tabpage is unchanged from
switch_win visiting it, as before. (Sean Dewar)

Maybe restore_win should only restore tp_curwin if
`curtab == switchwin->sw_curtab`, in case the user changed tabpages from within
win_execute, but not doing that is consistent with the old behaviour.

related: #14186

Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

c742498564fa 2024-03-12 06:15:04 Christian Brabandt

Added tag v9.1.0168 for changeset 64edf95a833a82a714b1eb43d0550067c83db76b

64edf95a833a v9.1.0168 2024-03-12 06:15:03 Christian Brabandt

patch 9.1.0168: too many STRLEN() calls

Commit: https://github.com/vim/vim/commit/bfcc895482c717c9f6d86890d789ec739c3016b4
Author: John Marriott <basilisk@internode.on.net>
Date: Mon Mar 11 22:04:45 2024 +0100

patch 9.1.0168: too many STRLEN() calls

Problem: too many STRLEN() calls
Solution: Make use of ml_get_len() calls instead
(John Marriott)

closes: #14123

Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>

0591aba1489d 2024-03-12 05:45:06 Christian Brabandt

runtime(vim): Update base-syntax, improve number matching (#14175)

Commit: https://github.com/vim/vim/commit/5cd86c6cff94256ed2db872c46b57da259a648ac
Author: dkearns <dougkearns@gmail.com>
Date: Tue Mar 12 07:40:58 2024 +1100

runtime(vim): Update base-syntax, improve number matching (https://github.com/vim/vim/issues/14175)

- Limit blob literals to an even number of hexadecimal digits and
correctly located dots.
- Match octal numbers.

The current version unsuccessfully attempts to match a leading '-' as
part of the float literal. It's actually parsed as part of the literal
for all numbers but the syntax file hasn't matched it like that for a
long time and highlights negative numbers as UNARY-MINUS NUMBER. This
will be fixed when better expression matching is implemented.


Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

ef8394eca183 2024-03-12 05:45:06 Christian Brabandt

Added tag v9.1.0167 for changeset 2ee041017eb4c04eede9758f2fc2729fb66678e9

2ee041017eb4 v9.1.0167 2024-03-12 05:45:05 Christian Brabandt

patch 9.1.0167: Changing buffer in another window causes it to show matchparen

Commit: https://github.com/vim/vim/commit/49ffb6b428e1e053446ec0209558a8f9d0963ae7
Author: zeertzjq <zeertzjq@outlook.com>
Date: Mon Mar 11 21:38:58 2024 +0100

patch 9.1.0167: Changing buffer in another window causes it to show matchparen

Problem: Changing buffer in another window using win_execute() causes
it to show matchparen (after 9.0.0969).
Solution: Delay highlighting with SafeState in BufWinEnter.
(zeertzjq)

closes: #14177

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

d9b1fde16a62 2024-03-12 05:45:04 Christian Brabandt

Added tag v9.1.0166 for changeset c770ad7ac4abd12fccc9745f7548aad49dfa79b8

c770ad7ac4ab v9.1.0166 2024-03-12 05:45:03 Christian Brabandt

patch 9.1.0166: Internal error with blockwise getregion() in another buffer

Commit: https://github.com/vim/vim/commit/5406eb8722bddb6a04876956f9a53c1752994851
Author: zeertzjq <zeertzjq@outlook.com>
Date: Mon Mar 11 21:36:42 2024 +0100

patch 9.1.0166: Internal error with blockwise getregion() in another buffer

Problem: Internal error with blockwise getregion() in another buffer
Solution: Also change curwin->w_buffer when changing curbuf (zeertzjq)

closes: #14179

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

98de080760c6 2024-03-12 00:30:03 Christian Brabandt

translation(lt): Update Lithuanian translation of Vim tutor to v.1.7 (#14176)

Commit: https://github.com/vim/vim/commit/cb942cc4cac7accb4aa01445e6d1e84e098d55a4
Author: Rimas Kudelis <rimas@kudelis.lt>
Date: Mon Mar 11 17:15:04 2024 +0200

translation(lt): Update Lithuanian translation of Vim tutor to v.1.7 (https://github.com/vim/vim/issues/14176)

Signed-off-by: Rimas Kudelis <rimas@kudelis.lt>
Signed-off-by: Christian Brabandt <cb@256bit.org>

4c1ae10c4cc9 2024-03-12 00:15:06 Christian Brabandt

runtime(doc): improve 'winfixbuf' docs (#14180)

Commit: https://github.com/vim/vim/commit/0049a495c8d4a597773587f622d8cc8573c2eb75
Author: zeertzjq <zeertzjq@outlook.com>
Date: Mon Mar 11 23:13:16 2024 +0800

runtime(doc): improve 'winfixbuf' docs (https://github.com/vim/vim/issues/14180)

- Make it not sound like a buffer option.
- "!" is called a modifier, not an option.

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

caf019e67e93 2024-03-11 03:45:03 Christian Brabandt

runtime(doc): Update Markdown syntax, add missing configs

Commit: https://github.com/vim/vim/commit/675cbfb47f03c65b2a5c245b632bdd7a0bf10e4f
Author: Christian Brabandt <cb@256bit.org>
Date: Sun Mar 10 19:32:55 2024 +0100

runtime(doc): Update Markdown syntax, add missing configs

fixes: https://github.com/vim/vim/issues/14168

Signed-off-by: Christian Brabandt <cb@256bit.org>

28465f94adbf 2024-03-11 03:30:04 Christian Brabandt

Added tag v9.1.0165 for changeset a089397c9bc63ef3fc198566fa76f19e074d5637

a089397c9bc6 v9.1.0165 2024-03-11 03:30:03 Christian Brabandt

patch 9.1.0165: Vim9: Importing an autoload imported script fails

Commit: https://github.com/vim/vim/commit/fa6300872732f80b770a768e785ae2b189d3e684
Author: Yegappan Lakshmanan <yegappan@yahoo.com>
Date: Sun Mar 10 19:22:38 2024 +0100

patch 9.1.0165: Vim9: Importing an autoload imported script fails

Problem: Vim9: Importing an autoload imported script fails
(Song-Tianxiang)
Solution: Return the script ID in this case
(Yegappan Lakshmanan)

fixes: #14171
closes: #14174

Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

95a648080001 2024-03-11 00:00:03 Christian Brabandt

Added tag v9.1.0164 for changeset f9a0bf1e7505bf2cd927c6d2a96d3c78a97b80c5

f9a0bf1e7505 v9.1.0164 2024-03-11 00:00:02 Christian Brabandt

patch 9.1.0164: Internal error when passing invalid position to getregion()

Commit: https://github.com/vim/vim/commit/26dd09ad5e86f4e2179be0181421bfab9a6b3b75
Author: zeertzjq <zeertzjq@outlook.com>
Date: Sun Mar 10 15:46:58 2024 +0100

patch 9.1.0164: Internal error when passing invalid position to getregion()

Problem: Internal error or crash when passing invalid position to
getregion().
Solution: Give an error for invalid position (zeertzjq).

closes: #14172

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

ceab7bedffcc 2024-03-10 17:00:11 Christian Brabandt

Added tag v9.1.0163 for changeset 80991201ed38c0f05c94cdc1e6fb1ad5e59ce0c5

80991201ed38 v9.1.0163 2024-03-10 17:00:08 Christian Brabandt

patch 9.1.0163: Calling STRLEN() to compute ml_line_textlen when not needed

Commit: https://github.com/vim/vim/commit/82e079df814f7372e9579450730062b205449efa
Author: zeertzjq <zeertzjq@outlook.com>
Date: Sun Mar 10 08:55:42 2024 +0100

patch 9.1.0163: Calling STRLEN() to compute ml_line_textlen when not needed

Problem: Calling STRLEN() to compute ml_line_textlen when not needed.
Solution: Use 0 when STRLEN() will be required and call STRLEN() later.
(zeertzjq)

closes: #14155

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

6358e85e21e3 2024-03-10 17:00:08 Christian Brabandt

Added tag v9.1.0162 for changeset fc2c34371f5ce4df7170980af22749c71de46bd2

fc2c34371f5c v9.1.0162 2024-03-10 17:00:06 Christian Brabandt

patch 9.1.0162: problem with writing extended attributes on failure

Commit: https://github.com/vim/vim/commit/14759ded57447345ba11c11a99fd84344797862c
Author: Paul R. Tagliamonte <paultag@gmail.com>
Date: Sun Mar 10 08:35:10 2024 +0100

patch 9.1.0162: problem with writing extended attributes on failure

Problem: problem with writing extended attributes on failure
Solution: Change return type to ssize_t and check listxattr's return
value correctly on failure (Paul Tagliamonte)

The existing logic will return when the listxattr call returns with the
errno set to ENOTSUP (or a size of 0 bytes), without checking to see if
listxattr actually failed. listxattr can fail with at least E2BIG,
ENOTSUP, ERANGE, or anything that `stat(2)` can fail with (in my case;
ENOENT from stat).

The returned size is stored to a size_t, but the return type is a
ssize_t. On failure, listxattr returns -1, which will get translated to
size_t's MAX. If the listxattr call failed with anything other than
ENOTSUP, this triggers a request for size_t MAX bytes.

This means that, if the listxattr call fails with anything other than
ENOTSUP on save, vim will error with

`E342: Out of memory! (allocating 18446744073709551615 bytes)`

(keen observers will note 18446744073709551615 is 0xffffffffffffffff)

In reality, this is likely masking a different (usually filesystem?)
error -- but at least it's an error being pushed to the user now, and we
don't try to allocate size_t MAX bytes.

I've opted to change the type that we store listxattr to from size_t to
ssize_t, to match listxattr(2)'s signature, and to check for the -1
return value. Additionally, I've removed the errno check -- if we get a
listxattr failure for any reason, we may as well bail without trying;
it's not like we can even recover.

closes: #14169

Signed-off-by: Paul Tagliamonte <paultag@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

56c7b599d524 2024-03-10 02:30:03 Christian Brabandt

translation(lt): Added Lithuanian translation of Tutor v. 1.4 by Laurynas Stančikas (#14118)

Commit: https://github.com/vim/vim/commit/ca0e0d2708eded356e9c14cbc22578b9a1b62181
Author: Rimas Kudelis <rimas@kudelis.lt>
Date: Sat Mar 9 19:27:46 2024 +0200

translation(lt): Added Lithuanian translation of Tutor v. 1.4 by Laurynas Stančikas (https://github.com/vim/vim/issues/14118)

This translation has been available for free download from lietuvybe.org,
then lietuvybe.akl.lt, then lietuvybė.lt since at least 2006[1], but noone
ever bothered to contribute it upstream.

[1] https://web.archive.org/web/20060222162117/http://lietuvybe.org/files/vim-tutor-lt.txt

Co-authored-by: Laurynas Stančikas <lasas@gim.ktu.lt>
Signed-off-by: Rimas Kudelis <rimas@kudelis.lt>
Signed-off-by: Christian Brabandt <cb@256bit.org>

728675946924 2024-03-10 02:15:04 Christian Brabandt

runtime(java): Recognise string templates (#14150)

Commit: https://github.com/vim/vim/commit/a2c65809dafe5c4f45f278fddf368c7c971d83e9
Author: Aliaksei Budavei <32549825+zzzyxwvut@users.noreply.github.com>
Date: Sat Mar 9 20:03:11 2024 +0300

runtime(java): Recognise string templates (https://github.com/vim/vim/issues/14150)

As this is encouraged in the referenced JEPs, "to visually
distinguish a string template from a string literal, and
a text block template from a text block", the default
colours for java\%[Debug]StrTempl are made distinct from
java\%[Debug]String.

According to §3.2 Lexical Translations (JLS, c. 1996 or any
more recent version), line terminators, white space, and
comments are discarded before tokens are accepted. Since
a template expression comprises a template processor, a dot,
and a template, it may be visually appealing to break up
its head across a few lines whenever its tail already spans
multiple lines. Curiously, no allowance for it is made in
the distributed tests for OpenJDK 21; the proposed regexp
patterns take in consideration a line terminator and white
space after a dot.

References:
https://openjdk.org/jeps/430 (Preview)
https://openjdk.org/jeps/459 (Second Preview)
https://openjdk.org/jeps/465

Signed-off-by: Aliaksei Budavei <0x000c70@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

97fc56ee7ca7 2024-03-10 02:15:04 Christian Brabandt

runtime(vim): Update base-syntax, improve :map highlighting (#14141)

Commit: https://github.com/vim/vim/commit/5d67aef3060d6d3aa14d273c39f23d8a90c4cef1
Author: dkearns <dougkearns@gmail.com>
Date: Sun Mar 10 04:01:22 2024 +1100

runtime(vim): Update base-syntax, improve :map highlighting (https://github.com/vim/vim/issues/14141)

Improve :map command highlighting.

- Fix multiline RHS matching, allow continued lines and comments.
- Allow ^V-escaped whitespace in LHS.
- Handle map-bar properly and allow trailing commands.

Fixes issue #12672.


Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

f68c5e30c2d4 2024-03-10 02:15:03 Christian Brabandt

Added tag v9.1.0161 for changeset 5397ce113043a02bf52a8c7dbe233ad3d63d4305

5397ce113043 v9.1.0161 2024-03-10 02:15:02 Christian Brabandt

patch 9.1.0161: expand() removes slash after env variable that ends with colon

Commit: https://github.com/vim/vim/commit/13a014452a7a020a119ac555a690c65b41f3126d
Author: zeertzjq <zeertzjq@outlook.com>
Date: Sat Mar 9 17:44:46 2024 +0100

patch 9.1.0161: expand() removes slash after env variable that ends with colon

Problem: expand() removes a slash after an environment variable that
ends with a colon on Windows.
Solution: Check the correct char for a colon (zeertzjq)

closes: #14161

Note: Vim still removes the path-separator at the end, if another path separator
follows directly after it, e.g. on:

```
echo $FOO='/usr/'
echo expand('$FOO/bar') == '/usr/bar'
```

see:

,----[ misc1.c:1630 ]
| // if var[] ends in a path separator and tail[] starts
| // with it, skip a character
| if (after_pathsep(dst, dst + c)
| #if defined(BACKSLASH_IN_FILENAME) || defined(AMIGA)
| && (dst == save_dst || dst[-1] != ':')
| #endif
| && vim_ispathsep(*tail))
| ++tail;
`----

Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

408e9818595d 2024-03-10 01:45:03 Christian Brabandt

runtime(vim): Update base-syntax, improve :menu{,translate} highlighting (#14162)

Commit: https://github.com/vim/vim/commit/62b26040eb4b6752be2c46852e8986083737a1bb
Author: dkearns <dougkearns@gmail.com>
Date: Sun Mar 10 03:43:28 2024 +1100

runtime(vim): Update base-syntax, improve :menu{,translate} highlighting (https://github.com/vim/vim/issues/14162)

Improve :menu and :menutranslate highlighting.

- Match args to :menutranslation and :popup.
- Only highlight special notation in {rhs} of :menu, like :map.
- Allow line continuations in {rhs} of :menu and between {english} and
{mylang} of :menutranslation, matching common usage.
- Bug fixes.

Signed-off-by: Doug Kearns <dougkearns@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>

Show on old repository browser