crash after "autocmd BufNew * setlocal bufhidden=delete"

[trusktr]

Whenever I try to set bufhidden=delete then close some buffers, :buffers still shows open buffers, and then trying set bufhidden outputs

  bufhidden=

indicating that the value didn't stay as delete. This is happening while running nvim with an empty init.vim and nvim -u NONE.

The does what I want:

        autocmd BufNew * setlocal bufhidden=delete

[justinmk]

Can you verify that the behavior is different in Vim?

[mhinz]

'bufhidden' is always local to the buffer.

[trusktr]

Oh, so set bufhidden=delete really doesn't do anything at all. Interesting. Maybe this can be a feature request to be able to configure this globally?

[justinmk]

The way to make buffer-local options "global" is to set them with an autocmd, as you are already doing.

autocmd BufNew * setlocal bufhidden=delete

[trusktr]

Well, that's not the same as just set bufhidden=... is it? In the autocmd case there's an event handler that's having to be called over and over (extra CPU for each call? Extra memory for each local var?).

[trusktr]

@justinmk When I have

autocmd BufNew * setlocal bufhidden=delete

set, NeoVim crashes after a while. When I remove that, all is fine and I can work without interruption.

[justinmk]

In the autocmd case there's an event handler that's having to be called over and over (extra CPU for each call? Extra memory for each local var?).

Performance impact in that case is almost zero. Moving it to C won't help anything and will increase the number of user-facing options.

NeoVim crashes after a while

That's very bad. But we need a backtrace to fix it...

[trusktr]

How might I start neovim and have a backtrace log to a file when it crashes?

[justinmk]

https://github.com/neovim/neovim/wiki/Development-tips#backtrace-linux

[trusktr]

ulimit looks like a builtin. Do I need to run that specifically in the terminal I run neovim in? Or just in any terminal on my system?

[trusktr]

Oh, I can probably set that in my zshrc.

[ZyX-I]

@trusktr In the shell (not terminal, this has nothing to do with terminal properties) you run Neovim from or any of its children that did not reset limits by themselves: limits are inherited like environment. You can also do this for an existing process: http://serverfault.com/questions/201207/set-max-file-limit-on-a-running-process.

If you set this in a zshrc then 1. it will not affect any of the already running shells unless you have some kind of automatic zshrc reloading and 2. you will have core files from every crashed application you have ever run all over the filesystem.

[trusktr]

Does ulimit -c unlimited need to be specified for core files to be written when things crash? I don't see any core files anywhere from the last crash.

[trusktr]

@justinmk @ZyX-I For life of me, I can't seem to get this to work any more. I'm trying this in my init.vim:

        set nohidden
        autocmd BufNew * setlocal bufhidden=delete

Then, I load a session, close all the windows, then :buffers is showing me all of the buffer that I thought were supposed to be deleted. I also tried set hidden and autocmd BufNew * setlocal bufhidden=wipe, and it just won't work now.

[trusktr]

Alright, so for some reason, after making new buffers, despite that autocmd, the output of setlocal bufhidden is bufhidden=, showing that the variable is not set. Any idea why this might be?

[justinmk]

Is the behavior different in Vim?

[trusktr]

I'm not sure, I don't even have vim installed, but I'm definitely confused. The wording in the help pages is already poor enough. I just want my buffers to vaporize when I close them.

[trusktr]

So, it seems to work sometimes. I'm not sure why. I open a bunch of buffer, edit stuff, then close stuff, until I have only a single buffer open in a single tab. Then I look at my buffer list and a few of them are there, and other are gone as expected.

I have think the edit command hides the current buffer. That might be why it works only sometimes, as the help page says

The commands that move through the buffer list sometimes make a buffer hidden although the 'hidden' option is off

Maybe :e is one of the commands that move through the buffer list? I want to get rid of that, and just destroy invisible buffers, and only keep buffers that are present in a window in some tab. The reason I want to do this is because over time my buffer list just gets bigger and bigger. I could make some command to delete hidden buffers, but I'd like for that not to be necessary.

[ZyX-I]

@trusktr For core files to be written when things crash ulimit must be something other then zero, unlimited is a value that allows dumping the whole process memory even if it died with SEGV after eating all GiBs of memory you have and accessed NULL returned by malloc afterwards. ulimit -c unlimited does not have to be specified: e.g. there is limits.conf file somewhere in /etc (I have it in /etc/security/limits.conf, but this is not the only possible location) which specifies system-wide limits and some other facility related to PAM which allow you to configure the same thing.

