Problem: Patch v8.1.0425 was wrong
Solution: Revert that patch (Hirohito Higashi)
This is because the root cause was fixed in 8.1.0786 and a regression
occurred elsewhere.
related: vim/vim#3455
related: vim/vim#3830fixes: vim/vim#11558closes: vim/vim#178996abe5e4904
Co-authored-by: Hirohito Higashi <h.east.727@gmail.com>
Problem: :bnext doesn't go to unlisted help buffers when cycling
through help buffers (after 9.1.0557).
Solution: Don't check if a help buffer is listed (zeertzjq).
From <https://github.com/vim/vim/issues/4478#issuecomment-498831057>:
> I think we should fix that, since once you get to a non-help buffer
> all unlisted buffers are skipped, thus you won't encounter another
> help buffer.
This implies that cycling through help buffers should work even if help
buffers are unlisted. Otherwise this part of :bnext isn't really useful,
as :h makes help buffers unlisted by default.
related: vim/vim#4478
related: vim/vim#15198closes: vim/vim#179139662f33480
Problem: [security]: Possible to open more windows into a closing
buffer without splitting, bypassing existing "b_locked_split"
checks and triggering use-after-free
Solution: Disallow switching to a closing buffer. Editing a closing
buffer (via ":edit", etc.) was fixed in v9.1.0764, but add an
error message and check just "b_locked_split", as "b_locked"
is necessary only when the buffer shouldn't be wiped, and may
be set for buffers that are in-use but not actually closing.
(Sean Dewar)
closes: vim/vim#172466cb1c82840
Problem: moving in the buffer list doesn't work as documented
(SenileFelineS)
Solution: Skip non-help buffers, when run from normal buffers, else
only move from help buffers to the next help buffer (LemonBoy)
As explained in the help section for :bnext and :bprev the commands
should jump from help buffers to help buffers (and from regular ones to
regular ones).
fixes: vim/vim#4478closes: vim/vim#15198893eeeb445
Co-authored-by: LemonBoy <thatlemon@gmail.com>
Problem: console dialog cannot save unnamed buffers
Solution: set bufname before save (glepnir). Define dialog_con_gui
to test for GUI+Console dialog support, use it to skip
the test when the GUI feature has been defined.
Note: The dialog_changed() function will also try to call the
browse_save_fname() function, when FEAT_BROWSE is defined (which is only
defined in a GUI build of Vim). This will eventually lead to a call of
do_browse(), which causes an error message if a GUI is not currently
running (see the TODO: in do_browse()) and will then lead to a failure
in Test_goto_buf_with_onfirm().
Therefore, we must disable the Test_goto_buf_with_onfirm(), when the
dialog_con_gui feature is enabled (which basically means dialog feature
for GUI and Console builds, in contrast to the dialog_con and dialog_gui
feature).
(Previously this wasn't a problem, because the test aborted in the YES
case for the :confirm :b XgotoConf case and did therefore not run into
the browse function call)
closes: vim/vim#14398df46115fc8
Co-authored-by: glepnir <glephunter@gmail.com>
Problem: Dialog for file changed outside of Vim not tested.
Solution: Add a test. Move FileChangedShell test. Add 'L' flag to
feedkeys().
5e66b42aae
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Tests are flaky because of using a common file name.
Solution: Rename files and directories to be more unique.
61abe7d8f8
Cherry-pick Test_custom_complete_autoload() from patch 8.2.4584.
Cherry-pick test_delete.vim & test_edit.vim changes from patch 9.0.0323.
Cherry-pick test_edit.vim changes from patch 8.2.3637.
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: On MS-Windows some tests are flaky.
Solution: Add sleeps, disable swapfile, mark test as flaky. (Ken Takata,
closesvim/vim#11082)
0500e87eba
Co-authored-by: K.Takata <kentkt@csc.jp>
Problem: Using separate delete() call instead of writefile() 'D' flag.
Solution: Use the writefile 'D' flag.
3411265a36
Co-authored-by: Bram Moolenaar <Bram@vim.org>
Problem: Using common name in tests leads to flaky tests.
Solution: Rename files and directories to be more specific.
e7cda97b6b
Co-authored-by: Bram Moolenaar <Bram@vim.org>
