Skip to content

Alternate buffer not restoring cursor position with window splits #28

Closed

Description

@natecraddock

Sometimes I am editing a file a.txt and I want to reference two separate locations while editing. For this I usually split the window. I will also often switch between the alternate buffer b.txt for another reference. Under some circumstances (detailed below), this plugin prevents restoring the cursor to the last buffer position when switching alternate buffers. Here are two recordings:

In both cases I:

  • Open a.txt for editing. Note that the cursor starts on line 3 (the '" marks's location)
  • Use 'G' to view the bottom of a.txt
  • Split my window with <c-w>s
  • Refocus the top window to the top of a.txt and open b.txt for editing in the lower window
  • Use <c-6> to switch to alternate buffer repeatedly in the lower window

If I open a.txt for editing and the '" mark is positioned on line 1, this issue does not occur.

The first with this plugin installed:
When switching from b.txt to a.txt as the alternate buffer with this plugin installed, the cursor is returned to line 3, where my file was opened (the '" mark). This loss of context removes the benefit of having an alternate buffer for reference.

lastplace.mp4

Without the plugin installed:

no-lastplace.mp4

Without the plugin installed everything works as expected. I also tested without loading my .vimrc which also functioned properly. I am using Neovim 0.6 if that makes a difference.

Activity

  1. farmergreg commented on Dec 16, 2021

    @farmergreg
    Owner

    Hi Nathan, thanks for the truly excellent bug report.

    I won't have availability to tackle this for quite some time.

    If you or anyone else wants to work up a patch and submit it, I'd be more than happy to review it and pull it in to the mainline.

  2. natecraddock commented on Feb 16, 2022

    @natecraddock
    CollaboratorAuthor

    I looked a bit more into this, and I can confirm that this bug also occurs in vim, not just neovim.

    Neovim's docs suggest using the following for restoring the cursor position automatically:

        autocmd BufRead * autocmd FileType <buffer> ++once
          \ if &ft !~# 'commit\|rebase' && line("'\"") > 1 && line("'\"") <= line("$") | exe 'normal! g`"' | endif

    This is different from the suggested command for vim because of differences in how neovim handles filetype loading: neovim/neovim#16339

    I tried the above in neovim and I don't see the bug anymore.

    vim-lastplace uses a BufWinEnter autocmd. Out of curiosity I replaced the BufWinEnter with BufRead in vim-lastplace and I cannot replicate this issue in either vim or neovim. Everything else seems to work okay still, though I did not test extensively. For example, I don't use folds and I didn't test if this impacted folds.

    I'm not super familiar with the differences between BufWinEnter and BufRead, but that simple change seems to have resolved things.

  3. nzbart commented on Feb 21, 2022

    @nzbart
    Contributor

    @natecraddock thanks for posting a solution. To clarify, do you remove farmergreg/vim-lastplace and replace it with the code in your comment, or do you load this plugin in addition to the autocmd?

  4. natecraddock commented on Feb 21, 2022

    @natecraddock
    CollaboratorAuthor

    @nzbart Sorry for the ambiguity. I found two solutions:

    1. Remove the plugin and use the above autocommand in neovim. This removes the bug, but this autocmd is missing a few features of lastplace (like centering the cursor). Vim has a similar autocmd documented at :h restore-cursor.

    2. Make the following edit to lastplace

    diff --git a/plugin/vim-lastplace.vim b/plugin/vim-lastplace.vim
    index 1aacd16..6ed1bec 100644
    --- a/plugin/vim-lastplace.vim
    +++ b/plugin/vim-lastplace.vim
    @@ -76,5 +76,5 @@ endf
     
     augroup lastplace_plugin
     	autocmd!
    -	autocmd BufWinEnter * call s:lastplace()
    +	autocmd BufRead * call s:lastplace()
     augroup END
    

    As I mentioned above, I'm not sure if solution 2 causes any side-effects, but it seems to work perfectly for me!

  5. added a commit that references this issue on Feb 22, 2022
  6. farmergreg commented on Feb 22, 2022

    @farmergreg
    Owner

    Thank-you for the patch @natecraddock and @nzbart. Merged into mainline for testing.

    Everyone, please test it out and leave comments here if you find something this patch breaks.

    @oblitum would you be willing to re-test the fold feature and ensure it continues to work properly?

  7. musjj commented on Dec 3, 2022

    @musjj

    Converted the autocmd from the docs to lua:

    vim.api.nvim_create_autocmd("BufRead", {
      callback = function(opts)
        vim.api.nvim_create_autocmd("FileType", {
          once = true,
          buffer = opts.buf,
          callback = function()
            local ft = vim.bo[opts.buf].ft
            local last_pos = vim.api.nvim_buf_get_mark(opts.buf, '"')
            if
              not (ft:match("commit") and ft:match("rebase"))
              and last_pos[1] > 1
              and last_pos[1] <= vim.api.nvim_buf_line_count(opts.buf)
            then
              vim.api.nvim_feedkeys('g`"', "x", false)
            end
          end,
        })
      end,
    })

    Not really that familiar with vimscript, so feel free to point out any mistakes.

  8. farmergreg commented on Aug 23, 2023

    @farmergreg
    Owner

    The fix for this bug may have created the conditions that created bug #30. keeping both bugs open until i have some time to dig into this. If anyone wants to look into it, please do so, and submit a patch when you figure it out!

    Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    No labels
    No labels

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions