* bug#4533: 23.1: reverting fails to update line ending mode line
@ 2009-09-23 2:01 Benjamin Peterson
2009-10-03 0:16 ` Glenn Morris
` (2 more replies)
0 siblings, 3 replies; 13+ messages in thread
From: Benjamin Peterson @ 2009-09-23 2:01 UTC (permalink / raw)
To: bug-gnu-emacs
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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2009-09-23 2:01 bug#4533: 23.1: reverting fails to update line ending mode line Benjamin Peterson
@ 2009-10-03 0:16 ` Glenn Morris
2009-11-05 4:17 ` Kenichi Handa
2010-11-13 22:27 ` Chong Yidong
2 siblings, 0 replies; 13+ messages in thread
From: Glenn Morris @ 2009-10-03 0:16 UTC (permalink / raw)
To: Benjamin Peterson; +Cc: 4533
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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2009-09-23 2:01 bug#4533: 23.1: reverting fails to update line ending mode line Benjamin Peterson
2009-10-03 0:16 ` Glenn Morris
@ 2009-11-05 4:17 ` Kenichi Handa
2010-11-13 22:27 ` Chong Yidong
2 siblings, 0 replies; 13+ messages in thread
From: Kenichi Handa @ 2009-11-05 4:17 UTC (permalink / raw)
To: Benjamin Peterson, 4533; +Cc: bug-gnu-emacs
In article <1afaf6160909221901p527cca80jcbf81e589cde629d@mail.gmail.com>, Benjamin Peterson <benjamin@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@m17n.org
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2009-09-23 2:01 bug#4533: 23.1: reverting fails to update line ending mode line Benjamin Peterson
2009-10-03 0:16 ` Glenn Morris
2009-11-05 4:17 ` Kenichi Handa
@ 2010-11-13 22:27 ` Chong Yidong
2010-11-14 9:51 ` Eli Zaretskii
2010-11-15 16:51 ` Stefan Monnier
2 siblings, 2 replies; 13+ messages in thread
From: Chong Yidong @ 2010-11-13 22:27 UTC (permalink / raw)
To: Kenichi Handa; +Cc: 4533
> - 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-13 22:27 ` Chong Yidong
@ 2010-11-14 9:51 ` Eli Zaretskii
2010-11-14 17:32 ` Chong Yidong
2010-11-15 16:51 ` Stefan Monnier
1 sibling, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2010-11-14 9:51 UTC (permalink / raw)
To: Chong Yidong; +Cc: 4533
> From: Chong Yidong <cyd@stupidchicken.com>
> Date: Sat, 13 Nov 2010 17:27:18 -0500
> Cc: 4533@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-14 9:51 ` Eli Zaretskii
@ 2010-11-14 17:32 ` Chong Yidong
2010-11-14 20:23 ` Dani Moncayo
0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2010-11-14 17:32 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 4533
Eli Zaretskii <eliz@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-14 17:32 ` Chong Yidong
@ 2010-11-14 20:23 ` Dani Moncayo
2010-11-14 20:46 ` Eli Zaretskii
0 siblings, 1 reply; 13+ messages in thread
From: Dani Moncayo @ 2010-11-14 20:23 UTC (permalink / raw)
To: Chong Yidong; +Cc: 4533
On Sun, Nov 14, 2010 at 6:32 PM, Chong Yidong <cyd@stupidchicken.com> wrote:
> Eli Zaretskii <eliz@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)
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-14 20:23 ` Dani Moncayo
@ 2010-11-14 20:46 ` Eli Zaretskii
2010-11-14 20:55 ` Dani Moncayo
0 siblings, 1 reply; 13+ messages in thread
From: Eli Zaretskii @ 2010-11-14 20:46 UTC (permalink / raw)
To: Dani Moncayo; +Cc: cyd, 4533
> Date: Sun, 14 Nov 2010 21:23:12 +0100
> From: Dani Moncayo <dmoncayo@gmail.com>
> Cc: Eli Zaretskii <eliz@gnu.org>, 4533@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-14 20:46 ` Eli Zaretskii
@ 2010-11-14 20:55 ` Dani Moncayo
2010-11-14 21:47 ` Dani Moncayo
0 siblings, 1 reply; 13+ messages in thread
From: Dani Moncayo @ 2010-11-14 20:55 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, 4533
On Sun, Nov 14, 2010 at 9:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Sun, 14 Nov 2010 21:23:12 +0100
>> From: Dani Moncayo <dmoncayo@gmail.com>
>> Cc: Eli Zaretskii <eliz@gnu.org>, 4533@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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-14 20:55 ` Dani Moncayo
@ 2010-11-14 21:47 ` Dani Moncayo
0 siblings, 0 replies; 13+ messages in thread
From: Dani Moncayo @ 2010-11-14 21:47 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: cyd, 4533
On Sun, Nov 14, 2010 at 9:55 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> On Sun, Nov 14, 2010 at 9:46 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>>> Date: Sun, 14 Nov 2010 21:23:12 +0100
>>> From: Dani Moncayo <dmoncayo@gmail.com>
>>> Cc: Eli Zaretskii <eliz@gnu.org>, 4533@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-13 22:27 ` Chong Yidong
2010-11-14 9:51 ` Eli Zaretskii
@ 2010-11-15 16:51 ` Stefan Monnier
2010-11-15 17:27 ` Chong Yidong
1 sibling, 1 reply; 13+ messages in thread
From: Stefan Monnier @ 2010-11-15 16:51 UTC (permalink / raw)
To: Chong Yidong; +Cc: 4533
> 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
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-15 16:51 ` Stefan Monnier
@ 2010-11-15 17:27 ` Chong Yidong
2013-02-10 3:09 ` Chong Yidong
0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2010-11-15 17:27 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 4533
Stefan Monnier <monnier@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?
^ permalink raw reply [flat|nested] 13+ messages in thread
* bug#4533: 23.1: reverting fails to update line ending mode line
2010-11-15 17:27 ` Chong Yidong
@ 2013-02-10 3:09 ` Chong Yidong
0 siblings, 0 replies; 13+ messages in thread
From: Chong Yidong @ 2013-02-10 3:09 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 4533-done, Kenichi Handa
Chong Yidong <cyd@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.
^ permalink raw reply [flat|nested] 13+ messages in thread
end of thread, other threads:[~2013-02-10 3:09 UTC | newest]
Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2009-09-23 2:01 bug#4533: 23.1: reverting fails to update line ending mode line Benjamin Peterson
2009-10-03 0:16 ` Glenn Morris
2009-11-05 4:17 ` Kenichi Handa
2010-11-13 22:27 ` Chong Yidong
2010-11-14 9:51 ` Eli Zaretskii
2010-11-14 17:32 ` Chong Yidong
2010-11-14 20:23 ` Dani Moncayo
2010-11-14 20:46 ` Eli Zaretskii
2010-11-14 20:55 ` Dani Moncayo
2010-11-14 21:47 ` Dani Moncayo
2010-11-15 16:51 ` Stefan Monnier
2010-11-15 17:27 ` Chong Yidong
2013-02-10 3:09 ` Chong Yidong
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).