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

autowrite when receiving SIGHUP, SIGQUIT #29411

Open
robin-carlier opened this issue Jun 19, 2024 · 5 comments
Open

autowrite when receiving SIGHUP, SIGQUIT #29411

robin-carlier opened this issue Jun 19, 2024 · 5 comments
Labels
enhancement feature request events events, autocommands system
Milestone

Comments

@robin-carlier
Copy link

Problem

Currently (at least with neovim 0.10.0) when autowrite or autowriteall is set the buffers are not being written out when neovim receive a deadly signal such as SIGHUP or SIGQUIT.

Expected behavior

Neovim should try to write out the buffers as it would with a normal exit in cases like this as this would be what one expects when they set autowrite or autowriteall.

@robin-carlier robin-carlier added the enhancement feature request label Jun 19, 2024
@dundargoc
Copy link
Member

How often does neovim crash that this becomes relevant lol?

Also I don't think it's as obvious as you say that autowrite "should" save on abort. In all cases now autowrite is triggered by a deliberate action by the user, while this will write on any random state it happens to be on. Do the recovery functionality/swap mechanism not essentially fulfill this need anyway?

@justinmk
Copy link
Member

justinmk commented Jun 19, 2024

preserve_exit is called on deadly signal:

neovim/src/nvim/os/signal.c

Lines 180 to 181 in a2d510e

// Preserve files and exit.
preserve_exit(IObuff);

IIUC, that only writes swap files. For SIGHUP/SIGQUIT (but not others like SIGTERM) maybe it makes sense to also write the buffer contents.

@justinmk justinmk added this to the unplanned milestone Jun 19, 2024
@justinmk justinmk added the needs:discussion issue needs attention from an expert, or PR proposes significant changes to architecture or API label Jun 19, 2024
@justinmk justinmk changed the title Autowrite should also be triggered when receiving deadly signals autowrite when receiving deadly signals Jun 19, 2024
@robin-carlier
Copy link
Author

robin-carlier commented Jun 19, 2024

@dundargoc

How often does neovim crash that this becomes relevant lol?

It’s not relevant for crashes, but the use case that makes me want such a functionality is the following: I wanted a "quick and dirty" neovim scratchpad windows in my desktop environment, and I’m used to quit windows through my DE shorcuts, which calls a SIGHUP.

I agree that there are multiple workarounds for this particular usage but as @justinmk says for signals like SIGHUP or SIGQUIT (but not SIGTERM, I agree), I thought it would make more sense that neovim goes through its usual exit sequence as a :q would.

@justinmk justinmk removed the needs:discussion issue needs attention from an expert, or PR proposes significant changes to architecture or API label Jun 19, 2024
@justinmk justinmk modified the milestones: unplanned, backlog Jun 19, 2024
@justinmk justinmk changed the title autowrite when receiving deadly signals autowrite when receiving SIGHUP, SIGQUIT Jun 19, 2024
@justinmk justinmk added system events events, autocommands labels Jun 19, 2024
@justinmk
Copy link
Member

'autowrite' already (should) works like this for :suspend (SIGTSTP). And 'autowriteall' is intended to extend 'autowrite' behavior for "quit" (:help autowriteall mentions "closing the Vim window").

Proposal

  • Respect 'autowriteall' for SIGHUP/SIGQUIT.
  • Are VimLeave/VimLeavePre triggered on SIGHUP/SIGQUIT? Or should they be? Or should the Signal autocmd allow hooking into SIGHUP/SIGQUIT?

@matveyt
Copy link
Contributor

matveyt commented Jun 27, 2024

Are VimLeave/VimLeavePre triggered on SIGHUP/SIGQUIT? Or should they be?

I believe, they should if v:dying == 1 (i.e. only one deadly signal caught), as documented at :h v:dying.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement feature request events events, autocommands system
Projects
None yet
Development

No branches or pull requests

4 participants