C-M-TAB stand-in for M-TAB, on MS Windows?

C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

M-TAB doesn't work on MS Windows. ESC TAB works in its stead in some contexts,
but not all.

For instance, in isearch, C-s foo ESC TAB does not do what C-s foo M-TAB does,
which is isearch-complete(-edit). Instead, it exits isearch and calls
`complete-symbol'.

Some Windows users change the Meta key to something other than ALT, but that is
an individual solution and preference. It would be good to have a default
binding on Windows that works generally.

C-M-tab is undefined by default, and many (most? nearly all?) users on Windows
will use Emacs with the window manager, so this key is available to them. What
about, on Windows, binding C-M-tab to whatever M-TAB is bound to? To me, this
seems like a good fit. (No reason to unbind M-TAB; it's enough to add C-M-tab.)

If this doesn't sound like something you find appealing, then drop it - I don't
feel like discussing this to death.

[It seems like this would have been discussed already, but I didn't find
anything specifically about it in the archives. There was a 2005 thread ("M-Tab
on w332 (and other window systems?)") about possibly binding C-RET in place of
M-TAB on Windows, but that was rightfully rejected because C-RET is used for
other things.]

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> C-M-tab is undefined by default, and many (most? nearly all?) users on Windows
> will use Emacs with the window manager, so this key is available to them. What
> about, on Windows, binding C-M-tab to whatever M-TAB is bound to?

Seems like a decent idea to me... Why not do it on all systems?

[Besides the benefit of consistency, it would help with other WMs (e.g.,
gnome's) which copy the windows behavior and steal M-TAB from apps.]

-Miles

-- 
Acquaintance, n. A person whom we know well enough to borrow from, but not
well enough to lend to.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
>> C-M-tab is undefined by default, and many (most? nearly all?) users on Windows
>> will use Emacs with the window manager, so this key is available to them. What
>> about, on Windows, binding C-M-tab to whatever M-TAB is bound to?
>
> Seems like a decent idea to me... Why not do it on all systems?
>
> [Besides the benefit of consistency, it would help with other WMs (e.g.,
> gnome's) which copy the windows behavior and steal M-TAB from apps.]

Though I notice that gnome _also_ seems to steal C-M-TAB!

-Miles

-- 
You can hack anything you want, with TECO and DDT.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Miles Bader]

Miles Bader <miles@gnu.org> writes:
> Though I notice that gnome _also_ seems to steal C-M-TAB!

... on my home machine.  On my work machine, it doesn't.  blah.

-Miles

-- 
Friendship, n. A ship big enough to carry two in fair weather, but only one
in foul.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[David De La Harpe Golden]

Miles Bader wrote:
>> [Besides the benefit of consistency, it would help with other WMs (e.g.,
>> gnome's) which copy the windows behavior and steal M-TAB from apps.]
> 
> Though I notice that gnome _also_ seems to steal C-M-TAB!
> 
> -Miles
> 

C-M-TAB is apparently now eaten in vista:
http://kb.adobe.com/selfservice/viewContent.do?externalId=8718ad77

I tend to rebind window manager M-TAB to Super-TAB so that emacs can
have the M-TAB I'm accustomed to it having - FWIW, for gnome/metacity,
if a setting is missing from the GUI, sometimes it's lurking in gnome's
irritating registry^Wgconf, use gconf-editor to adjust values of keys
/apps/metacity/global_keybindings/switch_windows
/apps/metacity/global_keybindings/switch_panels


Usually C-M-i is effectively M-TAB though?
(Since traditionally ^i => TAB)

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Miles Bader]

David De La Harpe Golden <david@harpegolden.net> writes:
> Usually C-M-i is effectively M-TAB though?
> (Since traditionally ^i => TAB)

Hmm, very true.  Since M-TAB is also available via ESC TAB, maybe that's
enough...

-Miles

-- 
It wasn't the Exxon Valdez captain's driving that caused the Alaskan oil spill.
It was yours.  [Greenpeace advertisement, New York Times, 25 February 1990]

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> Usually C-M-i is effectively M-TAB though?
> (Since traditionally ^i => TAB)

That suggestion was in the archives. IMO, it's not very helpful in this context
that TAB is C-i - that provides little more than a pun or mnemonic here.

However, I don't have an answer to the replies concerning C-M-TAB being
unavailable in Gnome or Windows Vista. That's unfortunate.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Miles Bader]

"Drew Adams" <drew.adams@oracle.com> writes:
> That suggestion was in the archives. IMO, it's not very helpful in this context
> that TAB is C-i - that provides little more than a pun or mnemonic here.

ESC TAB might be more useful -- the fact that ESC can be used for meta
is useful generally.

-Miles

-- 
Sabbath, n. A weekly festival having its origin in the fact that God made the
world in six days and was arrested on the seventh.

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> ESC TAB might be more useful -- the fact that ESC can be used for meta
> is useful generally.

Yes, but see my first post - ESC TAB does not work in all contexts (e.g.
isearch). Perhaps it could be made to work everywhere, but currently it does
not.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

Miles Bader wrote:
> "Drew Adams" <drew.adams@oracle.com> writes:
>> That suggestion was in the archives. IMO, it's not very helpful in this context
>> that TAB is C-i - that provides little more than a pun or mnemonic here.
> 
> ESC TAB might be more useful -- the fact that ESC can be used for meta
> is useful generally.

As I pointed out earlier when we discussed this that does not work if 
you use Viper.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> As I pointed out earlier when we discussed this that does not work if 
> you use Viper.

Viper users cannot expect Emacs keybindings to work in general, so this 
is a non-issue.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> As I pointed out earlier when we discussed this that does not work if 
>> you use Viper.
> 
> Viper users cannot expect Emacs keybindings to work in general, so this 
> is a non-issue.

Jason,

This is not about keybindings in general. If both C-Tab and Esc-Tab does 
not work there is no default keybinding at all for completion when you 
are using Viper.

Since this is an important key binding I think it is unfortunate.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Jason Rumney]

Lennart Borgman (gmail) wrote:
> This is not about keybindings in general. If both C-Tab and Esc-Tab 
> does not work there is no default keybinding at all for completion 
> when you are using Viper.

What is C-M-i bound to in viper?

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

Jason Rumney wrote:
> Lennart Borgman (gmail) wrote:
>> This is not about keybindings in general. If both C-Tab and Esc-Tab 
>> does not work there is no default keybinding at all for completion 
>> when you are using Viper.
> 
> What is C-M-i bound to in viper?

You are right, I forgot, that one work.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[David De La Harpe Golden]

Drew Adams wrote:
>> Usually C-M-i is effectively M-TAB though?
>> (Since traditionally ^i => TAB)
> 
> That suggestion was in the archives. IMO, it's not very helpful in this context
> that TAB is C-i - that provides little more than a pun or mnemonic here.

But N.B. at least on X (can't test windoze), C-M-i /currently/ works the
same as "real" M-TAB in isearch etc. (unlike ESC TAB).  What does it do
on windoze?

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> >> Usually C-M-i is effectively M-TAB though?
> >> (Since traditionally ^i => TAB)
> > 
> > That suggestion was in the archives. IMO, it's not very 
> > helpful in this context that TAB is C-i - that provides
> > little more than a pun or mnemonic here.
> 
> But N.B. at least on X (can't test windoze), C-M-i 
> currently works the same as "real" M-TAB in isearch etc.
> (unlike ESC TAB).  What does it do on windoze?

It works on Windows also. Thanks for pointing that out.
I still think it would be good to also bind C-M-tab to this.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[John Paul Wallington]

On 26 May 2008, at 01:12, Drew Adams wrote:

> M-TAB doesn't work on MS Windows. ESC TAB works in its stead in some  
> contexts,
> but not all.

FWIW, on NT derived systems one can use the function `w32-register-hot- 
key' to enable Emacs to see M-TAB (untested on Vista).

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

