Menu commands to M-x history?

Menu commands to M-x history?

[Lennart Borgman]

Menu commands are all commands that can be started from M-x.  I think
they should be added to M-x history.

Users often uses menus to start commands because they do not know the
command name. Menus are very good for them -- and for commands that we
seldom use. (Advanced users may prefer a controller/view UI instead,
like Drew has been trying to make with Icicles.)

We have had a hard time to decide how the menus should look. There are
now many very useful commands, especially for beginners, like
rgrep/lgrep etc that we have not been able to place in the menus
because we do not know where to put them. That is not very good for
anyone of course, but worse for newcommers.

One reason is the available space in the menus. They should not be too
long and there should not be too many levels. These two constraints
fight each other.

I personally prefer each menu level to be not too long and good
structured by dividing it into groups. In my opinion it makes it
easier to quickly read them and search for commands.

However making it menu level smaller makes the menu levels deeper
instead. Some people have said that this makes it very inconvenient
for things you use often. Adding the commands choosen from the menus
to M-x history may make it less inconvenient.


Now, if someone says it clutters the M-x history then I must ask if it
is not cluttered already. What are those things that are there already
when you start with "emacs -Q"? ;-)


BTW I have lately seen some new kind of problems with the menus. I
guess I am one of those that are most likely to see it, since my
patches on w32 allows normal access to the menus. Lately I have seen
things like

    <emacs-manual> is not defined.

That looks bad to me. Anyone knows what is going on?

Re: Menu commands to M-x history?

[Bill Wohler]

Lennart Borgman <lennart.borgman@gmail.com> writes:

> Menu commands are all commands that can be started from M-x.  I think
> they should be added to M-x history.

This seems like a good idea. Whether a command is run with M-x, a menu
item, or a button, the semantics should be identical.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Menu commands to M-x history?

[Stefan Monnier]

> Menu commands are all commands that can be started from M-x.  I think
> they should be added to M-x history.

Most of them should have a key shortcut anyway, which the user has seen
in the menu entry.

For those entries which don't have a keyboard shortcut, maybe we could
(along the lines of what M-x does) output a message like "You can run
this command with M-x foo-bar-baz".


        Stefan

Re: Menu commands to M-x history?

[Lennart Borgman]

On Tue, Jul 21, 2009 at 5:31 PM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
>> Menu commands are all commands that can be started from M-x.  I think
>> they should be added to M-x history.
>
> Most of them should have a key shortcut anyway, which the user has seen
> in the menu entry.


We have discussed several cases where this is unnecessary. It does not
always reduce the number of keystrokes.


> For those entries which don't have a keyboard shortcut, maybe we could
> (along the lines of what M-x does) output a message like "You can run
> this command with M-x foo-bar-baz".


Yes, and wouldn't it be good to have those commands in the the history
then? In that case a helpful message might tell that too.

Re: Menu commands to M-x history?

[Richard Stallman]

    > Menu commands are all commands that can be started from M-x.  I think
    > they should be added to M-x history.

    This seems like a good idea. Whether a command is run with M-x, a menu
    item, or a button, the semantics should be identical.

The only "M-x history" in Emacs is the history list used for reading
the argument of M-x.  That should only be used for arguments that you
enter in the M-x command.

Keyboard keys also run commands that you could run with M-x, but
putting their names in the M-x history list would not be consistent or
useful.  It is the same for menu-run commands.

There is also command-history, which gets all commands
that read an argument from the terminal, whether or not they
were run from a menu.

RE: Menu commands to M-x history?

[Drew Adams]

> The only "M-x history" in Emacs is the history list used for reading
> the argument of M-x.  That should only be used for arguments that you
> enter in the M-x command.
> 
> Keyboard keys also run commands that you could run with M-x, but
> putting their names in the M-x history list would not be consistent or
> useful.  It is the same for menu-run commands.
> 
> There is also command-history, which gets all commands
> that read an argument from the terminal, whether or not they
> were run from a menu.

FWIW, that sounds right to me.

The question of informing users what command corresponds to a menu item they've
used, and which could therefore be run alternatively via `M-x', is a different
question. Nothing wrong with looking for good ways to inform users about this.

Re: Menu commands to M-x history?

[Lennart Borgman]

On Wed, Jul 22, 2009 at 3:43 AM, Richard Stallman<rms@gnu.org> wrote:
>    > Menu commands are all commands that can be started from M-x.  I think
>    > they should be added to M-x history.
>
>    This seems like a good idea. Whether a command is run with M-x, a menu
>    item, or a button, the semantics should be identical.
>
> The only "M-x history" in Emacs is the history list used for reading
> the argument of M-x.  That should only be used for arguments that you
> enter in the M-x command.
>
> Keyboard keys also run commands that you could run with M-x, but
> putting their names in the M-x history list would not be consistent or
> useful.


It would not be useful to put commands run by keyboard keys in the
history of course since the user already knows a good way to start the
command. I therefore did not suggest that. Sorry if you misunderstod
me.

Regarding the consistency I do not mind. We do similar things in other
parts of Emacs. On this level, ie UI, the usefulness is more
important, at least to my understanding. And the history list is only
for usefulness, it's target is the user. Not the developer.


> It is the same for menu-run commands.


No. For menu-run commands the user may need some help. One of the
reasons for using menus is that you do not know the command name.

Putting the commands in the history makes it easier to remember.
Consider the case that a user used a menu command and then a while
later want to do the same thing again. Then having the command in the
history would be useful (both to new and old users, actually).

However what I wonder is if other find such a feature useful. It is
not tremendously important, but small things adds together.


> There is also command-history, which gets all commands
> that read an argument from the terminal, whether or not they
> were run from a menu.


Yes, but that is not very helpful here, or?

Re: Menu commands to M-x history?

[Bill Wohler]

Richard Stallman <rms@gnu.org> wrote:

>     > Menu commands are all commands that can be started from M-x.  I think
>     > they should be added to M-x history.
> 
>     This seems like a good idea. Whether a command is run with M-x, a menu
>     item, or a button, the semantics should be identical.
> 
> The only "M-x history" in Emacs is the history list used for reading
> the argument of M-x.  That should only be used for arguments that you
> enter in the M-x command.
> 
> Keyboard keys also run commands that you could run with M-x, but
> putting their names in the M-x history list would not be consistent or
> useful.  It is the same for menu-run commands.

Yes, that is true.

Perhaps a better way of learning what command is on a button or menu
item is to use help such as `M-x help RET k <Menu item> RET'.

