[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#18141: 24.4.50; saving .gz file breaks file coding
From: |
Eli Zaretskii |
Subject: |
bug#18141: 24.4.50; saving .gz file breaks file coding |
Date: |
Wed, 06 Aug 2014 22:45:22 +0300 |
> 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.
- bug#18141: 24.4.50; saving .gz file breaks file coding, Glenn Morris, 2014/08/05
- bug#18141: 24.4.50; saving .gz file breaks file coding, Eli Zaretskii, 2014/08/06
- bug#18141: 24.4.50; saving .gz file breaks file coding, Vincent Lefevre, 2014/08/06
- bug#18141: 24.4.50; saving .gz file breaks file coding, Eli Zaretskii, 2014/08/06
- bug#18141: 24.4.50; saving .gz file breaks file coding, Vincent Lefevre, 2014/08/06
- bug#18141: 24.4.50; saving .gz file breaks file coding,
Eli Zaretskii <=
- bug#18141: 24.4.50; saving .gz file breaks file coding, Vincent Lefevre, 2014/08/06
- bug#18141: 24.4.50; saving .gz file breaks file coding, Stefan Monnier, 2014/08/07
- bug#18141: 24.4.50; saving .gz file breaks file coding, Vincent Lefevre, 2014/08/07
- bug#18141: 24.4.50; saving .gz file breaks file coding, Glenn Morris, 2014/08/10
bug#18141: 24.4.50; saving .gz file breaks file coding, Stefan Monnier, 2014/08/06
- bug#18141: 24.4.50; saving .gz file breaks file coding, Eli Zaretskii, 2014/08/06
- bug#18141: 24.4.50; saving .gz file breaks file coding, Stefan Monnier, 2014/08/06
- bug#18141: 24.4.50; saving .gz file breaks file coding, Eli Zaretskii, 2014/08/07
- bug#18141: 24.4.50; saving .gz file breaks file coding, Stefan Monnier, 2014/08/07
- bug#18141: 24.4.50; saving .gz file breaks file coding, Eli Zaretskii, 2014/08/07