bug-gnu-emacs
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

bug#13522: 24.2; save-buffer removes edited file under some conditions


From: Eli Zaretskii
Subject: bug#13522: 24.2; save-buffer removes edited file under some conditions
Date: Mon, 14 Mar 2022 19:02:14 +0200

> Date: Mon, 14 Mar 2022 16:20:53 +0100
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: Lars Ingebrigtsen <larsi@gnus.org>, 13522@debbugs.gnu.org
> 
> This is silly. Ctrl-C is *standard* to interrupt commands. When there
> is a risk to lose data or to get in an inconsistent state, commands
> should trap SIGINT (either to ignore it or to do some cleanup before
> exiting).

That's what Emacs does.  Except that not every processing interrupted
in its middle can be restarted and run to its "normal" completion.

> Note that in any case, C-x C-c in Emacs does not replace Ctrl-C in the
> terminal, as with C-x C-c, Emacs quits with a zero exit status, which
> may not be what one wants. Example: in a "svn ci", one may want to
> abort the commit without losing the text written in Emacs. Ctrl-C in
> the terminal (where "svn ci" has been run) allows one to do that.

Emacs is not SVN, and doesn't work in transactions.

> In this bug, the issue is actually more important: When one does
> C-x C-s, the file has been renamed, which is bad, because the user
> may not choose what to do immediately, and many things can happen
> in the period, such as a power outage, a network outage, a crash of
> the machine, etc. The user may not notice the issue with the file
> immediately, so that he may lose the contents (or the changes, e.g.
> if the file is handled by a VCS). The file may also be needed by
> other software while the user is editing it (for instance, as backup
> software, or some application if this is a configuration file).

There should be an auto-save file to recover your edits.

> > SIGINT is a fatal signal, and our response to fatal signals cannot
> > be too fancy. We just auto-save what we can and commit suicide. Even
> > that is disliked by some, who say we cannot safely do anything
> > non-trivial from a fatal signal handler -- and they are absolutely
> > right, we do stuff that invokes undefined behavior.
> 
> SIGINT could be equivalent to something like C-g in Emacs + quit
> without saving (a backup of the current buffer can be kept),
> exiting with a non-zero exit status. Note that you do not need to
> do everything in the signal handler. In general, what is done is
> just to set some variable saying that SIGINT has been received.
> The abort of the operations is done in the main code.

When the program is delivered a fatal signal, the only way to get back
to "main code" is longjmp from the signal handler, which is already
"not recommended", to say the least.

Anyway, what you describe is not what actually happens, AFAIK.
Handling a fatal signal and handling C-g are very different in Emacs.
But maybe I'm missing something, so I will let others speak up.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]