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 11:50:59 +0000 Message-ID: References: <87vam26amc.fsf@users.sourceforge.net> <83lgmywlo4.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="001a114205e4e1dd500556003ae3" X-Trace: blaine.gmane.org 1501933936 15778 195.159.176.226 (5 Aug 2017 11:52:16 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sat, 5 Aug 2017 11:52:16 +0000 (UTC) Cc: 22819@debbugs.gnu.org To: Eli Zaretskii , Noam Postavsky Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sat Aug 05 13:52:08 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 1ddxck-0003bH-C4 for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Aug 2017 13:52:06 +0200 Original-Received: from localhost ([::1]:56334 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddxcq-0006MX-Co for geb-bug-gnu-emacs@m.gmane.org; Sat, 05 Aug 2017 07:52:12 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:40604) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ddxcj-0006M2-8c for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 07:52:06 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ddxcg-0005Oc-LF for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 07:52:05 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:39897) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1ddxcg-0005O3-H3 for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 07:52:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1ddxcg-0002Z0-30 for bug-gnu-emacs@gnu.org; Sat, 05 Aug 2017 07:52: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: Sat, 05 Aug 2017 11:52: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.15019338799797 (code B ref 22819); Sat, 05 Aug 2017 11:52:02 +0000 Original-Received: (at 22819) by debbugs.gnu.org; 5 Aug 2017 11:51:19 +0000 Original-Received: from localhost ([127.0.0.1]:42574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddxbz-0002Xx-3z for submit@debbugs.gnu.org; Sat, 05 Aug 2017 07:51:19 -0400 Original-Received: from mail-lf0-f46.google.com ([209.85.215.46]:37745) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ddxbx-0002Xl-EG for 22819@debbugs.gnu.org; Sat, 05 Aug 2017 07:51:17 -0400 Original-Received: by mail-lf0-f46.google.com with SMTP id m86so15594310lfi.4 for <22819@debbugs.gnu.org>; Sat, 05 Aug 2017 04:51:17 -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=IZpNvN/xXl7yNSx4K7ofNxxngnv2FHQztt71Z/c3Q9k=; b=n+rmLd7vfBQJkHSxUQwh63CbfFsLzgb4hBkdktqGxtQMyFh4aTOxg1UvDzRRx474QF /acZ8+LDLCKTXBHyTzVBbN8eBBHZVpNMa3NATjlK8Eaki6LclAegQrMVVGygy2mZao8h V63Y0/fNdzX82Ki+BY8Kiw1KXVvbBP0LtbIWhmie+uWFSpoLktlYiNPONsk8INuuTacs hueuVMvZ5u7kMhetRudAnH4/Iywptcw6Ss5ru0whagKNUGg/HCEsRbY0BlXJSze9juJF toX/WAFvUwoSKXF990vnJFN8UPki+bOtknkGvbh6SbmMmer7B4z5KgS+B/bryweNbby2 7qbw== 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=IZpNvN/xXl7yNSx4K7ofNxxngnv2FHQztt71Z/c3Q9k=; b=snj2+6HuEY//O5mKodwTtIBA9olF71wfsTV+8v47jbFtNtop+s1ugl6ybKKZ5/qToy etBy90lHcVx4MfAfNEmbs7vOuH5tJ0ramUXmo+v44SbKDMcWS4M1CBX3UnuedeJC7whN 00BPQ8PXLbZpKr4HjNbFoY2V4QIh0Zy7DqSckA/WwX5dqOCJm4HYwEfgcu4tgdRo+ub+ BnKeeZR/3Kofqacd09sjOiuDDH1omFrqrCisJkol6jB+NO4q6JAnq//k8LM7hCVHJfEL zP1twy//FD3qlZxoCRJCyT6kqgGEq+6MReURtfsYUr/DMUIHN/xALnRoNNUtTF2C4A0P /ByQ== X-Gm-Message-State: AHYfb5gSj15XX/yJbgwBYlUw4kEKtCtg0LdFkpC0YlyKMcE2HgBlkCvY Eq8BIN5daVNTAFnauXWzzjvsemf2og== X-Received: by 10.25.211.71 with SMTP id k68mr1488980lfg.43.1501933871420; Sat, 05 Aug 2017 04:51:11 -0700 (PDT) In-Reply-To: <83lgmywlo4.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:135417 Archived-At: --001a114205e4e1dd500556003ae3 Content-Type: text/plain; charset="UTF-8" On Sat, Aug 5, 2017, 2:53 AM Eli Zaretskii wrote: > > From: npostavs@users.sourceforge.net > > Date: Fri, 04 Aug 2017 21:56:11 -0400 > > Cc: 22819@debbugs.gnu.org > > > > I wonder if someone will complain that they were relying on this > > behaviour to check indentation in read-only buffers (currently if the > > indentation is already correct there is no error). > Thanks Noam for reviewing this. I am away from PC for a few days. I'll review your patch next week on Tuesday. The act of indenting is an editing action. So the buffer should be checked if it's editable before attempting an indent. If the buffer is read-only and no indentation change is required, then good. But what if indentation change is required? Here's what's will happen: 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. The clear disadvantage is that > this goes > I am failing to see the disadvantage. Before: Do indent > Attempt to write that indent to buffer After (my patch): Check if buffer is writable > Do indent > Attempt to write that indent. Isn't it just logical that if you need to do an expensive indentation, the buffer should be checked if it's editable to prevent spending that time twice? >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? If the rationale is user surprise, then I'd suggest to leave the > current behavior unchanged. > 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? > -- Kaushal Modi --001a114205e4e1dd500556003ae3 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sat, Aug 5, 2017, 2:53 AM El= i Zaretskii <eliz@gnu.org> wrote:=
> From: npostavs@users.sourceforge.net=
> Date: Fri, 04 Aug 2017 21:56:11 -0400
> Cc: 22819@d= ebbugs.gnu.org
>
> I wonder if someone will complain that they were relying on this
> behaviour to check indentation in read-only buffers (currently if the<= br> > indentation is already correct there is no error).

Thanks Noam for reviewing this. I am away from PC fo= r a few days. I'll review your patch next week on Tuesday.=C2=A0
<= div>
The act of indenting is an editing action. So the buffer= should be checked if it's editable before attempting an indent. If the= buffer is read-only and no indentation change is required, then good. But = what if indentation change is required? Here's what's will happen:<= /div>

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 b= ecause the buffer is read-only".
4. User: Make buffer editab= le. It's not a simple act of chmod. In my case, the buffer was read-onl= y because the file is part of a centralized version control system (Cliosof= t 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 t= o "check out" the file. That act replaces the symlink link with a= physical file copy.=C2=A0
5. User: Re-do that several seconds/mi= nutes long indentation.

My commit saves the user f= rom wasting that time in Step 2 above.=C2=A0

The original submission pro= vided no rationale for the change, so it's
hard to reason about its advantages.

= Please consider the above use case.=C2=A0

The
clear disadvantage is that
this goes=C2=A0

I am failing to s= ee the disadvantage. =C2=A0

Before: Do indent >= Attempt to write that indent to buffer

After (my = patch): Check if buffer is writable > Do indent > Attempt to write th= at indent.=C2=A0

Isn't it just logical that if= you need to do an expensive indentation, the buffer should be checked if i= t's editable to prevent spending that time twice?

<= div>>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 u= se. Which other commands do the text manipulation, and then check the buffe= r read-only status?=C2=A0

If
=C2= =A0the rationale is user surprise, then I'd suggest to leave the
current behavior unchanged.

The f= lip question is: How common is a workflow, where a buffer is read-only, use= r does indentation, and is fine with seeing that error after the fact?
--

Kaushal Modi

--001a114205e4e1dd500556003ae3--