bug#18141: 24.4.50; saving .gz file breaks file coding

[Eli Zaretskii <eliz@gnu.org>]

> Date: Wed, 6 Aug 2014 21:08:25 +0200
> From: Vincent Lefevre <vincent@vinc17.net>
> Cc: rgm@gnu.org, 18141@debbugs.gnu.org, yamaoka@jpl.org
> 
> On 2014-08-06 20:32:27 +0300, Eli Zaretskii wrote:
> > > (Emacs seems to be confused on files that have several encodings,
> > > such as mailboxes)
> > 
> > It does?  I didn't see that since Emacs 23.1 at the least.
> 
> Things may have been fixed. I don't remember exactly. There's also
> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=13505 that was fixed
> not so long ago.

So I think you are talking about a problem that largely doesn't exist,
perhaps at all.

> > > and I sometimes hit Ctrl-C in the terminal (from which Emacs was
> > > started) to discard any change.
> > 
> > Then don't do that, if it hurts.
> 
> Ctrl-C is standard to interrupt a foreground process. If the process
> can't handle that, it should trap SIGINT. Ditto for SIGQUIT. But
> processes must handle SIGHUP and SIGTERM gracefully, ditto for various
> errors, like an X server crash.

Be that as it may, it is still unjustified to use such drastic
measures where safer ones are available.

> > C-g or M-~ or C-/ in Emacs will discard changes (in different
> > scenarios) without any adverse effects, as will killing the buffer
> > that visits the modified file. Why brutally abort Emacs by a signal,
> > when Emacs gives you better ways to do that?
> 
> I haven't see any better way. My goal is to quit Emacs, discarding any
> change.

My point is that you can easily discard changes without quitting
Emacs.  If you do, the problem you raised would not have existed.

> Ctrl-C in the terminal is the fastest way to do that.

I don't see why the speed is relevant here.

> > > And that's not OK to only leave the backup file,
> > > since it can be removed or overwritten pretty quickly, before
> > > I notice that the original file is gone.
> > 
> > Removed or overwritten by whom or what?
> 
> By me. I sometimes get rid of all the backup files because I don't need
> them, since the original file should have been kept.

Again, then don't do that.  Disk space is cheap nowadays, whereas data
in our files is precious.

> A backup file is overwritten if I edit a file of the same name in
> another directory

??? Then your make-backup-file function (or whatever other method you
use to put backup files in a special directory) needs to be improved,
so that files in different directories don't overwrite each other's
backups.

Really this sounds more and more like a series of problems with your
personal configuration and setup, which is unlikely to be seen on
someone else's machine.  I see no reason to make non-trivial changes
to Emacs due problems that might not be rare with your peculiar setup,
but are otherwise quite unlikely.

> > > But why isn't the backup done just before the file is actually
> > > written?
> > 
> > It _is_ done "just before", see basic-save-buffer-2.
> 
> No, not without r111638: the backup is done before the user is asked
> to the provide an encoding, thus not just before the file is written.

Please see the code, which speaks for itself.  basic-save-buffer-2
calls backup-buffer and after that calls write-region, which writes
the new contents.  Before r111638, the prompt to select a suitable
encoding was issued from inside write-region.  After r111638, the
prompt is issued before backing up the file.  That's all the
difference introduced by r111638.  There's still a window of
opportunity between backing up and writing the new contents; if Emacs
is killed during that window, you get your disappearing file again.

IOW, the window didn;t disappear, it just got smaller in those rare
cases where Emacs needs to ask the user about encoding.