-- 
Bill Wohler <wohler@newt.com>  http://www.newt.com/wohler/  GnuPG ID:610BD9AD

Re: Menu commands to M-x history?

[Mathias Dahl]

> Perhaps a better way of learning what command is on a button or menu
> item is to use help such as `M-x help RET k <Menu item> RET'.

I think that is enough too.

At first I kind of liked Lennart's idea. For example, sometimes I have
used the Edit -> Text Properties -> Foreground Color command and have
been wondering how to do the same from the keyboard (is it possible?)
but I think I would be annoyed having my precious M-x history filled
with things I did not expect. Quite often I execute the same M-x
command over and over again, doing something else in between, and if
what I did in between included executing some menu commands I might be
annoyed to have to step back some extra steps in order to get at the
command I want to run.

BTW, Lennart, you run Windows, right? Wouldn't your proposal be like
adding stuff to the Start -> Run prompt history whenever you ran
something from a shortcut on the Start menu? (hmm... hopefully you
would not like this, but who knows... :)

/Mathias

RE: Menu commands to M-x history?

[Drew Adams]

> > Perhaps a better way of learning what command is on a button or menu
> > item is to use help such as `M-x help RET k <Menu item> RET'.
> 
> I think that is enough too.

I agree: `C-h k' or a tooltip is sufficient to show the command associated with
a menu item or button.

However, it can also be convenient to be able to complete against commands that
were previously executed using a menu. You might want to do this some of the
time (but probably not by default).


FWIW, this feature is available in Icicles in the following way:

1. Each command executed by `call-interactively' is added to a larger history
list, `icicle-interactive-history'. The normal history for commands,
`extended-command-history', is treated just as before: commands are added to it
only via `M-x'.

2. If you use `C-M-pause' during completion of a command name, your input is
completed against the larger history, `icicle-interactive-history'. You can thus
complete your input to the command that is behind a previously used menu item.

3. If you use `C-M-pause' during any other completion (or if you use it with a
prefix arg during command completion), then you can choose an alternative
history to use for the current completion. You can then use the usual ways of
accessing history entries.