John Paul Wallington wrote:
> 
> On 26 May 2008, at 01:12, Drew Adams wrote:
> 
>> M-TAB doesn't work on MS Windows. ESC TAB works in its stead in some 
>> contexts,
>> but not all.
> 
> FWIW, on NT derived systems one can use the function 
> `w32-register-hot-key' to enable Emacs to see M-TAB (untested on Vista).

On what version did you test this?

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[John Paul Wallington]

On 26 May 2008, at 17:16, Lennart Borgman (gmail) wrote:

> John Paul Wallington wrote:
>> On 26 May 2008, at 01:12, Drew Adams wrote:
>>> M-TAB doesn't work on MS Windows. ESC TAB works in its stead in  
>>> some contexts,
>>> but not all.
>> FWIW, on NT derived systems one can use the function `w32-register- 
>> hot-key' to enable Emacs to see M-TAB (untested on Vista).
>
> On what version did you test this?

The development version of Emacs during 2004-2007 or so on Windows  
2000 and Windows XP.  Does it not work anymore?  I think I put (w32- 
register-hot-key [A-tab]) in my .emacs file.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

John Paul Wallington wrote:
> On 26 May 2008, at 17:16, Lennart Borgman (gmail) wrote:
> 
>> John Paul Wallington wrote:
>>> On 26 May 2008, at 01:12, Drew Adams wrote:
>>>> M-TAB doesn't work on MS Windows. ESC TAB works in its stead in some 
>>>> contexts,
>>>> but not all.
>>> FWIW, on NT derived systems one can use the function 
>>> `w32-register-hot-key' to enable Emacs to see M-TAB (untested on Vista).
>>
>> On what version did you test this?
> 
> The development version of Emacs during 2004-2007 or so on Windows 2000 
> and Windows XP.  Does it not work anymore?  I think I put 
> (w32-register-hot-key [A-tab]) in my .emacs file.

Yes, it does. I just tested on XP Pro.

I thought that Alt-Tab could not be handled this way. This key sequence 
and those that involve the Windows keys are special.

I just did the w32-register-hotkey thing above and then bound [A-tab] to 
`ignore' but it is not totally ignored. Hm, I say a very strange thing 
that tells me this, but it is unrelated to the key binding - I believe.

You can however handle those key sequences with a low level keyboard hook.

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> >> M-TAB doesn't work on MS Windows. ESC TAB works in its 
> >> stead in some contexts, but not all.
> > 
> > FWIW, on NT derived systems one can use the function 
> > `w32-register-hot-key' to enable Emacs to see M-TAB 
> > (untested on Vista).
> 
> On what version did you test this?

It seems to work on this version:

GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
 of 2008-05-04 on LENNART-69DE564

However, the doc string is not as clear as it could be:

 Register key as a hot-key combination.
 Certain key combinations like Alt-Tab are reserved for system use on
 Windows, and therefore are normally intercepted by the system.  However,
 most of these key combinations can be received by registering them as
 hot-keys, overriding their special meaning.

 key must be a one element key definition in vector form that would be
 acceptable to `define-key' (e.g. [A-tab] for Alt-Tab).  The meta
 modifier is interpreted as Alt if `w32-alt-is-meta' is t, and hyper
 is always interpreted as the Windows modifier keys.

 The return value is the hotkey-id if registered, otherwise nil.

By default, `w32-alt-is-meta' is t. I tried (w32-register-hot-key [A-tab]) on
Windows XP, and it had no effect. However, I then tried (w32-register-hot-key
[M-tab]), and it worked.

