Re: Recent commit modifying mark-whole-buffer (master/aeb613ea95b7970e66d663ec5cba54e9ec0528fa)

[Kaushal Modi <kaushal.modi@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 5881 bytes --]

Here is my proposal with replies to earlier comments by Eli and Lars.

- Add '(cursor-intangible t) by default to minibuffer-prompt-properties.
- Add cursor-intangible-mode by default to minibuffer-setup-hook, so that
  the cursor is intangible by default.
- Then we do not need to tweak C-a, C-x h to cater to the minibuffer prompt
  corner case.


>> Eli Emacs always allowed one to enter the prompt, if one wanted badly
enough.
> One use case where this is handy is when you need to copy the prompt text
to
> somewhere else;

In that case, the cursor-intangible-mode can be temporarily disabled and
then
the prompt will be accessible using C-x h (the version using just
(point-min)
and (point-max)). The current version in master hard-codes the C-x h
behavior so
that the prompt is never accessible, and also we lose the simple and sweet
definition of mark-whole-buffer.

> I'm sure there are others.

Would toggling the cursor-intangible-mode help? Would a binding to toggle
that
mode to the minibuffer-local-map help?

If you consider your use cases when you need to edit/copy the prompt versus
the
ones when you do not, what would be a rough split?


> AFAIR, we make the prompt a field so that simple commands like C-a don't
enter
> it inadvertently; that measure was good enough for us for many years.  Why
> isn't it good enough now?

Even though I do not use the arrow keys for navigation, I feel that the
current
state is inconsistent, and we are patching up each use case as we find. So
I am
suggesting that we enable the cursor-intangible-mode by default in the
minibuffer so get a consistent behavior when using C-a, C-x h,
arrows/character-based navigation, etc.

> The initial message in bug #21874 provides no rationale for the request
(which
> seems to be a feature request, not a bug that needs to be fixed).

That bug report raises the inconsistency concern I presented above.

> So I'm not sure why we want to make such significant changes in behavior
due
> to that bug report.

I am not suggesting to make this change in the emacs-25 branch, just in the
master branch. Also my suggestion would affect only the minibuffer, not
other
major modes. I do not have experience writing the tests to verify the new
behavior. But I can always provide detailed bug reports and my analysis of
what's going wrong on the elisp side by running the master build as my daily
driver.

> Do I understand correctly that the proposed change will disallow doing
that,
> without some complicated operations that many users won't even know
about?  If
> so, I object.

I did not understand that. With my proposed change, user simply needs to
toggle
cursor-intangible-mode in the minibuffer to restore the old behavior. On the
other hand, the change in mark-whole-buffer is hard-coded.

> Working with minibuffer prompts is too hardwired into the muscle memory of
> veteran Emacs users for us to change that in radical ways at this point.

It again comes to how often the veteran Emacs users need to edit/copy the
minibuffer prompt in their daily use. What would be a rough percentage of
times
accessing the minibuffer when one would need to copy the prompt too?

> If some newcomers get surprised by some of the aspects of that behavior,
I say
let them get

It boils down to Do The Right Thing. The prompt, I believe, is not designed
to
be changed by the user at the time of use.. If the prompt says "Query
Replace:
", the user naturally would want to edit only the text following that
prompt. If
for some reason, I want to copy whatever incomplete regexp I wrote for later
use, it's natural to just do "C-x h M-w". It would be unnatural if that
copied
the prompt too! I am not a veteran Emacs user like you, but I am also not a
newcomer and I still find the prompt invading default behavior unnatural.

>> Lars I think we have three ideas about how the minibuffer should be
> handled: 1) It should be as normal a buffer as possible, and we should do
> minimal things to distinguish between the prompt and the text (your
stance).

That has issues from the UX point of view; like the query replace example I
gave
above.

> 2) We should try to make the prompt go away from (some) common commands
where
> that makes sense (which is what Emacs does now with C-a and the
> mark-whole-buffer change).

I like the commit you made. But my proposal is to make a change that
results in
consistent behavior throughout, rather than having to patch up simple
commands
like mark-whole-buffer, on as-we-find basis. After the recent commit, the
mark-whole-buffer does not truly mark the whole buffer. With my proposal, by
toggling the cursor-intangible-mode, the user can choose to make C-x h to
select
the prompt or not.

> 3) The prompt should be a totally separate thing, not affected by any
commands
> whatsoever (the suggestion made yesterday).

Yes.

I do not have enough "karma points" to add weight to my proposal. So I rest
my case here.

On Fri, Apr 29, 2016 at 1:07 PM Eli Zaretskii <eliz@gnu.org> wrote:

> > From: Lars Ingebrigtsen <larsi@gnus.org>
> > Cc: emacs-devel@gnu.org,  Stephan.Mueller@microsoft.com
> > Date: Fri, 29 Apr 2016 16:28:54 +0200
> >
> > 1) It should be as normal a buffer as possible, and we should do minimal
> > things to distinguish between the prompt and the text (your stance).
> >
> > 2) We should try to make the prompt go away from (some) common commands
> > where that makes sense (which is what Emacs does now with C-a and the
> > mark-whole-buffer change).
> >
> > 3) The prompt should be a totally separate thing, not affected by any
> > commands whatsoever (the suggestion made yesterday).
> >
> > 2), of course, means endless haggling of "what makes sense".  I think
> > mark-whole-buffer makes sense, but perhaps not?
>
> My stance is actually 2).  IOW, I'm saying that what we do now is
> okay, and shouldn't be "improved".
>
> --

-- 
Kaushal Modi

[-- Attachment #2: Type: text/html, Size: 7814 bytes --]