Semi-unhelpful error message given when trying to (provide 'CUA-mode)

Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Alan Mackenzie]

Afternoon, Emacs!

In Emacs-22.0.50, if you try to load a legacy cua-mode.el (or whatever),
an eval-after-load form tells you to set the CUA option via the menu.
This is useful only to users who have a mouse and like using it.

For the benefit of other users, M-x cua-mode should also be mentioned.


 
2006-05-20  Alan Mackenzie  <acm@acm.acm>

	* emulation/cua-base.el: Mention "M-x cua-mode" in the error
	message provoked by trying to (provide 'CUA-mode).


Index: cua-base.el
===================================================================
RCS file: /cvsroot/emacs/emacs/lisp/emulation/cua-base.el,v
retrieving revision 1.70
diff -c -r1.70 cua-base.el
*** cua-base.el	9 Apr 2006 23:04:07 -0000	1.70
--- cua-base.el	20 May 2006 12:56:17 -0000
***************
*** 1499,1505 ****
  ;;;###autoload (eval-after-load 'CUA-mode
  ;;;###autoload  '(error (concat "\n\n"
  ;;;###autoload  "CUA-mode is now part of the standard GNU Emacs distribution,\n"
! ;;;###autoload  "so you may now enable and customize CUA via the Options menu.\n\n"
  ;;;###autoload  "You have loaded an older version of CUA-mode which does\n"
  ;;;###autoload  "not work correctly with this version of GNU Emacs.\n\n"
  ;;;###autoload  (if user-init-file (concat
--- 1499,1506 ----
  ;;;###autoload (eval-after-load 'CUA-mode
  ;;;###autoload  '(error (concat "\n\n"
  ;;;###autoload  "CUA-mode is now part of the standard GNU Emacs distribution,\n"
! ;;;###autoload  "so you may now enable and customize CUA via the Options menu\n"
! ;;;###autoload  "or toggle it with M-x cua-mode.\n\n"
  ;;;###autoload  "You have loaded an older version of CUA-mode which does\n"
  ;;;###autoload  "not work correctly with this version of GNU Emacs.\n\n"
  ;;;###autoload  (if user-init-file (concat



-- 
Alan.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> Afternoon, Emacs!
>
> In Emacs-22.0.50, if you try to load a legacy cua-mode.el (or whatever),
> an eval-after-load form tells you to set the CUA option via the menu.
> This is useful only to users who have a mouse and like using it.

F10 exists, and the menu bar is displayed by default.  So the menu is
clearly intended to be used by tty users as well.

> For the benefit of other users, M-x cua-mode should also be
> mentioned.

I don't think this should be necessary.  If the possibility of using
the menu is not apparent enough, we need to think about how to change
that, not how to work around it.

Maybe the text menubar should display at its furthest right (if there
is still room, which should be the case in default modes) <f10> (if
that binding is active at the point of time)?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Alan Mackenzie]

Afternoon, David!

On Sat, 20 May 2006, David Kastrup wrote:

>Alan Mackenzie <acm@muc.de> writes:

>> In Emacs-22.0.50, if you try to load a legacy cua-mode.el (or
>> whatever), an eval-after-load form tells you to set the CUA option via
>> the menu.  This is useful only to users who have a mouse and like
>> using it.

>F10 exists, and the menu bar is displayed by default.  So the menu is
>clearly intended to be used by tty users as well.

The menu bar is stupidly displayed, yes, but there's no way to activate
its items.  It's just a waste of space.  I didn't actually know about the
F10 binding, though I do know M-`.

>> For the benefit of other users, M-x cua-mode should also be
>> mentioned.

>I don't think this should be necessary.  If the possibility of using
>the menu is not apparent enough, we need to think about how to change
>that, not how to work around it.

I would resent being forced to use a menu; not having to use menus is a
big attraction of Emacs for me.  I know I'm not alone in this, even if
I'm not in a majority.

>Maybe the text menubar should display at its furthest right (if there
>is still room, which should be the case in default modes) <f10> (if
>that binding is active at the point of time)?

Given that there isn't a working mouse in a Linux tty, it would be better
not to display this space waster of a menu at all.  (Personally, I
disable it in my site-start.el.)

>David Kastrup

-- 
Alan.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Alan Mackenzie <acm@muc.de> writes:

> On Sat, 20 May 2006, David Kastrup wrote:
>
>>Alan Mackenzie <acm@muc.de> writes:
>
>>> In Emacs-22.0.50, if you try to load a legacy cua-mode.el (or
>>> whatever), an eval-after-load form tells you to set the CUA option via
>>> the menu.  This is useful only to users who have a mouse and like
>>> using it.
>
>>F10 exists, and the menu bar is displayed by default.  So the menu is
>>clearly intended to be used by tty users as well.
>
> The menu bar is stupidly displayed, yes, but there's no way to
> activate its items.

F10 activates them.

> It's just a waste of space.  I didn't actually know about the F10
> binding, though I do know M-`.

So where is the problem?

>>> For the benefit of other users, M-x cua-mode should also be
>>> mentioned.
>
>>I don't think this should be necessary.  If the possibility of using
>>the menu is not apparent enough, we need to think about how to
>>change that, not how to work around it.
>
> I would resent being forced to use a menu; not having to use menus
> is a big attraction of Emacs for me.  I know I'm not alone in this,
> even if I'm not in a majority.

Irrelevant.  We don't recommend half a dozen different ways to do
things if there is one way that works.  Customizing cua-mode via the
menu works, and you can save this setting.  Calling M-x cua-mode RET,
in contrast, fails to have a permanent effect.  It is comparatively
useless.

>>Maybe the text menubar should display at its furthest right (if
>>there is still room, which should be the case in default modes)
>><f10> (if that binding is active at the point of time)?
>
> Given that there isn't a working mouse in a Linux tty, it would be
> better not to display this space waster of a menu at all.

What has the mouse to do with the menu on a tty?  Anyway, there is
t-mouse.el even on text terminals.  No idea whether it will do
something useful with the menu bar, though.

> (Personally, I disable it in my site-start.el.)

Well, you can still press F10.  It is ok if a user disables the menu
bar once he has read the deal about it.

Personally, I think we should have drop-down menus in ttys in general
instead of the tmm-menubar.  I seem to remember that this is already
the case with the MSDOS port.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Werner LEMBERG]

> > The menu bar is stupidly displayed, yes, but there's no way to
> > activate its items.
>
> F10 activates them.

Hmm.  Is there any reason why F10 under X Windows doesn't activate the
visible toolbar so that I can move around with the cursor keys?
Binding F10 to `tmm-menubar' is probably not that helpful...


    Werner

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Werner LEMBERG <wl@gnu.org> writes:

>> > The menu bar is stupidly displayed, yes, but there's no way to
>> > activate its items.
>>
>> F10 activates them.
>
> Hmm.  Is there any reason why F10 under X Windows doesn't activate
> the visible toolbar so that I can move around with the cursor keys?
> Binding F10 to `tmm-menubar' is probably not that helpful...

Maybe to accessibility dependent people?  On the other hand, walking
toolkit menus should be pretty standard for accessibility tools.

In my opinion, it would make sense to offer this kind of drop-down
menu traversal both in text mode as well as in the toolkits.  I don't
see that tmm-menubar has advantages that make it worth making it the
default.

I'd vote to add this to todo.texi.  This is one part of CUA where the
cost of accommodating it does not appear to have a negative impact
elsewhere within Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Kim F. Storm]

Alan Mackenzie <acm@muc.de> writes:

> In Emacs-22.0.50, if you try to load a legacy cua-mode.el (or whatever),
> an eval-after-load form tells you to set the CUA option via the menu.
> This is useful only to users who have a mouse and like using it.
>
> For the benefit of other users, M-x cua-mode should also be mentioned.
>

M-x cua-mode only enables CUA for the current session, so I think this is better:

CUA-mode is now part of the standard GNU Emacs distribution, so you may
now enable it by customizing `cua-mode' or via the Options menu.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Alan Mackenzie]

Good morning, Kim!

On Sat, 20 May 2006, Kim F. Storm wrote:

>Alan Mackenzie <acm@muc.de> writes:

>> In Emacs-22.0.50, if you try to load a legacy cua-mode.el (or whatever),
>> an eval-after-load form tells you to set the CUA option via the menu.
>> This is useful only to users who have a mouse and like using it.
>>
>> For the benefit of other users, M-x cua-mode should also be mentioned.

>M-x cua-mode only enables CUA for the current session, so I think this
>is better:

People will want to enable CUA only for the current session, just to try
it out.

>CUA-mode is now part of the standard GNU Emacs distribution, so you may
>now enable it by customizing `cua-mode' or via the Options menu.

The canonical way of giving commands in Emacs is with M-x foo.  Why
should this one be different?  If your aim were to make it as difficult
as possible for a GUI hating user to find out that the command is called
`cua-mode', you could hardly do better than what you suggest.  Remember,
C-h c and friends don't work in menus, unless you're willing to click the
mouse (See my other bug report from yesterday).  Why the obfuscation?

I am myself a GUI hating user, and I detest being forced to click menu
items with mouse buttons, and I'm less than fond of the M-` style menus
and the baroque customization stuff.  The kind of error message which
says "... via the options menu" without giving me the option of doing it
"properly" gets me screaming with rage.  What am I meant to write into my
.emacs?  What on earth am I supposed to give to C-h f?  Have I really got
to go through the hassle of C-h i?