I can't tell from the doc string whether registering [A-tab] should have an
effect, in which case there is a bug, or not.

Also, why must KEY be "a one element key definition in vector form"? Just
curious. What is the underlying restriction?

Questions:

1. How to UNregister a hot key, once it's registered?
2. How about registering M-tab by default?
3. How about mentioning w32-register-hot-key in the Emacs manual,
   and indexing it there? This represents an important FAQ.
4. Likewise, for the Elisp manual.
5. Likewise, for NEWS. How are users supposed to know about this?

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> > On what version did you test this?
> 
> It seems to work on this version:
> 
> GNU Emacs 23.0.60.1 (i386-mingw-nt5.1.2600)
>  of 2008-05-04 on LENNART-69DE564

Whoa! This even works (with Windows XP) on Emacs 20!

After decades of using Emacs, including a decade on Windows, I never heard of
this function - learn something new every day. 

This should be documented. 
Perhaps M-tab should be "registered" by default.
There should be an easy way (is there?) to UNregister a hot key.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

> There should be an easy way (is there?) to UNregister a hot key.

w32-unregister-hot-key?

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> > There should be an easy way (is there?) to UNregister a hot key.
> 
> w32-unregister-hot-key?

Thanks (duh). It too needs to be documented.

We document all of the following in the Emacs manual:

 `w32-alt-is-meta' 
 `w32-pass-alt-to-system'
 `w32-capslock-is-shiftlock'
 `w32-enable-caps-lock'
 `w32-enable-num-lock'
 `w32-apps-modifier'
 `w32-lwindow-modifier'
 `w32-rwindow-modifier'
 `w32-scroll-lock-modifier'
 `w32-pass-lwindow-to-system'
 `w32-pass-rwindow-to-system'
 `w32-recognize-altgr'
 `w32-phantom-key-code'
 `w32-get-true-file-attributes'
 `w32-mouse-button-tolerance'
 `w32-pass-extra-mouse-buttons-to-system'
 `w32-swap-mouse-buttons'
 `w32-quote-process-args'
 `w32-shell-execute'
 `w32-charset-info-alist'
 `w32-use-visible-system-caret'
 `w32-grab-focus-on-raise'
 `w32-list-proportional-fonts' 

We should also document `w32-(un)register-hot-key'.
This seems to be a gross oversight.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Mon, 26 May 2008 10:27:03 -0700
> Cc: emacs-devel@gnu.org, 'John Paul Wallington' <jpw@pobox.com>
> 
> We should also document `w32-(un)register-hot-key'.
> This seems to be a gross oversight.

Actually, I deliberately decided not to document it, because it
sounded like an obscure function whose meaning and semantics will not
be clear to most users (you just confirmed that, btw), and whose use
is limited to marginal cases.

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> > We should also document `w32-(un)register-hot-key'.
> > This seems to be a gross oversight.
> 
> Actually, I deliberately decided not to document it, because it
> sounded like an obscure function whose meaning and semantics will not
> be clear to most users (you just confirmed that, btw), and whose use
> is limited to marginal cases.

I didn't confirm that at all - quite the contrary. Just because I didn't know
that Emacs has such a setting does not mean that I didn't wish for it.

And how is this limited to marginal cases? Please elaborate.

There is a fair amount of Internet traffic and Web space devoted to ALT-TAB,
M-TAB, Emacs, and Windows. Some people prefer the Windows ALT-TAB behavior from
within Emacs and some prefer that Emacs see ALT-TAB as M-TAB. There are
discussions both ways, but the topic is at least alive. And there seems to be
general ignorance of `w32-(un)register-hot-key', resulting in diverse hacks to
get the job done or construct workarounds.

What the default Emacs behavior should be might be something to discuss, but I
cannot see why this should not at least be _documented_.

BTW, we say this in the Emacs manual (node Symbol Completion):

 If your window manager defines `M-<TAB>' to switch windows, you can
 type `<ESC> <TAB>' or `C-M-i' instead.  However, most window managers
 let you customize these shortcuts, and we recommend that you change any
 that get in the way of use of Emacs.

That seems to argue in support of giving Emacs, not the Window manager, M-TAB by
default. MS Windows should, by default, not "get in the way of use of Emacs".
And since Emacs provides a way to do this (in Windows, at least), there is no
reason to recommend that users go to the trouble of customizing the
window-manager shortcuts outside Emacs - just fix it in Emacs, by default.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>, <jpw@pobox.com>
> Date: Mon, 26 May 2008 13:07:34 -0700
> 
> > > We should also document `w32-(un)register-hot-key'.
> > > This seems to be a gross oversight.
> > 
> > Actually, I deliberately decided not to document it, because it
> > sounded like an obscure function whose meaning and semantics will not
> > be clear to most users (you just confirmed that, btw), and whose use
> > is limited to marginal cases.
> 
> I didn't confirm that at all

Yes, you did, by not quite understanding what the doc string says.

> And how is this limited to marginal cases? Please elaborate.

I don't want to elaborate; I had enough of this thread already.  Back
when I added many w32-* functions and variables to the manual, I
decided `w32-(un)register-hot-key' don't need to be there.  But if
someone thinks differently and is willing to write a change, I don't
intend to fight them.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

> 2. How about registering M-tab by default?

I know some people would hate it. ;-)

> 3. How about mentioning w32-register-hot-key in the Emacs manual,
>    and indexing it there? This represents an important FAQ.

Maybe because it does not work that good with the Windows keys? And it 
does not work totally transparent with Alt either.

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> > 2. How about registering M-tab by default?
> 
> I know some people would hate it. ;-)

Some? I suspect that most would appreciate it, but I might be wrong.

