From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Recent commit modifying mark-whole-buffer (master/aeb613ea95b7970e66d663ec5cba54e9ec0528fa) Date: Fri, 29 Apr 2016 21:33:23 +0300 Message-ID: <837ffgw9ho.fsf@gnu.org> 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> Reply-To: Eli Zaretskii NNTP-Posting-Host: plane.gmane.org X-Trace: ger.gmane.org 1461954919 29991 80.91.229.3 (29 Apr 2016 18:35:19 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 Apr 2016 18:35:19 +0000 (UTC) Cc: larsi@gnus.org, emacs-devel@gnu.org, Stephan.Mueller@microsoft.com To: Kaushal Modi Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Apr 29 20:35:15 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 1awDFw-0006qU-OU for ged-emacs-devel@m.gmane.org; Fri, 29 Apr 2016 20:35:13 +0200 Original-Received: from localhost ([::1]:55855 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awDFt-0005id-36 for ged-emacs-devel@m.gmane.org; Fri, 29 Apr 2016 14:35:09 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:42385) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awDEq-0004Bk-9D for emacs-devel@gnu.org; Fri, 29 Apr 2016 14:34:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1awDEe-0007uR-Dq for emacs-devel@gnu.org; Fri, 29 Apr 2016 14:33:58 -0400 Original-Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33509) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1awDEe-0007sD-B5; Fri, 29 Apr 2016 14:33:52 -0400 Original-Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4847 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1awDEX-0004dh-2u; Fri, 29 Apr 2016 14:33:45 -0400 In-reply-to: (message from Kaushal Modi on Fri, 29 Apr 2016 17:43:44 +0000) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e 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:203422 Archived-At: > From: Kaushal Modi > Date: Fri, 29 Apr 2016 17:43:44 +0000 > Cc: Stephan.Mueller@microsoft.com, emacs-devel@gnu.org > > - 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. Yes, you said that much earlier, and I read that. I disagree with such changes, sorry. > >> 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)). This is tail wagging the dog: because there's some inconvenience in "C-x h", we are asked to disallow moving cursor to the prompt. I don't think this is reasonable. If "C-x h" has problems (and I don't say it does, I just believe those who say it does), then "C-x h" should solve them. > 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 see no problem with that. > > 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. I don't see why we need to be consistent here. The prompt is a field, and how cursor motion behaves in the presence of fields is well documented. > > 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. I didn't just object to having the change on emacs-25, I objected to make it at all. > > 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. Toggling cursor-intangible-mode is much more complicated, and much less visible to users, than another C-a. Sorry, I still object. > On the other hand, the change in mark-whole-buffer is hard-coded. If that is a problem, we can discuss how to resolve it. > > 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? My objection is general; the use case I provided is just that. I don't want to be so severely limited in my ability to move point in the minibuffer. Once again, I don't see why this is suddenly a problem, after many years of using the current arrangement. Is there something else here beyond the desire to be "consistent"? > 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. This is Emacs. In Emacs, the minibuffer is just another buffer. We teach that newcomers, and therefore we should back that up by letting the minibuffer behave like a buffer. Any deviation from that is an inconsistency that we should not allow. Thanks.