bug#4533: 23.1: reverting fails to update line ending mode line
Glenn Morris
> 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.
Kenichi Handa
> 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
ha...@m17n.org
Kenichi Handa
Chong Yidong
> - 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
Eli Zaretskii
> Date: Sat, 13 Nov 2010 17:27:18 -0500
> Cc: 45...@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.
Chong Yidong
> 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.
Dani Moncayo
Isn't this bug a duplicated from bug #7383? (Actually, bug #7383 is
about two different problems)
Dani Moncayo
>> Date: Sun, 14 Nov 2010 21:23:12 +0100
>> From: Dani Moncayo <dmon...@gmail.com>
>> Cc: Eli Zaretskii <el...@gnu.org>, 45...@debbugs.gnu.org
>>
>> Isn't this bug a duplicated from bug #7383? (Actually, bug #7383 is
>> about two different problems)
>
> 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?
Eli Zaretskii
Dani Moncayo
> On Sun, Nov 14, 2010 at 9:46 PM, Eli Zaretskii <el...@gnu.org> wrote:
> 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.
Stefan Monnier
> 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
Chong Yidong
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?
Chong Yidong
>> 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?
this change, I went ahead and committed it in the trunk. Let's see how
it shakes out.