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