If it's a toss-up, then shouldn't Emacs emphasize Emacs, not Windows? As long as
there is a way for users to put Windows back in control, what's the harm in
giving Emacs the control by default?

> > 3. How about mentioning w32-register-hot-key in the Emacs manual,
> >    and indexing it there? This represents an important FAQ.
> 
> Maybe because it does not work that good with the Windows keys?

What does that mean? Do you mean the Windows key? Please elaborate.

And why would that mean that it shouldn't be documented?

> And it does not work totally transparent with Alt either.

What does that mean? Please elaborate.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>> 2. How about registering M-tab by default?
>> I know some people would hate it. ;-)
> 
> Some? I suspect that most would appreciate it, but I might be wrong.
> 
> If it's a toss-up, then shouldn't Emacs emphasize Emacs, not Windows? As long as
> there is a way for users to put Windows back in control, what's the harm in
> giving Emacs the control by default?

As you know we have been through this many times before. My gut feeling 
is that most users prefer consistency over very smart key sequences. Of 
course I do not mean long time Emacs users then, but potentially new users.

>>> 3. How about mentioning w32-register-hot-key in the Emacs manual,
>>>    and indexing it there? This represents an important FAQ.
>> Maybe because it does not work that good with the Windows keys?
> 
> What does that mean? Do you mean the Windows key? Please elaborate.

MS documents Alt-Tab and the windows keys as special. Don't ask me for 
any links now, but I believe I have given such links earlier (not quite 
sure).

To alter those keys you have to use a low level keyboard hook. Such 
beasts are app specific and where invented as a reaction to the critics 
raised against earlier mechanisms for keyboard control on w32. (At least 
that was how I understands it.)

> And why would that mean that it shouldn't be documented?

Because it does not work consistently without the low level keyboard hook.

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> >>> 2. How about registering M-tab by default?
> >> I know some people would hate it. ;-)
> > 
> > Some? I suspect that most would appreciate it, but I might be wrong.
> > 
> > If it's a toss-up, then shouldn't Emacs emphasize Emacs, 
> > not Windows? As long as there is a way for users to put
> > Windows back in control, what's the harm in
> > giving Emacs the control by default?
> 
> As you know we have been through this many times before. My 
> gut feeling is that most users prefer consistency over very
> smart key sequences. Of course I do not mean long time Emacs
> users then, but potentially new users.

Who's to say whose gut feeling is accurate?

Whoever polls Emacs users could do so - that could help. And there is no need to
exclude either newbies or oldies. It is a general question for all Emacs users
on Windows: Do you prefer that M-TAB within Emacs be handled by Emacs or by
Windows (as ALT-TAB)?

> >>> 3. How about mentioning w32-register-hot-key in the Emacs manual,
> >>>    and indexing it there? This represents an important FAQ.
> >> Maybe because it does not work that good with the Windows keys?
> > 
> > What does that mean? Do you mean the Windows key? Please elaborate.
> 
> MS documents Alt-Tab and the windows keys as special. Don't 
> ask me for any links now, but I believe I have given such links
> earlier (not quite sure).
> 
> To alter those keys you have to use a low level keyboard hook. Such 
> beasts are app specific and where invented as a reaction to 
> the critics raised against earlier mechanisms for keyboard control
> on w32. (At least that was how I understands it.)

I have no idea what you're talking about. This is about _documenting_
`w32-register-hot-key'. Please don't turn it into something else. Whatever you
mean by "special" and "alter those keys", it doesn't seem to be about
documenting `w32-register-hot-key'.

The question is not what MS documents but what Emacs should document. It is not
about what Windows should do by default but what Emacs should do by default.
It's about Emacs users on Windows. No one is proposing changing the behavior of
Windows outside Emacs.

> > And why would that mean that it shouldn't be documented?
> 
> Because it does not work consistently without the low level 
> keyboard hook.

What does not work consistently, without what low-level keyboard hook?

AFAICT, `w32-register-hot-key' works quite consistently and without jumping
through any hoops. I have the feeling you are trying to change this discussion
to something other than a question about `w32-register-hot-key'. But I admit
that I'm having trouble following.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

Drew Adams wrote:
> Who's to say whose gut feeling is accurate?

I am to say my gut feeling is accurate, you are to say your gut feeling 
is accurate ;-)


> Whoever polls Emacs users could do so - that could help.

In a question like this I do not think it will help that much. We will 
simply not reach those potential new users that we really would like to 
reach.


>> To alter those keys you have to use a low level keyboard hook. Such 
>> beasts are app specific and where invented as a reaction to 
>> the critics raised against earlier mechanisms for keyboard control
>> on w32. (At least that was how I understands it.)
> 
> I have no idea what you're talking about. This is about _documenting_
> `w32-register-hot-key'. Please don't turn it into something else. Whatever you
> mean by "special" and "alter those keys", it doesn't seem to be about
> documenting `w32-register-hot-key'.

I tried to say that the documentation of w32-register-hot-key should 
take the technical things I referred to into account in some way.


> No one is proposing changing the behavior of
> Windows outside Emacs.

It is not that simple to divide those things. If you change Alt-Tab in 
Emacs would you not in a way change Windows too then?


> What does not work consistently, without what low-level keyboard hook?

Alt-tab and the windows keys may in some circumstances still be sent to 
Windows without the low-level keyboard hook. (MS has not documented when 
this happen. It is just that the recommended way is to use a low level 
keyboard hook.)

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> > Whoever polls Emacs users could do so - that could help.
> 
> In a question like this I do not think it will help that 
> much. We will simply not reach those potential new users
> that we really would like to reach.

