GNU bug report logs - #4533
23.1: reverting fails to update line ending mode line

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 4533 in the body.
You can then email your comments to 4533 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Benjamin Peterson <benjamin <at> python.org>
To: bug-gnu-emacs <at> gnu.org
Subject: 23.1: reverting fails to update line ending mode line
Date: Tue, 22 Sep 2009 21:01:31 -0500

I had a buffer with a mode line like this:

- U:(DOS)

I ran dos2unix on the file, and did M-x revert-buffer.

The DOS stayed in the mode line until I killed the buffer and
revisited the buffer.


In GNU Emacs 23.1.1 (x86_64-pc-linux-gnu)
 of 2009-09-07 on benjamin
Windowing system distributor `The X.Org Foundation', version 11.0.10503000
configured using `configure  '--prefix=/usr'
'--build=x86_64-pc-linux-gnu' '--host=x86_64-pc-linux-gnu'
'--mandir=/usr/share/man' '--infodir=/usr/share/info'
'--datadir=/usr/share' '--sysconfdir=/etc' '--localstatedir=/var/lib'
'--libdir=/usr/lib64' '--program-suffix=-emacs-23'
'--infodir=/usr/share/info/emacs-23' '--with-sound' '--with-x'
'--without-toolkit-scroll-bars' '--without-gif' '--with-jpeg'
'--with-png' '--with-rsvg' '--with-tiff' '--with-xpm' '--with-xft'
'--without-libotf' '--without-m17n-flt' '--with-x-toolkit=no'
'--without-hesiod' '--without-kerberos' '--without-kerberos5'
'--with-gpm' '--with-dbus' 'build_alias=x86_64-pc-linux-gnu'
'host_alias=x86_64-pc-linux-gnu' 'CFLAGS=-O2 -pipe' 'LDFLAGS=-Wl,-O1''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default-enable-multibyte-characters: t

Major mode: Python