Please put the name of the command `cua-mode' into this error message
somehow.  I think my suggested patch is a reasonable way of doing this.

>Kim F. Storm

-- 
Alan.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Kim F. Storm]

Alan Mackenzie <acm@muc.de> writes:

> Good morning, Kim!
>
> On Sat, 20 May 2006, Kim F. Storm wrote:
>
>>Alan Mackenzie <acm@muc.de> writes:
>
>>> In Emacs-22.0.50, if you try to load a legacy cua-mode.el (or whatever),
>>> an eval-after-load form tells you to set the CUA option via the menu.
>>> This is useful only to users who have a mouse and like using it.
>>>
>>> For the benefit of other users, M-x cua-mode should also be mentioned.
>
>>M-x cua-mode only enables CUA for the current session, so I think this
>>is better:
>
> People will want to enable CUA only for the current session, just to try
> it out.

The reason for the error message in cua-base.el is to assist existing
users of CUA-mode who upgrades from 21.4 to 22.1, and experience that
the CUA bindings no longer works -- or works in peculiar ways...

Since those users already have CUA-mode permanently enabled in their
emacs, I think it is the right thing to tell them how to enable the
new cua-mode -- which is to customize cua-mode or use the Options menu.


You never see the error message if you don't already use CUA-mode,
so that's the wrong place to tell people how to try it out...

> The canonical way of giving commands in Emacs is with M-x foo.  Why
> should this one be different?  If your aim were to make it as difficult
> as possible for a GUI hating user to find out that the command is called
> `cua-mode', you could hardly do better than what you suggest.  Remember,
> C-h c and friends don't work in menus, unless you're willing to click the
> mouse (See my other bug report from yesterday).  Why the obfuscation?

M-x apropos RET cua RET tells about "cua-mode" and "cua-selection-mode".

That's the canonical way to find out that whe command is called...


>                                       The kind of error message which
> says "... via the options menu" without giving me the option of doing it
> "properly" gets me screaming with rage.  What am I meant to write into my
> .emacs?  

You still only get the hint if you already have CUA-mode in .emacs.

>          What on earth am I supposed to give to C-h f?  Have I really got
> to go through the hassle of C-h i?

C-h a cua RET doesn't seem a lot of hassle to me...
It tells you about cua-mode, so C-h f cua-mode RET is "no secret".

> Please put the name of the command `cua-mode' into this error message
> somehow.  I think my suggested patch is a reasonable way of doing this.

Sorry, but I think the current (updated) text is reasonable.

More experienced users like yourself, is capable of finding the necessary
command temselves.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    > In Emacs-22.0.50, if you try to load a legacy cua-mode.el (or whatever),
    > an eval-after-load form tells you to set the CUA option via the menu.
    > This is useful only to users who have a mouse and like using it.

    F10 exists, and the menu bar is displayed by default.  So the menu is
    clearly intended to be used by tty users as well.

I agree with ACM here.  Menus do work on the terminal, but they are
not convenient on the terminal, and hard-core Emacs users would
probably prefer M-x commands to menu items on any kind of display.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

David Kastrup skrev:
> Werner LEMBERG <wl@gnu.org> writes:
> 
>>>> The menu bar is stupidly displayed, yes, but there's no way to
>>>> activate its items.
>>> F10 activates them.
>> Hmm.  Is there any reason why F10 under X Windows doesn't activate
>> the visible toolbar so that I can move around with the cursor keys?
>> Binding F10 to `tmm-menubar' is probably not that helpful...
> 
> Maybe to accessibility dependent people?  On the other hand, walking
> toolkit menus should be pretty standard for accessibility tools.
> 
> In my opinion, it would make sense to offer this kind of drop-down
> menu traversal both in text mode as well as in the toolkits.  I don't
> see that tmm-menubar has advantages that make it worth making it the
> default.
> 
> I'd vote to add this to todo.texi.  This is one part of CUA where the
> cost of accommodating it does not appear to have a negative impact
> elsewhere within Emacs.
> 

I have a patch for the X11 versions of Emacs that activates the menubar when 
F10 is pressed.  I think that is very common, I have not seen any application 
that activates the toolbar on F10.

	Jan D..

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> David Kastrup skrev:
>> Werner LEMBERG <wl@gnu.org> writes:
>>
>>>>> The menu bar is stupidly displayed, yes, but there's no way to
>>>>> activate its items.
>>>> F10 activates them.
>>> Hmm.  Is there any reason why F10 under X Windows doesn't activate
>>> the visible toolbar so that I can move around with the cursor keys?
>>> Binding F10 to `tmm-menubar' is probably not that helpful...
>>
>> Maybe to accessibility dependent people?  On the other hand, walking
>> toolkit menus should be pretty standard for accessibility tools.
>>
>> In my opinion, it would make sense to offer this kind of drop-down
>> menu traversal both in text mode as well as in the toolkits.  I don't
>> see that tmm-menubar has advantages that make it worth making it the
>> default.
>>
>> I'd vote to add this to todo.texi.  This is one part of CUA where the
>> cost of accommodating it does not appear to have a negative impact
>> elsewhere within Emacs.
>>
>
> I have a patch for the X11 versions of Emacs that activates the
> menubar when F10 is pressed.  I think that is very common, I have not
> seen any application that activates the toolbar on F10.

I am trying to figure out what you _intend_ to be saying.  #1 is that
you mean just what you wrote, in which case I can't figure out why you
are bringing the toolbar into play.  #2 would be that you mean "I
_don't_ think that is very common, I have not seen any application
that activates the _menubar_ on F10".  This may be, but we can't
easily use ALT here.  But if people have a way to traverse the menus
by keyboard (in both X11 and tty), this goes a long way towards
accommodating accustomed keyboard/GUI interaction, even though the
entry is not completely what they are used to.  And there might be the
possibility to get something closer to ALT-activation under some
circumstances, in a similar way that CUA-mode gets closer to utilizing
C-x and C-c.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Stefan Monnier]

> I have a patch for the X11 versions of Emacs that activates the menubar
> when F10 is pressed.

That'd be great,


        Stefan

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> David Kastrup skrev:
>>> Werner LEMBERG <wl@gnu.org> writes:
>>>
>>>>>> The menu bar is stupidly displayed, yes, but there's no way to
>>>>>> activate its items.
>>>>> F10 activates them.
>>>> Hmm.  Is there any reason why F10 under X Windows doesn't activate
>>>> the visible toolbar so that I can move around with the cursor keys?
>>>> Binding F10 to `tmm-menubar' is probably not that helpful...
>>> Maybe to accessibility dependent people?  On the other hand, walking
>>> toolkit menus should be pretty standard for accessibility tools.
>>>
>>> In my opinion, it would make sense to offer this kind of drop-down
>>> menu traversal both in text mode as well as in the toolkits.  I don't
>>> see that tmm-menubar has advantages that make it worth making it the
>>> default.
>>>
>>> I'd vote to add this to todo.texi.  This is one part of CUA where the
>>> cost of accommodating it does not appear to have a negative impact
>>> elsewhere within Emacs.
>>>
>> I have a patch for the X11 versions of Emacs that activates the
>> menubar when F10 is pressed.  I think that is very common, I have not
>> seen any application that activates the toolbar on F10.
> 
> I am trying to figure out what you _intend_ to be saying.  #1 is that
> you mean just what you wrote, in which case I can't figure out why you
> are bringing the toolbar into play.

Because it was mentioned above: "Is there any reason why F10 under X Windows 
doesn't activate the visible toolbar ..."  I don't know who wrote that.

>  #2 would be that you mean "I
> _don't_ think that is very common, I have not seen any application
> that activates the _menubar_ on F10".  This may be, but we can't
> easily use ALT here.  But if people have a way to traverse the menus
> by keyboard (in both X11 and tty), this goes a long way towards
> accommodating accustomed keyboard/GUI interaction, even though the
> entry is not completely what they are used to.  And there might be the
> possibility to get something closer to ALT-activation under some
> circumstances, in a similar way that CUA-mode gets closer to utilizing
> C-x and C-c.
> 

F10 activation of menus is actually Gnome/Gtk+ standard.  In fact, there is 
code in Emacs to turn it off for Gtk+-menus, because it interacts badly with 
tmm.  ALT activation is a bit trickier to do that just F10.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> David Kastrup skrev:
>
>> that activates the _menubar_ on F10".  This may be, but we can't
>> easily use ALT here.  But if people have a way to traverse the
>> menus by keyboard (in both X11 and tty), this goes a long way
>> towards accommodating accustomed keyboard/GUI interaction, even
>> though the entry is not completely what they are used to.  And
>> there might be the possibility to get something closer to
>> ALT-activation under some circumstances, in a similar way that
>> CUA-mode gets closer to utilizing C-x and C-c.
>>
>
> F10 activation of menus is actually Gnome/Gtk+ standard.

Then I think it would be a good idea to have that.  And add the desire
to have that in ttys as well to the Todo file.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
> Jan Djärv <jan.h.d@swipnet.se> writes:
>
>   
>> David Kastrup skrev:
>>
>>     
>>> that activates the _menubar_ on F10".  This may be, but we can't
>>> easily use ALT here.  But if people have a way to traverse the
>>> menus by keyboard (in both X11 and tty), this goes a long way
>>> towards accommodating accustomed keyboard/GUI interaction, even
>>> though the entry is not completely what they are used to.  And
>>> there might be the possibility to get something closer to
>>> ALT-activation under some circumstances, in a similar way that
>>> CUA-mode gets closer to utilizing C-x and C-c.
>>>
>>>       
>> F10 activation of menus is actually Gnome/Gtk+ standard.
>>     
>
> Then I think it would be a good idea to have that.  And add the desire
> to have that in ttys as well to the Todo file.
>   
As far as I know F10 also always works on w32 for activating the menus. 
However the most usual way on w32 is to use the ALT key. Is that the 
usual way in Gnome/Gtk+ too?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    I have a patch for the X11 versions of Emacs that activates the menubar when 
    F10 is pressed.

Once you do that, how do you select a menu item from the menu?
Is there a way to do that with the keyboard?  Or must the user switch
to the mouse for that?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Eli Zaretskii]

> From: Richard Stallman <rms@gnu.org>
> Date: Sun, 21 May 2006 22:38:37 -0400
> Cc: acm@muc.de, emacs-devel@gnu.org
> 
>     I have a patch for the X11 versions of Emacs that activates the menubar when 
>     F10 is pressed.
> 
> Once you do that, how do you select a menu item from the menu?

With keyboard keys, such as the arrow keys and RET.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

Richard Stallman skrev:
>     I have a patch for the X11 versions of Emacs that activates the menubar when 
>     F10 is pressed.
> 
> Once you do that, how do you select a menu item from the menu?
> Is there a way to do that with the keyboard?  Or must the user switch
> to the mouse for that?

You use arrow keys to navigate the menu and enter/return to select an item. 
What would be nice is the ability to type the keyboard command shown in the 
menu (for example C-x C-s for "Save file") when navigating the menu with the 
arrow keys.  This does not seem that easy to do though.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

