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

[Eli Zaretskii]

> From: "Peromsik, Aaron" <peromsik@ptc.com>
> CC: "rgm@gnu.org" <rgm@gnu.org>, "23709@debbugs.gnu.org"
>       <23709@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.