emacs-devel
[Top][All Lists]
Advanced

[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.




reply via email to

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