If you can't reach them, then don't worry about them. If no one can justifiably
speak for them, and no one can measure them, then we must ignore them. No sense
polling or speaking for the supernatural.

If and when they become reachable, we can ask them. Easier: let Emacs use its
own default behavior by default, and see how many complain.

I don't see why Emacs wouldn't provide its own default behavior by default. As
long as users can override it, where is the harm?

> I tried to say that the documentation of w32-register-hot-key should 
> take the technical things I referred to into account in some way.

I don't know what those "technical things" are or why the Emacs doc should take
them into account. Why make this so complicated? It's just about letting users
choose Windows ALT-TAB within Emacs or Emacs M-TAB within Emacs.

You "referred" to nebulous stuff without actually referencing it, and that stuff
seems to be irrelevant here anyway (but, not knowing what it is, I can't be
sure). The table in front of me seems to be shaking, but I can't discern which
spirits are behind it.

> > No one is proposing changing the behavior of
> > Windows outside Emacs.
> 
> It is not that simple to divide those things. If you change 
> Alt-Tab in Emacs would you not in a way change Windows too then?

Not outside Emacs. AFAIK, w32-register-hot-key has no effect outside of Emacs.
Are you suggesting the contrary?

When I try it, ALT-TAB still does its Windows thing outside Emacs, even with
Emacs still running. I really don't see the problem you hint at.

> > What does not work consistently, without what low-level 
> > keyboard hook?
> 
> Alt-tab and the windows keys may in some circumstances still 
> be sent to Windows without the low-level keyboard hook.

So are you saying that w32-register-hot-key does not work in some cases? Can you
give an example?

> (MS has not documented when this happen. It is just that the
> recommended way is to use a low level keyboard hook.)

Recommended way to do what? To have Emacs recognize ALT-TAB as M-TAB? Why care
what MS recommends about that?

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Lennart Borgman (gmail)]

Drew Adams wrote:
>>> Whoever polls Emacs users could do so - that could help.
>> In a question like this I do not think it will help that 
>> much. We will simply not reach those potential new users
>> that we really would like to reach.
> 
> If you can't reach them, then don't worry about them. If no one can justifiably
> speak for them, and no one can measure them, then we must ignore them. No sense
> polling or speaking for the supernatural.

If you want reliable results you can't ignore them.

>> I tried to say that the documentation of w32-register-hot-key should 
>> take the technical things I referred to into account in some way.
> 
> I don't know what those "technical things" are or why the Emacs doc should take
> them into account. Why make this so complicated? It's just about letting users
> choose Windows ALT-TAB within Emacs or Emacs M-TAB within Emacs.

I am trying to say that there might be technical limitations (but I am 
unsure which these are).

> So are you saying that w32-register-hot-key does not work in some cases? Can you
> give an example?

It is rather complicated I believe. When you do things that you are not 
supposed to do the window manager/OS might get upset.

When I registered Alt-Tab I could see things happening with the menus 
that I never seen before. One of the menus in Emacs where jumping a bit 
upwards and it became bold. Like if it had recieved most of the Alt key 
but not all.

>> (MS has not documented when this happen. It is just that the
>> recommended way is to use a low level keyboard hook.)
> 
> Recommended way to do what? To have Emacs recognize ALT-TAB as M-TAB? Why care
> what MS recommends about that?

To get things working.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Stefan Monnier]

Can we stop this useless thread?  We're not going to activate this thing
by default, this is a final decision.


        Stefan

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> Can we stop this useless thread?  We're not going to activate 
> this thing by default, this is a final decision.

It's not important to "activate this thing by default"
(by which I assume you mean (w32-register-hot-key [M-tab])).

What is important is to  _document_  it.
What were the objections raised to that?

* Eli decided not to document it "because it sounded like an obscure function
whose meaning and semantics will not be clear to most users".

* Lennart said "there might be technical limitations (but I am unsure which
these are)."

Dunno what "it sounded like" means, but the name can be changed, if that's a
problem. And the meaning can be made clear. If no one can specify any "technical
limitations", then their mere supposition should not block documentation. If
some limitations are known, then they can be documented.

IOW, whether `w32-register-hot-key' is 100% reliable and 100% easy to understand
for all cases has been questioned only vaguely, with no explanation.

What is important is that it works for `M-TAB', at least, and that is a use case
that is easy to understand and important to communicate to Windows users. Give
users the information and let them choose - no concrete reason has been given to
keep them in the dark. 

