From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#23709: 24.5; inhibit-eol-conversion breaks archive-7z-summarize Date: Fri, 07 Apr 2017 10:05:18 +0300 Message-ID: <838tncofyp.fsf@gnu.org> References: <9zpeg8a0yxz.fsf@PEROMSIK0D.i-did-not-set--mail-host-address--so-tickle-me> <6zo9wcc4sg.fsf@fencepost.gnu.org>,<83tw63oac8.fsf@gnu.org> , <83pogqondg.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1491548776 4121 195.159.176.226 (7 Apr 2017 07:06:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Apr 2017 07:06:16 +0000 (UTC) Cc: 23709@debbugs.gnu.org To: "Peromsik\, Aaron" Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri Apr 07 09:06:10 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwNyC-0000BM-VS for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Apr 2017 09:06:09 +0200 Original-Received: from localhost ([::1]:49295 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwNyH-00057M-8c for geb-bug-gnu-emacs@m.gmane.org; Fri, 07 Apr 2017 03:06:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:49448) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwNyB-000576-5J for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2017 03:06:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cwNy6-00006Y-Ld for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2017 03:06:07 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:37485) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1cwNy6-00006S-HD for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2017 03:06:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1cwNy6-0004py-7f for bug-gnu-emacs@gnu.org; Fri, 07 Apr 2017 03:06:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 07 Apr 2017 07:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 23709 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 23709-submit@debbugs.gnu.org id=B23709.149154872818551 (code B ref 23709); Fri, 07 Apr 2017 07:06:02 +0000 Original-Received: (at 23709) by debbugs.gnu.org; 7 Apr 2017 07:05:28 +0000 Original-Received: from localhost ([127.0.0.1]:35684 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwNxY-0004p9-5D for submit@debbugs.gnu.org; Fri, 07 Apr 2017 03:05:28 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:58367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1cwNxW-0004ou-OE for 23709@debbugs.gnu.org; Fri, 07 Apr 2017 03:05:27 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1cwNxN-0008Mh-12 for 23709@debbugs.gnu.org; Fri, 07 Apr 2017 03:05:21 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:34219) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1cwNxM-0008Md-U3; Fri, 07 Apr 2017 03:05:16 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4502 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1cwNxI-0000KE-Jm; Fri, 07 Apr 2017 03:05:13 -0400 In-reply-to: (peromsik@ptc.com) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:131326 Archived-At: > From: "Peromsik, Aaron" > CC: "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.