all messages for Emacs-related lists mirrored at yhetil.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 13:26:59 -0700	[thread overview]
Message-ID: <F3A6C4A69CCE4648AD6A33AD0D8EC454@us.oracle.com> (raw)
In-Reply-To: <e01d8a50907271222q605e580ep8fc0c51ca9ba2d59@mail.gmail.com>

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





  reply	other threads:[~2009-07-27 20:26 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
2009-07-27 19:22                       ` Lennart Borgman
2009-07-27 20:26                         ` Drew Adams [this message]
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

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

  git send-email \
    --in-reply-to=F3A6C4A69CCE4648AD6A33AD0D8EC454@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 external index

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

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.