>>>>       
>>> F10 activation of menus is actually Gnome/Gtk+ standard.
>>>     
>>
>> Then I think it would be a good idea to have that.  And add the desire
>> to have that in ttys as well to the Todo file.
>>   
> As far as I know F10 also always works on w32 for activating the menus. 
> However the most usual way on w32 is to use the ALT key. Is that the 
> usual way in Gnome/Gtk+ too?

Most usual depends on what the user do, but keyboard shortcuts for menus, 
using ALT + some key, are available if the menus are set up like that by the 
program.  Emacs does not.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Miles Bader]

Alan Mackenzie <acm@muc.de> writes:
>>F10 exists, and the menu bar is displayed by default.  So the menu is
>>clearly intended to be used by tty users as well.
>
> The menu bar is stupidly displayed, yes, but there's no way to activate
> its items.  It's just a waste of space.  I didn't actually know about the
> F10 binding, though I do know M-`.

The tty "menus" invoked by F10 on a tty are so clunky and annoying to
use that I think most users will not want to use them.

Morever, I think in general we want to gently encourage people to become
familiar with "Emacsy" ways to do things.

I think Alan's change is a good one.

-Miles
-- 
`Suppose Korea goes to the World Cup final against Japan and wins,' Moon said.
`All the past could be forgiven.'   [NYT]

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Miles Bader <miles.bader@necel.com> writes:

> Alan Mackenzie <acm@muc.de> writes:
>>>F10 exists, and the menu bar is displayed by default.  So the menu is
>>>clearly intended to be used by tty users as well.
>>
>> The menu bar is stupidly displayed, yes, but there's no way to activate
>> its items.  It's just a waste of space.  I didn't actually know about the
>> F10 binding, though I do know M-`.
>
> The tty "menus" invoked by F10 on a tty are so clunky and annoying to
> use that I think most users will not want to use them.
>
> Morever, I think in general we want to gently encourage people to become
> familiar with "Emacsy" ways to do things.

The "Emacsy way" to enable cua-mode permanently is to either use the
menu where you can _save_ the setting, or to use customize-variable on
cua-mode.

> I think Alan's change is a good one.

Alan's suggestion to the user does not enable cua-mode permanently.
It is useless.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

Jan Djärv wrote:
>> As far as I know F10 also always works on w32 for activating the 
>> menus. However the most usual way on w32 is to use the ALT key. Is 
>> that the usual way in Gnome/Gtk+ too?
>
> Most usual depends on what the user do, but keyboard shortcuts for 
> menus, using ALT + some key, are available if the menus are set up 
> like that by the program.  Emacs does not.

What is missing in Emacs here? I know from what you told me before that 
Emacs does not setup accelerator keys for the menus (which at least on 
w32 are underlined characters). However on w32 this is not needed to 
activate the menus with ALT. It suffices to just press ALT. (Usually 
once but sometimes in some apps twice, which I believe is due to 
somewhat bad handling of accessibility in those programs.)

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

Lennart Borgman skrev:
> Jan Djärv wrote:
>>> As far as I know F10 also always works on w32 for activating the 
>>> menus. However the most usual way on w32 is to use the ALT key. Is 
>>> that the usual way in Gnome/Gtk+ too?
>>
>> Most usual depends on what the user do, but keyboard shortcuts for 
>> menus, using ALT + some key, are available if the menus are set up 
>> like that by the program.  Emacs does not.
> 
> What is missing in Emacs here? I know from what you told me before that 
> Emacs does not setup accelerator keys for the menus (which at least on 
> w32 are underlined characters). However on w32 this is not needed to 
> activate the menus with ALT. It suffices to just press ALT. (Usually 
> once but sometimes in some apps twice, which I believe is due to 
> somewhat bad handling of accessibility in those programs.)

Oh, you men just pressing ALT and no additional key?  That is not used in 
Gnome/Gtk+.  Or any other toolkit or OS I know of either.  Must be w32-specific.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

Jan Djärv wrote:
>
>
> Lennart Borgman skrev:
>> Jan Djärv wrote:
>>>> As far as I know F10 also always works on w32 for activating the 
>>>> menus. However the most usual way on w32 is to use the ALT key. Is 
>>>> that the usual way in Gnome/Gtk+ too?
>>>
>>> Most usual depends on what the user do, but keyboard shortcuts for 
>>> menus, using ALT + some key, are available if the menus are set up 
>>> like that by the program.  Emacs does not.
>>
>> What is missing in Emacs here? I know from what you told me before 
>> that Emacs does not setup accelerator keys for the menus (which at 
>> least on w32 are underlined characters). However on w32 this is not 
>> needed to activate the menus with ALT. It suffices to just press ALT. 
>> (Usually once but sometimes in some apps twice, which I believe is 
>> due to somewhat bad handling of accessibility in those programs.)
>
> Oh, you men just pressing ALT and no additional key?  That is not used 
> in Gnome/Gtk+.  Or any other toolkit or OS I know of either.  Must be 
> w32-specific.
Yes, I mean just pressing ALT and then using the arrow keys to navigate 
in the menus.

Thanks, then I understand a little bit better why my cries for reserving 
the ALT key for the menus on w32 have fallen unheard here. However on 
w32 that is very important. Too bad those things are not cross-OS. Does 
anyone knows if there is something in the accessibility guidelines that 
says something about this?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Jan Djärv wrote:
>>
>>
>> Lennart Borgman skrev:
>>> Jan Djärv wrote:
>>>>> As far as I know F10 also always works on w32 for activating the
>>>>> menus. However the most usual way on w32 is to use the ALT
>>>>> key. Is that the usual way in Gnome/Gtk+ too?
>>>>
>>>> Most usual depends on what the user do, but keyboard shortcuts for
>>>> menus, using ALT + some key, are available if the menus are set up
>>>> like that by the program.  Emacs does not.
>>>
>>> What is missing in Emacs here? I know from what you told me before
>>> that Emacs does not setup accelerator keys for the menus (which at
>>> least on w32 are underlined characters). However on w32 this is not
>>> needed to activate the menus with ALT. It suffices to just press
>>> ALT. (Usually once but sometimes in some apps twice, which I
>>> believe is due to somewhat bad handling of accessibility in those
>>> programs.)
>>
>> Oh, you men just pressing ALT and no additional key?  That is not
>> used in Gnome/Gtk+.  Or any other toolkit or OS I know of either.
>> Must be w32-specific.
> Yes, I mean just pressing ALT and then using the arrow keys to
> navigate in the menus.
>
> Thanks, then I understand a little bit better why my cries for
> reserving the ALT key for the menus on w32 have fallen unheard
> here. However on w32 that is very important. Too bad those things are
> not cross-OS. Does anyone knows if there is something in the
> accessibility guidelines that says something about this?

There is some variable w32-pass-alt-to-system or similarly, I believe.
Not having a w32 system, I can't vouch for its actual name.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> However on w32 that is very important. 

However on w32 this very annoying.

> Too bad those things are not cross-OS. 

Fortunately those things are not cross-OS.

:-) :-)

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[martin rudalics]

> Thanks, then I understand a little bit better why my cries for reserving 
> the ALT key for the menus on w32 have fallen unheard here. However on 
> w32 that is very important. Too bad those things are not cross-OS. Does 
> anyone knows if there is something in the accessibility guidelines that 
> says something about this?

Does (setq w32-pass-alt-to-system t) not do that for you?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

martin rudalics wrote:
>> Thanks, then I understand a little bit better why my cries for 
>> reserving the ALT key for the menus on w32 have fallen unheard here. 
>> However on w32 that is very important. Too bad those things are not 
>> cross-OS. Does anyone knows if there is something in the 
>> accessibility guidelines that says something about this?
>
> Does (setq w32-pass-alt-to-system t) not do that for you?
Thanks Martin, it does. That is not the problem. I use a slightly 
patched version of Emacs where this works very good (with the windows 
keys as META instead).

I am just trying to see what can be done to enhance "cross-platform 
usability". Since w32 still is the by far most common platform for the 
users I believe we should think of how to avoid making it a burdon 
switching from that platform to GNU/Linux.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

Kim F. Storm wrote:
>   
>> Too bad those things are not cross-OS. 
>>     
>
> Fortunately those things are not cross-OS.
>
> :-) :-)
>   
You want me to stay with w32? :-)

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> martin rudalics wrote:
>>> Thanks, then I understand a little bit better why my cries for
>>> reserving the ALT key for the menus on w32 have fallen unheard
>>> here. However on w32 that is very important. Too bad those things
>>> are not cross-OS. Does anyone knows if there is something in the
>>> accessibility guidelines that says something about this?
>>
>> Does (setq w32-pass-alt-to-system t) not do that for you?
> Thanks Martin, it does. That is not the problem. I use a slightly
> patched version of Emacs where this works very good (with the windows
> keys as META instead).
>
> I am just trying to see what can be done to enhance "cross-platform
> usability". Since w32 still is the by far most common platform for
> the users I believe we should think of how to avoid making it a
> burdon switching from that platform to GNU/Linux.

If the conventions on GNU/Linux are different, it is not the business
of Emacs to emulate Windows.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Kim F. Storm wrote:
>>   
>>> Too bad those things are not cross-OS.     
>>
>> Fortunately those things are not cross-OS.
>>
>> :-) :-)
>>   
> You want me to stay with w32? :-)

If it keeps you from whining about GNU/Linux, all will benefit.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
>> I am just trying to see what can be done to enhance "cross-platform
>> usability". Since w32 still is the by far most common platform for
>> the users I believe we should think of how to avoid making it a
>> burdon switching from that platform to GNU/Linux.
>>     
>
> If the conventions on GNU/Linux are different, it is not the business
> of Emacs to emulate Windows.
>   
That is maybe true, but I am not sure. Maybe I was unclear. Emacs is not 
my only concern. Here I wrote also about GNU/Linux.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>> Kim F. Storm wrote:
>>     
>>>   
>>>       
>>>> Too bad those things are not cross-OS.     
>>>>         
>>> Fortunately those things are not cross-OS.
>>>
>>> :-) :-)
>>>   
>>>       
>> You want me to stay with w32? :-)
>>     
>
> If it keeps you from whining about GNU/Linux, all will benefit.
>   
;-)

