Age | Commit message (Collapse) | Author |
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
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>
|
|
object method
Problem: Add support for using a class type of itself in an object
method (thinca)
Solution: Vim9: Add support for using a class type of itself in an
object method (Yegappan Lakshmanan)
fixes: #12369
closes: #14165
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Crash in WinClosed after BufUnload closes other windows
Solution: Don't trigger WinClosed if the buffer is NULL (zeertzjq)
Now win_close_othertab() doesn't trigger any autocommands if the buffer
is NULL, so remove the autocmd blocking above (which was added not long
ago in patch v9.0.0550) for consistency.
Also remove an unreachable close_last_window_tabpage() above:
- It is only reached if only_one_window() returns TRUE and last_window()
returns FALSE.
- If only_one_window() returns TRUE, there is only one tabpage.
- If there is only one tabpage and last_window() returns FALSE, the
one_window() in last_window() must return FALSE, and the ONE_WINDOW
in close_last_window_tabpage() must also be FALSE.
- So close_last_window_tabpage() doesn't do anything and returns FALSE.
Then the curtab != prev_curtab check also doesn't make much sense, and
the only_one_window() can be replaced with a check for popup and a call
to last_window() since this is a stricter check than only_one_window().
closes: #14166
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: 'shortmess' "F" flag doesn't work properly with 'autoread'
(after 9.1.0154)
Solution: Hide the file info message instead of the warning dialog
(zeertzjq)
closes: #14159
closes: #14158
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Duplicate assignment in f_getregion().
Solution: Remove the duplicate assignment. Also improve getregion()
docs wording and fix an unrelated typo (zeertzjq)
closes: #14154
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: may not be clear why failing to split causes an ":Xdo" command
to abort if 'wfb' is set.
Solution: do not return immediately if win_split fails, so E1513 is
still given. Expect both errors in the test. Also fix tests to
pass CI.
(Sean Dewar)
closes: #14152
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: can only call getregion() for current buffer
Solution: Allow to retrieve selections from different buffers
(Shougo Matsushita)
closes: #14131
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: shm=F not respected when reloading buffer with 'autoread'
Solution: Check SHM_FILEINFO in buf_check_timestamp()
(Shougo Matsushita)
closes: #14144
Signed-off-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Text properties corrupted with fo+=aw and backspace
Solution: Allocate line and move text properties
(zeertzjq)
closes: #14147
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Signed-off-by: Antonio Giovanni Colombo <azc100@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Coverity complains about ignoring return value of win_split()
(after v9.1.150)
Solution: Check if win_split() failed, add winfixbuf.res to Makefile
|
|
Problem: ml_get_buf_len() does not consider text properties
(zeertzj)
Solution: Store text length excluding text properties length
in addition in the memline
related #14123
closes: #14133
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: several minor 'winfixbuf' issues exist, mostly relating to the
quickfix list
Solution: address them and adjust tests. Retab and reflow a few things too.
(Sean Dewar)
Things touched include:
- Replace the semsgs with gettext'd emsgs.
- Handle window switching in ex_listdo properly, so curbuf and curwin
are kept in-sync and trigger autocommands; handle those properly.
- Don't change the list entry index in qf_jump_edit_buffer if we fail
due to 'wfb' (achieved by returning FAIL; QF_ABORT should only be used
if the list was changed).
- Make qf_jump_edit_buffer actually switch to prevwin when using `:cXX`
commands **outside** of the list window if 'wfb' is set in curwin.
Handle autocommands properly in case they mess with the list.
NOTE: previously, it seemed to split if 'wfb' was set, but do nothing
and fail if prevwin is *valid*. This behaviour seemed strange, and maybe
unintentional? Now it aligns more with what's described for the `:cXX`
commands in the original PR description when used outside a list window,
I think.
- In both functions, only consider prevwin if 'wfb' isn't set for it;
fallback to splitting otherwise.
- Use win_split to split. Not sure if there was a specific reason for
using ex_splitview. win_split is simpler and respects modifiers like
:vertical that may have been used. Plus, its return value can be checked
for setting opened_window in qf code (technically win_split_ins autocmds
could immediately close it or change windows, in which the qf code might
close some other window on failure; it's already the case elsewhere,
though).
closes: #14142
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
* translation(sr): Update Serbian messages
* Update serbian.nsi
* Update gvim.nsi
Add serbian language to the installer
Signed-off-by: Ivan Pešić <27575106+eevan78@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: qf_goto_win_with_qfl_file may check if prevwin has 'winfixbuf'
set without checking if it's valid first.
Solution: Reverse the condition. Add a test, a modeline, and a missing
CheckFeature. (Searn Dewar)
closes: #14140
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Vim9: can't call internal methods with objects
Solution: Add support for empty(), len() and string() function
calls for objects (Yegappan Lakshmanan)
closes: #14129
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Cannot keep a buffer focused in a window
(Amit Levy)
Solution: Add the 'winfixbuf' window-local option
(Colin Kennedy)
fixes: #6445
closes: #13903
Signed-off-by: Colin Kennedy <colinvfx@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: v:echospace wrong after setting invalid value to 'showcmdloc'.
Solution: Only call comp_col() if value is valid.
(zeertzjq)
closes: #14119
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: the amount of available space (v:echospace) on the command
line is not correct when showcmdloc is drawn into the
statusline or tabline.
Solution: only add SHOWCMD_COLS to the shown command column when
'showcmdloc' is set to last (Sam-programs)
closes: #14108
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Sam-programs <130783534+Sam-programs@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: getregion() needs more tests
Solution: Run the getregion() test in both the legacy and Vim9 contexts
(Yegappan Lakshmanan)
closes: #14114
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: [security]: autocmd cause use-after-free in set_curbuf()
(kawarimidoll)
Solution: check side-effect of BufLeave autocommand, when the number
of windows changed, close windows containing buffers that will
be wiped, if curbuf changed unexpectedly make sure b_nwindows
is decremented otherwise it cannot be wiped
set_curbuf() already makes some efforts to ensure the BufLeave
autocommands do not cause issues. However there are still 2 issues
that are not taken care of:
1) If a BufLeave autocommand opens a new window containing the same
buffer as that is going got be closed in close_buffer() a bit later,
we suddenly have another window open, containing a free'd buffer. So we
must check if the number of windows changed and if it does (and the
current buffer is going to be wiped (according to the 'bufhidden'
setting), let's immediately close all windows containing the current
buffer using close_windows()
2) If a BufLeave autocommand changes our current buffer (displays it in
the current window), buf->b_nwindow will be incremented. As part of
set_curbuf() we will however enter another buffer soon, which means, the
newly created curbuf will have b_nwindows still have set, even so the
buffer is no longer displayed in a window. This causes later problems,
because it will no longer be possible to wipe such a buffer. So just
before entering the final buffer, check if the curbuf changed when
calling the BufLeave autocommand and if it does (and curbuf is still
valid), decrement curbuf->b_nwindows.
Both issues can be verified using the provided test (however the second
issue only because such an impacted buffer won't be wiped, causing
futher issues in later tests).
fixes: #13839
closes: #14104
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: getregion() can be improved (after v9.1.120)
Solution: change getregion() implementation to use pos as lists and
one optional {opt} dictionary (Shougo Matsushita)
Note: The following is a breaking change!
Currently, the getregion() function (included as of patch v9.1.120) takes
3 arguments: the first 2 arguments are strings, describing a position,
arg3 is the type string.
However, that is slightly inflexible, there is no way to specify
additional arguments. So let's instead change the function signature to:
getregion(pos1, pos2 [, {Dict}]) where both pos1 and pos2 are lists.
This is slightly cleaner, and gives us the flexibility to specify
additional arguments as key/value pairs to the optional Dict arg.
Now it supports the "type" key to specify the selection type
(characterwise, blockwise or linewise) and now in addition one can also
define the selection type, independently of what the 'selection' option
actually is.
Technically, this is a breaking change, but since the getregion()
Vimscript function is still quite new, this should be fine.
closes: #14090
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Shougo Matsushita <Shougo.Matsu@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Put in Visual mode wrong if it replaces fold marker.
Solution: Temporarily disable folding during put in Visual mode.
(zeertzjq)
fixes: #14097
closes: #14100
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Signed-off-by: Ivan Pešić <27575106+eevan78@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Signed-off-by: Antonio Giovanni Colombo <azc100@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
EOL is shown
Problem: The cursor screen row was incorrectly being calculated when the
cursor follows a 1 character text_align 'below' virtual text line,
resulting in the cursor being shown on the wrong line.
This was caused by a cell size of 2 instead of 1 being used for the EOL
character, which propagated to the calculation of space for putting the
'below' virtual text on its own line. (rickhowe)
Solution: Fix the size used for the EOL character in calculating the
cursor's screen position (Dylan Thacker-Smith)
fixes: #11959
related: #12028
closes: #14096
Signed-off-by: Dylan Thacker-Smith <dylan.ah.smith@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: MS-Windows: ligatures map cleared on startup
Solution: Don't clear the ligatures_map, if the guiligatures
option has already been set (Erik S. V. Jansson)
If guiligatures is set from a .vimrc it's possible
that it will be cleared on start-up (e.g. in Win32
that's what happens).
So don't clear the ligatures map if gui_set_ligatures()
has already been called (e.g. after setting 'ligatures'
from .vimrc)
closes: #14094
Signed-off-by: Erik S. V. Jansson <caffeineviking@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: too many STRLEN calls when getting a memline
Solution: Optimize calls to STRLEN(), add a few functions in memline.c
that return the byte length instead of relying on STRLEN()
(John Marriott)
closes: #14052
Signed-off-by: John Marriott <basilisk@internode.on.net>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: <Del> in cmdline mode doesn't delete composing chars
Solution: Use mb_head_off() and mb_ptr2len() (zeertzjq)
closes: #14095
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
methods
Problem: Vim9: need more test for exists()
Solution: Add test for exists() with class/objct variables and methods
(Yegappan Lakshmanan)
closes: #14088
Signed-off-by: Yegappan Lakshmanan <yegappan@yahoo.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Insufficient testing for 'delcombine'.
Solution: Add test for both Normal and Insert modes without Arabic.
(zeertzjq)
closes: #14086
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Test_term_gettitle() is flaky on MacOS 14 and Github runners
Solution: Skip the test on Github CI
closes: #14085
It fails with this: '^\\[No Name\\] - VIM\\d*$' does not match 'e] - VIM'
It is not clear why term_gettitle() only get's the last part of the
expected title (perhaps there is a Carriage return in there or the
terminal window is too small?)
So let's just skip this test for now.
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: font ligatures don't render correctly in the Win32 GUI-version
of gvim even when set rop=type:directx is used. Setting
guiligatures also doesn't make any difference. This leads to
broken font ligatures when the cursor passes through them. It
does not recover from this, and they remain broken until you
re-render the whole buffer (e.g. by using Ctrl+L).
Solution: the problem is that we only re-draw the current and previous
character in gui_undraw_cursor() and only have the special case
for GTK when it comes to rendering ligatures. So let's enable
gui_adjust_undraw_cursor_for_ligatures() to also happen for
Win32 GUI if guiligatures is setup correctly (all this does is
expand the range of gui_undraw_cursor() with ligature characters).
related: #9181
related: #12901
closes: #14084
Signed-off-by: Erik S. V. Jansson <caffeineviking@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: using "C" and 've=all' set, doesn't include composing chars
when changing a line, keeps the composing chars for whatever
is typed afterwards.
Solution: Use mb_head_off() and mb_ptr2len() instead of mb_tail_off().
(zeertzjq)
closes: #14083
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: buffer-completion code too complicated and does not always
find all matches (irisjae)
Solution: do not try to anchor pattern to beginning of line or
directory-separator, always return all matches
Note: we are considering the non-fuzzy buffer-matching here.
Currently, the buffer-completion code makes 2 attempts to match a
pattern against the list of available patterns. First try is to match
the pattern and anchor it to either the beginning of the file name or
at a directory-separator (// or \\).
When a match is found, Vim returns the matching buffers and does not try
to find a match anywhere within a buffer name. So if you have opened two
buffers like /tmp/Foobar.c and /tmp/MyFoobar.c using `:b Foo` will only
complete to the first filename, but not the second (the same happens
with `getcompletion('Foo', 'buffer')`).
It may make sense, that completion priorities buffer names at directory
boundaries, but it inconsistent, may cause confusion why a certain
buffer name is not completed when typing `:b Foo<C-D>` which returns
only a single file name and then pressing Enter (to switch to that
buffer), Vim will error with 'E93: More than one match for Foo').
Similar things may happen when wiping the /tmp/Foobar.c pattern and
afterwards the completion starts completing other buffers.
So let's simplify the code and always match the pattern anywhere in the
buffer name, do not try to favor matches at directory boundaries. This
is also simplifies the code a bit, we do not need to run over the list
of buffers several times, but only twice.
fixes #13894
closes: #14082
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: heap-use-after-free in win_splitmove if Enter/Leave
autocommands from win_split_ins immediately closes "wp".
Solution: check that "wp" is valid after win_split_ins.
(Sean Dewar)
closes: #14078
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Virtual text with text_wrap 'wrap' was effectively being
truncated by a break conditional on the EOL list character
being added to the screen line. (BigPeet)
Solution: Remove the condition that was leading to the early break and
instead fix a similar but incorrectly written outer condition
that checks if there is more to add at the end of the screen
line. (Dylan Thacker-Smith)
Also, related:
- update comment in win_line()
- remove no longer necessary at_end_str variable in win_line()
fixes: #12725
closes: #14079
Co-authored-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Dylan Thacker-Smith <dylan.ah.smith@gmail.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: win_gotoid() checks for textlock and other things when switching
to a window that is already current (after v9.1.0119)
Solution: return early with success when attempting to switch to curwin
(Sean Dewar)
Other potential causes of E565 from win_gotoid after v9.1.0119 should be
correct. Plugins can consider using win_execute() instead if they wish to
temporarily switch windows during textlock.
fixes: #14073
closes: #14074
Signed-off-by: Sean Dewar <6256228+seandewar@users.noreply.github.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Naming a non-pointer variable "oap" is strange.
Solution: Rename it to "oa". Also prevent using freed memory in case of
memory allocation failure. (zeertzjq)
closes: #14075
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Signed-off-by: Christian Brabandt <cb@256bit.org>
|
|
Problem: Internal error when passing mark in another buffer to
getregion().
Solution: Don't allow marks in another buffer (zeertzjq)
closes: #14076
Signed-off-by: zeertzjq <zeertzjq@outlook.com>
Internal error when passing mark in another buffer to getregion()
|