Minor modes in effect:
  show-paren-mode: t
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  global-auto-composition-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  column-number-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
n i c o d e C-s C-s C-s C-s C-s C-s C-s C-x b <return>
M-v M-v M-v M-v C-p C-p C-p C-p C-p C-p C-p C-p C-p
C-p C-n C-n C-n C-n C-n C-n C-f C-f C-f C-f C-f C-f
C-f C-f C-f C-f C-f C-f C-f C-f C-f C-f C-p C-p C-p
C-p C-p C-p C-p C-f C-f <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> <backspace> <backspace> <backspace> <backspace>
<backspace> c l a s s SPC _ u n i c o d e ( s t r )
: <return> p a s s C-x C-s C-v C-v C-v C-v C-v C-v
C-v M-v M-v M-v C-x b <return> <up> <up> <up> <up>
<up> <up> <up> <up> <up> <up> <up> <up> <left> <left>
<left> <left> <left> <left> <left> <left> _ C-x C-s
M-v C-v C-n C-n C-n C-n C-n C-n C-n <return> C-p <tab>
# SPC S D <backspace> <backspace> <backspace> <backspace>
p y . t e s t . s k i p ( " w i l l SPC r e w r i t
e " ) C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n C-n
C-n C-n C-n C-n C-n <return> p y . t e s t . s k i
p ( " w i l l SPC r e w r i t e " ) C-x C-s <help-echo>
M-x r e v e r t - u f <tab> <backspace> <backspace>
b u f <tab> <return> y M-v M-v M-v f r C-x k <return>
C-x C-f t e s t - s e r <tab> <backspace> <backspace>
<backspace> <backspace> _ s e r <tab> <return> C-v
C-v C-v M-v M-v M-x r e p o r t - e m <tab> <retur
n>

Recent messages:
Local value of py-indent-offset set to 4
Using the CPython shell
test_serializer.py changed on disk; really edit the buffer? (y, n, r or C-h)
Fontifying test_serializer.py... (regexps............)
Local value of py-indent-offset set to 4
Using the CPython shell
byte-code: File reverted: /home/benjamin/dev/repos/pylib/test_serializer.py
Fontifying test_serializer.py... (regexps............)
Local value of py-indent-offset set to 4
Using the CPython shell
call-interactively: End of buffer

Message #8 received at 4533 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Benjamin Peterson <benjamin <at> python.org>
Cc: 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Fri, 02 Oct 2009 20:16:50 -0400

Benjamin Peterson wrote:

> I had a buffer with a mode line like this:
>
> - U:(DOS)
>
> I ran dos2unix on the file, and did M-x revert-buffer.
>
> The DOS stayed in the mode line until I killed the buffer and
> revisited the buffer.


I have not been able to reproduce this.

Message #15 received at 4533 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Jack Tanner <ihok <at> hotmail.com>
To: <4533 <at> debbugs.gnu.org>
Cc: <lennart.borgman <at> gmail.com>
Subject: i can reproduce this
Date: Sun, 1 Nov 2009 12:07:36 -0500

[Message part 1 (text/plain, inline)]

Emacs 23.1.1 i386-mingw-nt5.1.2600 (from ftp.gnu.org) on WinXP SP3.

- Start emacs -Q .
- C-x C-f ~/foo.txt, creating a new file.
- Enter text: 
Line 1
Line 2

- C-x C-s.
- dos2unix ~/foo.txt
- M-x revert-buffer
Nothing changes in the mode line. Mousing over the \ in -1\--- shows "End-of-line style: DOS-style CRLF".
- C-x k RET
- C-x C-f ~/foo.txt
Mode line shows --(Unix)---.
 		 	   		  
_________________________________________________________________
Bing brings you maps, menus, and reviews organized in one place.
http://www.bing.com/search?q=restaurants&form=MFESRP&publ=WLHMTAG&crea=TEXT_MFESRP_Local_MapsMenu_Resturants_1x1

[Message part 2 (text/html, inline)]

Message #18 received at 4533 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Jack Tanner <ihok <at> hotmail.com>
Cc: 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: i can reproduce this
Date: Mon, 02 Nov 2009 03:11:16 -0500

tags 4533 =
stop

Jack Tanner wrote:

> - Start emacs -Q .
> - C-x C-f ~/foo.txt, creating a new file.
> - Enter text: 
> Line 1
> Line 2
>
> - C-x C-s.
> - dos2unix ~/foo.txt
> - M-x revert-buffer

Thanks for the recipe. Saving the file was the missing step.

The issue seems to be that saving a file causes basic-save-buffer-1 to
set buffer-file-coding-system-explicit. Eg for me on GNU/Linux, it is
set to (iso-latin-1-unix). revert-buffer uses this to set
coding-system-for-read before it inserts the file contents. So the
change in line ending is ignored. If I manually set
buffer-file-coding-system-explicit to nil before reverting the buffer,
the change in line ending is noticed.

I don't know what the right fix is though.

Message #23 received at 4533 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: reverting fails to update line ending mode line
Date: Mon, 02 Nov 2009 03:57:14 -0500

But

    http://debbugs.gnu.org/cgi/bugreport.cgi?bug=1039#42

seems to say this is a feature?

    But, the problem is the case that you load "hello" by explicitly
    specifying dos coding system, or you once save the file by dos coding
    sytem before reverting.  In this case, Emacs respects your
    specification, and thus revert-buffer loads the file as dos coding
    system, which results in seeing many CR charaters in the above case.

    We think this behaviour is not a bug but a feature.

Message #26 received at 4533 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: reverting fails to update line ending mode line
Date: Wed, 04 Nov 2009 22:28:39 -0500

Hi,

Could you comment on this

http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4533#15

(it seems related to your final comment in bug#1039)

The behaviour in this case seems odd to me, given that the coding
system is never explicitly specified.

Message #31 received at submit <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Benjamin Peterson <benjamin <at> python.org>, 4533 <at> debbugs.gnu.org
Cc: bug-gnu-emacs <at> gnu.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Thu, 05 Nov 2009 13:17:00 +0900

In article <1afaf6160909221901p527cca80jcbf81e589cde629d <at> mail.gmail.com>, Benjamin Peterson <benjamin <at> python.org> writes:

> I had a buffer with a mode line like this:
> - U:(DOS)

> I ran dos2unix on the file, and did M-x revert-buffer.

> The DOS stayed in the mode line until I killed the buffer and
> revisited the buffer.

I found that insert-file-contents forgets to update
buffer-file-coding-system in case of replace.  I've just
installed a fix.

---
Kenichi Handa
handa <at> m17n.org

Message #41 received at 4533 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Kenichi Handa <handa <at> m17n.org>
To: Glenn Morris <rgm <at> gnu.org>
Cc: 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: reverting fails to update line ending mode line
Date: Thu, 05 Nov 2009 13:18:49 +0900

In article <wfiqdpd508.fsf <at> fencepost.gnu.org>, Glenn Morris <rgm <at> gnu.org> writes:

> Could you comment on this

> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4533#15

I've just installed a fix, and replied to the above message.

> (it seems related to your final comment in bug#1039)

I don't think so.  As I wrote in the mail, it's a simple bug
in insert-file-contents.

---
Kenichi Handa
handa <at> m17n.org

Message #44 received at 4533 <at> emacsbugs.donarmstrong.com (full text, mbox):

From: Glenn Morris <rgm <at> gnu.org>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: reverting fails to update line ending mode line
Date: Thu, 05 Nov 2009 13:47:49 -0500

Kenichi Handa wrote:

>> http://debbugs.gnu.org/cgi/bugreport.cgi?bug=4533#15
>
> I've just installed a fix, and replied to the above message.

Thanks, but it makes no difference for me on GNU/Linux.

I use the same recipe as in the above message, but with "unix2dos"
instead of "dos2unix". I just get "^M" appearing at the ends of lines
on reverting.

Message #47 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Kenichi Handa <handa <at> m17n.org>
Cc: 4533 <at> debbugs.gnu.org
Subject: Re: 23.1: reverting fails to update line ending mode line
Date: Sat, 13 Nov 2010 17:27:18 -0500

> - Start emacs -Q .
> - C-x C-f ~/foo.txt, creating a new file.
> - Enter text:
> Line 1
> Line 2
>
> - C-x C-s.
> - dos2unix ~/foo.txt
> - M-x revert-buffer
> - C-x k RET
> - C-x C-f ~/foo.txt
> Mode line shows --(Unix)---

The problem is that `C-x C-s' sets buffer-file-coding-system-explicit.
This causes revert-buffer to set coding-system-for-read to that value
(which is now incorrect) when inserting the file contents.  This is why
the revert goes correctly if you omit the `C-x C-s' step.

I think the use of buffer-file-coding-system-explicit in revert-buffer
is bogus, and should be removed---see below.  What do you think?


*** lisp/files.el	2010-11-11 22:19:01 +0000
--- lisp/files.el	2010-11-13 22:22:01 +0000
***************
*** 4906,4916 ****
  		   (let ((coding-system-for-read
  			  ;; Auto-saved file should be read by Emacs'
  			  ;; internal coding.
! 			  (if auto-save-p 'auto-save-coding
! 			    (or coding-system-for-read
! 				(and
! 				 buffer-file-coding-system-explicit
! 				 (car buffer-file-coding-system-explicit))))))
  		     (if (and (not enable-multibyte-characters)
  			      coding-system-for-read
  			      (not (memq (coding-system-base
--- 4906,4914 ----
  		   (let ((coding-system-for-read
  			  ;; Auto-saved file should be read by Emacs'
  			  ;; internal coding.
! 			  (if auto-save-p
! 			      'auto-save-coding
! 			    coding-system-for-read)))
  		     (if (and (not enable-multibyte-characters)
  			      coding-system-for-read
  			      (not (memq (coding-system-base

Message #50 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 4533 <at> debbugs.gnu.org, handa <at> m17n.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Sun, 14 Nov 2010 04:51:13 -0500

> From: Chong Yidong <cyd <at> stupidchicken.com>
> Date: Sat, 13 Nov 2010 17:27:18 -0500
> Cc: 4533 <at> debbugs.gnu.org
> 
> > - Start emacs -Q .
> > - C-x C-f ~/foo.txt, creating a new file.
> > - Enter text:
> > Line 1
> > Line 2
> >
> > - C-x C-s.
> > - dos2unix ~/foo.txt
> > - M-x revert-buffer
> > - C-x k RET
> > - C-x C-f ~/foo.txt
> > Mode line shows --(Unix)---
> 
> The problem is that `C-x C-s' sets buffer-file-coding-system-explicit.
> This causes revert-buffer to set coding-system-for-read to that value
> (which is now incorrect) when inserting the file contents.  This is why
> the revert goes correctly if you omit the `C-x C-s' step.

Why is this a real problem?  I can handle this situation with

    C-x RET c undecided RET M-x revert-buffer RET

(Perhaps "C-x RET r" should be fixed to do the same, when given
`undecided' as the encoding.)

> I think the use of buffer-file-coding-system-explicit in revert-buffer
> is bogus, and should be removed---see below.  What do you think?

I'm not sure it's bogus.  Why do you think so?

Perhaps Handa-san remembers why this variable was introduced in the
first place.  I'm sure it was to solve some real-life problems.

Message #53 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 4533 <at> debbugs.gnu.org, handa <at> m17n.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Sun, 14 Nov 2010 12:32:45 -0500

Eli Zaretskii <eliz <at> gnu.org> writes:

> Why is this a real problem?  I can handle this situation with
>
>     C-x RET c undecided RET M-x revert-buffer RET

Sure; you can also kill the buffer and visit the file again with
C-x C-f, making the revert-buffer command redundant.  That's not really
the point.

The fact that revert-buffer correctly changes the coding system if you
do one thing (i.e. visit the file but haven't yet saved), and does
another thing if you do another (i.e. save some changes first) indicates
that this is a real bug.

Message #56 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: Eli Zaretskii <eliz <at> gnu.org>, 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Sun, 14 Nov 2010 21:23:12 +0100

On Sun, Nov 14, 2010 at 6:32 PM, Chong Yidong <cyd <at> stupidchicken.com> wrote:
> Eli Zaretskii <eliz <at> gnu.org> writes:
>
>> Why is this a real problem?  I can handle this situation with
>>
>>     C-x RET c undecided RET M-x revert-buffer RET
>
> Sure; you can also kill the buffer and visit the file again with
> C-x C-f, making the revert-buffer command redundant.  That's not really
> the point.
>
> The fact that revert-buffer correctly changes the coding system if you
> do one thing (i.e. visit the file but haven't yet saved), and does
> another thing if you do another (i.e. save some changes first) indicates
> that this is a real bug.
>

Isn't this bug a duplicated from bug #7383? (Actually, bug #7383 is
about two different problems)

Message #59 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Dani Moncayo <dmoncayo <at> gmail.com>
Cc: cyd <at> stupidchicken.com, 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Sun, 14 Nov 2010 22:46:01 +0200

> Date: Sun, 14 Nov 2010 21:23:12 +0100
> From: Dani Moncayo <dmoncayo <at> gmail.com>
> Cc: Eli Zaretskii <eliz <at> gnu.org>, 4533 <at> debbugs.gnu.org
> 
> Isn't this bug a duplicated from bug #7383? (Actually, bug #7383 is
> about two different problems)

How can bug #4533 be a duplicate of #7383?  Is someone able of
predicting the future?  If so, I'd like to consult him/her about my
stocks.

Message #62 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Sun, 14 Nov 2010 21:55:34 +0100

On Sun, Nov 14, 2010 at 9:46 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> Date: Sun, 14 Nov 2010 21:23:12 +0100
>> From: Dani Moncayo <dmoncayo <at> gmail.com>
>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 4533 <at> debbugs.gnu.org
>>
>> Isn't this bug a duplicated from bug #7383? (Actually, bug #7383 is
>> about two different problems)
>
> How can bug #4533 be a duplicate of #7383?  Is someone able of
> predicting the future?  If so, I'd like to consult him/her about my
> stocks.
>

Yes, the numbering is strange. I noticed that. But check the shipment
dates. Which bug was filed earlier?

Message #65 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Dani Moncayo <dmoncayo <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: cyd <at> stupidchicken.com, 4533 <at> debbugs.gnu.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Sun, 14 Nov 2010 22:47:42 +0100

On Sun, Nov 14, 2010 at 9:55 PM, Dani Moncayo <dmoncayo <at> gmail.com> wrote:
> On Sun, Nov 14, 2010 at 9:46 PM, Eli Zaretskii <eliz <at> gnu.org> wrote:
>>> Date: Sun, 14 Nov 2010 21:23:12 +0100
>>> From: Dani Moncayo <dmoncayo <at> gmail.com>
>>> Cc: Eli Zaretskii <eliz <at> gnu.org>, 4533 <at> debbugs.gnu.org
>>>
>>> Isn't this bug a duplicated from bug #7383? (Actually, bug #7383 is
>>> about two different problems)
>>
>> How can bug #4533 be a duplicate of #7383?  Is someone able of
>> predicting the future?  If so, I'd like to consult him/her about my
>> stocks.
>>
>
> Yes, the numbering is strange. I noticed that. But check the shipment
> dates. Which bug was filed earlier?
>

Ooops, I'm sorry. I don't know how I searched the bugs archives. #4533
it a lot older than #7383. But both are related bugs.

Message #68 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Chong Yidong <cyd <at> stupidchicken.com>
Cc: 4533 <at> debbugs.gnu.org, Kenichi Handa <handa <at> m17n.org>
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Mon, 15 Nov 2010 11:51:36 -0500

> I think the use of buffer-file-coding-system-explicit in revert-buffer
> is bogus, and should be removed---see below.  What do you think?

Its use is not bogus.  It's so that when a file's coding-system is
incorrectly auto-detected, the user can force the use of a correct
coding-system and subsequent revert-buffers won't disregard it.

So maybe the problem is that C-x C-s should not set
buffer-file-coding-system-explicit (unless the C-x C-s prompted the user
to choose  a coding-system, I guess).


        Stefan

Message #71 received at 4533 <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> stupidchicken.com>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: 4533 <at> debbugs.gnu.org, Kenichi Handa <handa <at> m17n.org>
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Mon, 15 Nov 2010 12:27:39 -0500

Stefan Monnier <monnier <at> iro.umontreal.ca> writes:

>> I think the use of buffer-file-coding-system-explicit in revert-buffer
>> is bogus, and should be removed---see below.  What do you think?
>
> Its use is not bogus.  It's so that when a file's coding-system is
> incorrectly auto-detected, the user can force the use of a correct
> coding-system and subsequent revert-buffers won't disregard it.
>
> So maybe the problem is that C-x C-s should not set
> buffer-file-coding-system-explicit (unless the C-x C-s prompted the user
> to choose  a coding-system, I guess).

I see.  The comments in mule.el say that

;; This variable is set in these three cases:
;;   (1) A file is read by a coding system specified explicitly.
;;       after-insert-file-set-coding sets the car of this value to
;;       coding-system-for-read, and sets the cdr to nil.
;;   (2) A buffer is saved.
;;       After writing, basic-save-buffer-1 sets the car of this value
;;       to last-coding-system-used.
;;   (3) set-buffer-file-coding-system is called.
;;       The cdr of this value is set to the specified coding system.
;; This variable is used for decoding in revert-buffer and encoding in
;; select-safe-coding-system.

Indeed, this seems to imply that (2) can be omitted, as you suggest,
since "force selecting" a coding system should trigger (1) and (3).  Is
there any reason that (2) was originally included?

Message #78 received at 4533-done <at> debbugs.gnu.org (full text, mbox):

From: Chong Yidong <cyd <at> gnu.org>
To: Stefan Monnier <monnier <at> iro.umontreal.ca>
Cc: Kenichi Handa <handa <at> m17n.org>, 4533-done <at> debbugs.gnu.org
Subject: Re: bug#4533: 23.1: reverting fails to update line ending mode line
Date: Sun, 10 Feb 2013 11:09:51 +0800

Chong Yidong <cyd <at> stupidchicken.com> writes:

>> So maybe the problem is that C-x C-s should not set
>> buffer-file-coding-system-explicit (unless the C-x C-s prompted the user
>> to choose  a coding-system, I guess).
>
> I see.  The comments in mule.el say that
>
> ;; This variable is set in these three cases:
> ;;   (1) A file is read by a coding system specified explicitly.
> ;;       after-insert-file-set-coding sets the car of this value to
> ;;       coding-system-for-read, and sets the cdr to nil.
> ;;   (2) A buffer is saved.
> ;;       After writing, basic-save-buffer-1 sets the car of this value
> ;;       to last-coding-system-used.
> ;;   (3) set-buffer-file-coding-system is called.
> ;;       The cdr of this value is set to the specified coding system.
> ;; This variable is used for decoding in revert-buffer and encoding in
> ;; select-safe-coding-system.
>
> Indeed, this seems to imply that (2) can be omitted, as you suggest,
> since "force selecting" a coding system should trigger (1) and (3).  Is
> there any reason that (2) was originally included?

Since there's been no response, and my testing showed no ill effects to
this change, I went ahead and committed it in the trunk.  Let's see how
it shakes out.

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.