[Top][All Lists]

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

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

From: Lennart Borgman
Subject: Re: Bikeshedding go! Why is <M-f4> unbound?
Date: Fri, 14 Jan 2011 21:27:38 +0100

On Fri, Jan 14, 2011 at 6:58 PM, Drew Adams <address@hidden> wrote:
>> I don't think the argument that "if we bind <M-f4> to this function
>> now, we won't be able to bind it to something else later" holds up
>> for this key combination.
> AFAICT no one has argued that.  Certainly not I.
> I mainly _asked_ what our reasons are for binding it.  (And the reasons given
> have varied, BTW.)  AFAICT, we have not concluded _why_ we should do it, even 
> if
> some people are definitely in favor of doing it.
> If we do this kind of thing it is good to know why, especially because we will
> no doubt be having this same conversation again someday about some other 
> outside
> hotkey.
> To the extent that I do argue against Emacs binding this key by default
> (actually, I don't feel super strongly about it, it's just that the reasons in
> favor have so far been so weak), my arguments are these:
> 1. Alt-f4 (or `M-f4') is an _easily repeatable chord_.  Unlike `C-x 5 0' or 
> `C-x
> C-c', you can repeat it by just holding it down.  Such keys are valuable - for
> use in Emacs.  By users.  By Emacs libraries.  Finding such keys that are not
> already bound or reserved or in some other way "taken" is getting harder.
> I do not like for Emacs to gratuitously "waste" keys.  And this particular 
> waste
> seems pretty darn gratuitous to me, which is why I asked for the reasons 
> behind
> it.
> 2. Giving a default binding to this key will (yes, it seems to) discourage 
> other
> uses of it in Emacs.  Over time, default bindings sometimes become sacrosanct.

As I have already said (but you might have missed) Emacs does bind
Alt+F4 by default now (but does not use it). Aren't you from that
perspective actually kind of defending that binding?

reply via email to

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