I thought our overall goals where more equal than that.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>>> I am just trying to see what can be done to enhance "cross-platform
>>> usability". Since w32 still is the by far most common platform for
>>> the users I believe we should think of how to avoid making it a
>>> burdon switching from that platform to GNU/Linux.
>>>     
>>
>> If the conventions on GNU/Linux are different, it is not the business
>> of Emacs to emulate Windows.
>>   
> That is maybe true, but I am not sure. Maybe I was unclear. Emacs is
> not my only concern. Here I wrote also about GNU/Linux.

Alt popping up menus makes it a burden using Emacs.  I don't see it as
Emacs' task to help people shoot themselves in the foot on GNU/Linux
because they are accustomed to the pain elsewhere.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>>
>>   
>>> Kim F. Storm wrote:
>>>     
>>>>         
>>>>> Too bad those things are not cross-OS.             
>>>> Fortunately those things are not cross-OS.
>>>>
>>>> :-) :-)
>>>>         
>>> You want me to stay with w32? :-)
>>
>> If it keeps you from whining about GNU/Linux, all will benefit.
>>   
> ;-)
>
> I thought our overall goals where more equal than that.

Sounds like "Animal Farm".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
> Alt popping up menus makes it a burden using Emacs.  I don't see it as
> Emacs' task to help people shoot themselves in the foot on GNU/Linux
> because they are accustomed to the pain elsewhere.
>   
That depends. I have Alt activating the menus but that is absolutely no 
burden since Alt is not META in my case. (I use the windows keys for META.)

For me it is exactly the reverse. I often access some menu functions 
from the keyboard regardless of the app (like maximizing, minimizing 
etc). If Alt is META that is a problem for me.

But it is in no way a personal issue. The main problem here is how to 
attract users.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
>>>> You want me to stay with w32? :-)
>>>>         
>>> If it keeps you from whining about GNU/Linux, all will benefit.
>>>   
>>>       
>> ;-)
>>
>> I thought our overall goals where more equal than that.
>>     
>
> Sounds like "Animal Farm".
>   
Hm. What is your goal then?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> But it is in no way a personal issue. The main problem here is how
> to attract users.

Emacs has nothing to gain by attracting users that want it to be
Wordpad.  They only distract from the input of users who have
suggestions at how it can be better at being Emacs.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>>>>> You want me to stay with w32? :-)
>>>>>         
>>>> If it keeps you from whining about GNU/Linux, all will benefit.
>>>>         
>>> ;-)
>>>
>>> I thought our overall goals where more equal than that.
>>>     
>>
>> Sounds like "Animal Farm".
>>   
> Hm. What is your goal then?

Improve Emacs.  If it attracts more users as a consequence, that's not
harmful in itself, but it is a sideeffect.  Making Emacs less usable
for some purported shortterm increase in user numbers is a dead end.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>> But it is in no way a personal issue. The main problem here is how
>> to attract users.
>>     
>
> Emacs has nothing to gain by attracting users that want it to be
> Wordpad.  They only distract from the input of users who have
> suggestions at how it can be better at being Emacs.
>   
Can you prove that?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
>> Hm. What is your goal then?
>>     
>
> Improve Emacs.  If it attracts more users as a consequence, that's not
> harmful in itself, but it is a sideeffect.  Making Emacs less usable
> for some purported shortterm increase in user numbers is a dead end.
>   
I see. There is nothing wrong with your goal in my opinion, but the 
challenge in my opinion is trying to do both things. Maybe that is in 
line with your long term goals too?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>>
>>   
>>> But it is in no way a personal issue. The main problem here is how
>>> to attract users.
>>>     
>>
>> Emacs has nothing to gain by attracting users that want it to be
>> Wordpad.  They only distract from the input of users who have
>> suggestions at how it can be better at being Emacs.
>>   
> Can you prove that?

I am tempted to say that you are doing a better job than I could.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>>> Emacs has nothing to gain by attracting users that want it to be
>>> Wordpad.  They only distract from the input of users who have
>>> suggestions at how it can be better at being Emacs.
>>>   
>>>       
>> Can you prove that?
>>     
>
> I am tempted to say that you are doing a better job than I could.
>   
;-)

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>>> Hm. What is your goal then?
>>>     
>>
>> Improve Emacs.  If it attracts more users as a consequence, that's
>> not harmful in itself, but it is a sideeffect.  Making Emacs less
>> usable for some purported shortterm increase in user numbers is a
>> dead end.
>
> I see. There is nothing wrong with your goal in my opinion, but the
> challenge in my opinion is trying to do both things. Maybe that is
> in line with your long term goals too?

I have enough challenges without tackling pointless ones.  I recommend
Emacs when I consider it the best solution to a problem, not because I
would derive pleasure from anybody using it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    >     I have a patch for the X11 versions of Emacs that activates the menubar when 
    >     F10 is pressed.
    > 
    > Once you do that, how do you select a menu item from the menu?
    > Is there a way to do that with the keyboard?  Or must the user switch
    > to the mouse for that?

    You use arrow keys to navigate the menu and enter/return to select an item. 
Using the keyboard is the right thing.

Some X toolkits have conventions for using the keyboard to activate
menus and menu items.  I am not sure what they are; do you know?
To what extent do they work with Emacs?  Is your patch coherent
with them?  Could it be?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    The "Emacsy way" to enable cua-mode permanently is to either use the
    menu where you can _save_ the setting, or to use customize-variable on
    cua-mode.

In that case, it should suggest customizing the variable.
Not _just_ using the menu.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

David Kastrup wrote:
> I have enough challenges without tackling pointless ones.  I recommend
> Emacs when I consider it the best solution to a problem, not because I
> would derive pleasure from anybody using it.
>   
I am glad but not surprised you are not tackling pointless goals. But I 
am a bit surprised that what you write suggests that attracting users 
does not seem to be connected to any long term goal. (However it is of 
course quite ok if you think this way.)

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

Richard Stallman wrote:
>> I have a patch for the X11 versions of Emacs that activates the menubar
>> when F10 is pressed.
>> 
>> Once you do that, how do you select a menu item from the menu? Is there a
>> way to do that with the keyboard?  Or must the user switch to the mouse
>> for that?
> 
> You use arrow keys to navigate the menu and enter/return to select an item.
>  Using the keyboard is the right thing.
> 
> Some X toolkits have conventions for using the keyboard to activate menus
> and menu items.  I am not sure what they are; do you know? To what extent
> do they work with Emacs?  Is your patch coherent with them?  Could it be?

The patch is coherent in that it implements opening menus on F10, which is 
standard for many toolkits.

Another way to activate menus is with accelerator keys, usually Alt + the 
first letter in the menu entry (the letter in question is underlined in the 
menu).  That would be Alt+F for File.  On Mac it is the Command key instead of 
Alt, but the principle is the same.  When a menu has been opened there may be 
more accelerators (like S for Save), so instead of using the arrow to navigate 
down to Save and then press RET, you can press just S or Alt+S to select Save.

My patch does not implement this, but it is quite easy to do in Lesstif/Motif 
and Gtk+ (harder in Lucid).  The thing is to decide which accelerators to use 
and how to represent them in the current lisp menu structures.  Another thing 
it to figure out how to avoid collisions, so that for example, File and 
Fortran-mode doesn't both use F, and of course only use accelerator keys if 
Alt is different from Meta.

This is more work, so I have not started to look in to it.  I'll will do that 
after the release though.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> David Kastrup wrote:
>> I have enough challenges without tackling pointless ones.  I recommend
>> Emacs when I consider it the best solution to a problem, not because I
>> would derive pleasure from anybody using it.
>>   
> I am glad but not surprised you are not tackling pointless
> goals. But I am a bit surprised that what you write suggests that
> attracting users does not seem to be connected to any long term
> goal.

I didn't say that it is unconnected to any long term goal, quite the
contrary.  Attracting users is highly connected to improving Emacs.
Like skin rashes are highly connected to allergic shock.  You don't
treat allergic shock with makeup, though.

Attracting users at the cost of making Emacs worse is putting the cart
before the horse.  And I doubt you could keep your intended clientele
for long, anyway.  You'll stand there shaking your head and saying "I
don't understand why he went into shock after all.  I painted the nuts
orange and made them look like cherries.  He could not possibly have
recognized them."

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Richard Stallman wrote:
>>> I have a patch for the X11 versions of Emacs that activates the menubar
>>> when F10 is pressed.
>>>
>>> Once you do that, how do you select a menu item from the menu? Is there a
>>> way to do that with the keyboard?  Or must the user switch to the mouse
>>> for that?
>>
>> You use arrow keys to navigate the menu and enter/return to select an item.
>>  Using the keyboard is the right thing.
>>
>> Some X toolkits have conventions for using the keyboard to activate menus
>> and menu items.  I am not sure what they are; do you know? To what extent
>> do they work with Emacs?  Is your patch coherent with them?  Could it be?
>
> The patch is coherent in that it implements opening menus on F10,
> which is standard for many toolkits.
>
> Another way to activate menus is with accelerator keys, usually Alt
> + the first letter in the menu entry (the letter in question is
> underlined in the menu).  That would be Alt+F for File.  On Mac it
> is the Command key instead of Alt, but the principle is the same.
> When a menu has been opened there may be more accelerators (like S
> for Save), so instead of using the arrow to navigate down to Save
> and then press RET, you can press just S or Alt+S to select Save.
>
> My patch does not implement this, but it is quite easy to do in
> Lesstif/Motif and Gtk+ (harder in Lucid).  The thing is to decide
> which accelerators to use and how to represent them in the current
> lisp menu structures.

tmm-menubar already picks accelerator keys.  It seems reasonable to
steal the choice from there.

At the current point of time, on 105-key keyboards, the "Menu" key on
Emacs puts up "M-x".  It might be reasonable to let this instead
access the menu.  After all, "M-x" is easy enough to type when the Alt
key is Meta, and Alt being Meta is rather desirable.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[public]

Jan Djärv <jan.h.d@swipnet.se> writes:

> I have a patch for the X11 versions of Emacs that activates the
> menubar when F10 is pressed.  

It would be very nice to have this capability of navigating the menus
entirely via the keyboard, especially as it is consistent with both the
Gnome human interface guidelines and with the Emacs tendency to enable
as much as possible to be done via the keyboard instead of the mouse.

