From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: John Wiegley Newsgroups: gmane.emacs.bugs Subject: bug#22819: 25.0.91; Don't try to indent region if the buffer is read-only Date: Wed, 09 Aug 2017 14:14:45 -0700 Message-ID: References: <87vam26amc.fsf@users.sourceforge.net> <83lgmywlo4.fsf@gnu.org> <83y3qtswvv.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/signed; boundary="=-=-="; micalg=pgp-sha512; protocol="application/pgp-signature" X-Trace: blaine.gmane.org 1502313382 31268 195.159.176.226 (9 Aug 2017 21:16:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Aug 2017 21:16:22 +0000 (UTC) User-Agent: Gnus/5.130016 (Ma Gnus v0.16) Emacs/25.2.50 (darwin) Cc: 22819@debbugs.gnu.org, npostavs@users.sourceforge.net To: Kaushal Modi Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 09 23:16:17 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 1dfYKr-0007gL-GK for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Aug 2017 23:16:13 +0200 Original-Received: from localhost ([::1]:49869 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfYKx-0002cL-Pw for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Aug 2017 17:16:19 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37636) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfYKk-0002bm-Ju for bug-gnu-emacs@gnu.org; Wed, 09 Aug 2017 17:16:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dfYKh-0004kg-C2 for bug-gnu-emacs@gnu.org; Wed, 09 Aug 2017 17:16:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:45055) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dfYKh-0004kL-7y for bug-gnu-emacs@gnu.org; Wed, 09 Aug 2017 17:16:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dfYKg-00059k-G5 for bug-gnu-emacs@gnu.org; Wed, 09 Aug 2017 17:16:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: John Wiegley Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Aug 2017 21:16:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 22819 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 22819-submit@debbugs.gnu.org id=B22819.150231330719746 (code B ref 22819); Wed, 09 Aug 2017 21:16:02 +0000 Original-Received: (at 22819) by debbugs.gnu.org; 9 Aug 2017 21:15:07 +0000 Original-Received: from localhost ([127.0.0.1]:53735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfYJj-00058K-JT for submit@debbugs.gnu.org; Wed, 09 Aug 2017 17:15:05 -0400 Original-Received: from mail-pf0-f173.google.com ([209.85.192.173]:33741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfYJi-00057Z-7o for 22819@debbugs.gnu.org; Wed, 09 Aug 2017 17:15:02 -0400 Original-Received: by mail-pf0-f173.google.com with SMTP id h68so32680243pfk.0 for <22819@debbugs.gnu.org>; Wed, 09 Aug 2017 14:15:02 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:date:message-id:references :user-agent:mime-version; bh=ingx9J1Bx08hYcnK9Nshl9YbTeu97SFPDq/RrA9IYJY=; b=Fg3wHqYqwjZui2ICoCCUf3LQitoAuNMWhPY5mR2lJc5R1XAwDMqvzBrdFe2ki7KmGG hFMaHvTdLG+J1j+vGQ2DYHF8JRQGkLMGQLTcU+3Mch2LKOuj3jQK6+z88HNTXiBnWM0p EJ1n7iswcMEk5bB5i48+QQ1QNWtRvLzrPt1BeqQAzJMcbuV6+Kze4ECCFwS1xnaursNe COtgrupE/G/8WH91MexLP5Ccs6cwVfhjgR9iJ1n8WuyY3Un3EXPF8u2YTZAx1jKRwsSQ lTPVyvnBJZfALBu5gchmYYJoGwOpFzlpd4DYaFO41jG9E0LQvVeKsVntlv06zby8WllZ WWNg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:date:message-id :references:user-agent:mime-version; bh=ingx9J1Bx08hYcnK9Nshl9YbTeu97SFPDq/RrA9IYJY=; b=TEXu1MIKlODiYRHLijNAbMHfd8zrKhuzJ388tweLaceuXf73ICh5Q4qePCTmtPGQdI vsztZupzpv6GYYY/QXDSBzZ2CMLUwG5qitZNrLPaL+JXwRQ1Zo0Nvg0gF2WhOOhcE7eZ QZdd9dwSHSO9f0zU/MR9LX3/pyOUa3dR5vBXUXd+IJ3M38RQr4CghRmGbMrtTIVqleTR gXhdQ5M5fPSuDmnvDLZ1Vr53Q4x4TO9grW1zyml8JjfiGYA8P0PURSU/3VbEbo+AwSoz TXXYyHNQ8rbQXRDHt4Uu5NT3i+HWVkRh9RRmbnU2bcIkZ+Seg7srXQB0JlhUOc4BmxFx uQbQ== X-Gm-Message-State: AHYfb5jLSU9jdVJEXd3lRIl/dzcSrU4wdpjdgLFuuc5h09/Fa73qfUYQ 76SpBFqd6u458afJp5o= X-Received: by 10.99.1.203 with SMTP id 194mr8852893pgb.315.1502313296063; Wed, 09 Aug 2017 14:14:56 -0700 (PDT) Original-Received: from Vulcan.local (76-234-69-149.lightspeed.frokca.sbcglobal.net. [76.234.69.149]) by smtp.gmail.com with ESMTPSA id 66sm8736315pfq.20.2017.08.09.14.14.53 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Wed, 09 Aug 2017 14:14:53 -0700 (PDT) X-Google-Original-From: "John Wiegley" Original-Received: by Vulcan.local (Postfix, from userid 501) id 9D45178E121C; Wed, 9 Aug 2017 14:14:52 -0700 (PDT) In-Reply-To: (Kaushal Modi's message of "Wed, 09 Aug 2017 11:03:34 +0000") 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:135608 Archived-At: --=-=-= Content-Type: text/plain Content-Transfer-Encoding: quoted-printable >>>>> Kaushal Modi writes: > Understood. My only hope that I can convince the maintainers with my reas= on > that this proposal fixes a real-life problem with the help democratic vot= ing > system (if the opinions asked on emacs-devel matter and can be called tha= t). That's fair, though we still need to be personally convinced. :) Ancient behavior has a mystique that requires a fair bit of motivation for us to change. It really just comes down to the fact that Eli and I are conservati= ve fellows in these things. > Wouldn't the master branch be a good playground for this? If it affects > people negatively, it's just a one-line commit and thus easy to revert. I'm not sure enough people use the master branch for it to determine how it will affect the majority. In all likelihood it won't affect anyone badly at all (I don't really see h= ow it could), it's just not something we need to do today. I'm fine with keepi= ng the issue open, though. My preference would be that another solution will solve this, and all similar issues, by way of a better design. Otherwise, we're picking at gnats in a sensitive area (i.e., long-held behavior). > I should have used the term "wall time". This issue has wasted quite a few > minutes for me. Understood. > Of course. I will do that. I was just hoping the "right fix" would get in. > (Otherwise why would anyone bother to submit bug reports and patches?) You're making us aware of bad implementation decisions made long ago, which are good to know about. There have been other, fairly long, debates on the meaning of the "read-only" bit, and when a buffer should get marked as modified. I'm sure these issues relate to yours as well. For example: shoul= d a buffer-modifying operation be aborted early even if the actual operation of the function won't change anything? People argue that M-q shouldn't mark a buffer as modified if the reformatting changes nothing: does that mean M-q should be allowed on a read-only buffer if it doesn't modify, or should it abort early because its makes no sense? And how many people have built up macros or customizations or custom functi= ons in their configuration that rely on ultimately-non-modifying operations bei= ng allowed in read-only buffers, rather than turning them into errors? Arguably their code is "wrong", but how much of their time should we waste by fixing this and causing their keyboard macros to break? I realize my argument tends toward "change nothing", but that's not what I mean. I'm only saying that there's a lot of users to be considered, so unle= ss we *need* to risk breakage, we prefer to avoid it. The current behavior has been around for a long, long time, and while it's painful for your use case= , I know you have the expertise to advise Emacs as needed. > I haven't yet got an answer to a real-life scenario that would break by t= his > change. What kind of (i) side-effects would one be relying on (ii) while > running indent-region (iii) on read-only files? >=20 > It's a bit sad, I am presenting a solution to a real problem and the coun= ter > argument is just one, and hypothetical. We don't normally have any counter-evidence that an old, bad behavior *shou= ld* be kept. It's more an argument that we don't change them until we're convin= ced it's time. =2D-=20 John Wiegley GPG fingerprint =3D 4710 CF98 AF9B 327B B80F http://newartisans.com 60E1 46C4 BD1A 7AC1 4BA2 --=-=-= Content-Type: application/pgp-signature; name="signature.asc" -----BEGIN PGP SIGNATURE----- iQGzBAEBCgAdFiEE3lW3afxXihSlvlQwwUTY9PGf5jAFAlmLe0UACgkQwUTY9PGf 5jBMnQv/VhrOeKL0kawJK5n6iQHQVHwhVbQD9/HcuWPB99p1vge+qSFb34T5C36H 0hD04Ytl9MDCZTbrLDf0ubHSCY2FQ/x4Xzx7EFbz8rvXZ99kMEHIrdP1DMqXcMjb uyYqo1LSnlUShzwe/wD1e3dXfcgOyK4a2oQL0n1Ee8W8oazDgSlF5ZToeLXXkXQR EjXJrK0WpL4/2DkXS7IMJulR7ItRPQrz/3h7dvjxrEalcn+bIGmYGn95H3HjFzu9 fdWvy0n2EqAyDDFzH8rLXbAEb82vetsQtTGsS2qNTgLz98qeUsMWHXN2sYhJIXoy 9D+TwSP6RDQvGXVDEkqOjOyOL0RlbPVODPuHNzjckaF9e5YTAcrVFsiO6yNzL5Jw Dxzm6dkOvCVuC+q0DW2CLL2hKTQW4lmlptQ9uIx+7qVlQrzUGK6eLpm0c+7SKdRL jX+0UpU5kfzekzhFCaFe18H41aa/r3eTF9L1ce8KVB7Hx9qvX1U1aLccBFe5t+Ow 9oqVLC1S =jLul -----END PGP SIGNATURE----- --=-=-=--