From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Vincent Lefevre Newsgroups: gmane.emacs.bugs Subject: bug#18141: 24.4.50; saving .gz file breaks file coding Date: Thu, 7 Aug 2014 02:31:16 +0200 Message-ID: <20140807003116.GM4813@xvii.vinc17.org> References: <9pzjfrwvsl.fsf@fencepost.gnu.org> <83iom5ptwv.fsf@gnu.org> <20140806164316.GK4813@xvii.vinc17.org> <831tstplqs.fsf@gnu.org> <20140806190825.GL4813@xvii.vinc17.org> <83oavxo10t.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Trace: ger.gmane.org 1407371545 16023 80.91.229.3 (7 Aug 2014 00:32:25 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Thu, 7 Aug 2014 00:32:25 +0000 (UTC) Cc: 18141@debbugs.gnu.org, yamaoka@jpl.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Aug 07 02:32:19 2014 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1XFBcw-00059X-8Y for geb-bug-gnu-emacs@m.gmane.org; Thu, 07 Aug 2014 02:32:18 +0200 Original-Received: from localhost ([::1]:42550 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFBct-0007f3-S3 for geb-bug-gnu-emacs@m.gmane.org; Wed, 06 Aug 2014 20:32:15 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:38518) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFBcm-0007er-2E for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2014 20:32:12 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1XFBch-0005I3-2s for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2014 20:32:08 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:54019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1XFBcg-0005Hz-V6 for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2014 20:32:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1XFBcg-0001j7-Bv for bug-gnu-emacs@gnu.org; Wed, 06 Aug 2014 20:32:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Vincent Lefevre Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 07 Aug 2014 00:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 18141 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 18141-submit@debbugs.gnu.org id=B18141.14073714816582 (code B ref 18141); Thu, 07 Aug 2014 00:32:02 +0000 Original-Received: (at 18141) by debbugs.gnu.org; 7 Aug 2014 00:31:21 +0000 Original-Received: from localhost ([127.0.0.1]:60962 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XFBc1-0001i3-1B for submit@debbugs.gnu.org; Wed, 06 Aug 2014 20:31:21 -0400 Original-Received: from ioooi.vinc17.net ([92.243.22.117]:54110) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1XFBby-0001ht-Dz for 18141@debbugs.gnu.org; Wed, 06 Aug 2014 20:31:20 -0400 Original-Received: from smtp-xvii.vinc17.net (128.119.75.86.rev.sfr.net [86.75.119.128]) by ioooi.vinc17.net (Postfix) with ESMTPSA id 2CB58319; Thu, 7 Aug 2014 02:31:17 +0200 (CEST) Original-Received: by xvii.vinc17.org (Postfix, from userid 1000) id CDDCB21A07C; Thu, 7 Aug 2014 02:31:16 +0200 (CEST) Content-Disposition: inline In-Reply-To: <83oavxo10t.fsf@gnu.org> X-Mailer-Info: http://www.vinc17.net/mutt/ User-Agent: Mutt/1.5.23-6361-vl-r59709 (2014-07-25) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:92231 Archived-At: On 2014-08-06 22:45:22 +0300, Eli Zaretskii wrote: > > Date: Wed, 6 Aug 2014 21:08:25 +0200 > > From: Vincent Lefevre > > 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. It still exists on a file containing the \x80 byte (which happens to be the simplest HTML file containing the Euro symbol, BTW). > > > > 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. Ctrl-C is safe with any correctly written software. > > > 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. No, that's not easy: one needs to type C-g, then C-x C-c, then answer 'n' (or 'q'), then answer 'yes', thus 10 keys instead of 2 (and also some messages to read). > > Ctrl-C in the terminal is the fastest way to do that. > > I don't see why the speed is relevant here. It's more than 5 times as fast, thus very relevant. > > > > 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. I'm tired of this stupid argument! First it is completely wrong. Disk space is *not* always cheap. I have an account where the default quota is 10 GB and my backup files currently take 169 MB; this is not entirely negligible (1.7%). On a different machine, 1 GB costs 0.10 EUR per month, and I don't want to waste several dozens of GB of backups (easily produced without clean-up). Once becoming useless, backup files have no value. There are other issues with backup files: if one has many files, this makes filename completion work much less efficiently if old files are on the way. There are also potential security/privacy issues, in case the machine gets compromised. It's always better not to keep obsolete files with private data. > > 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. I repeat that this is normally fine for me. If a different method were used to avoid such collisions, this means that it would be slower to enter the filenames, even with the help of completion (see above) or whatever. > 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. There is a good reason: Emacs is obviously buggy, and it's entirely its fault. > > > > 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. What's important is what the user can see, not the code. > 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. So, one has: 1. The backup is made. 2. The prompt appears. 3. If the user has not killed Emacs due to this interaction, the file is written. So, the backup isn't done just before the file is written. > After r111638, the prompt is issued before backing up the file. And that's a much more logical sequence. > 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. I don't understand why the user would kill Emacs here: the user has confirmed the save operation (no more prompts), and he can easily see when the save has been completed. > IOW, the window didn;t disappear, it just got smaller in those rare > cases where Emacs needs to ask the user about encoding. Wrong, it didn't get just smaller: it suppressed user interaction between the backup and the write operation. That's the main point. -- Vincent Lefèvre - Web: 100% accessible validated (X)HTML - Blog: Work: CR INRIA - computer arithmetic / AriC project (LIP, ENS-Lyon)