RE: read-face-name PROMPT arg should be self-contained, including ": "

RE: read-face-name PROMPT arg should be self-contained, including ": "

[Drew Adams]

`read-face-name' still blindly appends ": " to the prompt it is supplied.
This means that it doesn't conform to what other functions, such as
`completing-read' do. It also means that code that is intended to work with
Emacs 20 as well must have two separate calls to `read-face-name', just to
work around the change in  prompt behavior, one with a prompt arg that
includes the ": " and one with a prompt arg that doesn't include it.

Can we please change this exceptional prompt treatment of `read-face-name',
to make it compatible with `completing-read' behavior and with the previous
`read-face-name' behavior? Nothing important is gained by having the
function tweak the prompt blindly this way. Please let user code decide what
prompt to use, rather than having `read-file-name' try to second-guess what
prompt is needed.

If it is insisted that `read-file-name' try to be smart this way, then at
least have it check the prompt arg to first strip any trailing ": ", before
it appends ": ". That will let most programs that use it work with any Emacs
version. Something as simple as this, for example:

(when (string-match ": $" prompt)
  (setq prompt (substring prompt 0 -2)))

(It would still be better to let user programs control the prompt, with no
second-guessing.)

P.S. I suggest this for Emacs, not for myself. I've already redefined
`read-face-name' in my own code to undo this prompt intelligence.


> From: Drew Adams Sent: Tuesday, January 23, 2007 10:32 AM
> To: Emacs-Pretest-Bug
>
> emacs -Q
>
> `read-face-name' has changed the meaning and behavior of its PROMPT
> arg since Emacs 20, and it is now unconventional, conflicting with
> standard Emacs treatment of PROMPT args. It should not append ": ".
> Instead, calling functions should do that themselves as they deem
> appropriate.
>
> This change was made in Emacs 21, but it is not a good change.  It is
> presumably an attempt to be smart, but it reduces flexibility for
> calling functions.  `read-face-name' should treat its PROMPT arg the
> same way that other Emacs prompting functions, such as
> `completing-read', treat their PROMPT args.
...
> There is at least one other function that is [also] non-standard wrt
> tacking on ": " instead of expecting the PROMPT arg to include it if
> needed: `bookmark-completing-read'.  This problem should be fixed for
> `bookmark-completing-read' also.  It's better to leave ": " to the
> calling function.

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Richard Stallman]

    `read-face-name' still blindly appends ": " to the prompt it is supplied.

I thought of `read-face-name' as an internal function, not for users to use.
But I agree that it could be useful for user code to call.
So I'm not against making this change.  I see that all the callers
within Emacs are easy to change.

If someone wants to do it, please do it.

RE: read-face-name PROMPT arg should be self-contained, including ": "

[Drew Adams]

>     `read-face-name' still blindly appends ": " to the prompt it
>     is supplied.
>
> I thought of `read-face-name' as an internal function, not for
> users to use.
> But I agree that it could be useful for user code to call.
> So I'm not against making this change.  I see that all the callers
> within Emacs are easy to change.
>
> If someone wants to do it, please do it.

Thanks, I hope someone does.

BTW, for sometime after the release, we might consider adding an optional
history-list arg to `read-face-name', so accessing history entries doesn't
include non-face stuff.

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Stefan Monnier]

>> `read-face-name' still blindly appends ": " to the prompt it
>> is supplied.
>> 
>> I thought of `read-face-name' as an internal function, not for
>> users to use.
>> But I agree that it could be useful for user code to call.
>> So I'm not against making this change.  I see that all the callers
>> within Emacs are easy to change.
>> 
>> If someone wants to do it, please do it.

> Thanks, I hope someone does.

> BTW, for sometime after the release, we might consider adding an optional
> history-list arg to `read-face-name', so accessing history entries doesn't
> include non-face stuff.