4. If after #3 you use `M-h', you can complete your input against the
alternative history you chose. (`M-h' always completes against the current
history, in Icicles.)

> At first I kind of liked Lennart's idea. For example, sometimes I have
> used the Edit -> Text Properties -> Foreground Color command and have
> been wondering how to do the same from the keyboard (is it possible?)
> but I think I would be annoyed having my precious M-x history filled
> with things I did not expect.

That's why Icicles uses a separate history that includes everything executed by
`call-interactively' (which includes menu items). And it's why you use this
larger history only on demand (via `C-M-pause').

> Quite often I execute the same M-x
> command over and over again, doing something else in between, and if
> what I did in between included executing some menu commands I might be
> annoyed to have to step back some extra steps in order to get at the
> command I want to run.

Yes. Use the larger history only when you want to.

5. Of course, when you complete against a command previously accessed using a
menu, you need to be able to recognize the command name, which is sometimes
quite different from the menu-item name.

Icicles helps here by showing the associated command name (in the *Completions*
mode line) whenever you cycle to a menu item during completion. For example,
library La Carte completes menu items, and Icicles shows the command for the
current item during cycling. (Unlike tmm-menubar, La Carte completes absolute
menu items (paths) - similar to file-name completion).

6. If you use `M-h' during La Carte's menu-item completion, you complete against
all commands previously entered interactively, including those accessed by menu
(via keyboard or otherwise).

Re: Menu commands to M-x history?

[Lennart Borgman]

On Mon, Jul 27, 2009 at 3:47 AM, Drew Adams<drew.adams@oracle.com> wrote:
>> > Perhaps a better way of learning what command is on a button or menu
>> > item is to use help such as `M-x help RET k <Menu item> RET'.
>>
>> I think that is enough too.
>
> I agree: `C-h k' or a tooltip is sufficient to show the command associated with
> a menu item or button.
>
> However, it can also be convenient to be able to complete against commands that
> were previously executed using a menu. You might want to do this some of the
> time (but probably not by default).
>
>
> FWIW, this feature is available in Icicles in the following way:


So you think it is enough to not have the menu commands available in
Emacs M-x history variable, but that it is good to have it available
(in a different way) in your Icicles library?

RE: Menu commands to M-x history?

[Drew Adams]

> >> > Perhaps a better way of learning what command is on a 
> >> > button or menu item is to use help such as `M-x help
> >> > RET k <Menu item> RET'.
> >>
> >> I think that is enough too.
> >
> > I agree: `C-h k' or a tooltip is sufficient to show the 
> > command associated with a menu item or button.
> >
> > However, it can also be convenient to be able to complete 
> > against commands that were previously executed using a menu.
> > You might want to do this some of the time (but probably not
> > by default).
> >
> > FWIW, this feature is available in Icicles in the following way:
> 
> So you think it is enough to not have the menu commands available in
> Emacs M-x history variable, but that it is good to have it available
> (in a different way) in your Icicles library?

Just what is unclear about what I wrote?

1. I think C-h k or a tooltip is generally enough for seeing the command
associated with a menu item.

2. Nevertheless, it can also help sometimes to be able to complete against
command names corresponding to menu items.

3. Such completion should probably not be part of the normal (default) command
completion, for reasons already discussed (e.g. by Mathias).

4. It can help to make such completion available on demand during normal command
completion. That is, while completing a normal command name, hit some key to
complete also against menu-item commands already entered.

5. This suggests having a separate, more inclusive command history, which
includes menu-item commands - to be used only on demand, not by default.

6. I explained how Icicles handles this, as an example of what is possible.

Re: Menu commands to M-x history?

[Lennart Borgman]

On Mon, Jul 27, 2009 at 5:48 PM, Drew Adams<drew.adams@oracle.com> wrote:
>> >> > Perhaps a better way of learning what command is on a
>> >> > button or menu item is to use help such as `M-x help
>> >> > RET k <Menu item> RET'.
>> >>
>> >> I think that is enough too.
>> >
>> > I agree: `C-h k' or a tooltip is sufficient to show the
>> > command associated with a menu item or button.
>> >
>> > However, it can also be convenient to be able to complete
>> > against commands that were previously executed using a menu.
>> > You might want to do this some of the time (but probably not
>> > by default).
>> >
>> > FWIW, this feature is available in Icicles in the following way:
>>
>> So you think it is enough to not have the menu commands available in
>> Emacs M-x history variable, but that it is good to have it available
>> (in a different way) in your Icicles library?
>
> Just what is unclear about what I wrote?
>
> 1. I think C-h k or a tooltip is generally enough for seeing the command
> associated with a menu item.
>
> 2. Nevertheless, it can also help sometimes to be able to complete against
> command names corresponding to menu items.
>
> 3. Such completion should probably not be part of the normal (default) command
> completion, for reasons already discussed (e.g. by Mathias).


Matthias said:
    Quite often I execute the same M-x
    command over and over again, doing something else in between, and if
    what I did in between included executing some menu commands I might be
    annoyed to have to step back some extra steps in order to get at the
    command I want to run.

Sorry Matthias, forgot to answer, but exactly why is it useful to
distinguish between commands started from the menu and from M-x
because of this? I don't believe that you think something like "ah,
wait, now I will do the next command from the menus to avoid getting
it into M-x history". Or do you actually do that? ;-)


Drew, I think you see what I mean. This reasoning just gets overlay
complicated to actually use IMO.

Just putting the menu commands in the M-x history (+ displaying a
comment about it) is simple, easy to understand and make the coupling
between M-x and the menus visible to new users too. And it also have
the advantage that it is much easier to redo commands that are rather
deep down in the menus.



> 4. It can help to make such completion available on demand during normal command
> completion. That is, while completing a normal command name, hit some key to
> complete also against menu-item commands already entered.
>
> 5. This suggests having a separate, more inclusive command history, which
> includes menu-item commands - to be used only on demand, not by default.
>
> 6. I explained how Icicles handles this, as an example of what is possible.
>
>

RE: Menu commands to M-x history?

[Drew Adams]

> Matthias said:
>     Quite often I execute the same M-x
>     command over and over again, doing something else in 
>     between, and if what I did in between included executing
>     some menu commands I might be annoyed to have to step back
>     some extra steps in order to get at the command I want to run.
> 
> exactly why is it useful to distinguish between commands started
> from the menu and from M-x

As someone else said, `M-x' is, well, for `M-x'-executed commands. That's
important for users. It is why commands executed using key bindings are also not
included in the history list.

Besides this difference in intention (meaning of M-x), there is the difference
in noise level. If you had to search a history for every command you ever
executed, including every key you pressed (C-f, C-k,...), the search history
would be much less useful.

So, I hear you say, filter out insignificant commands - commands such as
`self-insert-command' and `forward-char'. Then where do you draw the line? One
person's aid is another person's noise.

The current criterion of recording the commands actually entered using `M-x' is
a good one, and should be kept. Access to additional commands should be
optional, on demand.

> Drew, I think you see what I mean. This reasoning just gets overlay
> complicated to actually use IMO.

Why? The only change is to provide some key to let you access the additional
commands.

Icicles uses `C-M-pause' for that, which is admittedly exotic. ;-) But Emacs
could choose a simpler key.

(Icicles has lots of minibuffer key bindings, and this one is less simple
because it is not as important as some others. That doesn't mean the idea isn't
simple.)

> Just putting the menu commands in the M-x history (+ displaying a
> comment about it) is simple, easy to understand and make the coupling
> between M-x and the menus visible to new users too.

See above. Such a coupling is not helpful as the default behavior.

> And it also have the advantage that it is much easier to redo
> commands that are rather deep down in the menus.

As opposed to what? Easier to redo than what alternative - using the menu again?

If that's what you mean, then we agree: It can help users if we also provide
completion for commands originally accessed using a menu. The question we seem
to disagree about is whether those commands should be available for completion
_by default_, that is, as part of the normal `M-x' command history.

Re: Menu commands to M-x history?

[Lennart Borgman]

On Mon, Jul 27, 2009 at 6:21 PM, Drew Adams<drew.adams@oracle.com> wrote:
>> Matthias said:
>>     Quite often I execute the same M-x
>>     command over and over again, doing something else in
>>     between, and if what I did in between included executing
>>     some menu commands I might be annoyed to have to step back
>>     some extra steps in order to get at the command I want to run.
>>
>> exactly why is it useful to distinguish between commands started
>> from the menu and from M-x
>
> As someone else said, `M-x' is, well, for `M-x'-executed commands.

Yes, Richard said that but I do not agree. The M-x history is for the users.

Don't mix the programmer semantics with the user semantics unless
there is a good reason to do so. Very often there is, but not in a
case like this.


> That's important for users.

Why is it important for users?


> It is why commands executed using key bindings are also not
> included in the history list.

That is a totally diffirent story since it is a different context as I
said before. You really do not need any of the commands you execute
with a key binding in the M-x history.


> So, I hear you say, filter out insignificant commands - commands such as
> `self-insert-command' and `forward-char'.

That is hallucination ;-)

No one calls these commands from the menus. (You did not intend to say
that, but I could not resist writing this ...)


>> Drew, I think you see what I mean. This reasoning just gets overlay
>> complicated to actually use IMO.
>
> Why? The only change is to provide some key to let you access the additional
> commands.

Because it is intended to be helpful to newbies, Not to experienced Emacs users.


>> And it also have the advantage that it is much easier to redo
>> commands that are rather deep down in the menus.
>
> As opposed to what? Easier to redo than what alternative - using the menu again?

Yes, of course. The reason I am saying that is that there has been
some rather vaugue arguments that menus should not be to deep. (Not
here, but before, Richard has said that for example.)

That they should not be to deep is a valid argument mainly when you
use the commands from the menus often. But it is a bad argument when
you want to use the menus more for finding commands. (We use that
reasoning for example in the help menus.)

In the cases that the menus are deep it can be very helpful to put the
commands in M-x history IMO. And the other ones does not disturb very
much since you either do not use them often or use a key binding for
the commands.


> If that's what you mean, then we agree: It can help users if we also provide
> completion for commands originally accessed using a menu. The question we seem
> to disagree about is whether those commands should be available for completion
> _by default_, that is, as part of the normal `M-x' command history.

Yes. I think they should be in M-x command history. Not putting them
there is merely a misunderstanding of what semantics to use.

RE: Menu commands to M-x history?

[Drew Adams]

> > As someone else said, `M-x' is, well, for `M-x'-executed commands.
> 
> Yes, Richard said that but I do not agree. The M-x history is 
> for the users.

And? Of course histories are for users.

"The history"? There are plenty of different histories, appropriate to different
commands that use them. This is the history for `M-x'. When you call
`completing-read', if you specify a history-variable arg, then the user's input
is added to that particular history. The history used for `M-x' is
`extended-command-history'.

> Don't mix the programmer semantics with the user semantics unless
> there is a good reason to do so. Very often there is, but not in a
> case like this.

What does that mean? How did I mix them? Or what non-mixing do you have in mind?
IOW, what is it that you are really trying to say?

> > That's important for users.
> 
> Why is it important for users?

See what was said previously. Noise reduction. Pertinence of history entries to
the task at hand.

You know, we _could_ always use just `minibuffer-history', and have no such
specificity. But that is less useful to users.

> > It is why commands executed using key bindings are also not
> > included in the history list.
> 
> That is a totally diffirent story since it is a different context as I
> said before. You really do not need any of the commands you execute
> with a key binding in the M-x history.

I think you do. But only on demand. I won't bother arguing for/about that here.
But yes, in Icicles, on-demand access to menu-item commands is no different from
on-demand access to all other commands called using `call-interactively'. I
simply advise `call-interactively', to push each such command to the larger
list, `icicle-interactive-history'.

> > So, I hear you say, filter out insignificant commands - 
> commands such as
> > `self-insert-command' and `forward-char'.
> 
> That is hallucination ;-)