With your patch, is it possible to make the choice of the particular key
to use for activating the menubar (F10 or some other) configurable from
lisp, or do you have to specify that key at compile time?

-- 
Peter Heslin (http://www.dur.ac.uk/p.j.heslin)

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

public@heslin.eclipse.co.uk skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> I have a patch for the X11 versions of Emacs that activates the
>> menubar when F10 is pressed.  
> 
> It would be very nice to have this capability of navigating the menus
> entirely via the keyboard, especially as it is consistent with both the
> Gnome human interface guidelines and with the Emacs tendency to enable
> as much as possible to be done via the keyboard instead of the mouse.
> 
> With your patch, is it possible to make the choice of the particular key
> to use for activating the menubar (F10 or some other) configurable from
> lisp, or do you have to specify that key at compile time?
> 

It defines a new command x-menu-bar-start that you can set to any key.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     The "Emacsy way" to enable cua-mode permanently is to either use the
>     menu where you can _save_ the setting, or to use customize-variable on
>     cua-mode.
>
> In that case, it should suggest customizing the variable.
> Not _just_ using the menu.

I already changed the message to do that.

There is no need to discuss this any further.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Kim F. Storm]

Jan Djärv <jan.h.d@swipnet.se> writes:

> The patch is coherent in that it implements opening menus on F10,
> which is standard for many toolkits.

Which is good.

>
> Another way to activate menus is with accelerator keys, usually Alt +
> the first letter in the menu entry (the letter in question is
> underlined in the menu).  That would be Alt+F for File.  

I press Alt-F to get M-f ...   How is that going to co-exit?

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

Kim F. Storm wrote:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> The patch is coherent in that it implements opening menus on F10,
>> which is standard for many toolkits.
> 
> Which is good.
> 
>> Another way to activate menus is with accelerator keys, usually Alt +
>> the first letter in the menu entry (the letter in question is
>> underlined in the menu).  That would be Alt+F for File.  
> 
> I press Alt-F to get M-f ...   How is that going to co-exit?
> 

As I wrote: "... and of course only use accelerator keys if Alt is different 
from Meta."

The suggestion to use the menu key that exists on some keyboards can be 
implemented, so for your setup, you would have to use Menu-F.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

> After all, "M-x" is easy enough to type when the Alt
> key is Meta, and Alt being Meta is rather desirable.
>   
Is it not better to follow the standard for Gnome and other platforms 
where it is possible? Does not Alt beeing META clash with these? Would 
it not be better to have Alt as META as an option? Could not that be 
good for both new and old users?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

>> After all, "M-x" is easy enough to type when the Alt
>> key is Meta, and Alt being Meta is rather desirable.
>>   
> Is it not better to follow the standard for Gnome and other platforms
> where it is possible?

No.  Meta is far too important to assign it to some faraway key.
Especially some key far awar from x.

> Does not Alt beeing META clash with these? Would it not be better to
> have Alt as META as an option? Could not that be good for both new
> and old users?

For neither.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Stefan Monnier]

>> After all, "M-x" is easy enough to type when the Alt
>> key is Meta, and Alt being Meta is rather desirable.
> Is it not better to follow the standard for Gnome and other platforms where
> it is possible? Does not Alt beeing META clash with these? Would it not be
> better to have Alt as META as an option? Could not that be good for both new
> and old users?

This is not decided by Emacs.  If both Alt and Meta are available, Emacs
does distinguish between them.  It's only if Meta is not available that
Emacs treats Alt as Meta.

Given that some apps use Meta (e.g. Emacs) while others use Alt but
a vanishingly small number use both, I prefer to configure xmodmap so as to
only have one of the two, in order to remove this gratuitous distinction.


        Stefan

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

Stefan Monnier wrote:
>>> After all, "M-x" is easy enough to type when the Alt
>>> key is Meta, and Alt being Meta is rather desirable.
>>>       
>> Is it not better to follow the standard for Gnome and other platforms where
>> it is possible? Does not Alt beeing META clash with these? Would it not be
>> better to have Alt as META as an option? Could not that be good for both new
>> and old users?
>>     
>
> This is not decided by Emacs.  If both Alt and Meta are available, Emacs
> does distinguish between them.  It's only if Meta is not available that
> Emacs treats Alt as Meta.
>
> Given that some apps use Meta (e.g. Emacs) while others use Alt but
> a vanishingly small number use both, I prefer to configure xmodmap so as to
> only have one of the two, in order to remove this gratuitous distinction.
>   
Thanks Stefan, but what keyboard is used then? On w32 I mostly use a 
standard keyboard where I to the left have

    CTRL - WINL - ALT

and to the right

    ALTGR - WINR - APP - CTRL

I then use WINL (and sometimes WINR too) as META. This currently 
requires a patch to Emacs to work correctly.

Some keyboards (mostly old ones) does not have WINL and WINR then I have 
to sacrifice ALT as META of course.

But how does typical layout look on Gnome? Where is META?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Kim F. Storm]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Some keyboards (mostly old ones) does not have WINL and WINR then I
> have to sacrifice ALT as META of course.

One or both may also be missing on some newer notebook keyboards.
 
-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    Is it not better to follow the standard for Gnome and other platforms 
    where it is possible? Does not Alt beeing META clash with these?

Where else can Meta be?  My keyboard has no other suitable place.

The GNOME developers should not have chosen conventions that
clash with Emacs.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    > In that case, it should suggest customizing the variable.
    > Not _just_ using the menu.

    I already changed the message to do that.

Thanks.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    > You use arrow keys to navigate the menu and enter/return to select an item.
    >  Using the keyboard is the right thing.
    > 
    > Some X toolkits have conventions for using the keyboard to activate menus
    > and menu items.  I am not sure what they are; do you know? To what extent
    > do they work with Emacs?  Is your patch coherent with them?  Could it be?

    The patch is coherent in that it implements opening menus on F10, which is 
    standard for many toolkits.

I see that my words were unclear.  The issue I meant to raise is
specifically about the use of arrow keys and RET to select menu items.
How does that compare with what various X toolkits do?

    When a menu has been opened there may be 
    more accelerators (like S for Save), so instead of using the arrow to navigate 
    down to Save and then press RET, you can press just S or Alt+S to select Save.

That answers the question I meant to ask.

    My patch does not implement this, but it is quite easy to do in Lesstif/Motif 
    and Gtk+ (harder in Lucid).  The thing is to decide which accelerators to use 
    and how to represent them in the current lisp menu structures.

Since the motive for this would be compatibility with various
toolkits, I think it ought to try to choose the accelerators in the
same way that the toolkit in use does it.

You say this is "harder in Lucid".  Why is that?  Do the Lucid menus
support navigating within a menu with the keyboard using accelerators?
If not, then the arrow key solution you have already implemented is as
compatible as any other would be.

    This is more work, so I have not started to look in to it.  I'll
    will do that after the release though.

Ok.

    Another way to activate menus is with accelerator keys, usually Alt + the 
    first letter in the menu entry (the letter in question is underlined in the 
    menu).

I don't think we want this in Emacs, in general.  On terminals where
Alt is different from Meta, it could be useful to be able to set this
up; but that is not very important.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

Could you show us your existing patch?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

Richard Stallman skrev:
>     > You use arrow keys to navigate the menu and enter/return to select an item.
>     >  Using the keyboard is the right thing.
>     > 
>     > Some X toolkits have conventions for using the keyboard to activate menus
>     > and menu items.  I am not sure what they are; do you know? To what extent
>     > do they work with Emacs?  Is your patch coherent with them?  Could it be?
> 
>     The patch is coherent in that it implements opening menus on F10, which is 
>     standard for many toolkits.
> 
> I see that my words were unclear.  The issue I meant to raise is
> specifically about the use of arrow keys and RET to select menu items.
> How does that compare with what various X toolkits do?

It is what X toolkits do.  In fact, once the menu is posted, the arrow 
navigation and RET selection is all done by the toolkit (Lesstif/Motif/Gtk+).

> 
>     When a menu has been opened there may be 
>     more accelerators (like S for Save), so instead of using the arrow to navigate 
>     down to Save and then press RET, you can press just S or Alt+S to select Save.
> 
> That answers the question I meant to ask.
> 
>     My patch does not implement this, but it is quite easy to do in Lesstif/Motif 
>     and Gtk+ (harder in Lucid).  The thing is to decide which accelerators to use 
>     and how to represent them in the current lisp menu structures.
> 
> Since the motive for this would be compatibility with various
> toolkits, I think it ought to try to choose the accelerators in the
> same way that the toolkit in use does it.

Toolkits in general doesn't choose accelerators, the programmers of the 
applications that uses the toolkit does.  However, many meny entries are 
similar in a lot of applications (Open/Save/Copy/Paste/...) so we can choose 
those to be similar.

> 
> You say this is "harder in Lucid".  Why is that?  Do the Lucid menus
> support navigating within a menu with the keyboard using accelerators?
> If not, then the arrow key solution you have already implemented is as
> compatible as any other would be.

The lucid toolkit does not have support for accelerators, but the arrow and 
RET selection support is there.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

[-- Attachment #1: Type: text/plain, Size: 150 bytes --]

Richard Stallman skrev:
> Could you show us your existing patch?

Attached.  BTW, this does not work for non-toolkit menus (i.e. oldXmenu).


	Jan D.

[-- Attachment #2: emacs-F10.diff --]
[-- Type: text/plain, Size: 7134 bytes --]

diff -w -c lwlib/xlwmenu.c.orig lwlib/xlwmenu.c
Index: lwlib/xlwmenu.c
*** lwlib/xlwmenu.c.orig	2006-05-22 10:10:07.000000000 +0200
--- lwlib/xlwmenu.c	2006-05-22 10:06:28.000000000 +0200
***************
*** 2088,2093 ****
--- 2088,2094 ----
        mw->menu.windows [0].y = ev->xmotion.y_root - ev->xmotion.y;
  
        /* handles the down like a move, slots are compatible */
+       ev->xmotion.is_hint = 0;
        handle_motion_event (mw, &ev->xmotion);
      }
  }
***************
*** 2503,2508 ****
--- 2504,2510 ----
    x_uncatch_errors (display, count);
  #endif
  
