unofficial mirror of emacs-devel@gnu.org 
 help / color / mirror / code / Atom feed
* unhelpful menu keybinding notes
@ 2006-04-17  3:36 Miles Bader
  2006-04-17  7:10 ` Lennart Borgman
  2006-04-17  7:28 ` Eli Zaretskii
  0 siblings, 2 replies; 12+ messages in thread
From: Miles Bader @ 2006-04-17  3:36 UTC (permalink / raw)


In the GTK version of emacs, the keybinding notes for the "Edit > Cut"
and "Edit > Copy" menu entries say "<cut>" and "<copy>" respectively.

Those names don't seem very useful to me, as most keyboards don't have
such keys; also they don't help teach the real Emacs bindings.
Shouldn't those just say "C-w" and "M-w" ?

-Miles
-- 
`...the Soviet Union was sliding in to an economic collapse so comprehensive
 that in the end its factories produced not goods but bads: finished products
 less valuable than the raw materials they were made from.'  [The Economist]

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17  3:36 unhelpful menu keybinding notes Miles Bader
@ 2006-04-17  7:10 ` Lennart Borgman
  2006-04-17  7:28 ` Eli Zaretskii
  1 sibling, 0 replies; 12+ messages in thread
From: Lennart Borgman @ 2006-04-17  7:10 UTC (permalink / raw)
  Cc: emacs-devel

Miles Bader wrote:
> In the GTK version of emacs, the keybinding notes for the "Edit > Cut"
> and "Edit > Copy" menu entries say "<cut>" and "<copy>" respectively.
>
> Those names don't seem very useful to me, as most keyboards don't have
> such keys; also they don't help teach the real Emacs bindings.
> Shouldn't those just say "C-w" and "M-w" ?
>
> -Miles
>   
There is the same problem on w32 (which we discussed long ago).

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17  3:36 unhelpful menu keybinding notes Miles Bader
  2006-04-17  7:10 ` Lennart Borgman
@ 2006-04-17  7:28 ` Eli Zaretskii
  2006-04-17  8:19   ` Lennart Borgman
  1 sibling, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2006-04-17  7:28 UTC (permalink / raw)
  Cc: emacs-devel

> From: Miles Bader <miles.bader@necel.com>
> Date: Mon, 17 Apr 2006 12:36:25 +0900
> 
> In the GTK version of emacs, the keybinding notes for the "Edit > Cut"
> and "Edit > Copy" menu entries say "<cut>" and "<copy>" respectively.
> 
> Those names don't seem very useful to me, as most keyboards don't have
> such keys; also they don't help teach the real Emacs bindings.
> Shouldn't those just say "C-w" and "M-w" ?

This happens to come up periodically; I remember at least 2
discussions in the past.  <cut> and <copy> are Sun keyboard's keys,
and IIRC the problem is we don't have any good way to specify, for a
command that has several keybindings, which one gets mentioned in the
menu.  I think we currently display the last one bound.

Also, please note that, at least by default on GUI displays, these
menu items don't invoke the same functions as C-w and M-w (because
x-win.el turns on menu-bar-enable-clipboard).

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17  7:28 ` Eli Zaretskii
@ 2006-04-17  8:19   ` Lennart Borgman
  2006-04-17  8:41     ` Eli Zaretskii
  0 siblings, 1 reply; 12+ messages in thread
From: Lennart Borgman @ 2006-04-17  8:19 UTC (permalink / raw)
  Cc: emacs-devel, Miles Bader

Eli Zaretskii wrote:
>> From: Miles Bader <miles.bader@necel.com>
>> Date: Mon, 17 Apr 2006 12:36:25 +0900
>>
>> In the GTK version of emacs, the keybinding notes for the "Edit > Cut"
>> and "Edit > Copy" menu entries say "<cut>" and "<copy>" respectively.
>>
>> Those names don't seem very useful to me, as most keyboards don't have
>> such keys; also they don't help teach the real Emacs bindings.
>> Shouldn't those just say "C-w" and "M-w" ?
>>     
>
> This happens to come up periodically; I remember at least 2
> discussions in the past.  <cut> and <copy> are Sun keyboard's keys,
> and IIRC the problem is we don't have any good way to specify, for a
> command that has several keybindings, which one gets mentioned in the
> menu.  I think we currently display the last one bound.
>
> Also, please note that, at least by default on GUI displays, these
> menu items don't invoke the same functions as C-w and M-w (because
> x-win.el turns on menu-bar-enable-clipboard).
>   
Would it help if they invoked the same functions? Could we not fix that?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17  8:19   ` Lennart Borgman
@ 2006-04-17  8:41     ` Eli Zaretskii
  2006-04-17  8:46       ` David Kastrup
  0 siblings, 1 reply; 12+ messages in thread