You in fact say to filter out _all_ commands invoked via keys, which is an even
stronger hallucination.

> No one calls these commands from the menus. (You did not intend to say
> that, but I could not resist writing this ...)

I said that I treat all commands called using `call-interactively' the same way.


> >> Drew, I think you see what I mean. This reasoning just gets overlay
> >> complicated to actually use IMO.
> >
> > Why? The only change is to provide some key to let you 
> > access the additional commands.
> 
> Because it is intended to be helpful to newbies, Not to 
> experienced Emacs users.

I intend it to be helpful to both. If a newbie can learn `C-h k', then s?he can
learn a key to complete commands previously invoked from the menu.

And as I mentioned, with La Carte, a newbie can use just the menu if s?he wants,
with completion of menu items. And there, the history passed to
`completing-read' is `icicle-interactive-history', so there is no need to hit a
special key to access such commands. 

It is only for `M-x' (which is not about menu items) that you hit a special key
to enlarge the history list to include commands invoked other than by `M-x'.

> That they should not be to deep is a valid argument mainly when you
> use the commands from the menus often. But it is a bad argument when
> you want to use the menus more for finding commands. (We use that
> reasoning for example in the help menus.)

I don't have an argument with you here, except that _other things being equal_,
a shallow is easier than deep. Believe me, as someone who used the infamous
Interleaf GUI, which had cascading menus 8 zillion levels deep - that's no
panacea for users.

> In the cases that the menus are deep it can be very helpful to put the
> commands in M-x history IMO. And the other ones does not disturb very
> much since you either do not use them often or use a key binding for
> the commands.

We agree that being able to access menu items via history can be helpful. We
disagree whether such access should be by default or on demand.

> Yes. I think they should be in M-x command history. Not putting them
> there is merely a misunderstanding of what semantics to use.

Dunno what that means.

Re: Menu commands to M-x history?

[Lennart Borgman]

On Mon, Jul 27, 2009 at 8:57 PM, Drew Adams<drew.adams@oracle.com> wrote:
>> > As someone else said, `M-x' is, well, for `M-x'-executed commands.
>>
>> Yes, Richard said that but I do not agree. The M-x history is
>> for the users.
>
> And? Of course histories are for users.

You said that this history is for just M-x history commands. That
semantic is really a programmers semantic. The argument we want to use
for the user interface is rather if it is useful for users to do a
certain thing.


>> Don't mix the programmer semantics with the user semantics unless
>> there is a good reason to do so. Very often there is, but not in a
>> case like this.
>
> What does that mean? How did I mix them? Or what non-mixing do you have in mind?
> IOW, what is it that you are really trying to say?

Really nothing more than that the argument the M-x history is for "M-x
executed commands" is useless. It focuses more on the programming side
than on the user.


