Doesn't work fully when opening multiple files

[willcl-ark]

If I open multiple files in a directory with nvim *.txt lastplace will correctly return me to the last edit point for the first file. However switching buffers will open the second (and third...) files at the top.

If I close all files and only re-open file 2, then lastplace will again work correctly opening the file at the last edit point.

[ethanholz]

@willcl-ark, what version of neovim are you currently using? I tried to replicate your issue and did not have the same outcome.

[willcl-ark]

Hey @ethanholz thanks for your quick response, and sorry for my slow one. I'll be faster now! :)

I am on NVIM v0.8.0-v0.8.0, and definitely see the same behaviour still, which I am confused about... I don't think it was always like this which is odd.

I have done some trial-and-error debugging, and disabling all other plugins fixed it. OK. Renabling half in binary search fashion worked until, I had -reenabled them all, which was odd. However I think I did find a new clue based on switch method:

• Works: switch buffers with :b <num>
• Broken: switch buffers with Telescope, which I have bound as vim.keymap.set('n', '<leader><space>', require('telescope.builtin').buffers, { desc = '[ ] Find existing buffers' })

I'm curious if you've used Telescope's buffers builtin in your tests, as this seems to be where it doesn't work for me?

[ethanholz]

No worries! I have not tried using telescope to switch buffers but I will take a look at that. As an aside, was this testing completed on your fork of this repo? If it was on your fork, I noticed that it is out of date so please update accordingly.

[willcl-ark]

It's not from my fork, I'm just using use 'ethanholz/nvim-lastplace' with Packer and a config file containing some pretty non-intrusive looking options:

-- Enable nvim-lastplace
local lastplace_ok, lastplace = pcall(require, "nvim-lastplace")
if not lastplace_ok then
    vim.notify("nvim-lastplace failed to load")
    return
end

lastplace.setup({
    lastplace_ignore_buftype = { "quickfix", "nofile", "help" },
    lastplace_ignore_filetype = { "gitcommit", "gitrebase", "svn", "hgcommit" },
    lastplace_open_folds = true
})

[ethanholz]

All of that looks good. I went ahead and tested this and it seems that it is something to do with Telescope as you had mentioned. I tested this plugin, a slimmed down adaptation of this found in the neovim issues, and adapted the upstream code from vim-lastplace (I even took it one step further to see if vim-lastplace would handle this case correctly and it cannot).

After briefly looking through the Telescope code, I don't see why it would override the buffer marks like that. I might need to open an issue with Telescope to look further into this.

[willcl-ark]

Oh well, I'm glad it's not just my setup 😀

I think your probably best-placed to open the issue against Telescope, but if you'd prefer me to do it then just let me know and I'd be happy to.

Thanks again.

[ethanholz]

Sure thing! I will probably get to this at some point this weekend. I will keep this issue open until we find resolution for this.

[ethanholz]

@willcl-ark Is this issue still happening? I just closed a similar one and was curious if the issue persisted.

[willcl-ark]

Hey @ethanholz, yes I still see this issue. I've switched now to Lazy.nvim with the following config for lastplace:

return {
  -- Open files in last edited place
  "ethanholz/nvim-lastplace",
  lazy = false,
  config = function()
    require("nvim-lastplace").setup({
      lastplace_ignore_buftype = { "quickfix", "nofile", "help" },
      lastplace_ignore_filetype = { "gitcommit", "gitrebase", "svn", "hgcommit" },
      lastplace_open_folds = true,
    })
  end,
}

This still returns me to the last place of my first file, but not subsequenct files.

Also if I navigate within a file, close the file and open it again as part of a group-of-files, the last place is also not detected, only again for the first file.

Also now bothered to check (sorry) whether this is the same if I switch buffers with :b2 and it is, so perhaps not a Telescope issue...

[ethanholz]

I do not have the issue using b2, b3, etc. I only seem to be able to recreate this for Telescope. However, I will also note that I don't disable lazy loading of this plugin in my own config.

I think I will have to add something to allow for switching the underlying auto command because I have a feeling this might be based on the startup with neovim and/or telescope.

[willcl-ark]

Hmmm, well I disabled lazy loading so that lasplace would always be enabled (in my mind this could have helped).

I did notice one thing, and I'm not totally sure why it's happening... despite having this in lazy-lock.json

  "nvim-lastplace": { "branch": "main", "commit": "75a2b78bdbbd20467d499defceb5b20c0967a1ca" },

...when I search for autocommands with :Telescope autocommands I see this:

You selected autocmd: {
  command = "<lua function>",
  event = "BufReadPost",
  group_name = "NvimLastplace",
  pattern = "*"
}

Looking at the plugin, this has been updated to BufRead? I've tried un-installing and re-installing the plugin too, but apparently, no change? Am I reading the plugin right that I should see a BufRead autocmd?

edit: and sure enough, the version in /home/will/.local/share/nvim/lazy/nvim-lastplace/lua/nvim-lastplace/init.lua is correct? How odd...

[ethanholz]

You are correct. This should run on BufRead. Interestingly, this also occurs with vim-lastplace. Furthermore, they are listed together in the neovim docs which leads me to believe that BufRead autcommands might also get called with BufReadPost.