From: Eli Zaretskii @ 2006-04-17  8:41 UTC (permalink / raw)
  Cc: emacs-devel, miles

> Date: Mon, 17 Apr 2006 10:19:56 +0200
> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
> CC: Miles Bader <miles@gnu.org>,  emacs-devel@gnu.org
> 
> > Also, please note that, at least by default on GUI displays, these
> > menu items don't invoke the same functions as C-w and M-w (because
> > x-win.el turns on menu-bar-enable-clipboard).
> >   
> Would it help if they invoked the same functions? Could we not fix that?

??? They invoke different functions for a reason, please see the
source of the respective functions on menu-bar.el.  In other words,
this is a deliberate feature.  Are you suggesting to turn it off?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17  8:41     ` Eli Zaretskii
@ 2006-04-17  8:46       ` David Kastrup
  2006-04-17 15:50         ` Drew Adams
  2006-04-17 19:11         ` Lennart Borgman
  0 siblings, 2 replies; 12+ messages in thread
From: David Kastrup @ 2006-04-17  8:46 UTC (permalink / raw)
  Cc: Lennart Borgman, miles, emacs-devel

Eli Zaretskii <eliz@gnu.org> writes:

>> Date: Mon, 17 Apr 2006 10:19:56 +0200
>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>> CC: Miles Bader <miles@gnu.org>,  emacs-devel@gnu.org
>> 
>> > Also, please note that, at least by default on GUI displays, these
>> > menu items don't invoke the same functions as C-w and M-w (because
>> > x-win.el turns on menu-bar-enable-clipboard).
>> >   
>> Would it help if they invoked the same functions? Could we not fix that?
>
> ??? They invoke different functions for a reason, please see the
> source of the respective functions on menu-bar.el.  In other words,
> this is a deliberate feature.  Are you suggesting to turn it off?

I guess he'd rather use the same function which discriminates by some
other means between the two uses.

Alternatively, one could put explicit keyboard help strings into the
menus (or have some property for that purpose on the function?).  One
might assume that the people with actual "<cut>", "<paste>", "<copy>"
keys would still try using them without being prompted for them.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: unhelpful menu keybinding notes
  2006-04-17  8:46       ` David Kastrup
@ 2006-04-17 15:50         ` Drew Adams
  2006-04-17 16:29           ` Stefan Monnier
  2006-04-18  1:42           ` Richard Stallman
  2006-04-17 19:11         ` Lennart Borgman
  1 sibling, 2 replies; 12+ messages in thread
From: Drew Adams @ 2006-04-17 15:50 UTC (permalink / raw)


    Alternatively, one could put explicit keyboard help strings into the
    menus (or have some property for that purpose on the function?).  One
    might assume that the people with actual "<cut>", "<paste>", "<copy>"
    keys would still try using them without being prompted for them.

Yes, this is a general problem with `substitute-command-keys', which we have
discussed before. Whenever there is more than one key sequence bound to a
command, the problem surfaces.

No matter what algorithm is used to choose (ASCII, non-ASCII, shortest,
longest, chords, non-chords, whatever), people will want to be able to
specify the binding to use in the result, and there is no way to do that
now. I hope we will address this after the release and find a good solution.

