Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

After closing a buffer, Ctrl-o no longer re-opens the buffer #28968

Open
tschafer-gc opened this issue May 24, 2024 · 7 comments · May be fixed by #29347
Open

After closing a buffer, Ctrl-o no longer re-opens the buffer #28968

tschafer-gc opened this issue May 24, 2024 · 7 comments · May be fixed by #29347
Labels
compatibility compatibility with Vim or older Neovim enhancement feature request jumps-navigation
Milestone

Comments

@tschafer-gc
Copy link

Problem

In v0.9.5, closing a buffer and then pressing ctrl-o re-opened the closed buffer. In v0.10.0, this is no longer the case, and ctrl-o jumps back to the previous position only in currently open buffers.

Steps to reproduce

Assuming you have binaries for both v0.10.0 and v0.9.5 named nvim-0.10.0 and nvim-0.9.5 respectively:

nvim-0.9.5 --clean file1 file2
:bdelete
<C-o> # opens buffer that was just deleted
nvim-0.10.0 --clean file1 file2
:bdelete
<C-o> # does not open buffer that was just deleted

Expected behavior

<C-o> should presumably behave as it did in 0.9.5, by opening deleted buffers

Neovim version (nvim -v)

0.10.0 release, and latest prerelease 0e9c92a

Vim (not Nvim) behaves the same?

Vim 9.1.400 does not have this issue

Operating system/version

macOS 14.5

Terminal name/version

Alacritty 0.13.2

$TERM environment variable

tmux-256color

Installation

Homebrew

@tschafer-gc tschafer-gc added the bug issues reporting wrong behavior label May 24, 2024
@zeertzjq
Copy link
Member

I think this is caused by #25461

@tschafer-gc
Copy link
Author

I think this is caused by #25461

Ah yes you're right - I'm assuming there's no way of reverting to the old behaviour, or opening a recently closed buffer by any other means?

@justinmk justinmk added this to the unplanned milestone May 24, 2024
@justinmk justinmk added compatibility compatibility with Vim or older Neovim jumps-navigation and removed bug issues reporting wrong behavior labels May 24, 2024
@zeertzjq
Copy link
Member

zeertzjq commented May 24, 2024

Adding a link to my comment in #25365 (comment):

This may be changed to another flag of 'jumpoptions' that is enabled by default, so that the old behavior may still be achievable by removing the flag.

@abilkhan024
Copy link

Adding a link to my comment in #25365 (comment):

This may be changed to another flag of 'jumpoptions' that is enabled by default, so that the old behavior may still be achievable by removing the flag.

Didn't quite get it what do you mean by "old behavior may still be achievable by removing the flag", how do I remove flag, I've tried:

set jumpoptions=stack

But it only opens buffer one time after closing but, and stops after that.
Any help would be highly appreciated.

@zeertzjq
Copy link
Member

zeertzjq commented May 29, 2024

It's not implemented yet.

@justinmk justinmk added the enhancement feature request label Jun 4, 2024
@Gremious
Copy link

Uscase: Yeah, very often, I edit a buffer, then close (delete) it thinking I don't need it anymore, only to realize "wait, I need to fix a line"

I then tap ctrl-o and it re-openes that buffer on the line i was editing. It's very nice.

Second usecase: I start vim and press ctrl-o and immediately have the buffer I was editing last ready to go.

I would absolutely like to have the option to use a "global" jumplist again

@paulodiovani
Copy link

+1
I also used to type C-o to reopen a closed buffer.

For whoever have this same issue, C-^ (or maybe C-6) can still reopen a closed buffer.
I have gb mapped for this (to match gt): noremap gb <C-^>

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
compatibility compatibility with Vim or older Neovim enhancement feature request jumps-navigation
Projects
None yet
Development

Successfully merging a pull request may close this issue.

6 participants