From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Kaushal Modi 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 11:03:34 +0000 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/alternative; boundary="001a114942cc9fef02055650082c" X-Trace: blaine.gmane.org 1502276651 14143 195.159.176.226 (9 Aug 2017 11:04:11 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Wed, 9 Aug 2017 11:04:11 +0000 (UTC) Cc: 22819@debbugs.gnu.org, npostavs@users.sourceforge.net To: John Wiegley Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Aug 09 13:04:06 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 1dfOmT-0003S6-Bu for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Aug 2017 13:04:05 +0200 Original-Received: from localhost ([::1]:46793 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfOmZ-0006Uo-Kp for geb-bug-gnu-emacs@m.gmane.org; Wed, 09 Aug 2017 07:04:11 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33559) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1dfOmT-0006UH-5Z for bug-gnu-emacs@gnu.org; Wed, 09 Aug 2017 07:04:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1dfOmQ-0005vr-Cj for bug-gnu-emacs@gnu.org; Wed, 09 Aug 2017 07:04:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:44011) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1dfOmQ-0005vk-9F for bug-gnu-emacs@gnu.org; Wed, 09 Aug 2017 07:04:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1dfOmQ-0003eh-1b for bug-gnu-emacs@gnu.org; Wed, 09 Aug 2017 07:04:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kaushal Modi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 09 Aug 2017 11:04: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.150227663514037 (code B ref 22819); Wed, 09 Aug 2017 11:04:02 +0000 Original-Received: (at 22819) by debbugs.gnu.org; 9 Aug 2017 11:03:55 +0000 Original-Received: from localhost ([127.0.0.1]:52692 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfOmH-0003eK-Ek for submit@debbugs.gnu.org; Wed, 09 Aug 2017 07:03:54 -0400 Original-Received: from mail-yw0-f181.google.com ([209.85.161.181]:34058) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1dfOmF-0003e7-Do for 22819@debbugs.gnu.org; Wed, 09 Aug 2017 07:03:52 -0400 Original-Received: by mail-yw0-f181.google.com with SMTP id s143so37602231ywg.1 for <22819@debbugs.gnu.org>; Wed, 09 Aug 2017 04:03:51 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=rsBjot38ORkXd9K2PfqGB2+Wauccfi9xn4Kx1MRILA8=; b=abGYarVK2dJzSQVDWJjIqQ9MGcROPhkF8IFn8JX1lWD4ekwBmZD6CTpNxg1q3rIjv2 jtxbsDzWa6gxYA24ZOm0j3Udpdi+dqM9K+SRWvo+R7j3vlifU3lBDVecyXwe52nsT2s2 zwy40erVCcsqZjCKahFgd5gCvIy55dpuFhbVQ/5Ay87ddfemCjT9VZwEGqhqhIZFBu7m 9dk1pzkTB2O9n8kAVLseHQgp2qqArG2zJSjaEC2c3OL6ela1dYgecVA5ZRQS6ORMsqid l22AKvwLEMFrAsb4t1i18doMscZJUrdjX2Txn/2caiwZheoS7KRGHAFPhZkKPDrP8zif CdaQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=rsBjot38ORkXd9K2PfqGB2+Wauccfi9xn4Kx1MRILA8=; b=Vfofd+yDdk8wAWbVj8KdPRh3+Ttt9Ez3bhI+omhEZYArj5ZB/lDTlUyhTwdsALkaNs /6bgtuG27xic0R9FYIX9usDvR/m44N6NsxCcRGKlcQv3OrT8alRyjK4BswghP+tW9yoG EtggbteVxQBInlwQ7ig/CWo8EQnHpYzzmieKz7ew+885NesZ//3Yf0EMzwPtN3WCbinr UdtjXOndwyUVqQ0Z6NLGyh2+3q2jyzhHrQrFGlLyZu3ISaMvZWhIJ1q5VgS0LdZgAHcy ota4c33gMATNAqD+QrY/z/b3jK6gJJL2M8YxpKu4YzgWiqWhnxaKbJK8maQ3cABdAGbx R0jw== X-Gm-Message-State: AHYfb5hshPo1G8SiDk0JFIlQwGeU8zShzMj4z9j7yERGEaXDrNYaUedT trvBOoRBI39+N4OR7Y6iey327cnT7Q== X-Received: by 10.129.124.87 with SMTP id x84mr6486893ywc.170.1502276625622; Wed, 09 Aug 2017 04:03:45 -0700 (PDT) In-Reply-To: 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:135595 Archived-At: --001a114942cc9fef02055650082c Content-Type: text/plain; charset="UTF-8" On Tue, Aug 8, 2017, 5:31 PM John Wiegley wrote: > > Hello, Kaushal. > Hi John, thanks for your input. It should be pointed out here that maintenance of Emacs is at the > maintainers' > discretion. Even though we do take the opinions of others into account, > just > because emacs-devel "hasn't raised an issue", does not mean that a change > will > happen. If Eli and I don't like it, the issue must wait for the next round > of > maintainers. > Understood. My only hope that I can convince the maintainers with my reason that this proposal fixes a real-life problem with the help democratic voting system (if the opinions asked on emacs-devel matter and can be called that). There are a few factors why this change is being rejected now: > > a. It is a long-standing behavior, however less than ideal it is. We > don't > know what effect changing it will have, as obvious as it may seem. Our > strongly-held policy is to avoid changes in long-standing behavior > unless > the reason to do so is compelling. > 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. b. The main force of your argument is that we waste CPU time when I should have used the term "wall time". This issue has wasted quite a few minutes for me. we don't > need to, because we could just check before doing the indentation. I > have > no argument with that, and you're quite right. However , in all my years > of using Emacs I've never run into this case, so I don't buy the > argument > that it is a change that needs to happen right now, for everyone. > This change can be truly tested and appreciated only by people dealing with read-only files everyday. This would be mostly people working with a central version control system that makes all the files yet to be checked-out as read-only symbolic links. I deal with dozens of read-only files everyday, with a mix of editable files that are managed by git. So I am likely to do the mistake of indenting a read-only file (i.e. indenting a CVCS file before checking it out). Again, the benefit of this change is not seen unless the indentation operation takes at least a few seconds (depends on file size and major mode). c. Emacs is designed to be extensible. Advise the indentation functions so > they perform this check for you. It doesn't need to happen in core > Emacs > for you to get the behavior you want. > 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?) If your wish is to defend the interests of the "silent majority", who all, > without knowing it, would benefit from this change, then I appreciate your > concern. However, as maintainers, and given the lack of other voices *asking* > for this change, we prefer to retain the status quo, however far from > perfect > it may be. > I doubt that will ever change because my situation as I explained above, of working with primarily read-only files is not in majority. Plenty of projects on the Net strive to make every breaking change necessary > to approximate the best version of what they're trying to accomplish. I haven't yet got an answer to a real-life scenario that would break by this change. What kind of (i) side-effects would one be relying on (ii) while running indent-region (iii) on read-only files? It's a bit sad, I am presenting a solution to a real problem and the counter argument is just one, and hypothetical. That's not how it is here. We want a stable, well-functioning Emacs with > predictable > behavior, *predictable*: What should one expect to happen if one tried to indent-region in a read-only file? Would one be surprised if a read-only error is thrown? Emacs already does that.. just that this proposal does just that *before* the time-consuming indentation attempt is started. So this patch should bring no noticeable change to a majority of people. But people in minority like me -- (i) like to obsessively keep all files well-indented (ii) working with read-only files (iii) time-consuming indentation (major mode and file size dependent) -- would heavily appreciate this. and sometimes that means keeping things as they have been for > decades -- even if, in hindsight, it shouldn't have been done that way. What I'm interested to learn is how many other cases like this exist, I doubt if many still exist because the ones that affected most people are already fixed by using the same approach (as in this proposal) of using * interactive form or barf-if-buffer-read-only. and > whether a more general approach would make it less likely for it to occur. > What if we could know, for example, whether a function will try to change > the > buffer, and simply stop the evaluation before it starts... > This prolonged discussion makes me think "What's the point?". I can barely convince to commit this 1-line change to the master branch that can be easily reverted even if a single person complained. > -- Kaushal Modi --001a114942cc9fef02055650082c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, Aug 8, 2017, 5:31 PM Jo= hn Wiegley <jwiegley@gmail.com= > wrote:

Hello, Kaushal.

Hi John, thanks f= or your input.=C2=A0

It should be pointed out here that maintenance of E= macs is at the maintainers'
discretion. Even though we do take the opinions of others into account, jus= t
because emacs-devel "hasn't raised an issue", does not mean t= hat a change will
happen. If Eli and I don't like it, the issue must wait for the next ro= und of
maintainers.

Understood. My only = hope that I can convince the maintainers with my reason that this proposal = fixes a real-life problem with the help democratic voting system (if the op= inions asked on emacs-devel matter and can be called that).=C2=A0

There = are a few factors why this change is being rejected now:

=C2=A0 a. It is a long-standing behavior, however less than ideal it is. We= don't
=C2=A0 =C2=A0 =C2=A0know what effect changing it will have, as obvious as i= t may seem. Our
=C2=A0 =C2=A0 =C2=A0strongly-held policy is to avoid changes in long-standi= ng behavior unless
=C2=A0 =C2=A0 =C2=A0the reason to do so is compelling.

Wouldn't the master branch be a good playground f= or this?=C2=A0 If it affects people negatively, it's just a one-line co= mmit and thus easy to revert.

=C2=A0 b. The main force of your argument = is that we waste CPU time when

I sh= ould have used the term "wall time". This issue has wasted quite = a few minutes for me.=C2=A0

=
=C2=A0we don't
=C2=A0 =C2=A0 =C2=A0need to, because we could just check before doing the i= ndentation. I have
=C2=A0 =C2=A0 =C2=A0no argument with that, and you're quite right.

=C2=A0However
, in all my years
=C2=A0 =C2=A0 =C2=A0of using Emacs I've never run into this case, so I = don't buy the argument
=C2=A0 =C2=A0 =C2=A0that it is a change that needs to happen right now, for= everyone.

This change can be tru= ly tested and appreciated only by people dealing with read-only files every= day. This would be mostly people working with a central version control sys= tem that makes all the files yet to be checked-out as read-only symbolic li= nks. I deal with dozens of read-only files everyday, with a mix of editable= files that are managed by git. So I am likely to do the mistake of indenti= ng a read-only file (i.e. indenting a CVCS file before checking it out). Ag= ain, the benefit of this change is not seen unless the indentation operatio= n takes at least a few seconds (depends on file size and major mode).
=

= =C2=A0c. Emacs is designed to be extensible. Advise the indentation functio= ns so
=C2=A0 =C2=A0 =C2=A0they perform this check for you. It doesn't need to= happen in core Emacs
=C2=A0 =C2=A0 =C2=A0for you to get the behavior you want.
<= /div>

Of course. I will do that. I was just hoping the &= quot;right fix" would get in. (Otherwise why would anyone bother to su= bmit bug reports and patches?)

If your wish is to defend the interests o= f the "silent majority", who all,
without knowing it, would benefit from this change, then I appreciate your<= br> concern.

However, as maintainers, and given the lack of ot= her voices *asking*
for this change, we prefer to retain the status quo, however far from perfe= ct
it may be.

I doubt that will ever= change because my situation as I explained above, of working with primaril= y read-only files is not in majority.=C2=A0

Plenty of projects on the N= et strive to make every breaking change necessary
to approximate the best version of what they're trying to accomplish.

I haven't yet got an answer to a r= eal-life scenario that would break by this change. What kind of (i) side-ef= fects would one be relying on (ii) while running indent-region (iii) on rea= d-only files?

It's a bit sad, I am presenting = a solution to a real problem and the counter argument is just one, and hypo= thetical.=C2=A0

=C2=A0That's
not how it is here. We want a stable, well-functioning Emacs with predictab= le
behavior,

*predictable*: What=C2=A0should one expect to happen if one tried to in= dent-region in a read-only file? Would one be surprised if a read-only erro= r is thrown? Emacs already does that.. just that this proposal does just th= at *before* the time-consuming indentation attempt is started.=C2=A0=

So this patch should bring no noticeable change to a ma= jority of people. But people in minority like me -- (i) like to obsessively= keep all files well-indented (ii) working with read-only files (iii) time-= consuming indentation (major mode and file size dependent) -- would heavily= appreciate this.=C2=A0

and sometimes that means keeping things = as they have been for
decades -- even if, in hindsight, it shouldn't have been done that way.=

What I'm interested to learn is how many other cases l= ike this exist,

I doubt if many still= exist because the ones that affected most people are already fixed by usin= g the same approach (as in this proposal) of using * interactive form or ba= rf-if-buffer-read-only.=C2=A0

and
whether a more general approach would make it less likely for it to occur.<= br> What if we could know, for example, whether a function will try to change t= he
buffer, and simply stop the evaluation before it starts...
=

This prolonged discussion makes me think "Wh= at's the point?". I can barely convince to commit this 1-line chan= ge to the master branch that can be easily reverted even if a single person= complained.=C2=A0
--

Kaushal Modi

--001a114942cc9fef02055650082c--