+   ((XMotionEvent*)event)->is_hint = 0;
    handle_motion_event (mw, (XMotionEvent*)event);
  }
  
diff -w -c src/gtkutil.c.orig src/gtkutil.c
Index: src/gtkutil.c
*** src/gtkutil.c.orig	2006-03-06 17:51:14.000000000 +0100
--- src/gtkutil.c	2006-05-22 08:47:42.000000000 +0200
***************
*** 1970,1975 ****
--- 1970,1999 ----
    return w;
  }
  
+ /* Callback called when keyboard traversal (started by x-menu-bar-start) ends.
+    WMENU is the menu for which traversal has been done.  DATA points to the
+    frame for WMENU.  We must release grabs, some bad interaction between GTK
+    and Emacs makes the menus keep the grabs.  */
+ 
+ static void
+ menu_nav_ended (wmenu, data)
+      GtkMenuShell *wmenu;
+      gpointer data;
+ {
+   FRAME_PTR f = (FRAME_PTR) data;
+   Display *dpy = FRAME_X_DISPLAY (f);
+ 
+   BLOCK_INPUT;
+       GtkMenuShell *w = GTK_MENU_SHELL (FRAME_X_OUTPUT (f)->menubar_widget);
+       gtk_menu_shell_deactivate (w);
+       gtk_menu_shell_deselect (w);
+ 
+   XUngrabKeyboard (dpy, CurrentTime);
+   XUngrabPointer (dpy, CurrentTime);
+   UNBLOCK_INPUT;
+ }
+ 
+ 
  static GtkWidget *create_menus P_ ((widget_value *, FRAME_PTR, GCallback,
  				    GCallback, GCallback, int, int, int,
  				    GtkWidget *, xg_menu_cb_data *, char *));
***************
*** 2024,2029 ****
--- 2048,2059 ----
          }
        else wmenu = gtk_menu_bar_new ();
  
+       /* Fix up grabs after keyboard traversal ends.  */
+       g_signal_connect (G_OBJECT (wmenu),
+                         "selection-done",
+                         G_CALLBACK (menu_nav_ended),
+                         f);
+ 
        /* Put cl_data on the top menu for easier access.  */
        cl_data = make_cl_data (cl_data, f, highlight_cb);
        g_object_set_data (G_OBJECT (wmenu), XG_FRAME_DATA, (gpointer)cl_data);
diff -w -c src/xmenu.c.orig src/xmenu.c
Index: src/xmenu.c
*** src/xmenu.c.orig	2006-05-06 16:52:47.000000000 +0200
--- src/xmenu.c	2006-05-22 09:35:53.000000000 +0200
***************
*** 1301,1309 ****
--- 1301,1417 ----
      }
  }
  
+ DEFUN ("x-menu-bar-start", Fx_menu_bar_start, Sx_menu_bar_start, 0, 1, "i",
+        doc: /* Start key navigation of the menu bar in FRAME.
+ Usually the "File" menu is opened and you can then navigate with the
+ arrow keys, select a menu entry with the return key or cancel with the
+ escape key.  If FRAME has no menu bar this function does nothing.
+ 
+ If FRAME is nil or not given, use the selected frame.  */)
+      (frame)
+      Lisp_Object frame;
+ {
+   XEvent ev;
+   FRAME_PTR f = check_x_frame (frame);
+   Widget menubar;
+   BLOCK_INPUT;
+ 
+   if (FRAME_EXTERNAL_MENU_BAR (f))
+     set_frame_menubar (f, 0, 1);
+ 
+   menubar = FRAME_X_OUTPUT (f)->menubar_widget;
+   if (menubar)
+     {
+       Window child;
+       int error_p = 0;
+ 
+       x_catch_errors (FRAME_X_DISPLAY (f));
+       memset (&ev, 0, sizeof ev);
+       ev.xbutton.display = FRAME_X_DISPLAY (f);
+       ev.xbutton.window = XtWindow (menubar);
+       ev.xbutton.root = FRAME_X_DISPLAY_INFO (f)->root_window;
+       ev.xbutton.time = XtLastTimestampProcessed (FRAME_X_DISPLAY (f));
+       ev.xbutton.button = Button1;
+       ev.xbutton.x = ev.xbutton.y = FRAME_MENUBAR_HEIGHT (f) / 2;
+       ev.xbutton.same_screen = True;
+ 
+ #ifdef USE_MOTIF
+       {
+         Arg al[2];
+         WidgetList list;
+         Cardinal nr;
+         XtSetArg (al[0], XtNchildren, &list);
+         XtSetArg (al[1], XtNnumChildren, &nr);
+         XtGetValues (menubar, al, 2);
+         ev.xbutton.window = XtWindow (list[0]);
+       }
+ #endif
+ 
+       XTranslateCoordinates (FRAME_X_DISPLAY (f),
+                              /* From-window, to-window.  */
+                              ev.xbutton.window, ev.xbutton.root,
+ 
+                              /* From-position, to-position.  */
+                              ev.xbutton.x, ev.xbutton.y,
+                              &ev.xbutton.x_root, &ev.xbutton.y_root,
+ 
+                              /* Child of win.  */
+                              &child);
+       error_p = x_had_errors_p (FRAME_X_DISPLAY (f));
+       x_uncatch_errors ();
+ 
+       if (! error_p)
+         {
+           ev.type = ButtonPress;
+           ev.xbutton.state = 0;
+ 
+           XtDispatchEvent (&ev);
+           ev.xbutton.type = ButtonRelease;
+           ev.xbutton.state = Button1Mask;
+           XtDispatchEvent (&ev);
+         }
+     }
+ 
+   UNBLOCK_INPUT;
+ }
  #endif /* USE_X_TOOLKIT */
  
+ 
  #ifdef USE_GTK
+ DEFUN ("x-menu-bar-start", Fx_menu_bar_start, Sx_menu_bar_start, 0, 1, "i",
+        doc: /* Start key navigation of the menu bar in FRAME.
+ Usually the "File" menu is opened and you can then navigate with the
+ arrow keys, select a menu entry with the return key or cancel with the
+ escape key.  If FRAME has no menu bar this function does nothing.
+ 
+ If FRAME is nil or not given, use the selected frame.  */)
+      (frame)
+      Lisp_Object frame;
+ {
+   GtkWidget *menubar;
+   BLOCK_INPUT;
+   FRAME_PTR f = check_x_frame (frame);
+ 
+   if (FRAME_EXTERNAL_MENU_BAR (f))
+     set_frame_menubar (f, 0, 1);
+ 
+   menubar = FRAME_X_OUTPUT (f)->menubar_widget;
+   if (menubar)
+     {
+       /* Activate the first menu.  */
+       GList *children = gtk_container_get_children (GTK_CONTAINER (menubar));
+ 
+       gtk_menu_shell_select_item (GTK_MENU_SHELL (menubar),
+                                   GTK_WIDGET (children->data));
+       
+       popup_activated_flag = 1;
+       g_list_free (children);
+     }
+   UNBLOCK_INPUT;
+ 
+   return Qnil;
+ }
+ 
  /* Loop util popup_activated_flag is set to zero in a callback.
     Used for popup menus and dialogs. */
  
***************
*** 3659,3664 ****
--- 3767,3777 ----
  #endif
  
    defsubr (&Sx_popup_menu);
+ 
+ #if defined (USE_GTK) || defined (USE_X_TOOLKIT)
+   defsubr (&Sx_menu_bar_start);
+ #endif
+ 
  #ifdef HAVE_MENUS
    defsubr (&Sx_popup_dialog);
  #endif
diff -w -c lisp/term/x-win.el.orig lisp/term/x-win.el
Index: lisp/term/x-win.el
*** lisp/term/x-win.el.orig	2006-02-14 08:57:16.000000000 +0100
--- lisp/term/x-win.el	2006-05-22 08:42:00.000000000 +0200
***************
*** 2516,2520 ****
--- 2516,2524 ----
  (add-hook 'after-make-frame-functions 'x-dnd-init-frame)
  (global-set-key [drag-n-drop] 'x-dnd-handle-drag-n-drop-event)
  
+ ;; Let F10 do menu bar navigation.
+ (and (fboundp 'x-menu-bar-start)
+      (global-set-key [f10] 'x-menu-bar-start))
+ 
  ;; arch-tag: f1501302-db8b-4d95-88e3-116697d89f78
  ;;; x-win.el ends here

[-- Attachment #3: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Stefan Monnier]

> + DEFUN ("x-menu-bar-start", Fx_menu_bar_start, Sx_menu_bar_start, 0, 1, "i",

Could we spare the "x-" prefix?
This operation is meaningful in other environments as well (even if not
implemented there yet).


        Stefan

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

Jan Djärv wrote:
>
> Toolkits in general doesn't choose accelerators, the programmers of 
> the applications that uses the toolkit does.  However, many menu 
> entries are similar in a lot of applications 
> (Open/Save/Copy/Paste/...) so we can choose those to be similar.
For the record: This holds for w32 menus too.
>>
>> You say this is "harder in Lucid".  Why is that?  Do the Lucid menus
>> support navigating within a menu with the keyboard using accelerators?
>> If not, then the arrow key solution you have already implemented is as
>> compatible as any other would be.
>
> The lucid toolkit does not have support for accelerators, but the 
> arrow and RET selection support is there.
w32 menus has accelerators and if I do not misremember they are choosen 
in a way rather similar to some X toolkits (but I need more education 
there).

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Lennart Borgman <lennart.borgman.073@student.lu.se> writes:

> Jan Djärv wrote:
>>
>> Toolkits in general doesn't choose accelerators, the programmers of
>> the applications that uses the toolkit does.  However, many menu
>> entries are similar in a lot of applications
>> (Open/Save/Copy/Paste/...) so we can choose those to be similar.
> For the record: This holds for w32 menus too.

I have to say that this thread leaves a very bad taste in my mouth.
Two reasons:

a) new feature, not to be checked in.  If it is checked in, testing
and ironing out problems and possibly choosing accelerators, even
though they could possibly be provided by code in tmm-menubar and
consolidation with all platforms will cost considerable time and
effort.

b) it is rather essential functionality.  I want to see this soon, at
least in basics.

We need to get our back free for working stuff like that into Emacs.
Personally, I'd say add the menus on F10 now, think about accelerators
after the release.  But I realize that this is dissatisfactorily both
with catering for the feature properly, and with getting our release
out.

I think we have reached more or less the state where we are shooting
ourselves in the foot more with regard to code quality by further
delaying the release.  Regardless of how the menu issue is going to be
handled right now, I'd breathe a sign of relief if we declared pretest
to start a week from now.  And target a release one month from now.
And if we miss that date, fork a release branch at that time and get
it out when no significant improvement fixes appear to make it.

Telling people who want to improve Emacs "this is a great idea, and
we'll probably have it appear in a release in four more years" is not
helping.  Let's get this release over with.  It may be less than
perfect, but it's better than the last one.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan D.]

David Kastrup wrote:
> Lennart Borgman <lennart.borgman.073@student.lu.se> writes:
>
>   
>> Jan Djärv wrote:
>>     
>>> Toolkits in general doesn't choose accelerators, the programmers of
>>> the applications that uses the toolkit does.  However, many menu
>>> entries are similar in a lot of applications
>>> (Open/Save/Copy/Paste/...) so we can choose those to be similar.
>>>       
>> For the record: This holds for w32 menus too.
>>     
>
> I have to say that this thread leaves a very bad taste in my mouth.
> Two reasons:
>
> a) new feature, not to be checked in.  If it is checked in, testing
> and ironing out problems and possibly choosing accelerators, even
> though they could possibly be provided by code in tmm-menubar and
> consolidation with all platforms will cost considerable time and
> effort.
>
> b) it is rather essential functionality.  I want to see this soon, at
> least in basics.
>
> We need to get our back free for working stuff like that into Emacs.
> Personally, I'd say add the menus on F10 now, think about accelerators
> after the release.  But I realize that this is dissatisfactorily both
> with catering for the feature properly, and with getting our release
> out.

My view is that F10 is new functionallity and I did not intend to check 
this in before the release.  I think it can wait, it is not that important.

    Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> David Kastrup wrote:
>>
>> We need to get our back free for working stuff like that into
>> Emacs.  Personally, I'd say add the menus on F10 now, think about
>> accelerators after the release.  But I realize that this is
>> dissatisfactorily both with catering for the feature properly, and
>> with getting our release out.
>
> My view is that F10 is new functionallity and I did not intend to
> check this in before the release.  I think it can wait, it is not
> that important.

Being able to work the menus without a mouse is important (tmm-menubar
does not really make sense when the whole widgetry of a GUI is already
in-place).  So is getting out a release of Emacs.

We need to get out of limbo at some time.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jason Rumney]

David Kastrup wrote:
> Being able to work the menus without a mouse is important
It can't be that important, or we would have had users complaining 
before now.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Lennart Borgman]

