[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
RE: Bikeshedding "user choice"
From: |
Drew Adams |
Subject: |
RE: Bikeshedding "user choice" |
Date: |
Tue, 18 Jan 2011 09:45:38 -0800 |
> > > In general, if Emacs...hasn't bound the key, fall back
> > > to OS if available seems like a good idea (POLA).
> >
> > Show a `... is unbound' message is also a good idea.
> > That's the standard behavior in Emacs (POLA).
>
> Of course it is NOT the standard behavior in Emacs! ALL normal keys
> are normally bound, ALL control characters are normally bound, MOST
> meta characters are normally bound. The STANDARD BEHAVIOR of Emacs is
> "All Keys Yours Now Emacs Keys Are" and they do something! Arguing
> from "standard behavior" of Emacs suggests that we bind this key now!
Calm down, please; no need to shout. It should have been clear from the
previous sentence (and the entire context) that I was saying that this is the
standard behavior in Emacs _for an unbound key_. Which it is.
> But get real; Emacs is not about avoiding binding key sequences.
> Emacs is about binding everything in sight.
Not necessarily by default. We do not bind keys by default simply because they
are not yet bound.
> Heck, even the standard argument for not binding
> a key sequence is "it might turn out to be useful and then people
> would object to us binding it to something else in the future"!
Yes. M-f4, for instance. ;-)
> I only care what the default is.
Then why all the energetic venom here? You are not arguing here about the
default behavior of M-f4 or responding to a post about that. Why not reserve
your comments for discussion of the default, if that's all you care about?
> > I would prefer that approach to a `w32-passthrough-events'
> > option, as I mentioned. For one thing, `C-h M-f4' etc. would
> > tell you what the key does (at least that it is passed to the OS).
>
> I would not consider this feature complete if C-h M-F4 didn't do that
> no matter how pass-through is implemented.
(I (and I guess you too) meant `C-h k M-f4' (forgot the `k').)
So I guess we agree about this, at least. But I think that some have indicated
they would prefer that M-f4 (or Alt-f4) be sent to Windows regardless of whether
it is preceded by a prefix key, IOW whenever that key is hit.
> > I don't have a goal wrt the default behavior. I've been clear
> > about that. I am fine with either default behavior for the key.
> > I have my own preference, but I don't feel strongly about it.
>
> Not really, because you keep arguing implementation
No, I have not mentioned implementation. I know nothing about how pass-through
and the rest of the machinery would or should be implemented. I've discussed
only the user level.
> with people who only care about the default behavior, and don't care about
> implementation. But you keep claiming that various implementation
> strategies would result in bad behavior (though not necessarily of the
> key itself, eg, what would C-h k do).
Again, I have not discussed implementation strategies, though perhaps I don't
know what you mean by that. Certainly I've been absent from the subthreads
concerning C-code implementation.
About the only things I've said that might touch on "implementation" were:
1. I'm OK with Stefan's proposal of option `w32-passthrough-events'.
2. If it is feasible to just bind M-f4 to an Emacs command that signifies
pass-through (i.e., that passes the key sequence to Windows), then I would
prefer that to `w32-passthrough-events'.
My point of view here is only at the user level; I have nothing to say about how
either approach (or any other) might be implemented.
And I have discussed the default behavior of M-f4 very little. I've said what
my preference is (leave it unbound) and stated clearly that I don't feel
strongly about the default behavior.
Clear enough now? I have no strong feelings about the default. Make M-f4 do
_anything you want_ by default. My posts have generally been about what happens
when M-f4 is not bound and how users see and interact with this binding or lack
of binding.
- RE: Bikeshedding go! Why is <M-f4> unbound?, (continued)
- RE: Bikeshedding go! Why is <M-f4> unbound?, Drew Adams, 2011/01/16
- RE: Bikeshedding go! Why is <M-f4> unbound?, Drew Adams, 2011/01/16
- Re: Bikeshedding go! Why is <M-f4> unbound?, Lennart Borgman, 2011/01/17
- RE: Bikeshedding go! Why is <M-f4> unbound?, Drew Adams, 2011/01/17
- Re: Bikeshedding go! Why is <M-f4> unbound?, Lennart Borgman, 2011/01/17
- RE: Bikeshedding go! Why is <M-f4> unbound?, Drew Adams, 2011/01/17
- Re: Bikeshedding go! Why is <M-f4> unbound?, Lennart Borgman, 2011/01/17
- Bikeshedding "user choice", Stephen J. Turnbull, 2011/01/17
- RE: Bikeshedding "user choice", Drew Adams, 2011/01/18
- RE: Bikeshedding "user choice", Stephen J. Turnbull, 2011/01/18
- RE: Bikeshedding "user choice",
Drew Adams <=
- RE: Bikeshedding "user choice", Stephen J. Turnbull, 2011/01/19
- RE: Bikeshedding "user choice", Drew Adams, 2011/01/19
- RE: Bikeshedding go! Why is <M-f4> unbound?, jasonr, 2011/01/18
- Re: Bikeshedding go! Why is <M-f4> unbound?, Óscar Fuentes, 2011/01/17
- RE: Bikeshedding go! Why is <M-f4> unbound?, Drew Adams, 2011/01/17
- Re: Bikeshedding go! Why is <M-f4> unbound?, Jason Rumney, 2011/01/16
- RE: Bikeshedding go! Why is <M-f4> unbound?, Drew Adams, 2011/01/17
- RE: Bikeshedding go! Why is <M-f4> unbound?, Drew Adams, 2011/01/16
- Re: Bikeshedding go! Why is <M-f4> unbound?, Dimitri Fontaine, 2011/01/10
Re: Bikeshedding go! Why is <M-f4> unbound?, Christopher Allan Webber, 2011/01/05