emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bikeshedding go! Why is <M-f4> unbound?


From: Stuart Hacking
Subject: Re: Bikeshedding go! Why is <M-f4> unbound?
Date: Wed, 19 Jan 2011 10:08:09 +0000

2011/1/18 Drew Adams <address@hidden>:
>> >>>     (global-set-key [M-f4] 'w32-syskey)
>
> This is what I suggested - it's the Emacs way of defining keys. ;-)
> But since no one had discussed it here in terms of implementation I guessed it
> was not feasible as an approach.

The problem I see with this approach is that Emacs chooses the
binding. If a user has gone to the effort of changing the windows
bindings (however small this percentage of users is) then Emacs will
no longer play nice in their expectations. Although, if a user, say,
makes [Alt-x] the command to exit an application I guess Emacs will
stick with it's own behaviour.

If I follow the main discussion correctly, what Emacs should be doing is:

1)  Got a keystroke.
2)  Is this keystroke bound, or explicitly unbound?
3a) Yes: Do bound action
3b) No: Delegate to system key handler (however that may be implemented).

AFAICS Doing this way means that we tap into a lot of the window
manager behaviour for free without having to manually define the
keystrokes.

>> >> If we go that route why not just bind M-f4 to a function
>> >> that closes the current frame, as suggested at the beginning
>> >> of this thread?
>> > Because you want to support menu accelerators [Alt-<letter>] ?
>
> I assume that `w32-syskey' here is a placeholder for pass-through to Windows.
> Which means that Windows does what it wants with M-f4 (Alt-f4 might be better
> here? dunno).

This still makes the assumption that the user is using the default
keybindings. If they have changed them in their environment then
Emacs' behaviour will be surprising?

> Yes, that is a good thing.  We should pass M-f4 through only if the key 
> sequence
> is M-f4, not if it is C-h k M-f4 or C-x M-f4 etc.

The behaviour in Windows would normally be that [Alt-F4] interrupts
whatever operation is in progress and exits. Is it feasible to have a
sequence that interrupts the current command input like [C-g] and what
if we don't know what this key is in advance?

--Stuart



reply via email to

[Prev in Thread] Current Thread [Next in Thread]