From: Kaushal Modi <kaushal.modi@gmail.com>
To: Eli Zaretskii <eliz@gnu.org>,
Noam Postavsky <npostavs@users.sourceforge.net>
Cc: 22819@debbugs.gnu.org
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 [thread overview]
Message-ID: <CAFyQvY1ND_=YgMc9_moAMHV1Tkv_A9B0w3yyoM65JcNTX-ETUA@mail.gmail.com> (raw)
In-Reply-To: <83lgmywlo4.fsf@gnu.org>
[-- Attachment #1: Type: text/plain, Size: 2652 bytes --]
On Sat, Aug 5, 2017, 2:53 AM Eli Zaretskii <eliz@gnu.org> 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
[-- Attachment #2: Type: text/html, Size: 4583 bytes --]
next prev parent reply other threads:[~2017-08-05 11:50 UTC|newest]
Thread overview: 22+ messages / expand[flat|nested] mbox.gz Atom feed top
2016-02-26 13:54 bug#22819: 25.0.91; Don't try to indent region if the buffer is read-only Kaushal Modi
2017-08-05 1:56 ` npostavs
2017-08-05 6:52 ` Eli Zaretskii
2017-08-05 11:50 ` Kaushal Modi [this message]
2017-08-05 12:10 ` Eli Zaretskii
2017-08-05 12:29 ` Kaushal Modi
2017-08-05 12:37 ` Eli Zaretskii
2017-08-05 12:47 ` npostavs
2017-08-05 13:13 ` Eli Zaretskii
2017-08-07 17:45 ` Kaushal Modi
2017-08-07 17:53 ` Noam Postavsky
2017-08-07 18:02 ` Kaushal Modi
2017-08-07 18:11 ` Noam Postavsky
2017-08-08 13:06 ` Kaushal Modi
2017-08-08 13:15 ` npostavs
2017-08-08 19:05 ` Eli Zaretskii
2017-08-08 19:19 ` Kaushal Modi
2017-08-08 21:31 ` John Wiegley
2017-08-09 11:03 ` Kaushal Modi
2017-08-09 21:14 ` John Wiegley
2019-06-25 14:33 ` Lars Ingebrigtsen
2019-06-25 14:35 ` Kaushal Modi
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to='CAFyQvY1ND_=YgMc9_moAMHV1Tkv_A9B0w3yyoM65JcNTX-ETUA@mail.gmail.com' \
--to=kaushal.modi@gmail.com \
--cc=22819@debbugs.gnu.org \
--cc=eliz@gnu.org \
--cc=npostavs@users.sourceforge.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.