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: Sat, 05 Aug 2017 12:29:15 +0000 Message-ID: References: <87vam26amc.fsf@users.sourceforge.net> <83lgmywlo4.fsf@gnu.org> <83r2wqusep.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="94eb2c0c884ac0e080055600c31f" X-Trace: blaine.gmane.org 1501936217 14579 195.159.176.226 (5 Aug 2017 12:30:17 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 5 Aug 2017 12:30:17 +0000 (UTC) Cc: 22819@debbugs.gnu.org, Noam Postavsky To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 05 14:30:13 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 1ddyDY-0003FJ-RY for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Aug 2017 14:30:09 +0200 Original-Received: from localhost ([::1]:56666 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddyDd-0004Oz-Bd for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Aug 2017 08:30:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:50220) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddyDW-0004OO-TO for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 08:30:08 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ddyDT-0001Ml-Qb for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 08:30:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39920) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ddyDT-0001MG-NX for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 08:30:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ddyDT-0003Rc-1I for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 08:30:03 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Kaushal Modi Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Aug 2017 12:30: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.150193617513181 (code B ref 22819); Sat, 05 Aug 2017 12:30:02 +0000 Original-Received: (at 22819) by debbugs.gnu.org; 5 Aug 2017 12:29:35 +0000 Original-Received: from localhost ([127.0.0.1]:42597 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddyD1-0003QX-6I for submit@debbugs.gnu.org; Sat, 05 Aug 2017 08:29:35 -0400 Original-Received: from mail-lf0-f42.google.com ([209.85.215.42]:36631) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddyCz-0003QL-Pr for 22819@debbugs.gnu.org; Sat, 05 Aug 2017 08:29:34 -0400 Original-Received: by mail-lf0-f42.google.com with SMTP id o85so15799821lff.3 for <22819@debbugs.gnu.org>; Sat, 05 Aug 2017 05:29:33 -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=QohJ7Gh2Fa5+PalL4CS9G/tjEfhd43LtifH+jRkV/YU=; b=Km4BtRStVwvtZqIhmCQYMuVzifT24m1c74pFSGWSZX1XLAPdgP6no8yM0fnT32qeZa hIfcyTUrL41lkb+yaZwHx+749om50gTojh6zmn9bKZATrq3nO8KlRKz7F9FeYfKrlqyX l2OsmY1J/4jKCf47AvGcvHkseC7Ccx3Q6CBz6R/7s4+z1FlkMYH5W+y/0BveIGQsB21q XQ1s5KVLqTgRaRXUwbbXN+mrI23Wk6i3RdNrRESDWOohhl4LGLrEq0yYS6xg+Thxc65S n44GgQ7yB9Q/YmrH18Hh6fgwlDjuQzMkchyRrS2bxJs99oIp9cPPV5X0Rci5TTJdBi+t cy5A== 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=QohJ7Gh2Fa5+PalL4CS9G/tjEfhd43LtifH+jRkV/YU=; b=b2b0D9wKEYBHJNVARuA2RfmViXLsEowZhvS60njJUjkNRqEfJKQ91FrduF9PAq5Tj6 qQ7ppQgw8Zy37T9mu/qM2WBvwpsbF+s7iZTn8+Xxz3+BSn4kPLqYxFBZtmbpIdaOdpPK Bj7+arM6snVbGfUEZrSWH9Wh5TGM8NAGLbH3Js4Lp3jXCDs9xVXvinP8vc9ZpzHMt8l+ RBPNyVRS729AQ35SXQNrAMkjZ2rDzhqfhak6UgKcCAVbjXXBcY36N77kziXnYlblkmJO uf6ij3UWewQ+CSCHab149O7IktIYRuTCtNXeNrQl7ylduZDm7Vr+muaXazxzZ9MNzxbD AIlQ== X-Gm-Message-State: AHYfb5j/EmaC5EMSHne7yYDEGxFCDdTWAlE/SOqSQF00l+3oqyCdN1JJ Lbf7H8ifSi7COnmQ5jAW5KUbXcd6fA== X-Received: by 10.25.221.196 with SMTP id w65mr1665501lfi.91.1501936167737; Sat, 05 Aug 2017 05:29:27 -0700 (PDT) In-Reply-To: <83r2wqusep.fsf@gnu.org> 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:135420 Archived-At: --94eb2c0c884ac0e080055600c31f Content-Type: text/plain; charset="UTF-8" On Sat, Aug 5, 2017, 8:10 AM Eli Zaretskii wrote: > > I see no problem in it, sorry. And why was the user not aware of the > read-only status of the buffer to begin with? Cockpit error, as you say later. It's easy to forget if you are working on a DVCS (like git) controlled file or CVCS (like SOS). How plausible is such a > scenario? I resorted to writing this patch because it frustrated me quite a few times. Are we trying to change Emacs behavior to cater to a clear > cockpit error? > Isn't it better to alert user of an operation that will not succeed anyways beforehand, especially if the operation can be expensive like this one? > >against veteran Emacs behavior regarding read->only text, > > >behavior that is present in several other >commands, and that AFAIR > > >resulted from some past discussions. > > > > This is the only one that provided me this surprise in about a decade of > Emacs use. Which other commands > > do the text manipulation, and then check the buffer read-only status? > > C-w, to name just one. > OK, it would be unnoticeable in that case as I have yet to see a kill operation that can take couple of minutes. IOW, a command could have useful side effects that are produced even > if the buffer is read-only and its text cannot be changed, thus > preventing the main effect of the command from happening. > > > The flip question is: How common is a workflow, where a buffer is > read-only, user does indentation, and is fine > > with seeing that error after the fact? > > This goes both ways: if it's uncommon enough to be unimportant, then > changing the behavior is not important as well. > Would it be OK to open this up to emacs-devel to understand what workflows can break because of this change? > -- Kaushal Modi --94eb2c0c884ac0e080055600c31f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 5, 2017, 8:10 AM El= i Zaretskii <eliz@gnu.org> wrote:=

I see no problem in it, sorry.=C2=A0 And why was the user not aware of the<= br> read-only status of the buffer to begin with?

<= /div>
Cockpit error, as you say later. It's easy to forget if you a= re working on a DVCS (like git) controlled file or CVCS (like SOS).=C2=A0

How
plausible is such a
scenario?

I resorted to writing this = patch because it frustrated me quite a few times.=C2=A0

=C2=A0Are
we trying to change Emacs behavior to ca= ter to a clear
cockpit error?

Isn't it bette= r to alert user of an operation that will not succeed anyways beforehand, e= specially if the operation can be expensive like this one?

> >agai= nst veteran Emacs behavior regarding read->only text,
> >behavior that is present in several other >commands, and that A= FAIR
> >resulted from some past discussions.
>
> This is the only one that provided me this surprise in about a decade = of Emacs use. Which other commands
> do the text manipulation, and then check the buffer read-only status?<= br>
C-w, to name just one.

OK, it wou= ld be unnoticeable in that case as I have yet to see a kill operation that = can take couple of minutes.=C2=A0

IOW, a command could have useful side = effects that are produced even
if the buffer is read-only and its text cannot be changed, thus
preventing the main effect of the command from happening.

> The flip question is: How common is a workflow, where a buffer is read= -only, user does indentation, and is fine
> with seeing that error after the fact?

This goes both ways: if it's uncommon enough to be unimportant, then changing the behavior is not important as well.
=
Would it be OK to open this up to emacs-devel to understand = what workflows can break because of this change?
--

Kaushal Modi

--94eb2c0c884ac0e080055600c31f--