Jason Rumney wrote:
> David Kastrup wrote:
>> Being able to work the menus without a mouse is important
> It can't be that important, or we would have had users complaining 
> before now.
We have.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> David Kastrup wrote:
>> Being able to work the menus without a mouse is important
> It can't be that important, or we would have had users complaining
> before now.

They are giving me .... about it frequently in the TeX related Usenet
groups.  AUCTeX makes such a compelling environment that people put up
with Emacs for that reason.  But they don't particularly enjoy the
breaking-in phase.  "Working menus with keyboard" is one of the more
frequent and somewhat embarrassing complaints.  And the suggestion F10
(which starts tmm-menubar) does not really get the most enthusiastic
response.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

Stefan Monnier skrev:
>> + DEFUN ("x-menu-bar-start", Fx_menu_bar_start, Sx_menu_bar_start, 0, 1, "i",
> 
> Could we spare the "x-" prefix?
> This operation is meaningful in other environments as well (even if not
> implemented there yet).

Yes of course.  But there are a lot of x- functions in the mac and w32 files 
already (x-show/hide-tip, x-file-dialog, x-popup-dialog/menu, ...).

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Stefan Monnier]

>>> + DEFUN ("x-menu-bar-start", Fx_menu_bar_start, Sx_menu_bar_start, 0, 1, "i",
>> 
>> Could we spare the "x-" prefix?
>> This operation is meaningful in other environments as well (even if not
>> implemented there yet).

> Yes of course.  But there are a lot of x- functions in the mac and w32 files
> already (x-show/hide-tip, x-file-dialog, x-popup-dialog/menu, ...).

I know, but I think these names were mistakenly chosen (back when they were
introduced in the X11 code) and we shouldn't keep doing the same mistakes.


        Stefan

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    > How does that compare with what various X toolkits do?

    It is what X toolkits do.  In fact, once the menu is posted, the arrow 
    navigation and RET selection is all done by the toolkit (Lesstif/Motif/Gtk+).

In that case, it is clearly the right thing.

    > Since the motive for this would be compatibility with various
    > toolkits, I think it ought to try to choose the accelerators in the
    > same way that the toolkit in use does it.

    Toolkits in general doesn't choose accelerators, the programmers of the 
    applications that uses the toolkit does.  However, many meny entries are 
    similar in a lot of applications (Open/Save/Copy/Paste/...) so we can choose 
    those to be similar.

I suspect another miscommunication here.  What do you mean by
"accelerators"?  I thought we were talking about typing a letter _once
the menu is active_ to select a given menu item.  Is that what you
mean, too?

How do these get selected, with LessTif and GTK?

(This discussion is for work to be done after the release, if at all.)

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

I think your F10 change will be a big convenience, and since it is
so simple, we should install it now.  However, implementing accelerators
is something else; that should not be done now.

It is not things like this that are delaying the release.
It is doing the things that need to be done before the release.
Would people please turn their attention to the tasks in FOR-RELEASE
and start doing them?

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jason Rumney]

Richard Stallman wrote:
> I suspect another miscommunication here.  What do you mean by
> "accelerators"?  I thought we were talking about typing a letter _once
> the menu is active_ to select a given menu item.  Is that what you
> mean, too?
>   
Technically, GTK calls these mnemonics, and what it calls accelerators 
are the normal keybindings, which we already display to the right of the 
menu item.

> How do these get selected, with LessTif and GTK?
>   
With GTK, the menu item's text contains an underscore before the letter 
which the developer wants to use as a mnemonic. I think lesstif does it 
the same way (I can only find documentation for Motif, which does it 
this way), and in windows, an ampersand is used in the same way. On all 
three platforms, to the user the mnemonic character is underlined, and 
the _ or & does not appear as part of the menu text. From what I've read 
about Mac OSX, mnemonics are not supported, instead it has a completion 
like interface - effectively, the first letter of the menu functions 
like a mnemonic for the first encountered menu item, but menu items 
further down may require two or more keystrokes to access.

Probably the best way to handle this then is for the Windows menu code 
to replace _ in menu item text with &, and for mac, tmm and non-toolkit 
X menu code to strip out the _ (or build the code in to handle it). Then 
we can go through our menus and add _'s as appropriate.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Jason Rumney <jasonr@gnu.org> writes:

> Richard Stallman wrote:
>> I suspect another miscommunication here.  What do you mean by
>> "accelerators"?  I thought we were talking about typing a letter _once
>> the menu is active_ to select a given menu item.  Is that what you
>> mean, too?
>>   
> Technically, GTK calls these mnemonics, and what it calls accelerators
> are the normal keybindings, which we already display to the right of
> the menu item.
>
>> How do these get selected, with LessTif and GTK?
>>   
> With GTK, the menu item's text contains an underscore before the
> letter which the developer wants to use as a mnemonic. I think lesstif
> does it the same way (I can only find documentation for Motif, which
> does it this way), and in windows, an ampersand is used in the same
> way. On all three platforms, to the user the mnemonic character is
> underlined, and the _ or & does not appear as part of the menu
> text. From what I've read about Mac OSX, mnemonics are not supported,
> instead it has a completion like interface - effectively, the first
> letter of the menu functions like a mnemonic for the first encountered
> menu item, but menu items further down may require two or more
> keystrokes to access.
>
> Probably the best way to handle this then is for the Windows menu code
> to replace _ in menu item text with &, and for mac, tmm and
> non-toolkit X menu code to strip out the _ (or build the code in to
> handle it). Then we can go through our menus and add _'s as
> appropriate.

Menus are often consed together from various modules.  I don't think
that this would work reliably.  I think it would be better when the
abbreviations would be chosen automatically in most cases.  Even
though it might make sense if the automatisms would try to obey
suggestions where possible.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

>     Toolkits in general doesn't choose accelerators, the programmers of the 
>     applications that uses the toolkit does.  However, many meny entries are 
>     similar in a lot of applications (Open/Save/Copy/Paste/...) so we can choose 
>     those to be similar.
> 
> I suspect another miscommunication here.  What do you mean by
> "accelerators"?  I thought we were talking about typing a letter _once
> the menu is active_ to select a given menu item.  Is that what you
> mean, too?
> 
> How do these get selected, with LessTif and GTK?

As has been pointed out, the correct term is mnemonics.  I mean the single 
letter you press to select a menu item when navigating it with the keyboard.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

>>
>> Probably the best way to handle this then is for the Windows menu code
>> to replace _ in menu item text with &, and for mac, tmm and
>> non-toolkit X menu code to strip out the _ (or build the code in to
>> handle it). Then we can go through our menus and add _'s as
>> appropriate.
> 
> Menus are often consed together from various modules.  I don't think
> that this would work reliably.  I think it would be better when the
> abbreviations would be chosen automatically in most cases.  Even
> though it might make sense if the automatisms would try to obey
> suggestions where possible.
> 


Case in point is the buffers menu.  If you happen to have a buffer with an 
underscore in the name, it wouldn't be correct when making the menu entry.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    > I suspect another miscommunication here.  What do you mean by
    > "accelerators"?  I thought we were talking about typing a letter _once
    > the menu is active_ to select a given menu item.  Is that what you
    > mean, too?
    >   
    Technically, GTK calls these mnemonics, and what it calls accelerators 
    are the normal keybindings, which we already display to the right of the 
    menu item.

In that case, the issue here is the mnemonics, not the accelerators,
right?  We already handle accelerators.

    Probably the best way to handle this then is for the Windows menu code 
    to replace _ in menu item text with &, and for mac, tmm and non-toolkit 
    X menu code to strip out the _ (or build the code in to handle it). Then 
    we can go through our menus and add _'s as appropriate.