In my own libraries I sometimes hard-code explicit bindings and sometimes
rely upon \\[...]. The advantage of the former is that you can control what
gets communicated; the disadvantage is that that can be incorrect if the
user has changed the bindings.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17 15:50         ` Drew Adams
@ 2006-04-17 16:29           ` Stefan Monnier
  2006-04-17 16:57             ` Drew Adams
  2006-04-18  1:42             ` Richard Stallman
  2006-04-18  1:42           ` Richard Stallman
  1 sibling, 2 replies; 12+ messages in thread
From: Stefan Monnier @ 2006-04-17 16:29 UTC (permalink / raw)
  Cc: emacs-devel

>     Alternatively, one could put explicit keyboard help strings into the
>     menus (or have some property for that purpose on the function?).  One
>     might assume that the people with actual "<cut>", "<paste>", "<copy>"
>     keys would still try using them without being prompted for them.

> Yes, this is a general problem with `substitute-command-keys', which we have
> discussed before. Whenever there is more than one key sequence bound to a
> command, the problem surfaces.

> No matter what algorithm is used to choose (ASCII, non-ASCII, shortest,
> longest, chords, non-chords, whatever), people will want to be able to
> specify the binding to use in the result, and there is no way to do that
> now. I hope we will address this after the release and find a good solution.

> In my own libraries I sometimes hard-code explicit bindings and sometimes
> rely upon \\[...]. The advantage of the former is that you can control what
> gets communicated; the disadvantage is that that can be incorrect if the
> user has changed the bindings.

In some pars of Emacs we use another trick: make and use an alias, like
`advertised-undo'.  I think this is a bad solution because C-h f undo RET
then lists all bindings except for the "advertised" one C-x u.

Maybe a better solution is to add a `advertised-binding' property to the
function's symbol:

  (put 'undo 'advertised-binding [?\C-x ?u])

which could be used similarly to the :key-sequence property in menus
(i.e. it's used if the key seuqnece is indeed bound to the specified
command).


        Stefan

^ permalink raw reply	[flat|nested] 12+ messages in thread

* RE: unhelpful menu keybinding notes
  2006-04-17 16:29           ` Stefan Monnier
@ 2006-04-17 16:57             ` Drew Adams
  2006-04-18  1:42             ` Richard Stallman
  1 sibling, 0 replies; 12+ messages in thread
From: Drew Adams @ 2006-04-17 16:57 UTC (permalink / raw)


    In some parts of Emacs we use another trick: make and use an alias,
    like `advertised-undo'.  I think this is a bad solution because
    C-h f undo RET then lists all bindings except for the "advertised"
    one C-x u.

I agree.

    Maybe a better solution is to add an `advertised-binding' property
    to the function's symbol:

      (put 'undo 'advertised-binding [?\C-x ?u])

    which could be used similarly to the :key-sequence property in menus
    (i.e. it's used if the key seuqnece is indeed bound to the specified
    command).

Some other ideas were kicked around previously. I don't recall them, but
it's worth discussing all of them sometime after the release. I like your
idea, but:

- What to do if the key sequence is not bound to the specified command and
there are several bindings? Which to pick?

- It might increase maintenance (but so might other solutions): Changing the
bindings in the library would also mean updating this property.

One question to consider is whether we want to allow control over what gets
communicated 1) at the point of use of `substitute-command-keys' or a doc
string or 2) at some earlier, more general point - or both.

