From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Kaushal Modi Newsgroups: gmane.emacs.devel Subject: Re: Recent commit modifying mark-whole-buffer (master/aeb613ea95b7970e66d663ec5cba54e9ec0528fa) Date: Fri, 29 Apr 2016 17:43:44 +0000 Message-ID: References: <87lh3x4dkb.fsf@gnus.org> <83wpngx69z.fsf@gnu.org> <87fuu4bo3y.fsf@gnus.org> <83inz0wprx.fsf@gnu.org> <87shy4a8d4.fsf@gnus.org> <83fuu4wnmm.fsf@gnu.org> <87y47w5w0p.fsf@gnus.org> <83bn4swdif.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: multipart/alternative; boundary=001a1141b0ecb79b000531a32faa X-Trace: ger.gmane.org 1461951894 13788 80.91.229.3 (29 Apr 2016 17:44:54 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Apr 2016 17:44:54 +0000 (UTC) Cc: emacs-devel@gnu.org, Stephan.Mueller@microsoft.com To: Eli Zaretskii , Lars Ingebrigtsen Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 29 19:44:54 2016 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1awCTF-0004wZ-6m for ged-emacs-devel@m.gmane.org; Fri, 29 Apr 2016 19:44:53 +0200 Original-Received: from localhost ([::1]:55696 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awCTB-0006F6-Eo for ged-emacs-devel@m.gmane.org; Fri, 29 Apr 2016 13:44:49 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55758) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awCT1-00061b-IK for emacs-devel@gnu.org; Fri, 29 Apr 2016 13:44:47 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1awCSo-00089y-Jw for emacs-devel@gnu.org; Fri, 29 Apr 2016 13:44:34 -0400 Original-Received: from mail-oi0-x233.google.com ([2607:f8b0:4003:c06::233]:33693) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awCSn-00081u-AM; Fri, 29 Apr 2016 13:44:26 -0400 Original-Received: by mail-oi0-x233.google.com with SMTP id v145so93374160oie.0; Fri, 29 Apr 2016 10:43:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=gt+DEPPRYklwBeXAJCNrGDM6gMD4ARruzbTmb8bekGM=; b=bZF3Bno0WihE3UI0T0phUi898NxgTOIWKF4cPnJ0muiincKaJ3+XY26udPkQURtXNm /hsTaTZ0EswK/WGXOOczhOvjaSD+lyni9LwENyD9prDyKmbe6ruptJOHfag5Bfa3Tl7Q MZWz9T6yFKuwXugZ6hVyKy1XYpGsEL2joxHBuVXQiQX+iqsnvoRXEDM4HsrBNXZ9y6VR NI7vKt+0wKmDHkHyd/LijdQiAlaAztHpqa7G/gYDRpNBWgOdJv7Auf9I1IgMElthvZgP r0STdpJ4IQrP8MaIldnUUosndIvQJLuvQ8YDhAEMvJ2Npvwql0KklqKocUSfPRe9re/v bRYg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=gt+DEPPRYklwBeXAJCNrGDM6gMD4ARruzbTmb8bekGM=; b=LPaTZ+DVIoB3dPtVe2VJlW4gOOgc1UCEruGmd9EM60bvr927hZrxmVO+YN9KOHTMfj ug2jGGAOlPZZpoghY86sET3dkpcrMeS0BRo4doguNG0+AZEip085wPTeAfxiDgfgxADq TzRgTnUpdcydQx+xfE/uvsjOCYsW1wPQojdmQjb6kv8pL7k0A12FbQSmLjWG+8dM3K+A VwdX9pu573/5h6f/s5XpgpitEhl2DN8NyzvSg0ZZ+PK4y8OWAXpZVNm4yjYh9tT0xuok SUsIphAUIZMJVxwFf9hvYqJnGKDFnvmYiUUQ+WyjgWJkJQTA5JNdBFzoPK171Z9ItdPd rbLw== X-Gm-Message-State: AOPr4FWtPSBrF6I/Pv7Q7vFHoVt6v+RA3uIH/QSOAfVdncc1GLfaye8EDnHjGgW0kGPrsjiorQp/cOiqmw7dZQ== X-Received: by 10.202.231.11 with SMTP id e11mr8862727oih.159.1461951833543; Fri, 29 Apr 2016 10:43:53 -0700 (PDT) In-Reply-To: <83bn4swdif.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2607:f8b0:4003:c06::233 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:203420 Archived-At: --001a1141b0ecb79b000531a32faa Content-Type: text/plain; charset=UTF-8 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 wrote: > > From: Lars Ingebrigtsen > > 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 --001a1141b0ecb79b000531a32faa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
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-intangib= le-mode by default to minibuffer-setup-hook, so that=C2=A0
=C2=A0= the cursor is intangible by default.
- Then we do not need to tw= eak C-a, C-x h to cater to the minibuffer prompt=C2=A0
=C2=A0 cor= ner 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, t= he cursor-intangible-mode can be temporarily disabled and then
th= e 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 to= ggle that
mode to the minibuffer-local-map help?

If you consider your use cases when you need to edit/copy the prom= pt versus the
ones when you do not, what would be a rough split?<= /div>


> AFAIR, we make the prompt a fi= eld so that simple commands like C-a don't enter
> it inad= vertently; that measure was good enough for us for many years.=C2=A0 Why
> isn't it good enough now?

Even th= ough 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 f= ind. So I am
suggesting that we enable the cursor-intangible-mode= by default in the
minibuffer so get a consistent behavior when u= sing C-a, C-x h,
arrows/character-based navigation, etc.

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

That bug report ra= ises the inconsistency concern I presented above.

= > So I'm not sure why we want to make such significant changes in be= havior 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 bu= g 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 d= isallow doing that,
> without some complicated operations that= many users won't even know about?=C2=A0 If
> so, I object= .

I did not understand that. With my proposed chan= ge, user simply needs to toggle
cursor-intangible-mode in the min= ibuffer to restore the old behavior. On the
other hand, the chang= e 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 p= oint.

It again comes to how often the veteran Emac= s users need to edit/copy the
minibuffer prompt in their daily us= e. What would be a rough percentage of times
accessing the minibu= ffer when one would need to copy the prompt too?

&= gt; 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 ch= anged by the user at the time of use.. If the prompt says "Query Repla= ce:
", the user naturally would want to edit only the text f= ollowing that prompt. If
for some reason, I want to copy whatever= incomplete regexp I wrote for later
use, it's natural to jus= t 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 u= nnatural.

>> Lars I think we have three idea= s about how the minibuffer should be
> handled: 1) It should b= e as normal a buffer as possible, and we should do
> minimal t= hings 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) W= e 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 t= he
> mark-whole-buffer change).