If you feel you need to add a disclaimer that `w32-register-hot-key' might not
work for some key sequences and its semantics might not be clear in all cases to
all users, go right ahead. But at least let users know that they can use it to
recuperate M-TAB for Emacs.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Stefan Monnier]

>> Can we stop this useless thread?  We're not going to activate 
>> this thing by default, this is a final decision.

> It's not important to "activate this thing by default"
> (by which I assume you mean (w32-register-hot-key [M-tab])).

> What is important is to  _document_  it.
> What were the objections raised to that?

None.  So go ahead, submit a patch.


        Stefan

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

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

> > It's not important to "activate this thing by default"
> > (by which I assume you mean (w32-register-hot-key [M-tab])).
> 
> > What is important is to  _document_  it.
> > What were the objections raised to that?
> 
> None.  So go ahead, submit a patch.

Attached. I'm no texi expert, so someone please check it.

[-- Attachment #2: msdog-texi-2008-05-27.patch --]
[-- Type: application/octet-stream, Size: 1541 bytes --]

diff -u -w msdog-2008-05-27.texi msdog-patched-2008-05-27.texi
--- msdog-2008-05-27.texi	2008-05-27 08:25:12.000000000 -0700
+++ msdog-patched-2008-05-27.texi	2008-05-27 09:07:40.000000000 -0700
@@ -403,6 +403,25 @@
 key.  If you wish it to produce the @code{Alt} modifier instead, set
 the variable @code{w32-alt-is-meta} to a @code{nil} value.
 
+@vindex w32-register-hot-key
+@vindex w32-unregister-hot-key
+  Although the @key{ALT} key is mapped by default to the Emacs
+@key{META} key, MS Windows preempts its use by Emacs for certain key
+combinations, such as @key{ALT-TAB}.  You can use function
+@code{w32-register-hot-key} to allow a key sequence to be seen by
+Emacs instead of being grabbed by Windows.
+
+@kindex M-TAB @r{(MS-Windows)}
+@cindex @code{M-TAB} vs @code{Alt-TAB} (MS-Windows)
+@cindex @code{Alt-TAB} vs @code{M-TAB} (MS-Windows)
+  For example, @code{(w32-register-hot-key [M-tab])} lets you use
+@kbd{M-TAB} normally in Emacs. This is effective at all levels, so,
+for instance, you can use @kbd{M-TAB} at top level to complete the
+word or symbol at point, and you can use it during incremental search
+to complete the current search string against previously sought
+strings.  The function @code{w32-unregister-hot-key} reverses the
+effect of @code{w32-register-hot-key}.
+
 @vindex w32-capslock-is-shiftlock
   By default, the @key{CapsLock} key only affects normal character
 keys (it converts lower-case characters to their upper-case

Diff finished.  Tue May 27 09:08:12 2008

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Date: Tue, 27 May 2008 09:09:53 -0700
> Cc: emacs-devel@gnu.org
> 
> > > It's not important to "activate this thing by default"
> > > (by which I assume you mean (w32-register-hot-key [M-tab])).
> > 
> > > What is important is to  _document_  it.
> > > What were the objections raised to that?
> > 
> > None.  So go ahead, submit a patch.
> 
> Attached. I'm no texi expert, so someone please check it.

Thanks.

I have a problem with this description: it doesn't really explain what
can and what can't be an argument to these functions, and whether
there's any significance to the term "hot-key" that is part of the
functions' names.  An example helps, but a single example is not
enough to overcome the difficulty of a total lack of description of
the argument, and also of what the function actually does.  Come to
think about it, the suggested text explains even less than the doc
string does, which to me doesn't make sense (it should be the other
way around).

A few minor comments about the patch:

> --- msdog-2008-05-27.texi	2008-05-27 08:25:12.000000000 -0700
> +++ msdog-patched-2008-05-27.texi	2008-05-27 09:07:40.000000000 -0700

Please have at least one of the two file names be the original file
name (in this case, msdog.texi).  Otherwise, the Patch utility will
not be able to deduce the file to patch automatically, and will prompt
whoever is applying to patch the manual, which is an annoyance.

> +@vindex w32-register-hot-key
> +@vindex w32-unregister-hot-key

These should be @findex; @vindex is for variables/options.

> +  Although the @key{ALT} key is mapped by default to the Emacs
> +@key{META} key, MS Windows preempts its use by Emacs for certain key
> +combinations, such as @key{ALT-TAB}.  You can use function
> +@code{w32-register-hot-key} to allow a key sequence to be seen by
> +Emacs instead of being grabbed by Windows.
> +
> +@kindex M-TAB @r{(MS-Windows)}
> +@cindex @code{M-TAB} vs @code{Alt-TAB} (MS-Windows)

You should use @kbd{M-@key{TAB}} and @kbd{Alt-@key{TAB}}, not
@key{ALT-TAB} or @code{M-TAB}.

> +@cindex @code{Alt-TAB} vs @code{M-TAB} (MS-Windows)
> +  For example, @code{(w32-register-hot-key [M-tab])} lets you use
> +@kbd{M-TAB} normally in Emacs. This is effective at all levels, so,
                                ^^
Two spaces after a period that ends a sentence, please.

Finally, please include a ChangeLog entry with your patch.

Thanks again.

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

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

> I have a problem with this description: it doesn't really explain what
> can and what can't be an argument to these functions, and whether
> there's any significance to the term "hot-key" that is part of the
> functions' names.  An example helps, but a single example is not
> enough to overcome the difficulty of a total lack of description of
> the argument, and also of what the function actually does.  Come to
> think about it, the suggested text explains even less than the doc
> string does, which to me doesn't make sense (it should be the other
> way around).
> 
> > +@vindex w32-register-hot-key
> > +@vindex w32-unregister-hot-key
> 
> These should be @findex; @vindex is for variables/options.
> 
> > +  Although the @key{ALT} key is mapped by default to the Emacs
> > +@key{META} key, MS Windows preempts its use by Emacs for certain key
> > +combinations, such as @key{ALT-TAB}.  You can use function
> > +@code{w32-register-hot-key} to allow a key sequence to be seen by
> > +Emacs instead of being grabbed by Windows.
> > +
> > +@kindex M-TAB @r{(MS-Windows)}
> > +@cindex @code{M-TAB} vs @code{Alt-TAB} (MS-Windows)
> 
> You should use @kbd{M-@key{TAB}} and @kbd{Alt-@key{TAB}}, not
> @key{ALT-TAB} or @code{M-TAB}.
> 
> > +@cindex @code{Alt-TAB} vs @code{M-TAB} (MS-Windows)
> > +  For example, @code{(w32-register-hot-key [M-tab])} lets you use
> > +@kbd{M-TAB} normally in Emacs. This is effective at all levels, so,
>                                 ^^
> Two spaces after a period that ends a sentence, please.
> 
> Finally, please include a ChangeLog entry with your patch.

Thanks for the corrections.

Attached is a new patch. My knowledge of this is limited to what the doc string
says, so I've reproduced that. Feel free to make any more additions or
corrections. In particular, feel free to explain what a Windows hot key and
hotkey-id are.

It is important to at least let users know that they can recuperate M-TAB. But I
certainly agree that it would be good to have a complete and accurate
description of what these functions do. If you can provide that information,
please do submit a better patch.

BTW, it looks to me like there might be similar syntax errors to those I made
(e.g. @code{Alt} in @cindex), throughout this file - you might want to check the
syntax generally.

HTH.

2008-05-27 Drew Adams  <drew.adams@oracle.com>
	* msdog.text:
	Added descriptions of w32-register-hot-key and w32-unregister-hot-key.

[-- Attachment #2: msdog-texi-2008-05-27b.patch --]
[-- Type: application/octet-stream, Size: 1988 bytes --]

diff -u -w "msdog.texi" "msdog-patched-2008-05-27b.texi"
--- msdog.texi	2008-05-27 12:49:58.000000000 -0700
+++ msdog-patched-2008-05-27b.texi	2008-05-27 12:55:04.000000000 -0700
@@ -403,6 +403,33 @@
 key.  If you wish it to produce the @code{Alt} modifier instead, set
 the variable @code{w32-alt-is-meta} to a @code{nil} value.
 
+@findex w32-register-hot-key
+@findex w32-unregister-hot-key
+  Although the @key{ALT} key is mapped by default to the Emacs
+@key{META} key, MS Windows preempts its use by Emacs for certain key
+combinations, such as @kbd{Alt-@key{TAB}}.  You can use function
+@code{w32-register-hot-key} to allow a key sequence to be seen by Emacs
+instead of being grabbed by Windows.  This registers the key sequence as
+a Windows hot key.
+
+  The argument to @code{w32-register-hot-key} must be a one element key
+definition in vector form that would be acceptable to `define-key'.  The
+@code{meta} modifier is interpreted as @key{ALT} if `w32-alt-is-meta' is
+@code{t}, and @code{hyper} is always interpreted as the Windows modifier
+keys.  The return value is the hotkey-id if registered, otherwise
+@code{nil}.
+
+@kindex M-TAB @r{(MS-Windows)}
+@cindex @kbd{M-@key{TAB}} vs @kbd{Alt-@key{TAB}} (MS-Windows)
+@cindex @kbd{Alt-@key{TAB}} vs @kbd{M-@key{TAB}} (MS-Windows)
+  For example, @code{(w32-register-hot-key [M-tab])} lets you use
+@kbd{M-TAB} normally in Emacs.  This is effective at all levels, so, for
+instance, you can use @kbd{M-TAB} at top level to complete the word or
+symbol at point, and you can use it during incremental search to
+complete the current search string against previously sought strings.
+The function @code{w32-unregister-hot-key} reverses the effect of
+@code{w32-register-hot-key}.
+
 @vindex w32-capslock-is-shiftlock
   By default, the @key{CapsLock} key only affects normal character
 keys (it converts lower-case characters to their upper-case

Diff finished at Tue May 27 12:59:36

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Stephen J. Turnbull]

Drew Adams writes:
 > 2008-05-27 Drew Adams  <drew.adams@oracle.com>
 > 	* msdog.text:
 > 	Added descriptions of w32-register-hot-key and w32-unregister-hot-key.

should be "msdog.texi", no?

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

>  > 2008-05-27 Drew Adams  <drew.adams@oracle.com>
>  > 	* msdog.text:
>  > 	Added descriptions of w32-register-hot-key and 
> w32-unregister-hot-key.
> 
> should be "msdog.texi", no?

Correct.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Stefan Monnier]

Can someone install this patch?


        Stefan


>>>>> "Drew" == Drew Adams <drew.adams@oracle.com> writes:

>> I have a problem with this description: it doesn't really explain what
>> can and what can't be an argument to these functions, and whether
>> there's any significance to the term "hot-key" that is part of the
>> functions' names.  An example helps, but a single example is not
>> enough to overcome the difficulty of a total lack of description of
>> the argument, and also of what the function actually does.  Come to
>> think about it, the suggested text explains even less than the doc
>> string does, which to me doesn't make sense (it should be the other
>> way around).
>> 
>> > +@vindex w32-register-hot-key
>> > +@vindex w32-unregister-hot-key
>> 
>> These should be @findex; @vindex is for variables/options.
>> 
>> > +  Although the @key{ALT} key is mapped by default to the Emacs
>> > +@key{META} key, MS Windows preempts its use by Emacs for certain key
>> > +combinations, such as @key{ALT-TAB}.  You can use function
>> > +@code{w32-register-hot-key} to allow a key sequence to be seen by
>> > +Emacs instead of being grabbed by Windows.
>> > +
>> > +@kindex M-TAB @r{(MS-Windows)}
>> > +@cindex @code{M-TAB} vs @code{Alt-TAB} (MS-Windows)
>> 
>> You should use @kbd{M-@key{TAB}} and @kbd{Alt-@key{TAB}}, not
>> @key{ALT-TAB} or @code{M-TAB}.
>> 
>> > +@cindex @code{Alt-TAB} vs @code{M-TAB} (MS-Windows)
>> > +  For example, @code{(w32-register-hot-key [M-tab])} lets you use
>> > +@kbd{M-TAB} normally in Emacs. This is effective at all levels, so,
>> ^^
>> Two spaces after a period that ends a sentence, please.
>> 
>> Finally, please include a ChangeLog entry with your patch.

> Thanks for the corrections.

> Attached is a new patch. My knowledge of this is limited to what the doc string
> says, so I've reproduced that. Feel free to make any more additions or
> corrections. In particular, feel free to explain what a Windows hot key and
> hotkey-id are.

> It is important to at least let users know that they can recuperate M-TAB. But I
> certainly agree that it would be good to have a complete and accurate
> description of what these functions do. If you can provide that information,
> please do submit a better patch.

> BTW, it looks to me like there might be similar syntax errors to those I made
> (e.g. @code{Alt} in @cindex), throughout this file - you might want to check the
> syntax generally.

> HTH.

> 2008-05-27 Drew Adams  <drew.adams@oracle.com>
> 	* msdog.text:
> 	Added descriptions of w32-register-hot-key and w32-unregister-hot-key.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Juanma Barranquero]

> Can someone install this patch?

Done.

   Juanma

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Stefan Monnier]

>> Can someone install this patch?
> Done.

Thank you,


        Stefan

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <emacs-devel@gnu.org>
> Date: Tue, 27 May 2008 13:09:10 -0700
> 
> My knowledge of this is limited to what the doc string
> says, so I've reproduced that.

Well, there's MS docs on MSDN where you can read about this.

> Feel free to make any more additions or corrections. In particular,
> feel free to explain what a Windows hot key and hotkey-id are.

Done.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Paul R]

"Drew Adams" <drew.adams@oracle.com> writes:

> If you can't reach them, then don't worry about them. If no one can justifiably
> speak for them, and no one can measure them, then we must ignore them. No sense
> polling or speaking for the supernatural.

This is all about changing defaults. Most software use defaults to
provide an "easy-to-start-with" configuration. A software hijacking
system-wide hotkeys is not easy to start with, IMO.

> If and when they become reachable, we can ask them. Easier: let Emacs use its
> own default behavior by default, and see how many complain.

This is not the way it works. New users don't spend time complaining
on a mailing list they don't read. They just jump to the next, "easier
to start with", good looking editor.

> I don't see why Emacs wouldn't provide its own default behavior by default. As
> long as users can override it, where is the harm?

Because this setting has system-wide effect in a way. If Joe is trying
emacs, and seeing its messenger software ringing, he can't use Alt-Tab
as he always did before.

-- 
      Paul

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Richard M Stallman]

    As you know we have been through this many times before. My gut feeling 
    is that most users prefer consistency over very smart key sequences. Of 
    course I do not mean long time Emacs users then, but potentially new users.

Whatever the decision, I suggest installing a comment referring to
this thread.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[John Paul Wallington]

On 26 May 2008, at 17:38, Drew Adams wrote:

> Questions:
>
> 1. How to UNregister a hot key, once it's registered?

There's a `w32-unregister-hot-key' function too.