>> > That's important for users.
>>
>> Why is it important for users?
>
> See what was said previously. Noise reduction.

If we want to put menu commands in M-x history then it is not noise.


> Pertinence of history entries to
> the task at hand.

I can't see why that should exclude menu commands from M-x history. Do
you do something very special when you use the menus that you do not
do when you use M-x?


> You know, we _could_ always use just `minibuffer-history', and have no such
> specificity. But that is less useful to users.

And why do you say this? ... ;-)


>> > It is why commands executed using key bindings are also not
>> > included in the history list.
>>
>> That is a totally diffirent story since it is a different context as I
>> said before. You really do not need any of the commands you execute
>> with a key binding in the M-x history.
>
> I think you do. But only on demand.

I am surprised. It seems like a very minor case.


>> Because it is intended to be helpful to newbies, Not to
>> experienced Emacs users.
>
> I intend it to be helpful to both. If a newbie can learn `C-h k', then s?he can
> learn a key to complete commands previously invoked from the menu.

Nothing wrong with that of course. I just mean that there is not so
very much to care about for old time users if commands invoked from
the menus are put in the M-x history.


>> In the cases that the menus are deep it can be very helpful to put the
>> commands in M-x history IMO. And the other ones does not disturb very
>> much since you either do not use them often or use a key binding for
>> the commands.
>
> We agree that being able to access menu items via history can be helpful. We
> disagree whether such access should be by default or on demand.

Yes.

RE: Menu commands to M-x history?

[Drew Adams]

> You said that this history is for just M-x history commands. That
> semantic is really a programmers semantic. The argument we want to use
> for the user interface is rather if it is useful for users to do a
> certain thing.

Well, that's exactly the question we're discussing:

1. Whether it is useful to include commands invoked using the menu in M-x's
history.

2. If so, whether to do that by default or only on demand.

You and I say it can be useful (1); some others have seemed to say no. You say
this should be the default behavior (2); I say no. Neither of us is arguing from
the point of view of implementers. All arguments so far have been in terms of
usefulness to users. We just disagree.
 
> >> Don't mix the programmer semantics with the user semantics unless
> >> there is a good reason to do so. Very often there is, but not in a
> >> case like this.
> >
> > What does that mean? How did I mix them? Or what non-mixing 
> > do you have in mind? IOW, what is it that you are really trying to say?
> 
> Really nothing more than that the argument the M-x history is for "M-x
> executed commands" is useless. It focuses more on the programming side
> than on the user.

I don't see why. As a user, I want to see, by default, the commands I have
already entered as input to M-x.

This has nothing, for me, to do with "the programming side". It would be easy
enough for me to always use the larger list, `icicle-interactive-history', which
includes menu item, in the Icicles implementation of `M-x'. I choose not to do
so for the benefit of users. There is no difficulty in substituting a different
history variable, so your "programming side" argument is without basis.

> >> > That's important for users.
> >> Why is it important for users?
> > See what was said previously. Noise reduction.
> 
> If we want to put menu commands in M-x history then it is not noise.

Again, it just means more stuff for users to search through. And in the Icicles
case, I include not only menu items but all commands invoked using
`call-interactively' (which means even more such noise).

> > Pertinence of history entries to the task at hand.
> 
> I can't see why that should exclude menu commands from M-x history. Do
> you do something very special when you use the menus that you do not
> do when you use M-x?

I don't have an answer that will satisfy you, I guess. I think we can agree to
disagree.

> > You know, we _could_ always use just `minibuffer-history', 
> > and have no such specificity. But that is less useful to users.
> 
> And why do you say this? ... ;-)

Why would no specificity at all be less useful? Seems obvious. Although the
`commandp' predicate for `M-x' would filter out non-commands as completion
candidates, accessing non-commands from the history via `M-p' etc. would mean
plowing through irrelevant noise.

If you consider all of the possible types of completion candiates (colors,
buffers, files, commands, variables, ...), I should think the interest in having
separate, domain-specific history lists would be obvious.

> >> > It is why commands executed using key bindings are also not
> >> > included in the history list.
> >>
> >> That is a totally diffirent story since it is a different 
> >> context as I said before. You really do not need any of the
> >> commands you execute with a key binding in the M-x history.
> >
> > I think you do. But only on demand.
> 
> I am surprised. It seems like a very minor case.

Well, in Icicles, you can do multiple things with multiple completion
candidates. Just as you can build a keyboard macro using both keystrokes and M-x
invocations, so a combination can sometimes be useful in Icicles. At least,
that's the idea.

But I suppose that three tiers could be useful:

1. M-x commands
2. #1 + commands invoked via menu
3. #2 + the other commands invoked via `call-interactively'

Currently, I have only two tiers: #1 and #3 (including #2).
 
