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

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

[Kaushal Modi]

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

Hi all,

The following recent commit in master branch slightly changes the behavior
of C-x h or mark-whole-buffer.

http://git.savannah.gnu.org/cgit/emacs.git/commit/?id=aeb613ea95b7970e66d663ec5cba54e9ec0528fa

I am writing because this fix for bug # 2589 is sort of related to bug #
21874. In the thread for the latter (
http://debbugs.gnu.org/cgi/bugreport.cgi?bug=21874 ), the solution was to
set the cursor-intangible property to t in minibuffer-prompt-properties.

So I have the below in my config since then and it works great.

=====

(let ((default (eval (car (get 'minibuffer-prompt-properties
'standard-value))))
      (dont-touch-prompt-prop '(cursor-intangible t)))
  (setq minibuffer-prompt-properties (append default
dont-touch-prompt-prop))
  (add-hook 'minibuffer-setup-hook #'cursor-intangible-mode))

=====

My suggestion would be to add '(cursor-intangible t) by default to
minibuffer-prompt-properties so that we don't need to modify individual
simple functions like mark-whole-buffer. Originally the function did as the
name says.. mark between (point-min) and (point-max). So the recent
modification feels a bit "impure".

The cursor-intangible approach will fix the C-x h case and also the case in
bug # 21874 where the cursor enters the minibuffer prompt when using arrow
keys.

If a user desires to in fact select the whole minibuffer including the
prompt, the original mark-whole-buffer (before this commit) will work if
the user has removed the cursor-intangible property from
minibuffer-prompt-properties.

Question:
- Should we revert mark-whole-buffer to its definition before this commit
and mark-whole-buffer and make the cursor intangible by default in
minibuffer prompt?

Kaushal

-- 

-- 
Kaushal Modi

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

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

[Lars Ingebrigtsen]

Kaushal Modi <kaushal.modi@gmail.com> writes:

> Question:
> - Should we revert mark-whole-buffer to its definition before this commit and
> mark-whole-buffer and make the cursor intangible by default in minibuffer
> prompt?

I have no opinion.  I've always thought it really weird that the
minibuffer prompt is reachable at all by any commands, but I guess that
sail has shipped a long time ago...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stephan Mueller]

Kaushal Modi <kaushal.modi@gmail.com> writes:
" Question:
" - Should we revert mark-whole-buffer to its definition before this commit and
"  mark-whole-buffer and make the cursor intangible by default in minibuffer
"  prompt?

+1 for "make minibuffer prompt generally inaccessible" to be more like the rest of the world (at least the parts I interact with).  If that allows restoring mark-whole-buffer to its traditional, obvious, trivial implementation, then +1 more.

stephan();

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

[Eli Zaretskii]

> From: Stephan Mueller <Stephan.Mueller@microsoft.com>
> Date: Thu, 28 Apr 2016 22:25:09 +0000
> 
> Kaushal Modi <kaushal.modi@gmail.com> writes:
> " Question:
> " - Should we revert mark-whole-buffer to its definition before this commit and
> "  mark-whole-buffer and make the cursor intangible by default in minibuffer
> "  prompt?
> 
> +1 for "make minibuffer prompt generally inaccessible" to be more like the rest of the world (at least the parts I interact with).  If that allows restoring mark-whole-buffer to its traditional, obvious, trivial implementation, then +1 more.

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; I'm sure there are others.  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?

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).  So I'm not sure why we want to make such significant
changes in behavior due to that bug report.

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.  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.  If some newcomers get
surprised by some of the aspects of that behavior, I say let them get
used, it doesn't take too long to do that.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> 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).  So I'm not sure why we want to make such significant
> changes in behavior due to that bug report.

I assumed it was an uncontroversial fix -- there are many commands that
work differently in the minibuffer exactly because we don't want to
include the prompt.

> 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 don't quite follow.  If you want to mark the prompt, there's a
gazillion ways of doing that, including `C-u C-a C-<SPC>'.  Or just hold
down `<left>'.  :-)

(By the way, I think it would be nice if `<left>' didn't enter the
prompt.)

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stephan Mueller <Stephan.Mueller@microsoft.com>,  emacs-devel@gnu.org
> Date: Fri, 29 Apr 2016 14:23:13 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> > 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).  So I'm not sure why we want to make such significant
> > changes in behavior due to that bug report.
> 
> I assumed it was an uncontroversial fix -- there are many commands that
> work differently in the minibuffer exactly because we don't want to
> include the prompt.

Fix of what problem?  I was saying that the problem is not clear to
me?

> > 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 don't quite follow.  If you want to mark the prompt, there's a
> gazillion ways of doing that, including `C-u C-a C-<SPC>'.  Or just hold
> down `<left>'.  :-)

Are we mis-communicating?  I thought the suggestion on the table, to
which I objected, was to make the prompt have a property that would
preclude doing all these things.

> (By the way, I think it would be nice if `<left>' didn't enter the
> prompt.)

And I don't understand why you think so.  We were allowed to do so for
eons, why suddenly change that?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> I assumed it was an uncontroversial fix -- there are many commands that
>> work differently in the minibuffer exactly because we don't want to
>> include the prompt.
>
> Fix of what problem?  I was saying that the problem is not clear to
> me?

Well, the problem was that mark-whole-buffer marked the prompt in the
minibuffer.  :-)

>> I don't quite follow.  If you want to mark the prompt, there's a
>> gazillion ways of doing that, including `C-u C-a C-<SPC>'.  Or just hold
>> down `<left>'.  :-)
>
> Are we mis-communicating?  I thought the suggestion on the table, to
> which I objected, was to make the prompt have a property that would
> preclude doing all these things.
>
>> (By the way, I think it would be nice if `<left>' didn't enter the
>> prompt.)
>
> And I don't understand why you think so.  We were allowed to do so for
> eons, why suddenly change that?

I think we must be miscommunicating.  On the one hand you seem to be
suggesting that we should make the prompt more special than it is now,
and on the other hand, you seem to be suggesting that we shouldn't,
because we haven't for eons?

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Stephan.Mueller@microsoft.com,  emacs-devel@gnu.org
> Date: Fri, 29 Apr 2016 14:48:39 +0200
> 
> Eli Zaretskii <eliz@gnu.org> writes:
> 
> >> I assumed it was an uncontroversial fix -- there are many commands that
> >> work differently in the minibuffer exactly because we don't want to
> >> include the prompt.
> >
> > Fix of what problem?  I was saying that the problem is not clear to
> > me?
> 
> Well, the problem was that mark-whole-buffer marked the prompt in the
> minibuffer.  :-)

And why is that a problem?  The prompt _is_ part of the buffer text.

> >> I don't quite follow.  If you want to mark the prompt, there's a
> >> gazillion ways of doing that, including `C-u C-a C-<SPC>'.  Or just hold
> >> down `<left>'.  :-)
> >
> > Are we mis-communicating?  I thought the suggestion on the table, to
> > which I objected, was to make the prompt have a property that would
> > preclude doing all these things.
> >
> >> (By the way, I think it would be nice if `<left>' didn't enter the
> >> prompt.)
> >
> > And I don't understand why you think so.  We were allowed to do so for
> > eons, why suddenly change that?
> 
> I think we must be miscommunicating.  On the one hand you seem to be
> suggesting that we should make the prompt more special than it is now,
> and on the other hand, you seem to be suggesting that we shouldn't,
> because we haven't for eons?

I didn't suggest any changes, no.  The prompt is special, but it
doesn't need to be more so.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> I didn't suggest any changes, no.  The prompt is special, but it
> doesn't need to be more so.

Then we weren't miscommunicating.  :-)  When you said we might be, I
misread the rest of your message.

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).

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?  

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> 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".

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

[Kaushal Modi]

[-- 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 --]

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

[Eli Zaretskii]

> From: Kaushal Modi <kaushal.modi@gmail.com>
> 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.

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

[Drew Adams]

> I'm saying that what we do now is okay, and shouldn't be "improved".

I agree (with Eli).  I don't see a bug here, and everything
suggested so far does not sound like an improvement.

FWIW, if we are envisaging changing the prompt implementation
then I think the prompt should be more amenable to Lisp (not
done in C), and that any prompt features (including text
properties, including `face' and read-only) should be default
behavior only.  At least a start would be to allow code to
provide a propertized prompt (esp. wrt `face') and have that
be used/respected and not overwridden.

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

[Eli Zaretskii]

> Date: Fri, 29 Apr 2016 12:28:40 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: Stephan.Mueller@microsoft.com, emacs-devel@gnu.org
> 
> I think the prompt should be more amenable to Lisp (not
> done in C), and that any prompt features (including text
> properties, including `face' and read-only) should be default
> behavior only.  At least a start would be to allow code to
> provide a propertized prompt (esp. wrt `face') and have that
> be used/respected and not overwridden.

There's already a face 'minibuffer-prompt', so I'm not sure what else
needs to be done wrt the face of the prompt.

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

> There's already a face 'minibuffer-prompt', so I'm not sure what else
> needs to be done wrt the face of the prompt.

The use case Drew is talking about is that you should be able to say

(read-from-minibuffer (concat "What " (propertize "do you want" 'face 'bold)))

and you can't.  I agree with Drew that that sounds like a useful thing
to have.  See bug#12377.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Eli Zaretskii]

> From: Lars Ingebrigtsen <larsi@gnus.org>
> Cc: Drew Adams <drew.adams@oracle.com>,  Stephan.Mueller@microsoft.com,  emacs-devel@gnu.org
> Date: Fri, 29 Apr 2016 22:18:27 +0200
> 
> (read-from-minibuffer (concat "What " (propertize "do you want" 'face 'bold)))

So, more than one face, one each for every part of the prompt?

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

[Lars Ingebrigtsen]

Eli Zaretskii <eliz@gnu.org> writes:

>> (read-from-minibuffer (concat "What " (propertize "do you want" 'face 'bold)))
>
> So, more than one face, one each for every part of the prompt?

Yup.  Like I said in the bug report, I think the solution here is to
have read-from-minibuffer not apply the default face if there are any
faces specified on the prompt string.  I'll see if I get around to
implementing it...

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

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

> > (read-from-minibuffer (concat "What " (propertize "do you want" 'face
> >                                                   'bold)))
> 
> So, more than one face, one each for every part of the prompt?

Maybe.  Depends on what you need/want.

It's not the minibuffer, but see attached screenshots of
isearch prompts (from `isearch+.el').

The screenshots with the white background show the default
faces.  The screenshot with the light orange background shows
the face values I myself use.

There are these faces used for parts of the Isearch+ prompt:

1. Standard prompt face (`minibuffer-prompt')
2. Regexp search face (`isearchp-regexp')
3. Wrapped search face (`isearchp-wrapped')
4. Overwrapped search (`isearchp-overwrapped')
5. Multi-buffer search (`isearchp-multi')

In addition, the `*wrapped' faces are used in the mode-line
lighter.

(In the screenshot that shows the mode-line lighter, the
lighter text is `R*SEARCH', which indicates case-insensitive
regexp search.)

Wrt the minibuffer prompt (not Isearch), here is an example:

(message
  "You can invoke command `%s' using `%s'"
  (propertize (symbol-name cmd) 'face 'icicle-msg-emphasis)
  (propertize (key-description binding) 'face 'icicle-msg-emphasis))

A screenshot shows this too, but using my setup (where red
is the normal prompt color for my standalone minibuffer).

[-- Attachment #2: throw-isearch-prompt-faces.png --]
[-- Type: image/png, Size: 7672 bytes --]

[-- Attachment #3: throw-isearch-prompt-faces-default.png --]
[-- Type: image/png, Size: 4983 bytes --]

[-- Attachment #4: throw-isearchp-face-defaults.png --]
[-- Type: image/png, Size: 24115 bytes --]

[-- Attachment #5: throw-minibuffer-prompt-w-face.png --]
[-- Type: image/png, Size: 7268 bytes --]

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

[Drew Adams]

> > I think the prompt should be more amenable to Lisp (not
> > done in C), and that any prompt features (including text
> > properties, including `face' and read-only) should be default
> > behavior only.  At least a start would be to allow code to
> > provide a propertized prompt (esp. wrt `face') and have that
> > be used/respected and not overwridden.
> 
> There's already a face 'minibuffer-prompt', so I'm not sure what else
> needs to be done wrt the face of the prompt.

See "should be default behavior only".

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

[Eli Zaretskii]

> Date: Fri, 29 Apr 2016 14:48:48 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: emacs-devel@gnu.org, drew.adams@oracle.com, Stephan.Mueller@microsoft.com
> 
> > > (read-from-minibuffer (concat "What " (propertize "do you want" 'face
> > >                                                   'bold)))
> > 
> > So, more than one face, one each for every part of the prompt?
> 
> Maybe.  Depends on what you need/want.
> 
> It's not the minibuffer, but see attached screenshots of
> isearch prompts (from `isearch+.el').
> 
> The screenshots with the white background show the default
> faces.

AFAICT, those don't show minibuffer prompts at all.  And you evidently
have succeeded to put faces you want there.  So once again, I don't
think I understand what is it that you are looking for, in terms of
faces.

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

[Eli Zaretskii]

> Date: Fri, 29 Apr 2016 14:49:20 -0700 (PDT)
> From: Drew Adams <drew.adams@oracle.com>
> Cc: larsi@gnus.org, emacs-devel@gnu.org, Stephan.Mueller@microsoft.com
> 
> > > I think the prompt should be more amenable to Lisp (not
> > > done in C), and that any prompt features (including text
> > > properties, including `face' and read-only) should be default
> > > behavior only.  At least a start would be to allow code to
> > > provide a propertized prompt (esp. wrt `face') and have that
> > > be used/respected and not overwridden.
> > 
> > There's already a face 'minibuffer-prompt', so I'm not sure what else
> > needs to be done wrt the face of the prompt.
> 
> See "should be default behavior only".

See "what should be the non-default behavior".

And all your examples are about stiff that isn't minibuffer prompts
anyway.

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

[John Wiegley]

>>>>> Kaushal Modi <kaushal.modi@gmail.com> writes:

> Then we do not need to tweak C-a, C-x h to cater to the minibuffer prompt
> corner case.

It certainly seems wrong to me that C-x h would need to take much else into
account except for the "current buffer", since that what it operates on.
Including knowledge about the nature of the buffer breaks an important
abstraction barrier.

-- 
John Wiegley                  GPG fingerprint = 4710 CF98 AF9B 327B B80F
http://newartisans.com                          60E1 46C4 BD1A 7AC1 4BA2

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

[Stefan Monnier]

> Emacs always allowed one to enter the prompt, if one wanted badly enough.

Actually, IIRC the ability to move into the prompt was introduced with
Emacs-21's new redisplay code.  Before that, the minibuffer prompt was
implemented by ad-hoc code in the redisplay (i.e. it did not actually
exist in the minibuffer's buffer).

But, admittedly, Emacs-21 is pretty far in the past.


        Stefan

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

[Stefan Monnier]

> Yup.  Like I said in the bug report, I think the solution here is to
> have read-from-minibuffer not apply the default face if there are any
> faces specified on the prompt string.

"Not apply" sounds wrong.  Better do an "append" so the face properties
provided to read-from-minibuffer get merged with the
minibuffer-prompt face.


        Stefan

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Yup.  Like I said in the bug report, I think the solution here is to
>> have read-from-minibuffer not apply the default face if there are any
>> faces specified on the prompt string.
>
> "Not apply" sounds wrong.  Better do an "append" so the face properties
> provided to read-from-minibuffer get merged with the
> minibuffer-prompt face.

That was my original idea, but I think Drew is right that if somebody
has said

(read-from-minibuffer (propertize "foo" 'face 'bold))

it's pretty unlikely that they want `bold' merged with the blue face...

I mean, they can also bind `minibuffer-prompt-properties', but
that's...  not very convenient, since it has other, necessary
properties, or redefine the minibuffer-prompt face, but that's also not
what you want to do for a single prompt.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Stefan Monnier]

> That was my original idea, but I think Drew is right that if somebody
> has said
> (read-from-minibuffer (propertize "foo" 'face 'bold))
> it's pretty unlikely that they want `bold' merged with the blue face...

FWIW, I disagree.  I expect on the contrary that if the author wrote
(propertize "foo" 'face 'bold), he meant "make this thing bolder than
the rest" rather than "make this thing bold and override the default
minibuffer prompt's face for all other properties".

> I mean, they can also bind `minibuffer-prompt-properties', but
> that's...  not very convenient, since it has other, necessary
> properties, or redefine the minibuffer-prompt face, but that's also not
> what you want to do for a single prompt.

You can use (propertize "foo" 'face '(bold default)) when you want to
override the default minibuffer prompt face.


        Stefan

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

[Lars Ingebrigtsen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> FWIW, I disagree.  I expect on the contrary that if the author wrote
> (propertize "foo" 'face 'bold), he meant "make this thing bolder than
> the rest" rather than "make this thing bold and override the default
> minibuffer prompt's face for all other properties".

Yes...  that might very well be true...

>> I mean, they can also bind `minibuffer-prompt-properties', but
>> that's...  not very convenient, since it has other, necessary
>> properties, or redefine the minibuffer-prompt face, but that's also not
>> what you want to do for a single prompt.
>
> You can use (propertize "foo" 'face '(bold default)) when you want to
> override the default minibuffer prompt face.

Ah, I didn't know that.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no

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

[Drew Adams]

> > > So, more than one face, one each for every part of the prompt?
> >
> > Maybe.  Depends on what you need/want.
> >
> > It's not the minibuffer, but see attached screenshots of
> > isearch prompts (from `isearch+.el').
> 
> AFAICT, those don't show minibuffer prompts at all.

Which is what I said - they are Isearch prompts.  They show
the effect of using different faces for different parts of a
prompt.  But not necessarily "one each for every part".

> And you evidently have succeeded to put faces you want there.

I tweaked Isearch code, yes.  Irrelevant.  Your question was
about what kind of face propertizing was being requested for
minibuffer prompts.  I showed examples of propertized prompts
(for Isearch and minibuffer).

> So once again, I don't think I understand what is it that
> you are looking for, in terms of faces.

I also showed an example using the minibuffer.  Dunno what
else you want to see.  It's about applying text properties,
in particular property `face', to any or all parts of the
minibuffer prompt, and not having that overridden by Emacs.

"So once again," it escapes me what you are having trouble
understanding about this.  Hopefully someone else can be
more helpful than I.  Lars pointed you to bug #12377, but
I guess that didn't help either.

(And yes, it is possible to remove `face' from
`minibuffer-prompt-properties', which is how I am able
to use a prompt that has parts that are propertized
with `face'.  But that means foregoing having face
`minibuffer-prompt' by default.)

The request of bug #12377 is for Emacs to use face
`minibuffer-prompt' _by default_, but not for it to override
text properties (e.g. `face') that are already in the prompt
string.  That's all.

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

[Drew Adams]

> And all your examples are about stiff that isn't minibuffer
> prompts anyway.

No.  I provided a screenshot of a minibuffer prompt also.

All the screenshots show what a prompt with different
parts propertized with faces might look like - why it
might be useful.

The Isearch prompt screenshots show the effect of using
multiple faces in a prompt - why that might be helpful.
(I did not happen to have a screenshot showing multiple
faces in a minibuffer prompt.)

Such a tug-of-war, for even the slightest communication...

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

[Drew Adams]

> Actually, IIRC the ability to move into the prompt was introduced with
> Emacs-21's new redisplay code.  Before that, the minibuffer prompt was
> implemented by ad-hoc code in the redisplay (i.e. it did not actually
> exist in the minibuffer's buffer).

Correct - you cannot move into the prompt with Emacs 20.