GNU bug report logs -
#23709
24.5; inhibit-eol-conversion breaks archive-7z-summarize
Previous Next
To reply to this bug, email your comments to 23709 AT debbugs.gnu.org.
Toggle the display of automated, internal messages from the tracker.
Report forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Mon, 06 Jun 2016 21:54:02 GMT)
Full text and
rfc822 format available.
Acknowledgement sent
to
<peromsik <at> ptc.com>:
New bug report received and forwarded. Copy sent to
bug-gnu-emacs <at> gnu.org.
(Mon, 06 Jun 2016 21:54:02 GMT)
Full text and
rfc822 format available.
Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):
M-x set-variable inhibit-eol-conversion t
Then try to open a 7z file. The expected summary does not appear. In the
*Messages* buffer (quoted below) you can see that the re-search-forward
call in archive-7z-summarize is confused by the ^M in the output of the
7za command. Perhaps adding inhibit-eol-conversion nil to that function's
let block would be in order?
In GNU Emacs 24.5.1 (x86_64-w64-mingw32)
of 2015-04-12 on KAEL
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/z/emacs --host=x86_64-w64-mingw32
--target=x86_64-w64-mingw32 --build=x86_64-w64-mingw32 --with-wide-int
--with-jpeg --with-xpm --with-png --with-tiff --with-rsvg --with-xml2
--with-gnutls --with-sound=yes --with-file-notification=yes
--without-dbus --without-imagemagick 'CFLAGS=-Ofast
-fomit-frame-pointer -funroll-loops -g0 -pipe' 'LDFLAGS=-static-libgcc
-static-libstdc++ -static -s -Wl,-s''
Important settings:
value of $LANG: C
locale-coding-system: cp1252
Major mode: Lisp Interaction
Minor modes in effect:
tooltip-mode: t
electric-indent-mode: t
mouse-wheel-mode: t
tool-bar-mode: t
menu-bar-mode: t
file-name-shadow-mode: t
global-font-lock-mode: t
font-lock-mode: t
blink-cursor-mode: t
auto-composition-mode: t
auto-encryption-mode: t
auto-compression-mode: t
line-number-mode: t
transient-mark-mode: t
Recent messages:
For information about GNU Emacs and the GNU system, type C-h C-a.
Making completion list...
Parsing archive file...
File mode specification error: (search-failed "^-----+
")
Type C-x 1 to delete the help window.
You can run the command `view-lossage' with C-h l
Type C-x 1 to delete the help window.
Load-path shadows:
None found.
Features:
(shadow sort gnus-util mail-extr emacsbug message format-spec rfc822 mml
mml-sec mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev
gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util
mail-prsvr mail-utils arc-mode archive-mode help-mode cus-edit easymenu
wid-edit cl-loaddefs cl-lib cus-start cus-load help-fns time-date
tooltip electric uniquify ediff-hook vc-hooks lisp-float-type mwheel
dos-w32 ls-lisp w32-common-fns disp-table w32-win w32-vars tool-bar dnd
fontset image regexp-opt fringe tabulated-list newcomment lisp-mode
prog-mode register page menu-bar rfn-eshadow timer select scroll-bar
mouse jit-lock font-lock syntax facemenu font-core frame cham georgian
utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean
japanese hebrew greek romanian slovak czech european ethiopic indian
cyrillic chinese case-table epa-hook jka-cmpr-hook help simple abbrev
minibuffer nadvice loaddefs button faces cus-face macroexp files
text-properties overlay sha1 md5 base64 format env code-pages mule
custom widget hashtable-print-readable backquote make-network-process
w32notify w32 multi-tty emacs)
Memory information:
((conses 16 96517 6281)
(symbols 56 19445 0)
(miscs 48 38 117)
(strings 32 16504 3894)
(string-bytes 1 432330)
(vectors 16 10255)
(vector-slots 8 388189 6479)
(floats 8 67 162)
(intervals 56 240 47)
(buffers 960 14))
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Tue, 04 Apr 2017 20:11:01 GMT)
Full text and
rfc822 format available.
Message #8 received at 23709 <at> debbugs.gnu.org (full text, mbox):
> M-x set-variable inhibit-eol-conversion t
>
> Then try to open a 7z file. The expected summary does not appear. In the
> *Messages* buffer (quoted below) you can see that the re-search-forward
> call in archive-7z-summarize is confused by the ^M in the output of the
> 7za command. Perhaps adding inhibit-eol-conversion nil to that function's
> let block would be in order?
Thanks for the report. I wonder if inhibit-eol-conversion should not
apply to processes, or should only apply to buffers visiting files, or
if there should be a process-specific version of i-e-c? Because as it
stands I think several places will break if ^M appears in process output
(eg vc-bzr). Binding inhibit-eol-conversion to nil around every single
process call doesn't sound sensible. But then term.el does the opposite,
binding it to t. Hmm. So maybe a process-specific version of
inhibit-eol-conversion, defaulting to nil?
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Wed, 05 Apr 2017 02:31:02 GMT)
Full text and
rfc822 format available.
Message #11 received at 23709 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Tue, 04 Apr 2017 16:10:39 -0400
> Cc: 23709 <at> debbugs.gnu.org
>
>
> > M-x set-variable inhibit-eol-conversion t
> >
> > Then try to open a 7z file. The expected summary does not appear. In the
> > *Messages* buffer (quoted below) you can see that the re-search-forward
> > call in archive-7z-summarize is confused by the ^M in the output of the
> > 7za command. Perhaps adding inhibit-eol-conversion nil to that function's
> > let block would be in order?
>
> Thanks for the report. I wonder if inhibit-eol-conversion should not
> apply to processes, or should only apply to buffers visiting files, or
> if there should be a process-specific version of i-e-c? Because as it
> stands I think several places will break if ^M appears in process output
> (eg vc-bzr). Binding inhibit-eol-conversion to nil around every single
> process call doesn't sound sensible. But then term.el does the opposite,
> binding it to t. Hmm. So maybe a process-specific version of
> inhibit-eol-conversion, defaulting to nil?
Why is the OP setting this variable to begin with?
I think that a user who sets this variable, as opposed to let-binding
it for a single operation, is shooting themselves in the foot. This
is not how this variable is supposed to be used. Just don't do that.
Any solution we would try to invent for this is going to bite us
somewhere.
If there are good reasons for setting this variable globally, let's
hear them. I'm not aware of any use patterns which would require
that.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Wed, 05 Apr 2017 14:15:01 GMT)
Full text and
rfc822 format available.
Message #14 received at 23709 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
I set it in my .emacs years ago, so I can't be sure. That said, I think it was probably because I almost never want to write a file with Windows line endings.
________________________________
From: Eli Zaretskii <eliz <at> gnu.org>
Sent: Tuesday, April 4, 2017 10:29:59 PM
To: Glenn Morris
Cc: Peromsik, Aaron; 23709 <at> debbugs.gnu.org
Subject: Re: bug#23709: 24.5; inhibit-eol-conversion breaks archive-7z-summarize
> From: Glenn Morris <rgm <at> gnu.org>
> Date: Tue, 04 Apr 2017 16:10:39 -0400
> Cc: 23709 <at> debbugs.gnu.org
>
>
> > M-x set-variable inhibit-eol-conversion t
> >
> > Then try to open a 7z file. The expected summary does not appear. In the
> > *Messages* buffer (quoted below) you can see that the re-search-forward
> > call in archive-7z-summarize is confused by the ^M in the output of the
> > 7za command. Perhaps adding inhibit-eol-conversion nil to that function's
> > let block would be in order?
>
> Thanks for the report. I wonder if inhibit-eol-conversion should not
> apply to processes, or should only apply to buffers visiting files, or
> if there should be a process-specific version of i-e-c? Because as it
> stands I think several places will break if ^M appears in process output
> (eg vc-bzr). Binding inhibit-eol-conversion to nil around every single
> process call doesn't sound sensible. But then term.el does the opposite,
> binding it to t. Hmm. So maybe a process-specific version of
> inhibit-eol-conversion, defaulting to nil?
Why is the OP setting this variable to begin with?
I think that a user who sets this variable, as opposed to let-binding
it for a single operation, is shooting themselves in the foot. This
is not how this variable is supposed to be used. Just don't do that.
Any solution we would try to invent for this is going to bite us
somewhere.
If there are good reasons for setting this variable globally, let's
hear them. I'm not aware of any use patterns which would require
that.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Wed, 05 Apr 2017 15:57:02 GMT)
Full text and
rfc822 format available.
Message #17 received at 23709 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> Why is the OP setting this variable to begin with?
>
> I think that a user who sets this variable, as opposed to let-binding
> it for a single operation, is shooting themselves in the foot. This
> is not how this variable is supposed to be used. Just don't do that.
> Any solution we would try to invent for this is going to bite us
> somewhere.
>
> If there are good reasons for setting this variable globally, let's
> hear them. I'm not aware of any use patterns which would require
> that.
It's a customizable user option. It seems perfectly valid to me to set
it globally, for the reasons given in the manual:
some people prefer this to the more subtle '(DOS)' end-of-line type
indication near the left edge of the mode line
I've had it set in my own .emacs for years, as it happens.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Wed, 05 Apr 2017 16:01:01 GMT)
Full text and
rfc822 format available.
Message #20 received at 23709 <at> debbugs.gnu.org (full text, mbox):
> From: "Peromsik, Aaron" <peromsik <at> ptc.com>
> CC: "23709 <at> debbugs.gnu.org" <23709 <at> debbugs.gnu.org>
> Date: Wed, 5 Apr 2017 14:14:05 +0000
>
> I set it in my .emacs years ago, so I can't be sure.
May I suggest to unset it now and see if you have any problems?
> That said, I think it was probably because I almost never
> want to write a file with Windows line endings.
On what OS? If on Windows, then the "official" way of doing that is
to use add-untranslated-filesystem. You could also set up the default
for buffer-file-coding-system to be SOMETHING-unix.
If you want that on Unix, then I don't think I understand your
original problem: Emacs on Windows doesn't save files with Windows
line endings, unless they had Windows line endings before you visited
them, and in the latter case setting inhibit-eol-conversion will not
help you in any way.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Wed, 05 Apr 2017 16:11:02 GMT)
Full text and
rfc822 format available.
Message #23 received at 23709 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: peromsik <at> ptc.com, 23709 <at> debbugs.gnu.org
> Date: Wed, 05 Apr 2017 11:56:20 -0400
>
> > If there are good reasons for setting this variable globally, let's
> > hear them. I'm not aware of any use patterns which would require
> > that.
>
> It's a customizable user option. It seems perfectly valid to me to set
> it globally, for the reasons given in the manual:
>
> some people prefer this to the more subtle '(DOS)' end-of-line type
> indication near the left edge of the mode line
>
> I've had it set in my own .emacs for years, as it happens.
Doesn't sound like good reasons to me, sorry. I'm guessing this
variable was made a defcustom under pressure from people who didn't
want to see "(DOS)". Me, I just modified the indicator to be just a
single backslash.
You are shooting yourself in the foot if you set this globally. Of
course, Emacs users should be free to do that, as part of their
freedom, but we don't need to bother "fixing" such use cases by
binding the variable in every place where its being non-nil could
break standard features.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Wed, 05 Apr 2017 19:59:01 GMT)
Full text and
rfc822 format available.
Message #26 received at 23709 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii wrote:
> I'm guessing this variable was made a defcustom under pressure from
> people who didn't want to see "(DOS)".
There's no evidence for this.
> You are shooting yourself in the foot if you set this globally. Of
> course, Emacs users should be free to do that, as part of their
> freedom, but we don't need to bother "fixing" such use cases by
> binding the variable in every place where its being non-nil could
> break standard features.
I find this a strange response.
"This is a user option, but users shouldn't set it".
It's been a user option since at least 1999.
The "some people prefer this" text was added by you in 2001.
If you don't want to support it, make it not a user option,
and stop documenting it in the user manual.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Thu, 06 Apr 2017 02:34:01 GMT)
Full text and
rfc822 format available.
Message #29 received at 23709 <at> debbugs.gnu.org (full text, mbox):
> From: Glenn Morris <rgm <at> gnu.org>
> Cc: peromsik <at> ptc.com, 23709 <at> debbugs.gnu.org
> Date: Wed, 05 Apr 2017 15:58:16 -0400
>
> If you don't want to support it, make it not a user option,
That's what it was originally.
Anyway, what's the alternative? If only a couple of features need to
forcefully bind it to nil, that's acceptable. But my impression was
that we will now have to bind it almost everywhere, in which case
making it not an option is a better way, IMO.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Thu, 06 Apr 2017 21:59:01 GMT)
Full text and
rfc822 format available.
Message #32 received at 23709 <at> debbugs.gnu.org (full text, mbox):
[Message part 1 (text/plain, inline)]
> Emacs on Windows doesn't save files with Windows
> line endings, unless they had Windows line endings before you visited
> them, and in the latter case setting inhibit-eol-conversion will not
> help you in any way.
Not quite true. It does help me in that I can see the Windows line endings and manually remove them.
> But my impression was
> that we will now have to bind it almost everywhere, in which case
> making it not an option is a better way, IMO.
As I said, I have been happily using this option for years. archive-7z-summarize was the first thing I noticed not working because of it-- if you don't count failure to remove ^M's on paste, which I am used to by now. Since I filed this bug report I have been happily continuing along my way with a let binding in advice for archive-7z-summarize. So I suspect your fears might be overblown.
[Message part 2 (text/html, inline)]
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Fri, 07 Apr 2017 07:06:02 GMT)
Full text and
rfc822 format available.
Message #35 received at 23709 <at> debbugs.gnu.org (full text, mbox):
> From: "Peromsik, Aaron" <peromsik <at> ptc.com>
> CC: "rgm <at> gnu.org" <rgm <at> gnu.org>, "23709 <at> debbugs.gnu.org"
> <23709 <at> debbugs.gnu.org>
> Date: Thu, 6 Apr 2017 21:58:01 +0000
>
> > Emacs on Windows doesn't save files with Windows
> > line endings, unless they had Windows line endings before you visited
> > them, and in the latter case setting inhibit-eol-conversion will not
> > help you in any way.
>
> Not quite true. It does help me in that I can see the Windows line endings and manually remove them.
If you want to remove them, just saving the file after typing "C-x RET
f unix RET" is a more efficient way than removing the CR characters by
hand. (You can make the combination of the above with "C-x C-s" a
function bound to a key, so invoking it will be a snap.) The
indication in the mode line clearly shows that the file has Windows
EOL format, so you know when to apply that.
> > But my impression was
> > that we will now have to bind it almost everywhere, in which case
> > making it not an option is a better way, IMO.
>
> As I said, I have been happily using this option for years.
I was referring to what Glenn proposed as a remedy.
Anyway, I suggest to review this setting, because Emacs development
didn't stall since then. You might find that there are better
solutions for the problems you had back then, and some problems might
not exist at all.
> archive-7z-summarize was the first thing I noticed
> not working because of it-- if you don't count failure to remove ^M's on paste, which I am used to by now.
> Since I filed this bug report I have been happily continuing along my way with a let binding in advice for
> archive-7z-summarize. So I suspect your fears might be overblown.
I'm okay with fixing this for archive-7z-summarize by forcing the
variable to have the right value, if that solves your problem (does
it?). But I'm opposed to inventing yet another, separate option for
reading sub-process output, as proposed by Glenn, primarily because I
don't think it will solve problems such as this one. I'm also opposed
to introducing any other significant infrastructure for similar use
cases, because I think having inhibit-eol-conversion globally non-nil
is a thing of the past, and there are nowadays much better and less
intrusive solutions for whatever problems people had when the related
features were first introduced into Emacs 20 years ago.
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Wed, 14 Feb 2018 11:35:02 GMT)
Full text and
rfc822 format available.
Message #38 received at 23709 <at> debbugs.gnu.org (full text, mbox):
Eli Zaretskii <eliz <at> gnu.org> writes:
>> It's a customizable user option. It seems perfectly valid to me to set
>> it globally, for the reasons given in the manual:
>>
>> some people prefer this to the more subtle '(DOS)' end-of-line type
>> indication near the left edge of the mode line
>>
>> I've had it set in my own .emacs for years, as it happens.
>
> I'm guessing this variable was made a defcustom under pressure from
> people who didn't want to see "(DOS)".
I think it's rather from people who *can't* see "(DOS)" (not literally
"can't", but find the indicator easy to miss). I came across a post [1]
about this recently (the post itself is from 2016):
Many versions ago, if you opened a dos-line-end file on Linux you
would see the extra ^M codes. Now it automatically recognizes the
situation and puts "DOS" in the info bar and hides the extra ^Ms.
How can I exit "DOS" mode and switch back to Unix mode? How can I
disable the auto-detection and force the files to be opened with
Unix line endings and the DOS CR shown as ^M?
And a further comment from the OP about it:
I guess there isn't really a compelling reason for it except that I
only occasionally encounter dos files and I was used to that obvious
visual cue of all the ^M's when I open one.
So this does sound like it's all about files. If inhibit-eol-conversion
is problematic, maybe a setting for file-coding-system-alist would be a
better recommendation?
[1]: https://emacs.stackexchange.com/questions/24984/how-to-disable-automatic-dos-mode/38576
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Wed, 14 Feb 2018 11:52:01 GMT)
Full text and
rfc822 format available.
Message #41 received at 23709 <at> debbugs.gnu.org (full text, mbox):
On Feb 14 2018, Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
> And a further comment from the OP about it:
>
> I guess there isn't really a compelling reason for it except that I
> only occasionally encounter dos files and I was used to that obvious
> visual cue of all the ^M's when I open one.
>
> So this does sound like it's all about files. If inhibit-eol-conversion
> is problematic, maybe a setting for file-coding-system-alist would be a
> better recommendation?
Probably setting the last element to '("" undecided-unix) will do.
Andreas.
--
Andreas Schwab, SUSE Labs, schwab <at> suse.de
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE 1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."
Information forwarded
to
bug-gnu-emacs <at> gnu.org:
bug#23709; Package
emacs.
(Thu, 15 Feb 2018 01:40:01 GMT)
Full text and
rfc822 format available.
Message #44 received at 23709 <at> debbugs.gnu.org (full text, mbox):
Andreas Schwab <schwab <at> suse.de> writes:
> On Feb 14 2018, Noam Postavsky <npostavs <at> users.sourceforge.net> wrote:
>
>> So this does sound like it's all about files. If inhibit-eol-conversion
>> is problematic, maybe a setting for file-coding-system-alist would be a
>> better recommendation?
>
> Probably setting the last element to '("" undecided-unix) will do.
I'm not sure: it will be overriden by some earlier elements. That's
correct for the no-conversion entries, but maybe not the others.
This bug report was last modified 7 years and 127 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.