> >> Because it is intended to be helpful to newbies, Not to
> >> experienced Emacs users.
> >
> > I intend it to be helpful to both. If a newbie can learn 
> > `C-h k', then s?he can learn a key to complete commands previously
> > invoked from the menu.
> 
> Nothing wrong with that of course. I just mean that there is not so
> very much to care about for old time users if commands invoked from
> the menus are put in the M-x history.

You mean that adding those commands won't bother old-timers? Dunno.
 
> > We agree that being able to access menu items via history 
> > can be helpful. We disagree whether such access should be by
> > default or on demand.
> 
> Yes.

Re: Menu commands to M-x history?

[Lennart Borgman]

On Mon, Jul 27, 2009 at 10:26 PM, Drew Adams<drew.adams@oracle.com> wrote:
>> You said that this history is for just M-x history commands. That
>> semantic is really a programmers semantic. The argument we want to use
>> for the user interface is rather if it is useful for users to do a
>> certain thing.
>
> Well, that's exactly the question we're discussing:
>
> 1. Whether it is useful to include commands invoked using the menu in M-x's
> history.
>
> 2. If so, whether to do that by default or only on demand.
>
> You and I say it can be useful (1); some others have seemed to say no. You say
> this should be the default behavior (2); I say no. Neither of us is arguing from
> the point of view of implementers. All arguments so far have been in terms of
> usefulness to users. We just disagree.


Then please don't use arguments like "As someone else said, `M-x' is,
well, for `M-x'-executed commands". By that it looks like you imply
there is a very special semantics behind it that we should follow.
(You can of course use such language, but just throw it away when you
can't defend it.)


>> Really nothing more than that the argument the M-x history is for "M-x
>> executed commands" is useless. It focuses more on the programming side
>> than on the user.
>
> I don't see why. As a user, I want to see, by default, the commands I have
> already entered as input to M-x.


Maybe. I don't think that is true for all users since I have seen this
implemented in other places (not in Emacs and I don't remember where
now).

Perhaps there should be an option for this then.


>> If we want to put menu commands in M-x history then it is not noise.
>
> Again, it just means more stuff for users to search through.


There should be no more than what is useful to have there and no less.
So I can't find your argument here useful.


> And in the Icicles
> case, I include not only menu items but all commands invoked using
> `call-interactively' (which means even more such noise).


To me it seems very strange to put all commands called from
call-interactively there so I am not proposing that.


>> I can't see why that should exclude menu commands from M-x history. Do
>> you do something very special when you use the menus that you do not
>> do when you use M-x?
>
> I don't have an answer that will satisfy you, I guess. I think we can agree to
> disagree.


Yes, it is not very important. I am just looking for an argument from
you that I can find valid in this context. I have found two arguments
(that I remember) so far:

- The length of the history list
- A surprising content of the history list

As I have said above I think I have good arguments against them, but
you obviously think different.


>> > You know, we _could_ always use just `minibuffer-history',
>> > and have no such specificity. But that is less useful to users.
>>
>> And why do you say this? ... ;-)
>
> Why would no specificity at all be less useful? Seems obvious. Although the
> `commandp' predicate for `M-x' would filter out non-commands as completion
> candidates, accessing non-commands from the history via `M-p' etc. would mean
> plowing through irrelevant noise.
>
> If you consider all of the possible types of completion candiates (colors,
> buffers, files, commands, variables, ...), I should think the interest in having
> separate, domain-specific history lists would be obvious.


Yes, but why are you arguing against your own arguments. This has
nothing to do with what I have said. (But please let us not waste time
on this part.)


>> Nothing wrong with that of course. I just mean that there is not so
>> very much to care about for old time users if commands invoked from
>> the menus are put in the M-x history.
>
> You mean that adding those commands won't bother old-timers? Dunno.


Everything bothers old timers ... ;-)

No, I really don't think it would. They mostly use menus very seldom.

RE: Menu commands to M-x history?

[Drew Adams]

> > Well, that's exactly the question we're discussing:
> > 1. Whether it is useful to include commands invoked using 
> >    the menu in M-x's history.
> > 2. If so, whether to do that by default or only on demand.
> >
> > You and I say it can be useful (1); some others have seemed 
> > to say no. You say this should be the default behavior (2);
> > I say no. Neither of us is arguing from the point of view of
> > implementers. All arguments so far have been in terms of
> > usefulness to users. We just disagree.
> 
> Then please don't use arguments like "As someone else said, `M-x' is,
> well, for `M-x'-executed commands". By that it looks like you imply
> there is a very special semantics behind it that we should follow.
> (You can of course use such language, but just throw it away when you
> can't defend it.)

No, by that I meant that it makes sense (IMO), for a _user_, to have the history
candidates for M-x be the same commands that s?he in fact has input using `M-x'.

M-x's history contains those commands that M-x executed. That is what I meant by
"`M-x' is for `M-x'-executed commands".

