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#22819: 25.0.91; Don't try to indent region if the buffer is read-only Date: Sat, 05 Aug 2017 15:10:22 +0300 Message-ID: <83r2wqusep.fsf@gnu.org> References: <87vam26amc.fsf@users.sourceforge.net> <83lgmywlo4.fsf@gnu.org> Reply-To: Eli Zaretskii NNTP-Posting-Host: blaine.gmane.org X-Trace: blaine.gmane.org 1501935086 16458 195.159.176.226 (5 Aug 2017 12:11:26 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 5 Aug 2017 12:11:26 +0000 (UTC) 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 Sat Aug 05 14:11: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 1ddxvA-0003O5-2y for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Aug 2017 14:11:08 +0200 Original-Received: from localhost ([::1]:56623 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddxvG-0006Nl-7o for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Aug 2017 08:11:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:45525) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddxv8-0006NK-BA for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 08:11:07 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ddxv4-0003kv-4q for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 08:11:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39914) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ddxv4-0003kg-0K for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 08:11:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ddxv3-00030Y-RN for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 08:11:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Aug 2017 12:11:01 +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.150193504311538 (code B ref 22819); Sat, 05 Aug 2017 12:11:01 +0000 Original-Received: (at 22819) by debbugs.gnu.org; 5 Aug 2017 12:10:43 +0000 Original-Received: from localhost ([127.0.0.1]:42591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddxuk-000301-Vn for submit@debbugs.gnu.org; Sat, 05 Aug 2017 08:10:43 -0400 Original-Received: from eggs.gnu.org ([208.118.235.92]:54432) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddxui-0002zn-DB for 22819@debbugs.gnu.org; Sat, 05 Aug 2017 08:10:41 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ddxuY-0003Gp-DJ for 22819@debbugs.gnu.org; Sat, 05 Aug 2017 08:10:34 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddxuY-0003Gj-9B; Sat, 05 Aug 2017 08:10:30 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1679 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1ddxuX-0006X0-Le; Sat, 05 Aug 2017 08:10:30 -0400 In-reply-to: (message from Kaushal Modi on Sat, 05 Aug 2017 11:50:59 +0000) 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:135419 Archived-At: > From: Kaushal Modi > Date: Sat, 05 Aug 2017 11:50:59 +0000 > Cc: 22819@debbugs.gnu.org > > 1. User: Try indentation > 2. User: Could take several seconds or few minutes (depending on major mode and file size) > 3. Emacs: "Bummer, couldn't save all that indentation because the buffer is read-only". > 4. User: Make buffer editable. It's not a simple act of chmod. In my case, the buffer was read-only because the > file is part of a centralized version control system (Cliosoft SOS). In "checked in" state, the file is just a > symlink to the cached version in server, and thus read-only. To make it editable, I need to "check out" the file. > That act replaces the symlink link with a physical file copy. > 5. User: Re-do that several seconds/minutes long indentation. > > My commit saves the user from wasting that time in Step 2 above. > > The original submission provided no rationale for the change, so it's > hard to reason about its advantages. > > Please consider the above use case. 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? How plausible is such a scenario? Are we trying to change Emacs behavior to cater to a clear cockpit error? > >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. 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.