I lik= e the commit you made. But my proposal is to make a change that results in<= /div>
consistent behavior throughout, rather than having to patch up si= mple 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 separa= te thing, not affected by any commands
> whatsoever (the sugge= stion made yesterday).

Yes.

I do not have enough "karma points&= quot; to add weight to my proposal. So I rest my case here.=C2=A0

On Fri, Apr 29= , 2016 at 1:07 PM Eli Zaretskii <eliz@gn= u.org> wrote:
> From: Lar= s Ingebrigtsen <lars= i@gnus.org>
> Cc: emacs-dev= el@gnu.org,=C2=A0 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 minim= al
> things to distinguish between the prompt and the text (your stance). >
> 2) We should try to make the prompt go away from (some) common command= s
> where that makes sense (which is what Emacs does now with C-a and the<= br> > mark-whole-buffer change).
>
> 3) The prompt should be a totally separate thing, not affected by any<= br> > commands whatsoever (the suggestion made yesterday).
>
> 2), of course, means endless haggling of "what makes sense".= =C2=A0 I think
> mark-whole-buffer makes sense, but perhaps not?

My stance is actually 2).=C2=A0 IOW, I'm saying that what we do now is<= br> okay, and shouldn't be "improved".

--

--
Kaushal Modi

--001a1141b0ecb79b000531a32faa--