For #2, a library might (somehow, perhaps using more or less the mechanism
you proposed) specify a list of bindings, in preference order, that would
apply to all uses of `substitute-command-keys' and all doc strings.

For #1, we might devise some way to indicate the preferred binding to use at
the point of call. For example (just thinking out loud; not a proposal),
"\\[((kbd "C-x") (kbd <f1> SPC) (kbd "C-M-<down>"))...]" might stipulate
using binding (kbd "C-x") if applicable, else (kbd <f1> SPC) if applicable,
else (kbd "C-M-<down>"). There might also be some way to specify a default
for the case where none were applicable.

Both general presciption (#2) and spec at point of use (#1) could of course
be used together, the latter (#1) taking precedence.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17  8:46       ` David Kastrup
  2006-04-17 15:50         ` Drew Adams
@ 2006-04-17 19:11         ` Lennart Borgman
  1 sibling, 0 replies; 12+ messages in thread
From: Lennart Borgman @ 2006-04-17 19:11 UTC (permalink / raw)
  Cc: Eli Zaretskii, emacs-devel, miles

David Kastrup wrote:
> Eli Zaretskii <eliz@gnu.org> writes:
>
>   
>>> Date: Mon, 17 Apr 2006 10:19:56 +0200
>>> From: Lennart Borgman <lennart.borgman.073@student.lu.se>
>>> CC: Miles Bader <miles@gnu.org>,  emacs-devel@gnu.org
>>>
>>>       
>>>> Also, please note that, at least by default on GUI displays, these
>>>> menu items don't invoke the same functions as C-w and M-w (because
>>>> x-win.el turns on menu-bar-enable-clipboard).
>>>>   
>>>>         
>>> Would it help if they invoked the same functions? Could we not fix that?
>>>       
>> ??? They invoke different functions for a reason, please see the
>> source of the respective functions on menu-bar.el.  In other words,
>> this is a deliberate feature.  Are you suggesting to turn it off?
>>     
>
> I guess he'd rather use the same function which discriminates by some
> other means between the two uses.
>   
Yes, thanks, that is of course what I suggested. Are there any 
advantages not to do it the way I suggested?

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17 15:50         ` Drew Adams
  2006-04-17 16:29           ` Stefan Monnier
@ 2006-04-18  1:42           ` Richard Stallman
  1 sibling, 0 replies; 12+ messages in thread
From: Richard Stallman @ 2006-04-18  1:42 UTC (permalink / raw)
  Cc: emacs-devel

    Yes, this is a general problem with `substitute-command-keys', which we have
    discussed before. Whenever there is more than one key sequence bound to a
    command, the problem surfaces.

The usual solution is to create an alias, such as advertised-undo.

^ permalink raw reply	[flat|nested] 12+ messages in thread

* Re: unhelpful menu keybinding notes
  2006-04-17 16:29           ` Stefan Monnier
  2006-04-17 16:57             ` Drew Adams
@ 2006-04-18  1:42             ` Richard Stallman
  1 sibling, 0 replies; 12+ messages in thread
From: Richard Stallman @ 2006-04-18  1:42 UTC (permalink / raw)
  Cc: drew.adams, emacs-devel

    Maybe a better solution is to add a `advertised-binding' property to the
    function's symbol:

      (put 'undo 'advertised-binding [?\C-x ?u])

    which could be used similarly to the :key-sequence property in menus
    (i.e. it's used if the key seuqnece is indeed bound to the specified
    command).

It is a good idea, but let's not consider it until after the release.

^ permalink raw reply	[flat|nested] 12+ messages in thread

end of thread, other threads:[~2006-04-18  1:42 UTC | newest]

Thread overview: 12+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2006-04-17  3:36 unhelpful menu keybinding notes Miles Bader
2006-04-17  7:10 ` Lennart Borgman
2006-04-17  7:28 ` Eli Zaretskii
2006-04-17  8:19   ` Lennart Borgman
2006-04-17  8:41     ` Eli Zaretskii
2006-04-17  8:46       ` David Kastrup
2006-04-17 15:50         ` Drew Adams
2006-04-17 16:29           ` Stefan Monnier
2006-04-17 16:57             ` Drew Adams
2006-04-18  1:42             ` Richard Stallman
2006-04-18  1:42           ` Richard Stallman
2006-04-17 19:11         ` Lennart Borgman

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