:bnext cursor positioning is different for a hidden buffer vs a buffer shown in another window

[zeertzjq]

Steps to reproduce

1. Run vim --clean
2. Source the following file:

set hidden
call setline(1, range(&lines + 10))
normal! G
vsplit
enew
bnext

3. Cursor in the left window is at the top of the file

Expected behaviour

Cursor in the left window is at the bottom of the file. The is the behavior if I removed the :vsplit, and if I revert patch 8.1.0425 I also get this behavior.

Version of Vim

9.0.813

Environment

Operating system: Arch Linux
Terminal: kitty
Value of $TERM: xterm-kitty
Shell: fish

Logs and stack traces

No response

[brammool]

### Steps to reproduce 1. Run `vim --clean` 2. Source the following file: ```vim set hidden call setline(1, range(&lines + 10)) normal! G vsplit enew bnext ``` 3. Cursor in the left window is at the top of the file ### Expected behaviour Cursor in the left window is at the bottom of the file. The is the behavior if I removed the `:vsplit`, and if I revert patch 8.1.0425 I also get this behavior.

Without setting 'hidden' the same seems to happen. Maybe there is another condition. Note that normally the cursor is always in the first line. Something has to move it to the last known position. Usually that's an autocommand. In the defaults.vim script this is done with BufReadPost, thus if the buffer was already loaded it's not triggered. Perhaps adding BufWinEnter there might work. However, I'm not sure if there are situation that the cursor would then be moved when the user doesn't want to.

…

-- hundred-and-one symptoms of being an internet addict: 85. Choice between paying Compuserve bill and paying for kids education is a no brainer -- although a bit painful for your kids. /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[zeertzjq]

I don't think this has anything to do with autocommands. :bnext still moves the cursor to last position when the buffer is not loaded even if I remove the autocommand:

augroup vimStartup | au! | augroup END
set hidden
call setline(1, range(&lines + 10))
normal! G
enew
bnext

And if revert patch 8.1.0425:

diff --git a/src/buffer.c b/src/buffer.c
index de4c40b58..78b41cd26 100644
--- a/src/buffer.c
+++ b/src/buffer.c
@@ -1906,9 +1906,6 @@ enter_buffer(buf_T *buf)
     // mark cursor position as being invalid
     curwin->w_valid = 0;
 
-    buflist_setfpos(curbuf, curwin, curbuf->b_last_cursor.lnum,
-					      curbuf->b_last_cursor.col, TRUE);
-
     // Make sure the buffer is loaded.
     if (curbuf->b_ml.ml_mfp == NULL)	// need to load the file
     {

The cursor is then also moved when the buffer is shown in another window even if I remove the autocommand:

augroup vimStartup | au! | augroup END
set hidden
call setline(1, range(&lines + 10))
normal! G
vsplit
enew
bnext

[zeertzjq]

Taking another look at patch 8.1.0425, it seems that fix doesn't always work. If the buffer isn't visible in any window, then curwin still cannot be set to a window that contains the buffer.

[brammool]

Taking another look at patch 8.1.0425, it seems that fix doesn't always work. If the buffer isn't visible in any window, then `curwin` still cannot be set to a window that contains the buffer.

You mean that find_win_for_curbuf() may leave "curwin" as it was, and then curwin->w_buffer differs from "curbuf"? That is indeed dangerous. Can you reproduce a failure with this situation? We probably should use aucmd_prepbuf(). It adds some overhead, but it was especially designed to handle changes in a buffer that isn't the current one. Before I make that change it would be good to have a test for any failures with the current implementation. After that we'll have to see if updating the last cursor position is also fixed.

…

-- From "know your smileys": :~) A man with a tape recorder up his nose /// Bram Moolenaar -- ***@***.*** -- http://www.Moolenaar.net \\\ /// \\\ \\\ sponsor Vim, vote for features -- http://www.Vim.org/sponsor/ /// \\\ help me help AIDS victims -- http://ICCF-Holland.org ///

[brammool]

I added the patch to make sure the buffer is changed in the context of a window. Please check that either this has fixed the problem or it can still be reproduced.
If this did fix the problem, can you write a regression test?
If did this not fix the problem, what is the simplest way to reproduce? Ideally in the form of a failing test.

[brammool]

Perhaps patch 9.0.0961 also matters for this issue.
Otherwise the questions from 8 days ago still matter.