I was recently thinking that rather than adding new history vars everywhere
all the time, we could change the history navigation to automatically skip
entries which are not completion candidates (at least for those cases that
are `must-match').


        Stefan

RE: read-face-name PROMPT arg should be self-contained, including ": "

[Drew Adams]

> >> `read-face-name' still blindly appends ": " to the prompt it
> >> is supplied.
> >>
> >> I thought of `read-face-name' as an internal function, not for
> >> users to use.
> >> But I agree that it could be useful for user code to call.
> >> So I'm not against making this change.  I see that all the callers
> >> within Emacs are easy to change.
> >>
> >> If someone wants to do it, please do it.
>
> > Thanks, I hope someone does.
>
> > BTW, for sometime after the release, we might consider adding
> > an optional history-list arg to `read-face-name', so accessing
> > history entries doesn't include non-face stuff.
>
> I was recently thinking that rather than adding new history vars
> everywhere
> all the time, we could change the history navigation to automatically skip
> entries which are not completion candidates (at least for those cases that
> are `must-match').

Hmm, maybe. It's worth thinking about, anyway.

Considerations:

. That would tie history cycling to the current typed input, rather than
letting you access any history entry. That is, history cycling would be
among matches only. Would that be good or bad? For non-`must-match', at
least, that might be a nuisance, requiring you to first clear the
minibuffer.

. We already have one way to match against the history, though it is
limited, giving you only the first match.

. It would not really be "rather than", because a history var, if available,
is more efficient. IOW, it would be good, in any case, to _allow_ use of a
history var.

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Stefan Monnier]

>> I was recently thinking that rather than adding new history vars
>> everywhere
>> all the time, we could change the history navigation to automatically skip
>> entries which are not completion candidates (at least for those cases that
>> are `must-match').

> among matches only. Would that be good or bad? For non-`must-match', at
> least, that might be a nuisance, requiring you to first clear the
> minibuffer.

You misunderstood.  By "completion candidates" I didn't mean completion of
the current input, but simply possible completions (i.e. filter the history
through `test-completion').  Of course.


        Stefan

RE: read-face-name PROMPT arg should be self-contained, including ": "

[Drew Adams]

> >> I was recently thinking that rather than adding new history vars
> >> everywhere all the time, we could change the history navigation
> >> to automatically skip entries which are not completion
> >> candidates (at least for those cases that are `must-match').
>
> > among matches only. Would that be good or bad? For non-`must-match', at
> > least, that might be a nuisance, requiring you to first clear the
> > minibuffer.
>
> You misunderstood.  By "completion candidates" I didn't mean completion of
> the current input, but simply possible completions (i.e. filter
> the history through `test-completion').  Of course.

OK, the current user input would be irrelevant here - got it.

But what do you mean by "filter the history"? Do you mean filter the initial
set of possible completions, to keep only those candidates that are in the
history?

If so, then this would still be limiting for non-`must-match', IIUC. If you
wanted to be able to cycle to a history entry that is not in the initial set
of completions, you could not.

IOW, this would still tie the history list to the set of possible
completions, even if it wasn't the set of completions matching the current
input. Maybe that would be a good thing, maybe not - it's worth thinking
about, at least.

A priori, I tend to think it's good to keep the history list and the initial
set of possible completions separate, allowing access to entries in each
that might not be in the other. But I'd like to hear arguments for linking
the two - it's good that you brought this up.

And, as I mentioned, we should at least _allow_ use of a history variable,
if only for efficiency.

I do agree that it would be worthwhile to provide an easy way to access any
historical input by matching - beyond what M-r does.

I misspoke, BTW, when I said that history matching (M-r) gives you only the
first match. What I meant was that you must use M-r again to access another
match. M-r M-r M-r is not very convenient for rapidly accessing different
matching history items, in order, and you cannot simply type input to match
against all of the history items that match the M-r regexp.

One way to improve on that might be to have successive M-r's not ask for a
regexp, but reuse the regexp that you input for the first M-r. We could then
arrange things so that you could then use just M-r e.*r M-r M-r M-r to cycle
among the history items matching e.*r. A problem with that is that you could
not then use M-r with a different regexp.

An alternative approach, which would not have that problem, would be to make
M-p (and M-n) following M-r (and M-s) cycle among only the regexp matches.
You could then do M-r e.*r M-p M-p M-p, getting the successive matches of
e.*r. A problem with that is that you could not then use M-p to access
historical candidates that didn't match the regexp. You could of course use
M-r .* again to "clear" the regexp filtering (except for \n matches), but
users might not think of that. We could, BTW, change M-r RET to clear regexp
filtering, instead of repeating the previous regexp.

FWIW - In Icicles, I do something different to let you match against the
history: You can type `M-pause' to filter  current matches for your input to
those that are in the history. Or you can type `M-h' to ignore the current
set of completions and match your input against the history list directly.
(Unlike `M-h', after you use `M-pause' you are not locked into matching
against the history list.) You can then complete against the historical
candidates or cycle among them. (Icicles allows regexp matching, so you can
match e.*r against stuff in the history list without using M-r.)

FWIW2 - Tamas Patrovics' library timid.el takes another approach. After a
short delay when you type some input, it pops up the list of matching
history items, without your asking for it explicitly (e.g. via `M-h'). You
can then cycle among the history matches (but you cannot complete to one of
those matches). Rather than being truly timid, doing nothing until asked
(e.g. `M-h'), Timid interrupts whenever there is a sufficient lull in the
conversation - it could be called "suggest.el". The longer the lull,
however, the greater the timidity; you can configure the lull to make Timid
as timid as you like.

What these various features offer are ways to filter the history list and
cycle among those matches (and, for Icicles, to complete against them).
Currently, it is not too convenient to cycle among matches in Emacs using
just M-r.

Both Icicles and Timid let you see the list of history matches, which is
another advantage, I think, over M-r. Especially when trying to come up with
an improved regexp for matching, it helps to see what the current matches
are (and how many there are). Perhaps Emacs could show the list of regexp
matches if you used TAB after you used M-r. (Again, that would require users
to use M-r .* to clear the regexp filtering, so that TAB would work
~normally again.)

Anyway, lots of stuff to think about...after the release.

Refs:
* Icicles: http://www.emacswiki.org/cgi-bin/wiki/icicles.el
* Timid: http://www.emacswiki.org/cgi-bin/wiki/timid.el

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Richard Stallman]

    I was recently thinking that rather than adding new history vars everywhere
    all the time, we could change the history navigation to automatically skip
    entries which are not completion candidates (at least for those cases that
    are `must-match').

That seems like a good idea, but I am not sure it is a substitute
for separate history lists.

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Stefan Monnier]

>     I was recently thinking that rather than adding new history vars
>     everywhere all the time, we could change the history navigation to
>     automatically skip entries which are not completion candidates (at
>     least for those cases that are `must-match').

> That seems like a good idea, but I am not sure it is a substitute
> for separate history lists.

In the case of read-face-name it should work just as well.


        Stefan

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Stefan Monnier]

>> >> I was recently thinking that rather than adding new history vars
>> >> everywhere all the time, we could change the history navigation
>> >> to automatically skip entries which are not completion
>> >> candidates (at least for those cases that are `must-match').
                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^

> If so, then this would still be limiting for non-`must-match', IIUC. If you
> wanted to be able to cycle to a history entry that is not in the initial set
> of completions, you could not.

Which part of my quoted text (underlined above) did you not understand?


        Stefan

RE: read-face-name PROMPT arg should be self-contained, including ": "

[Drew Adams]

> >> >> I was recently thinking that rather than adding new history vars
> >> >> everywhere all the time, we could change the history navigation
> >> >> to automatically skip entries which are not completion
> >> >> candidates (at least for those cases that are `must-match').
>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>
> > If so, then this would still be limiting for non-`must-match',
> > IIUC. If you wanted to be able to cycle to a history entry
> > that is not in the initial set of completions, you could not.
>
> Which part of my quoted text (underlined above) did you not understand?

I understood that. I tried to clarify that it is not "at least"; it is
_only_ for the must-match case.

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Tamas Patrovics]

Please remove me from the followups of this thread. I didn't ask to be  
included it in the first place.

On Mon, 19 Mar 2007 21:07:43 +0100, Drew Adams <drew.adams@oracle.com>  
wrote:

>> >> >> I was recently thinking that rather than adding new history vars
>> >> >> everywhere all the time, we could change the history navigation
>> >> >> to automatically skip entries which are not completion
>> >> >> candidates (at least for those cases that are `must-match').
>>                  ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>>
>> > If so, then this would still be limiting for non-`must-match',
>> > IIUC. If you wanted to be able to cycle to a history entry
>> > that is not in the initial set of completions, you could not.
>>
>> Which part of my quoted text (underlined above) did you not understand?
>
> I understood that. I tried to clarify that it is not "at least"; it is
> _only_ for the must-match case.
>

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Richard Stallman]

    > That seems like a good idea, but I am not sure it is a substitute
    > for separate history lists.

    In the case of read-face-name it should work just as well.

Maybe so, but your proposal is not specifically about read-face-name.

Re: read-face-name PROMPT arg should be self-contained, including ": "

[Stefan Monnier]

>> That seems like a good idea, but I am not sure it is a substitute
>> for separate history lists.

>     In the case of read-face-name it should work just as well.

> Maybe so, but your proposal is not specifically about read-face-name.

That's true, but I don't claim my proposal will make separate history lists
unnecessary, just less often necessary.


        Stefan

RE: read-face-name PROMPT arg should be self-contained, including ": "

[Drew Adams]

> Sent: March 18, 2007
> BTW, for sometime after the release, we might consider adding an optional
> history-list arg to `read-face-name', so accessing history entries doesn't
> include non-face stuff.

It might also be useful to allow a PREDICATE argument. It would then be easy
for an application to, say, limit candidates to face names that begin
`font-lock-'.