bug#23709: 24.5; inhibit-eol-conversion breaks archive-7z-summarize

["Peromsik, Aaron" <peromsik@ptc.com>]

[-- Attachment #1: Type: text/plain, Size: 1978 bytes --]

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@gnu.org>
Sent: Tuesday, April 4, 2017 10:29:59 PM
To: Glenn Morris
Cc: Peromsik, Aaron; 23709@debbugs.gnu.org
Subject: Re: bug#23709: 24.5; inhibit-eol-conversion breaks archive-7z-summarize

> From: Glenn Morris <rgm@gnu.org>
> Date: Tue, 04 Apr 2017 16:10:39 -0400
> Cc: 23709@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.

[-- Attachment #2: Type: text/html, Size: 3170 bytes --]