Limits are applied process-wise, and default on most systems is zero limit for core files (== core files are never written), so you have to change this default somehow. Most easy way to do this is ulimit -c unlimited in the shell you launch application that can crash in, before launching the application.

[ZyX-I]

@trusktr Core file will be written in the working directory of the crashed process.

[trusktr]

Core file will be written in the working directory of the crashed process.

I can't seem to find core dumps. The way my Gnome terminal works is it runs nvim +term instead of the default shell. I wonder where the core file would be written in that case. I don't see it in ~. I also don't see a /var/log/apport.log file. I'll do some research in the Arch Wiki to see if I can find where they go.

[ZyX-I]

@trusktr :edit is a command that opens a file in a buffer. If file is opened in current buffer, buffer will be reloaded. If file is opened in some (non-current) buffer, it switches buffers (if it was hidden it will not be reloaded, but if file changed you will be prompted). If file matches some BufReadCmd autocmd then what will be done depends entirely on this autocmd. If file is not opened and does not match any autocmd, buffer will be created. In all cases, except the first buffer will be switched.

[justinmk]

@trusktr Try this instead:

autocmd BufNew,BufNewFile,BufRead * setlocal bufhidden=delete

I have found some of the BufFoo commands in Vim are very unreliable and the conditions that trigger them are not well-defined.

[trusktr]

@ZyX-I Ah, it's coredumpctl list shows core dumps. I'll monitor that for crashed. This is nice to know, now my crash reports on here will be more helpful. 😄

@justinmk That works much better! Do you think it's possible a plugin might override the autocmd somehow? The autocmd BufNew was the last thing in my init.vim.

Anyways, things appear to be deleted all the time now, and if I have a crash I think I'll be able to find the core dump now too. :]

[ZyX-I]

@trusktr If you crashed Neovim which is opened directly by your terminal, then ulimit -c unlimited in zshrc does not apply to it: Neovim will inherit limits from the terminal (because it is now its direct parent), terminal will inherit it from whatever launched it (most likely, some of your desktop environment processes), whatever launched it most likely indirectly inherited limits from some system process that shows your login screen which inherited them from your service manager (e.g. systemd, upstart or openrc) which inherited this from init.

You see: no zsh is involved in process. So either use /etc/**/limits.conf, make terminal run zsh -c 'ulimit -c unlimited ; nvim +terminal' or use one of the advices regarding changing limits in the already running applications.

[trusktr]

@ZyX-I Yep, I put it in /etc/security/limits.conf. I'll observe how that goes. Hopefully my drive doesn't fill with core dumps. x}

[ZyX-I]

@trusktr Plugin may override absolutely anything in (Neo)vim, except things stored in s: variables and anonymous functions definitions. When I say “anything” I mean it: a plugin may redefine s: function defined in some other plugin! Though this will not give it access to other plugin’s s: variables.

[ZyX-I]

@trusktr I cannot answer you a question when changes to this file apply. Something suggests me that you at least need to relogin (at most to reboot).

[ZyX-I]

Also no access to local variables. (And almost nothing built-in can be redefined, but I was talking about whatever was defined by some plugin.)

[trusktr]

A little off topic now, but a function-based module system would be nice. The code of a .vim file would be placed into a function wrapper then executed with dependencies passed into the function (like JavaScript AMD or CommonJS, which led to ES2015 Modules). Is there anything like this in the works?

[ZyX-I]

@trusktr There is nothing like this I know about, or any plans.

Something more modular can be seen in my frawor. Though this is not the only framework which introduced dependencies, AFAIK it is the only one (at least, the only one I know) which supposes that developer wants to depend on files rather then on the whole plugin that contains a file. Frawor is full of hacks, of course.

[ZyX-I]

@trusktr Edited the comment because I have mistaken a level at which you suggest to put this module system: it can be implemented on top of current functionality and I for some reason thought you want this in core (i.e. in C or lua after luaviml).

[justinmk]

https://github.com/google/vim-maktaba supports "plugin objects".

[justinmk]

Merging this with #4393 since a backtrace was never provided here.

---

update: Isolated here: #4766. Turns out this is different than #4393.