This has nothing to do with implementation (for me). It has to do with how
pertinent the history should be for the particular call to `completing-read'.
That's the question and our disagreement: how pertinent are menu-invoked
commands to M-x completion. You say they are completely pertinent; I say they
are somewhat pertinent; others seem to be saying (or not saying) that they are
not at all pertinent.

> >> Really nothing more than that the argument the M-x history 
> >> is for "M-x executed commands" is useless. It focuses more on the 
> >> programming side than on the user.
> >
> > I don't see why. As a user, I want to see, by default, the 
> > commands I have already entered as input to M-x.
> 
> Maybe. I don't think that is true for all users since I have seen this
> implemented in other places (not in Emacs and I don't remember where
> now).
> 
> Perhaps there should be an option for this then.

Perhaps. Perhaps the 3 levels I mentioned. Even then, should the option control
the default behavior, or should the levels always be available on demand during
completion?

If the former, what should the default value be? If you don't succeed in
convincing others that menu items should be included _by default_, do you want
to require newbies to customize the option or teach them that they can get menu
items too by hitting a key?

> To me it seems very strange to put all commands called from
> call-interactively there so I am not proposing that.

OK. You didn't. I suggested it.
 
> Yes, it is not very important. I am just looking for an argument from
> you that I can find valid in this context. I have found two arguments
> (that I remember) so far:
> 
> - The length of the history list
> - A surprising content of the history list

Do you include in the second of those the close correspondence of M-x input and
M-x history? If so, OK.

> As I have said above I think I have good arguments against them, but
> you obviously think different.

Yes. But I don't think convincing me is your biggest obstacle. I don't see
anyone else even agreeing that menu-invoked commands can be useful in the
history.
 

Re: Menu commands to M-x history?

[Lennart Borgman]

On Mon, Jul 27, 2009 at 11:16 PM, Drew Adams<drew.adams@oracle.com> wrote:

> Yes. But I don't think convincing me is your biggest obstacle. I don't see
> anyone else even agreeing that menu-invoked commands can be useful in the
> history.


No, there is normally not much interest in features for new users. I
guess it is kind of natural since they are not here, but I see no
other way/place to argue for them than here.

The outcomes of such discussions often (but not always) are very small
however - and that is a problem. I wonder how many times we have
suggested to change the menus for example.


Maybe it is a matter of how the people that do discuss agree/disagree.
You and I have for example not come to any useful conclusion here. We
disagree and can't find any way to get further. Our failure to do so
might be the real obstacle.

My feeling is that I can't argue for your solution. It is too
complicated for me. It would miss the goal I was trying to reach.
Maybe your suggestions can be useful for advanced users, I do not
know.


However, drawing some conclusions what I have learned from political
discussions is that one way to make a suggestion collapse is to find
problems with it to early instead of beeing positively creative. It
might be unavoidable here since we both have ideas of how to do
things. But it might also be a certain culture here that makes us go
into some kind of decision before we have actually got a broad picture
of the alternatives. The usual suggestion for finding creative
solutions is to not argue against them to start with, rather trying to
build a creative view.

However it is difficult, maybe because we are communicating this
rather cumbersome way. Direct face to face interaction seems better
for quick grasping of things (if you get into the right mode).

RE: Menu commands to M-x history?

[Drew Adams]

I don't disagree with much of what you wrote. Perhaps it would have been better
for me not to mention my experience and partial support of adding menu items.
That probably clouded the issue as you would like to see it discussed.

Look at the bright side ;-): there wasn't much in the way of solid argument
against the idea of adding menu items for M-x history. My arguments were only
wrt default vs on-demand. 

Re: Menu commands to M-x history?

[Mathias Dahl]

> Matthias said:
>    Quite often I execute the same M-x
>    command over and over again, doing something else in between, and if
>    what I did in between included executing some menu commands I might be
>    annoyed to have to step back some extra steps in order to get at the
>    command I want to run.
>
> Sorry Matthias, forgot to answer, but exactly why is it useful to
> distinguish between commands started from the menu and from M-x
> because of this? I don't believe that you think something like "ah,
> wait, now I will do the next command from the menus to avoid getting
> it into M-x history". Or do you actually do that? ;-)

As I was trying to say earlier, I think I would be annoyed having "my
precious M-x history polluted by "other stuff". I can see that at
times it would be convenient to get at a previously executed "menu
command". It would be a way to not having to reach for the mouse again
(I'm mostly a keyboard guy). However, thinking about how annoyed I
think I would be when I don't want this and comparing that with having
to ask Emacs (via C-h k) what the command behind a menu option is, I
would prefer not to have a thing like this. At least not enabled by
default.

I agree with you that commands executed via the keyboard are not the
same thing (well, there are some *extremely* complicated ones which I
*might* have wanted to know the name if instead, and then
*theoretically* I *might* "be nice" to have them in some sort of
history - yes, I am being very vague now, I know...) as menu executed
commands so the "We cannot add all commands called interactively to
the M-x history"-argument does not bite on me either.

I took the liberty to check how this works in AutoCAD, a program that
also has a sort of command line and where you can freely mix keyboard
with mouse work in very convenient ways (you can start a command from
a menu, the keyboard or a toolbar, and then "continue" the execution
of command, that is to enter arguments, via the mouse or keyboard).
However, it does not mix the command history like you are suggesting
here. Commands initiated from the command line is what is available in
the command line history. Commands initiated via mouse (menu or
toolbar) is not in the command line history. AutoCAD has been around
for many years and I know that many of its users are very keen on
using the keyboard, and if "mixing the histories" had been a useful
thing to have by default, I am sure it would have been by now. Of
course, this is not a real argument, it's more of an example.

I have one small "issue" that is very similar to this and which
unfortunately :) argues in your direction and that is file name
history. I use bookmarks quite much, to files and directories. From
time to time, when doing C-x C-f I try to find a file that I
previously opened using a bookmark, and each time I am a bit annoyed
that I cannot find the file in the find-file history. So I have to do
C-x r b again to jump to my bookmark. Now, I also use the `anything'
package and there I have both bookmarks and file name history and
recentf history etc etc, so most of the time I use that.

By the way, someone mentioned that we could hint the user how he could
run a command he just executed using the menu, like we do when the
user M-x:es a command that has a keybinding. That suggestion I like
very much.

Okay, enough babbling from me.

/Mathias

PS. And no, I don't do the kind of thinking you suggested above :)

RE: Menu commands to M-x history?

[Drew Adams]

I said:

> I don't disagree with much of what you wrote. Perhaps it 
> would have been better for me not to mention my experience
> and partial support of adding menu items. That probably
> clouded the issue as you would like to see it discussed.
> 
> Look at the bright side ;-): there wasn't much in the way of 
> solid argument against the idea of adding menu items for M-x
> history. My arguments were only wrt default vs on-demand. 

FWIW, I've changed my mind about this, based on playing with it a bit.

