unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Vincent Lefevre <vincent@vinc17.net>
Cc: larsi@gnus.org, 13522@debbugs.gnu.org
Subject: bug#13522: 24.2; save-buffer removes edited file under some conditions
Date: Mon, 14 Mar 2022 19:02:14 +0200	[thread overview]
Message-ID: <83bky8jwmh.fsf@gnu.org> (raw)
In-Reply-To: <20220314152053.GB2381@cventin.lip.ens-lyon.fr> (message from Vincent Lefevre on Mon, 14 Mar 2022 16:20:53 +0100)

> 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	other threads:[~2022-03-14 17:02 UTC|newest]

Thread overview: 23+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-01-22  1:47 bug#13522: 24.2; save-buffer removes edited file under some conditions Vincent Lefevre
2013-01-24 20:28 ` Glenn Morris
2013-01-25  0:02   ` Vincent Lefevre
2013-01-25  0:48     ` Glenn Morris
2013-01-25  7:35       ` Eli Zaretskii
2013-01-25  8:07         ` Glenn Morris
2013-01-30  8:59           ` Glenn Morris
2013-01-30 19:34             ` Stefan Monnier
2013-01-31  6:36               ` Glenn Morris
2014-08-11  1:06                 ` Glenn Morris
2022-03-14 11:21 ` Lars Ingebrigtsen
2022-03-14 13:37   ` Eli Zaretskii
2022-03-14 13:43     ` Lars Ingebrigtsen
2022-03-14 14:05       ` Eli Zaretskii
2022-03-14 15:20         ` Vincent Lefevre
2022-03-14 17:02           ` Eli Zaretskii [this message]
2022-03-14 17:32             ` Vincent Lefevre
2022-03-15 11:42         ` Lars Ingebrigtsen
2022-03-15 14:23           ` Eli Zaretskii
2022-03-15 14:25             ` Lars Ingebrigtsen
2022-03-15 15:55               ` Vincent Lefevre
2022-04-30 16:47                 ` Lars Ingebrigtsen
2022-04-30 16:51                   ` Lars Ingebrigtsen

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=83bky8jwmh.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=13522@debbugs.gnu.org \
    --cc=larsi@gnus.org \
    --cc=vincent@vinc17.net \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).