> 2. How about registering M-tab by default?

I suspect that would be too distressing for newbies who want to use  
the Windows Alt-Tab CoolSwitch facility unfettered.

> 3. How about mentioning w32-register-hot-key in the Emacs manual,
>   and indexing it there? This represents an important FAQ.
> 4. Likewise, for the Elisp manual.
> 5. Likewise, for NEWS. How are users supposed to know about this?

Yeah, it should probably be documented somewhere.

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> > 2. How about registering M-tab by default?
> 
> I suspect that would be too distressing for newbies who want to use  
> the Windows Alt-Tab CoolSwitch facility unfettered.

Better to fetter Windows by default than Emacs. IMO.

One app's fetter is another app's free.
Oh, did I just call Windows an app?

> > 3. How about mentioning w32-register-hot-key in the Emacs manual,
> >    and indexing it there? This represents an important FAQ.
> > 4. Likewise, for the Elisp manual.
> > 5. Likewise, for NEWS. How are users supposed to know about this?
> 
> Yeah, it should probably be documented somewhere.

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Stefan Monnier]

> Better to fetter Windows by default than Emacs. IMO.

> One app's fetter is another app's free.
> Oh, did I just call Windows an app?

The problem is that it overrides a Windows-global setting in
a non-consistent way.  If you like it, by all means use it, but as
a default I think it'd be a mistake.


        Stefan

