unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: "Drew Adams" <drew.adams@oracle.com>
To: "'Lennart Borgman'" <lennart.borgman@gmail.com>
Cc: emacs-devel@gnu.org, rms@gnu.org,
	'Mathias Dahl' <mathias.dahl@gmail.com>
Subject: RE: Menu commands to M-x history?
Date: Mon, 27 Jul 2009 11:57:08 -0700	[thread overview]
Message-ID: <CD076EC8E52E49E68AE9EEA5DFD2B6FE@us.oracle.com> (raw)
In-Reply-To: <e01d8a50907270939g1b42636ag877b68b05a58a608@mail.gmail.com>

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





  reply	other threads:[~2009-07-27 18:57 UTC|newest]

Thread overview: 27+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2009-07-20 23:05 Menu commands to M-x history? Lennart Borgman
2009-07-21  3:44 ` Bill Wohler
2009-07-22  1:43   ` Richard Stallman
2009-07-22  2:03     ` Drew Adams
2009-07-22  2:18     ` Lennart Borgman
2009-07-22  4:15     ` Bill Wohler
2009-07-22 18:34       ` Mathias Dahl
2009-07-27  1:47         ` Drew Adams
2009-07-27  9:51           ` Lennart Borgman
2009-07-27 15:48             ` Drew Adams
2009-07-27 15:59               ` Lennart Borgman
2009-07-27 16:21                 ` Drew Adams
2009-07-27 16:39                   ` Lennart Borgman
2009-07-27 18:57                     ` Drew Adams [this message]
2009-07-27 19:22                       ` Lennart Borgman
2009-07-27 20:26                         ` Drew Adams
2009-07-27 20:53                           ` Lennart Borgman
2009-07-27 21:16                             ` Drew Adams
2009-07-27 21:34                               ` Lennart Borgman
2009-07-27 21:47                                 ` Drew Adams
2009-08-01 20:20                                   ` Drew Adams
2009-08-04 17:23                                     ` Stefan Monnier
2009-07-27 22:00                 ` Mathias Dahl
2009-07-21 15:31 ` Stefan Monnier
2009-07-21 17:43   ` Lennart Borgman
2009-08-03 21:51   ` Lennart Borgman
2009-08-04 17:31     ` Sillyness (was: Menu commands to M-x history?) Stefan Monnier

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.gnu.org/software/emacs/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CD076EC8E52E49E68AE9EEA5DFD2B6FE@us.oracle.com \
    --to=drew.adams@oracle.com \
    --cc=emacs-devel@gnu.org \
    --cc=lennart.borgman@gmail.com \
    --cc=mathias.dahl@gmail.com \
    --cc=rms@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).