I agree now with Lennart that it would generally be good to have menu-item
commands added to `extended-command-history' - not just available on demand via
some minibuffer key.

It would also be good to have a user option to control this feature (i.e.,
whether menu-item commands are recorded in the history). I think the use of an
option should accommodate those who disagree with the feature.

For users who rarely use a menu, no behavior change would be visible. Those who
use menus a lot would benefit by (a) learning the corresponding commands and (b)
having recall available, as well as completion (against the history list).

Remember, there is no other means for reinvoking a menu item - no way to refresh
your memory or quickly find again that (possibly deep) menu item that you used
30 minutes ago. This handicaps menu users unnecessarily. And that probably
includes many newbies (and even oldbies exploring parts of Emacs that are new to
them).

Adding commands invoked as menu-items to the command history will act as a
bridge between menu use and minibuffer use. I would even vote for having this
history addition be turned on by default.

Few participated in the previous discussion. WDOT?

Re: Menu commands to M-x history?

[Lennart Borgman]

On Tue, Jul 21, 2009 at 5:31 PM, Stefan Monnier<monnier@iro.umontreal.ca> wrote:
>> Menu commands are all commands that can be started from M-x.  I think
>> they should be added to M-x history.
>
> Most of them should have a key shortcut anyway, which the user has seen
> in the menu entry.

I think that is impossible. And many times it is not useful (as has
been discussed for rgrep/lgrep).


> For those entries which don't have a keyboard shortcut, maybe we could
> (along the lines of what M-x does) output a message like "You can run
> this command with M-x foo-bar-baz".

I do not think that will work. Those messages will very often be
hidden. And you will forget them - especially if you are new to Emac
and have a lot to learn.

I have added a simple recipe for my initial suggestion to nXhtml, see
below. A message is shown (if appropriate) when a command is added to
M-x history. If you want to, just include it in Emacs.

(defun ourcomments-M-x-menu-pre ()
  "Add menu command to M-x history."
  (let ((is-menu-command (equal '(menu-bar)
                                (elt (this-command-keys-vector) 0)))
        (pre-len (length extended-command-history)))
    (when (and is-menu-command
               (not (memq this-command '(ourcomments-M-x-menu-mode))))
      (pushnew (symbol-name this-command) extended-command-history)
      (when (< pre-len (length extended-command-history))
        ;; This message is given pre-command and is therefore likely
        ;; to be overwritten, but that is ok in this case. If the user
        ;; has seen one of these messages s?he knows.
        (message "(Added %s to M-x history so you can run it from
there)" this-command)))))

;;;###autoload
(define-minor-mode ourcomments-M-x-menu-mode
  "Add commands started from Emacs menus to M-x history.
The purpose of this is to make it easier to redo them and easier
to learn how to do them from the command line \(which is often
faster if you know how to do it).

Only commands that are not already in M-x history are added."
  :global t
  (if ourcomments-M-x-menu-mode
      (add-hook 'pre-command-hook 'ourcomments-M-x-menu-pre)
    (remove-hook 'pre-command-hook 'ourcomments-M-x-menu-pre)))

Re: Menu commands to M-x history?

[Stefan Monnier]

> I agree now with Lennart that it would generally be good to have
> menu-item commands added to `extended-command-history' - not just
> available on demand via some minibuffer key.

I don't have any strong opinion on this.  I know it wouldn't bother me.

> It would also be good to have a user option to control this feature
> (i.e., whether menu-item commands are recorded in the history).
> I think the use of an option should accommodate those who disagree
> with the feature.

Disagreed here: this is such a minor issue that it really doesn't
deserve a user option.


        Stefan

Sillyness (was: Menu commands to M-x history?)

[Stefan Monnier]

>> For those entries which don't have a keyboard shortcut, maybe we could
>> (along the lines of what M-x does) output a message like "You can run
>> this command with M-x foo-bar-baz".

> I do not think that will work. Those messages will very often be
> hidden.  And you will forget them - especially if you are new to Emacs
> and have a lot to learn.

Clearly they're more discrete (thus easier to forget or fail to notice),
but they should almost never be hidden.

BTW, on an unrelated note, here is a piece of useless code that some
people who like partial-completion-mode may find funny.  It told me

  You can run `gnus-read-ephemeral-emacs-bug-group' with M-x -r-em RET


-- Stefan


--- src/keyboard.c	2009-07-03 17:07:02 +0000
+++ src/keyboard.c	2009-07-24 18:45:56 +0000
@@ -10528,6 +10322,7 @@
 
 
 \f
+/* FIXME: Move to Elisp.  */
 DEFUN ("execute-extended-command", Fexecute_extended_command, Sexecute_extended_command,
        1, 1, "P",
        doc: /* Read function name, then read its arguments and call it.
@@ -10637,7 +10432,10 @@
   value = Fcommand_execute (function, Qt, Qnil, Qnil);
 
   /* If the command has a key binding, print it now.  */
-  if (!NILP (bindings)
+  if (SYMBOLP (Vsuggest_key_bindings)
+      && !NILP (Ffboundp (Vsuggest_key_bindings)))
+    call2 (Vsuggest_key_bindings, function, bindings);
+  else if (!NILP (bindings)
       && ! (VECTORP (bindings) && EQ (Faref (bindings, make_number (0)),
 				      Qmouse_movement)))
     {


and then


(defun suggest-key-binding-1 (name length)
  (cond
   ((zerop length) (list ""))
   ((equal name "") nil)
   (t
    (nconc (mapcar (lambda (s) (concat (substring name 0 1) s))
                   (suggest-key-binding-1 (substring name 1) (1- length)))
           (when (string-match "\\`\\(-\\)?[^-]*" name)
             (suggest-key-binding-1 (substring name (match-end 0)) length))))))

(defun suggest-key-binding (cmd binding)
  (unless (or binding executing-kbd-macro (not (symbolp cmd))
              (<= (length (symbol-name cmd)) 2))
    ;; There's no binding for CMD.  Let's try and find the shortest
    ;; string to use in M-x.
    (let ((name (symbol-name cmd))
          (candidates '())
          (len 1))
      (while (not binding)
        (unless candidates
          (setq len (1+ len))
          (setq candidates (suggest-key-binding-1 name len)))
        (let ((candidate (pop candidates)))
          (when (equal name
                       (car-safe (completion-try-completion
                                  candidate obarray 'commandp len)))
              (setq binding candidate))))))
  (when (and binding
             (sit-for (if (current-message) 2 0))
             (null unread-command-events))
    (let ((msg (current-message))
          (message-log-max nil))
      (message "You can run the command `%s' with %s"
               cmd (if (stringp binding)
                       (concat "M-x " binding " RET")
                     (key-description binding)))
      (when (and (sit-for 2) msg)
        (message msg)))))

(setq suggest-key-bindings 'suggest-key-binding)