Re: C-M-TAB stand-in for M-TAB, on MS Windows?

[Jason Rumney]

Stefan Monnier wrote:
> The problem is that it overrides a Windows-global setting in
> a non-consistent way.  If you like it, by all means use it, but as
> a default I think it'd be a mistake.
>   

Also, in Emacs one can use C-M-i and in most contexts ESC tab, as an 
alternative to M-tab. Windows does not have any keyboard alternative to 
Alt-tab.

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> Also, in Emacs one can use C-M-i and in most contexts ESC tab, as an 
> alternative to M-tab. Windows does not have any keyboard 
> alternative to Alt-tab.

Why does Windows need an alternative? If you prefer that Windows grab ALT-TAB
from Emacs, then you can set that as your preference - no problem. 

The question is about the default Emacs behavior, that is, the default behavior
of M-TAB within Emacs.

And the higher priority question is about _documenting_ the ability to configure
this using `w32-(un)register-hot-key'.
 

RE: C-M-TAB stand-in for M-TAB, on MS Windows?

[Drew Adams]

> > Better to fetter Windows by default than Emacs. IMO.
> >
> > One app's fetter is another app's free.
> > Oh, did I just call Windows an app?
> 
> The problem is that it overrides a Windows-global setting in
> a non-consistent way.  If you like it, by all means use it, but as
> a default I think it'd be a mistake.

How so "non-consistent"? `w32-register-hot-key' seems to act quite consistently,
affecting its KEY argument everywhere, at all levels. Is that not the case?

Besides, the Emacs manual explicitly recommends to users that they "change any"
Windows shortcuts "that get in the way of use of Emacs" - see node Symbol
Completion.

If that's what we recommend, then why don't we do it for them, as the default
behavior? Why don't we practice what we preach to users? And any user who wants
to go against that recommendation/default could still do so.