That seems like a good approach.  But let's put it in etc/TODO
and work on the release.

    Menus are often consed together from various modules.  I don't think
    that this would work reliably.  I think it would be better when the
    abbreviations would be chosen automatically in most cases.  Even
    though it might make sense if the automatisms would try to obey
    suggestions where possible.

Mixing menu items from various keymaps can happen in Emacs, but it
does not happen very much.  So I don't think it will make the feature
ineffective.  Of course, it should avoid getting confused in the case
where two menu items have the same mnemonic.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Richard Stallman]

    Case in point is the buffers menu.  If you happen to have a buffer with an 
    underscore in the name, it wouldn't be correct when making the menu entry.

Yes, we would need a Lisp-level way to turn off the mnemonics feature.
It could be done at the level of menu items, or it could be done at
the level of a whole menu.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

Richard Stallman skrev:
> I think your F10 change will be a big convenience, and since it is
> so simple, we should install it now.  However, implementing accelerators
> is something else; that should not be done now.

Installed.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Richard Stallman skrev:
>> I think your F10 change will be a big convenience, and since it is
>> so simple, we should install it now.  However, implementing accelerators
>> is something else; that should not be done now.
>
> Installed.

I just took a look across the fence.  In XEmacs, they have

    `accelerate-menu' is an interactive built-in function
    (accelerate-menu)

    Documentation:
    Make the menubar active.  Menu items can be selected using menu
    accelerators or by actions defined in menu-accelerator-map.

It would probably not be the worst idea to do this via a keybinding
instead of hardwired.  If that is infeasible for some reason or
already done like this, never mind.  I seem to remember from what I
saw in the patch that you did it in some other manner?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

David Kastrup skrev:

> I just took a look across the fence.  In XEmacs, they have
> 
>     `accelerate-menu' is an interactive built-in function
>     (accelerate-menu)
> 
>     Documentation:
>     Make the menubar active.  Menu items can be selected using menu
>     accelerators or by actions defined in menu-accelerator-map.
> 
> It would probably not be the worst idea to do this via a keybinding
> instead of hardwired.  If that is infeasible for some reason or
> already done like this, never mind.  I seem to remember from what I
> saw in the patch that you did it in some other manner?

You mean that navigation with arrow keys/Return/ESC should not be hardwired 
but done with a keybinding?  We could probably do this for Lucid, as we 
maintain the code for that.  But for Gtk+ and Lesstif/Motif, the actions are 
hardwired in the toolkit itself.  There might be a way to work around that, 
but I guess it would be too much work for too little gain.

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> David Kastrup skrev:
>
>> I just took a look across the fence.  In XEmacs, they have
>>
>>     `accelerate-menu' is an interactive built-in function
>>     (accelerate-menu)
>>
>>     Documentation:
>>     Make the menubar active.  Menu items can be selected using menu
>>     accelerators or by actions defined in menu-accelerator-map.
>>
>> It would probably not be the worst idea to do this via a keybinding
>> instead of hardwired.  If that is infeasible for some reason or
>> already done like this, never mind.  I seem to remember from what I
>> saw in the patch that you did it in some other manner?
>
> You mean that navigation with arrow keys/Return/ESC should not be
> hardwired but done with a keybinding?

Oh no, that would be a total mess, I guess.  No, just the F10 key
function should be a keybinding pointing to something like
"accelerate-menu".  Again, if it is already done like this, never
mind.

> We could probably do this for Lucid, as we maintain the code for
> that.  But for Gtk+ and Lesstif/Motif, the actions are hardwired in
> the toolkit itself.  There might be a way to work around that, but I
> guess it would be too much work for too little gain.

I definitely agree.  I was not intending to suggest interfering with
the menu-internal operation.  I was just thinking about the way to
_initiate_ it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

David Kastrup skrev:
> Jan Djärv <jan.h.d@swipnet.se> writes:
> 
>> David Kastrup skrev:
>>
>>> I just took a look across the fence.  In XEmacs, they have
>>>
>>>     `accelerate-menu' is an interactive built-in function
>>>     (accelerate-menu)
>>>
>>>     Documentation:
>>>     Make the menubar active.  Menu items can be selected using menu
>>>     accelerators or by actions defined in menu-accelerator-map.
>>>
>>> It would probably not be the worst idea to do this via a keybinding
>>> instead of hardwired.  If that is infeasible for some reason or
>>> already done like this, never mind.  I seem to remember from what I
>>> saw in the patch that you did it in some other manner?
>> You mean that navigation with arrow keys/Return/ESC should not be
>> hardwired but done with a keybinding?
> 
> Oh no, that would be a total mess, I guess.  No, just the F10 key
> function should be a keybinding pointing to something like
> "accelerate-menu".  Again, if it is already done like this, never
> mind.

The function I added is called menu-bar-start.  x-win.el does
(and (fboundp 'menu-bar-start)
      (global-set-key [f10] 'menu-bar-start))

Should we name it accelerate-menu?  Does the XEmacs function take any
parameters?

	Jan D.

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> David Kastrup skrev:
>> Jan Djärv <jan.h.d@swipnet.se> writes:
>>
>>> David Kastrup skrev:
>>>
>>>> I just took a look across the fence.  In XEmacs, they have
>>>>
>>>>     `accelerate-menu' is an interactive built-in function
>>>>     (accelerate-menu)
>>>>
>>>>     Documentation:
>>>>     Make the menubar active.  Menu items can be selected using menu
>>>>     accelerators or by actions defined in menu-accelerator-map.
>>>>
>>>> It would probably not be the worst idea to do this via a keybinding
>>>> instead of hardwired.  If that is infeasible for some reason or
>>>> already done like this, never mind.  I seem to remember from what I
>>>> saw in the patch that you did it in some other manner?
>>> You mean that navigation with arrow keys/Return/ESC should not be
>>> hardwired but done with a keybinding?
>>
>> Oh no, that would be a total mess, I guess.  No, just the F10 key
>> function should be a keybinding pointing to something like
>> "accelerate-menu".  Again, if it is already done like this, never
>> mind.
>
> The function I added is called menu-bar-start.  x-win.el does
> (and (fboundp 'menu-bar-start)
>      (global-set-key [f10] 'menu-bar-start))

Ok, so I remembered a lot of nonsense.  Don't ask me why.  Sorry for
the confusion.

> Should we name it accelerate-menu?  Does the XEmacs function take
> any parameters?

The XEmacs function does not take any parameters.  But I find its name
ugly: it is probably not something I would hit with an apropos search.
Also it does not fit our menu-bar name space.  For our function, I'd
find `menu-bar-open' a better name: one does not actually `start' a
menu bar.  `menu-bar-activate' would also be a possibility.

It might be worth adding an alias of `accelerate-menu': for those
coming from XEmacs, it will make it easier to transfer their .emacs
and they will also be more likely to find the functionality when using
apropos.

As the main function name, I find `accelerate-menu' too awkward.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Menus (was: Semi-unhelpful error message etc.)

[Johan Bockgård]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Richard Stallman skrev:
>> I think your F10 change will be a big convenience, and since it is
>> so simple, we should install it now. However, implementing
>> accelerators is something else; that should not be done now.
>
> Installed.

What should F10 do when menu-bar-mode is nil? After this change it
does nothing (it used to run tmm-menubar).

-- 
Johan Bockgård

Re: Menus (was: Semi-unhelpful error message etc.)

[Luc Teirlinck]

   What should F10 do when menu-bar-mode is nil? After this change it
   does nothing (it used to run tmm-menubar).

I believe that it should run tmm-menubar in this situation, as it used to do.

Sincerely,

Luc.

Re: Menus

[Jan Djärv]

Luc Teirlinck skrev:
>    What should F10 do when menu-bar-mode is nil? After this change it
>    does nothing (it used to run tmm-menubar).
> 
> I believe that it should run tmm-menubar in this situation, as it used to do.
> 

Another alternative would be to enable menu bar mode and then start navigation.

	Jan D.

Re: Menus

[Romain Francoise]

Also, why keep M-` bound to `tmm-menubar'?  It used to do the same thing
as F10, it should probably stay consistent.

(Or perhaps we should reclaim M-` for something else, it's a very
convenient key binding.)

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Menus

[David Kastrup]

Jan Djärv <jan.h.d@swipnet.se> writes:

> Luc Teirlinck skrev:
>>    What should F10 do when menu-bar-mode is nil? After this change it
>>    does nothing (it used to run tmm-menubar).
>>
>> I believe that it should run tmm-menubar in this situation, as it
>> used to do.
>
> Another alternative would be to enable menu bar mode and then start
> navigation.

At best temporarily: if the user chooses to save the frame real estate
for a menu bar, we should not defeat him.  I don't know how feasible
it is to blend in a menu bar temporarily: Emacs should not recenter or
get confused in case the menu bar shows over the current cursor or
exceeds a window or frame below it.  Also there is the possibility for
an iconized Emacs getting an F10 event (do we cater for that already?
I should CVS update again).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Menus

[David Kastrup]

Romain Francoise <romain@orebokech.com> writes:

> Also, why keep M-` bound to `tmm-menubar'?  It used to do the same thing
> as F10, it should probably stay consistent.
>
> (Or perhaps we should reclaim M-` for something else, it's a very
> convenient key binding.)

It is a pretty awkward binding on most international keyboards.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Semi-unhelpful error message given when trying to (provide 'CUA-mode)

[Jan Djärv]

David Kastrup skrev:

> The XEmacs function does not take any parameters.  But I find its name
> ugly: it is probably not something I would hit with an apropos search.
> Also it does not fit our menu-bar name space.  For our function, I'd
> find `menu-bar-open' a better name: one does not actually `start' a
> menu bar.  `menu-bar-activate' would also be a possibility.
> 

I changed the name to menu-bar-open.

	Jan D.

Re: Menus (was: Semi-unhelpful error message etc.)

[Richard Stallman]

    What should F10 do when menu-bar-mode is nil? After this change it
    does nothing (it used to run tmm-menubar).

I think it should still run tmm-menubar, when menu-bar-mode is nil.
The new function could be changed to do that.

Re: Menus

[Richard Stallman]

    Another alternative would be to enable menu bar mode and then start navigation.

I think changing the window setup is too drastic.