* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 13:18 ` Stefan Monnier
@ 2011-04-20 13:22 ` Reuben Thomas
2011-04-20 14:16 ` Stefan Monnier
2011-04-20 14:07 ` Deniz Dogan
` (2 subsequent siblings)
3 siblings, 1 reply; 60+ messages in thread
From: Reuben Thomas @ 2011-04-20 13:22 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8492
On 20 April 2011 14:18, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> This is the problem: unusable defaults. I'm asking if we can have a
>> usable default setting.
>
> Currently, the "usable default" is ESC TAB.
I think "usable" is stretching it a bit :)
> Since this problem has been around for a long time and no good key has
> popped up during this time, I believe that using TAB is the
> way forward, which means we need to figure out ways to make it work in
> the cases where it currently doesn't.
I am inclined to agree that that is the path of least resistance; I
think it remains to be demonstrated that two lots of magic can be
loaded on to the same key, but I'm prepared to give it a go!
> for those modes maybe completion should take precedence as
> in "see if we're somewhere where completion makes sense and if not try
> to reindent", so TAB would complete if point is in an identifier
> but not if it's a BOL.
And there's already code to do this.
At least if there's a concerted effort to make this work and it fails,
there's more incentive to come up with another solution.
--
http://rrt.sc3d.org
^ permalink raw reply [flat|nested] 60+ messages in thread* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 13:22 ` Reuben Thomas
@ 2011-04-20 14:16 ` Stefan Monnier
2011-04-20 14:49 ` Sven Joachim
` (2 more replies)
0 siblings, 3 replies; 60+ messages in thread
From: Stefan Monnier @ 2011-04-20 14:16 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 8492
>> Since this problem has been around for a long time and no good key has
>> popped up during this time, I believe that using TAB is the
>> way forward, which means we need to figure out ways to make it work in
>> the cases where it currently doesn't.
> I am inclined to agree that that is the path of least resistance; I
> think it remains to be demonstrated that two lots of magic can be
> loaded on to the same key, but I'm prepared to give it a go!
Of course, pursuing this route doesn't preclude pursuing other routes at
the same time. So, people should feel free to suggest other keys to use
for completion.
One that comes to mind is C-M-/ (currently bound to dabbrev-completion,
so somewhat compatible) but I'm not sure if it's convenient enough.
Another one could be M-SPC, based on the idea that SPC performs
completion in many cases in the minibuffer, but that would be an
incompatible change since M-SPC currently calls just-one-space.
>> for those modes maybe completion should take precedence as
>> in "see if we're somewhere where completion makes sense and if not try
>> to reindent", so TAB would complete if point is in an identifier
>> but not if it's a BOL.
> And there's already code to do this.
I didn't know that. Where is it?
> At least if there's a concerted effort to make this work and it fails,
> there's more incentive to come up with another solution.
And the failure itself might give us a clue as to what a better solution
might look like,
Stefan
^ permalink raw reply [flat|nested] 60+ messages in thread* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 14:16 ` Stefan Monnier
@ 2011-04-20 14:49 ` Sven Joachim
2011-04-20 16:41 ` David De La Harpe Golden
2011-04-20 21:59 ` Lennart Borgman
2 siblings, 0 replies; 60+ messages in thread
From: Sven Joachim @ 2011-04-20 14:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8492, Reuben Thomas
On 2011-04-20 16:16 +0200, Stefan Monnier wrote:
>>> Since this problem has been around for a long time and no good key has
>>> popped up during this time, I believe that using TAB is the
>>> way forward, which means we need to figure out ways to make it work in
>>> the cases where it currently doesn't.
>> I am inclined to agree that that is the path of least resistance; I
>> think it remains to be demonstrated that two lots of magic can be
>> loaded on to the same key, but I'm prepared to give it a go!
>
> Of course, pursuing this route doesn't preclude pursuing other routes at
> the same time. So, people should feel free to suggest other keys to use
> for completion.
>
> One that comes to mind is C-M-/ (currently bound to dabbrev-completion,
> so somewhat compatible) but I'm not sure if it's convenient enough.
With a German keyboard layout, C-M-/ is horribly cumbersome to type,
much more inconvenient than either ESC TAB or C-M-i (I usually use the
latter).
Sven
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 14:16 ` Stefan Monnier
2011-04-20 14:49 ` Sven Joachim
@ 2011-04-20 16:41 ` David De La Harpe Golden
2011-04-20 17:11 ` Deniz Dogan
2011-04-20 17:17 ` Eli Zaretskii
2011-04-20 21:59 ` Lennart Borgman
2 siblings, 2 replies; 60+ messages in thread
From: David De La Harpe Golden @ 2011-04-20 16:41 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8492, Reuben Thomas
On 20/04/11 15:16, Stefan Monnier wrote:
>>> Since this problem has been around for a long time and no good key has
>>> popped up during this time, I believe that using TAB is the
>>> way forward, which means we need to figure out ways to make it work in
>>> the cases where it currently doesn't.
>> I am inclined to agree that that is the path of least resistance; I
>> think it remains to be demonstrated that two lots of magic can be
>> loaded on to the same key, but I'm prepared to give it a go!
>
> Of course, pursuing this route doesn't preclude pursuing other routes at
> the same time. So, people should feel free to suggest other keys to use
> for completion.
>
Well, given that the usual mapping on x.org X11 is, for better or worse,
Alt key => Meta
Windows/other-symbol* key => super
then perhaps additionally binding s-TAB out-of-box might be worth
considering? I expect it's mostly people with keyboards with such keys
who have trouble with M-TAB (and also apparently don't like C-M-i and
ESC TAB).
(Though you might get people then trying to use such a default binding
as precedent to put all sorts of stuff on s-blah, sigh...)
Uh, but then given w32 emacs apparently sees "lwindow"/"rwindow" instead
of "super" when you press the windows keys (testing in wine not real
windows), w32 emacs may also need to be adjusted to map them to
left/right super by default and treat them as modifiers. Note that such
a mapping would be consistent with typical x11 as above, but also
arguably with macosx, where "command" (⌘) is often taken to send super**
- and when you plug a pc keyboard into a mac, the windows keys become
"command" by default. Yes, macosx, gnustep and x11 all allow fairly
easy adjustment, I'm just talking about out-of-box defaults.
(Of course, I also don't know if windows itself is now using
WindowsKey-TAB for anything, I know it used not to.)
I'm one of the people who puts any window manager bindings on super in
the first place (windows key, innit...), obviously easy to do in common
X11 window managers, so don't need any of this personally (in fact I put
what windows has on Alt-Tab on Super-Tab so I wouldn't even see it),
it's just a suggestion.
* You can get keyboards with a penguin there. :-)
** note how emacs/lisp/term/ns-win-el has a bunch of super bindings
out-of-box, saying "Here are some Nextstep-like bindings for command key
sequences."...
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 16:41 ` David De La Harpe Golden
@ 2011-04-20 17:11 ` Deniz Dogan
2011-04-20 18:28 ` David De La Harpe Golden
2011-04-21 0:13 ` Sean Sieger
2011-04-20 17:17 ` Eli Zaretskii
1 sibling, 2 replies; 60+ messages in thread
From: Deniz Dogan @ 2011-04-20 17:11 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: 8492, Reuben Thomas
2011/4/20 David De La Harpe Golden <david@harpegolden.net>:
> (Of course, I also don't know if windows itself is now using WindowsKey-TAB
> for anything, I know it used not to.)
>
Windows Vista and Windows 7 use Win+TAB to switch between windows in a
more useless and annoying manner. Sort of like a rolodex:
http://thavarajah.dk/sites/thavarajah.dk/uploads/2007/01/vista_window_switch.png
--
Deniz Dogan
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 17:11 ` Deniz Dogan
@ 2011-04-20 18:28 ` David De La Harpe Golden
2011-04-20 22:02 ` Lennart Borgman
2011-04-21 0:13 ` Sean Sieger
1 sibling, 1 reply; 60+ messages in thread
From: David De La Harpe Golden @ 2011-04-20 18:28 UTC (permalink / raw)
To: Deniz Dogan; +Cc: 8492, Reuben Thomas
On 20/04/11 18:11, Deniz Dogan wrote:
> 2011/4/20 David De La Harpe Golden<david@harpegolden.net>:
>> (Of course, I also don't know if windows itself is now using WindowsKey-TAB
>> for anything, I know it used not to.)
>>
>
> Windows Vista and Windows 7 use Win+TAB to switch between windows in a
> more useless and annoying manner.
D'oh. Oh well.
Though that does mean there is now something of an alternative to
Alt+TAB on windows, so if you do configure emacs to grab Alt+TAB at a
low level on windows with w32-register-hot-key as the docs mention, then
it's no longer the case you're hidden the ability to easily* switch app
from the keyboard, so the issue is maybe actually a bit less pressing
than it used to be on w32.
* though in a more useless and annoying, or at least gimmicky, manner...
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 18:28 ` David De La Harpe Golden
@ 2011-04-20 22:02 ` Lennart Borgman
0 siblings, 0 replies; 60+ messages in thread
From: Lennart Borgman @ 2011-04-20 22:02 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: 8492, Reuben Thomas
On Wed, Apr 20, 2011 at 8:28 PM, David De La Harpe Golden
<david@harpegolden.net>
>
> Though that does mean there is now something of an alternative to Alt+TAB on
> windows, so if you do configure emacs to grab Alt+TAB at a low level on
> windows with w32-register-hot-key as the docs mention, then it's no longer
> the case you're hidden the ability to easily* switch app from the keyboard,
> so the issue is maybe actually a bit less pressing than it used to be on
> w32.
I mentioned before that I have somewhere MS doc have read that Alt-TAB
is not configurable. It actually still was on xp when I tested, but
has anyone tested this on win7?
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 17:11 ` Deniz Dogan
2011-04-20 18:28 ` David De La Harpe Golden
@ 2011-04-21 0:13 ` Sean Sieger
2011-04-21 6:02 ` Deniz Dogan
1 sibling, 1 reply; 60+ messages in thread
From: Sean Sieger @ 2011-04-21 0:13 UTC (permalink / raw)
To: bug-gnu-emacs
Windows Vista and Windows 7 use Win+TAB to switch between windows in
a more useless and annoying manner. Sort of like a rolodex:
http://thavarajah.dk/sites/thavarajah.dk/uploads/2007/01/vista_window_switch.png
Yep.
But you know, when I first encountered Windows 7, I got the distinct
impression (with precisely phenomena like the `rolodex' you refer to,
what, with Alt-TAB doing the slide across the app images and the
redundancy) that Microsoft was trying to keep up with the slickitiness
of Ubuntu. Ubuntu's just as ugly and heavy.
^ permalink raw reply [flat|nested] 60+ messages in thread* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 0:13 ` Sean Sieger
@ 2011-04-21 6:02 ` Deniz Dogan
0 siblings, 0 replies; 60+ messages in thread
From: Deniz Dogan @ 2011-04-21 6:02 UTC (permalink / raw)
To: Sean Sieger; +Cc: bug-gnu-emacs
2011/4/21 Sean Sieger <sean.sieger@gmail.com>:
> Windows Vista and Windows 7 use Win+TAB to switch between windows in
> a more useless and annoying manner. Sort of like a rolodex:
> http://thavarajah.dk/sites/thavarajah.dk/uploads/2007/01/vista_window_switch.png
>
> Yep.
>
> But you know, when I first encountered Windows 7, I got the distinct
> impression (with precisely phenomena like the `rolodex' you refer to,
> what, with Alt-TAB doing the slide across the app images and the
> redundancy) that Microsoft was trying to keep up with the slickitiness
> of Ubuntu. Ubuntu's just as ugly and heavy.
>
I wasn't hating on Windows for the rolodex thing, I'm just saying it's
useless. That said, I'm not sure what window manager you're referring
to when you say Ubuntu.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 16:41 ` David De La Harpe Golden
2011-04-20 17:11 ` Deniz Dogan
@ 2011-04-20 17:17 ` Eli Zaretskii
2011-04-20 22:03 ` Lennart Borgman
1 sibling, 1 reply; 60+ messages in thread
From: Eli Zaretskii @ 2011-04-20 17:17 UTC (permalink / raw)
To: David De La Harpe Golden; +Cc: 8492, rrt
> Date: Wed, 20 Apr 2011 17:41:41 +0100
> From: David De La Harpe Golden <david@harpegolden.net>
> Cc: 8492@debbugs.gnu.org, Reuben Thomas <rrt@sc3d.org>
>
> Uh, but then given w32 emacs apparently sees "lwindow"/"rwindow" instead
> of "super" when you press the windows keys (testing in wine not real
> windows), w32 emacs may also need to be adjusted to map them to
> left/right super by default and treat them as modifiers.
See w32-lwindow-modifier and w32-rwindow-modifier. (And note the
footnote in the Emacs manual's "Windows Keyboard" node about the
caveats.)
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 17:17 ` Eli Zaretskii
@ 2011-04-20 22:03 ` Lennart Borgman
2011-04-21 6:43 ` Eli Zaretskii
0 siblings, 1 reply; 60+ messages in thread
From: Lennart Borgman @ 2011-04-20 22:03 UTC (permalink / raw)
To: Eli Zaretskii; +Cc: 8492, rrt
On Wed, Apr 20, 2011 at 7:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
>> Date: Wed, 20 Apr 2011 17:41:41 +0100
>> From: David De La Harpe Golden <david@harpegolden.net>
>> Cc: 8492@debbugs.gnu.org, Reuben Thomas <rrt@sc3d.org>
>>
>> Uh, but then given w32 emacs apparently sees "lwindow"/"rwindow" instead
>> of "super" when you press the windows keys (testing in wine not real
>> windows), w32 emacs may also need to be adjusted to map them to
>> left/right super by default and treat them as modifiers.
>
> See w32-lwindow-modifier and w32-rwindow-modifier. (And note the
> footnote in the Emacs manual's "Windows Keyboard" node about the
> caveats.)
Which are not guaranteed to work unless you use a low level keyboard
hook. See EmacsW32 repository for a path with this.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 22:03 ` Lennart Borgman
@ 2011-04-21 6:43 ` Eli Zaretskii
0 siblings, 0 replies; 60+ messages in thread
From: Eli Zaretskii @ 2011-04-21 6:43 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 8492, rrt
> From: Lennart Borgman <lennart.borgman@gmail.com>
> Date: Thu, 21 Apr 2011 00:03:10 +0200
> Cc: David De La Harpe Golden <david@harpegolden.net>, 8492@debbugs.gnu.org, rrt@sc3d.org
>
> On Wed, Apr 20, 2011 at 7:17 PM, Eli Zaretskii <eliz@gnu.org> wrote:
> >> Date: Wed, 20 Apr 2011 17:41:41 +0100
> >> From: David De La Harpe Golden <david@harpegolden.net>
> >> Cc: 8492@debbugs.gnu.org, Reuben Thomas <rrt@sc3d.org>
> >>
> >> Uh, but then given w32 emacs apparently sees "lwindow"/"rwindow" instead
> >> of "super" when you press the windows keys (testing in wine not real
> >> windows), w32 emacs may also need to be adjusted to map them to
> >> left/right super by default and treat them as modifiers.
> >
> > See w32-lwindow-modifier and w32-rwindow-modifier. (And note the
> > footnote in the Emacs manual's "Windows Keyboard" node about the
> > caveats.)
>
> Which are not guaranteed to work unless you use a low level keyboard
> hook. See EmacsW32 repository for a path with this.
Yeah, yeah, yeah, and we must destroy Carthage, too.
(The part in parentheses in my message exactly referred to the caveats
of using these two keys.)
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 14:16 ` Stefan Monnier
2011-04-20 14:49 ` Sven Joachim
2011-04-20 16:41 ` David De La Harpe Golden
@ 2011-04-20 21:59 ` Lennart Borgman
2 siblings, 0 replies; 60+ messages in thread
From: Lennart Borgman @ 2011-04-20 21:59 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8492, Reuben Thomas
On Wed, Apr 20, 2011 at 4:16 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>
> One that comes to mind is C-M-/ (currently bound to dabbrev-completion,
> so somewhat compatible) but I'm not sure if it's convenient enough.
Which is a problematic binding if you do not use US keyboard.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 13:18 ` Stefan Monnier
2011-04-20 13:22 ` Reuben Thomas
@ 2011-04-20 14:07 ` Deniz Dogan
2011-04-20 15:49 ` Drew Adams
2011-04-20 21:56 ` Lennart Borgman
3 siblings, 0 replies; 60+ messages in thread
From: Deniz Dogan @ 2011-04-20 14:07 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8492, Reuben Thomas
2011/4/20 Stefan Monnier <monnier@iro.umontreal.ca>:
>> This is the problem: unusable defaults. I'm asking if we can have a
>> usable default setting.
>
> Currently, the "usable default" is ESC TAB.
>
> It's a bit longwinded, so it'd be good to find a better solution.
> Since this problem has been around for a long time and no good key has
> popped up during this time, I believe that using TAB is the
> way forward, which means we need to figure out ways to make it work in
> the cases where it currently doesn't.
>
> Currently the way it works is "try to reindent, and if there was no
> change, try to complete". As mentioned this doesn't work for Python and
> Haskell, so for those modes maybe completion should take precedence as
> in "see if we're somewhere where completion makes sense and if not try
> to reindent", so TAB would complete if point is in an identifier
> but not if it's a BOL.
>
> Not sure if it would work well in practice, but it might be worth trying
> it out. There are other cases where TAB has trouble, e.g. in text modes
> where TAB doesn't reindent but jumps to the next tab position.
> I don't know how/if we can combine this TAB semantics with completion.
>
Surely there must be keys left that are not used for any particular
purpose in general. E.g. C-. comes to mind (c.f. C-M-. for
find-tag-regexp), although I'm not sure how well that key is
recognized by terminals.
--
Deniz Dogan
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 13:18 ` Stefan Monnier
2011-04-20 13:22 ` Reuben Thomas
2011-04-20 14:07 ` Deniz Dogan
@ 2011-04-20 15:49 ` Drew Adams
2011-04-20 18:28 ` Reuben Thomas
2011-04-20 21:56 ` Lennart Borgman
3 siblings, 1 reply; 60+ messages in thread
From: Drew Adams @ 2011-04-20 15:49 UTC (permalink / raw)
To: 'Stefan Monnier', 'Reuben Thomas'; +Cc: 8492
> Currently, the "usable default" is ESC TAB.
> It's a bit longwinded, so it'd be good to find a better solution.
It's not very longwinded. It was used for a very long time before ALT + TAB was
available for the same thing. It was used by many perfectly capable and fast
programmers, including the one who wrote Emacs (practically overnight) and gcc.
;-) Likewise `C-M-i' - not very longwinded, and long available for this.
And anyway it doesn't really matter all that much how longwinded a _default_
binding is. (Yes, there is no reason to purposefully use longer bindings when
better, shorter ones can be found.)
> Since this problem has been around for a long time and no good key has
> popped up during this time, I believe that using TAB is the
> way forward, which means we need to figure out ways to make it work in
> the cases where it currently doesn't.
So your logic is that simply because you cannot find an available key you want
to complicate the behavior of the command so that it acts, in effect, as
multiple commands depending on the context.
That's not a good argument. Occam stands with his razor against it - you are
multiplying things needlessly.
Keep it simple. Find a key or let users find their own key for a simple,
straightforward command (i.e., that does only what M-TAB does currently).
Forget about combining 36 different behaviors on the same key.
In practice, so-called "DWIM" too often means lousy, half-baked compromises and
"do-what-some-programmer-who-thought-herself-clever-figured-would-be-innovative-
and-loved-by-everyone". The "I" in DWIM is too seldom the user, and the "WIM"
is too seldom accurate.
Do I really care, for M-TAB or `completion-at-point'? Not much. I do care that
we needlessly complicate the behavior of keys with compromised,
not-so-clever-after-all DWIM-wittedness.
Please go back to the problem itself and look for a simple solution _to it_.
M-TAB is not easily available on several systems. OK, so you want a different
key as the default binding for `completion-at-point' (or whatever). OK, so pick
another key. Problem solved.
But please do not redesign the behavior to become hydra-headed so it tries to
adapt to multiple contexts, just because you cannot think of a good default key.
That makes little sense.
And TAB, in particular, is *not* "the way forward for this". If ever there was
a key *not* to double-up on for this (triple? quadruple? pentuple?), TAB is it.
It's just about the poorest choice possible here.
(Yes, I am aware that some users have done exactly what you suggest and like the
effect. Pick any behavior and you will find some users who are happy with it to
the point of proselytizing. But such a chimera is not a good solution for
vanilla Emacs.)
Just one opinion, and no, I do not really care much. But this is misguided,
IMHO.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 15:49 ` Drew Adams
@ 2011-04-20 18:28 ` Reuben Thomas
2011-04-20 22:48 ` Stefan Monnier
0 siblings, 1 reply; 60+ messages in thread
From: Reuben Thomas @ 2011-04-20 18:28 UTC (permalink / raw)
To: Drew Adams; +Cc: 8492
On 20 April 2011 16:49, Drew Adams <drew.adams@oracle.com> wrote:
>> Currently, the "usable default" is ESC TAB.
>> It's a bit longwinded, so it'd be good to find a better solution.
>
> It's not very longwinded.
It's two keystrokes rather than a two-key chord for a function which
users these days expect to use frequently.
> It was used by many perfectly capable and fast
> programmers, including the one who wrote Emacs practically
> overnight) and gcc.
I'd be interested to know whether that's actually true, or whether
they simply didn't use it.
> ;-) Likewise `C-M-i' - not very longwinded, and long available
> for this.
Takes two hands.
> And anyway it doesn't really matter all that much how longwinded a _default_
> binding is.
It does. If the letter 'e' were bound by default to "ESC C-M x 5 a" I
wouldn't use Emacs.
The point is that there are features that are relatively new which
users now expect. Syntax coloring is another which went from optional
(largely for performance reasons, IIRC) to on-by-default, but of
course it doesn't really need keybindings.
> So your logic is that simply because you cannot find an available key you want
> to complicate the behavior of the command so that it acts, in effect, as
> multiple commands depending on the context.
That may work: we already have plenty of context-dependent keystrokes,
which are often called "electric". Tab is, as even you've noted,
already overloaded.
Having said that, no key binding is better than a clever key binding.
Some uses of completion perhaps don't need a key (as for example many
uses of code completion, which in other IDEs pop up a list of
completions by default).
--
http://rrt.sc3d.org
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 18:28 ` Reuben Thomas
@ 2011-04-20 22:48 ` Stefan Monnier
2011-04-20 22:49 ` Reuben Thomas
0 siblings, 1 reply; 60+ messages in thread
From: Stefan Monnier @ 2011-04-20 22:48 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 8492
> Having said that, no key binding is better than a clever key binding.
> Some uses of completion perhaps don't need a key (as for example many
> uses of code completion, which in other IDEs pop up a list of
> completions by default).
I think this one is a fallacy: popping up the menu may not need a key
binding, but you do need a key binding in order to select something from
that menu. Admittedly, it changes the problem enough that the solution
may be simpler (e.g. M-n and M-p can be used for that whereas they don't
seem nearly as attractive for completion-at-point).
Stefan
^ permalink raw reply [flat|nested] 60+ messages in thread* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 22:48 ` Stefan Monnier
@ 2011-04-20 22:49 ` Reuben Thomas
0 siblings, 0 replies; 60+ messages in thread
From: Reuben Thomas @ 2011-04-20 22:49 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8492
On 20 April 2011 23:48, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Having said that, no key binding is better than a clever key binding.
>> Some uses of completion perhaps don't need a key (as for example many
>> uses of code completion, which in other IDEs pop up a list of
>> completions by default).
>
> I think this one is a fallacy: popping up the menu may not need a key
> binding, but you do need a key binding in order to select something from
> that menu. Admittedly, it changes the problem enough that the solution
> may be simpler (e.g. M-n and M-p can be used for that whereas they don't
> seem nearly as attractive for completion-at-point).
I should have been more precise, because I agree with you. I should
have said "perhaps doesn't need a global key binding".
--
http://rrt.sc3d.org
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 13:18 ` Stefan Monnier
` (2 preceding siblings ...)
2011-04-20 15:49 ` Drew Adams
@ 2011-04-20 21:56 ` Lennart Borgman
2011-04-20 22:49 ` Drew Adams
3 siblings, 1 reply; 60+ messages in thread
From: Lennart Borgman @ 2011-04-20 21:56 UTC (permalink / raw)
To: Stefan Monnier; +Cc: 8492, Reuben Thomas
On Wed, Apr 20, 2011 at 3:18 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> This is the problem: unusable defaults. I'm asking if we can have a
>> usable default setting.
>
> Currently, the "usable default" is ESC TAB.
Which does not work at all if you use Viper.
^ permalink raw reply [flat|nested] 60+ messages in thread* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 21:56 ` Lennart Borgman
@ 2011-04-20 22:49 ` Drew Adams
2011-04-20 22:51 ` Reuben Thomas
2011-04-21 12:42 ` Lennart Borgman
0 siblings, 2 replies; 60+ messages in thread
From: Drew Adams @ 2011-04-20 22:49 UTC (permalink / raw)
To: 'Lennart Borgman', 'Stefan Monnier'
Cc: 8492, 'Reuben Thomas'
> > Currently, the "usable default" is ESC TAB.
>
> Which does not work at all if you use Viper.
We should not change Emacs default bindings based on the bindings of Viper - or
of any other emulator - or of any other mode etc.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 22:49 ` Drew Adams
@ 2011-04-20 22:51 ` Reuben Thomas
2011-04-21 12:42 ` Lennart Borgman
1 sibling, 0 replies; 60+ messages in thread
From: Reuben Thomas @ 2011-04-20 22:51 UTC (permalink / raw)
To: Drew Adams; +Cc: 8492
On 20 April 2011 23:49, Drew Adams <drew.adams@oracle.com> wrote:
>> > Currently, the "usable default" is ESC TAB.
>>
>> Which does not work at all if you use Viper.
>
> We should not change Emacs default bindings based on the bindings of Viper - or
> of any other emulator - or of any other mode etc.
Well, any other mode whose operation involves changing the default
keymap. But otherwise, I agree with this sentiment: it's hard enough
making bindings fit into Emacs without worrying about other
essentially different bindings sets, other of course than the global
window manager bindings that made me raise this question in the first
place.
--
http://rrt.sc3d.org
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-20 22:49 ` Drew Adams
2011-04-20 22:51 ` Reuben Thomas
@ 2011-04-21 12:42 ` Lennart Borgman
2011-04-21 14:13 ` Drew Adams
1 sibling, 1 reply; 60+ messages in thread
From: Lennart Borgman @ 2011-04-21 12:42 UTC (permalink / raw)
To: Drew Adams; +Cc: 8492, Reuben Thomas
On Thu, Apr 21, 2011 at 12:49 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> > Currently, the "usable default" is ESC TAB.
>>
>> Which does not work at all if you use Viper.
>
> We should not change Emacs default bindings based on the bindings of Viper - or
> of any other emulator - or of any other mode etc.
Thanks for your view, Drew, but I found this statement of you just
unusable and unnecessary here.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 12:42 ` Lennart Borgman
@ 2011-04-21 14:13 ` Drew Adams
2011-04-21 18:49 ` Lennart Borgman
0 siblings, 1 reply; 60+ messages in thread
From: Drew Adams @ 2011-04-21 14:13 UTC (permalink / raw)
To: 'Lennart Borgman'; +Cc: 8492, 'Reuben Thomas'
> >> > Currently, the "usable default" is ESC TAB.
> >>
> >> Which does not work at all if you use Viper.
> >
> > We should not change Emacs default bindings based on the
> > bindings of Viper - or of any other emulator - or of any
> > other mode etc.
>
> Thanks for your view, Drew, but I found this statement of you just
> unusable and unnecessary here.
You claim that a given default key "does not work at all" if you put yourself in
a special emulation mode. So what? If I play chess in checkers mode should I
expect the default, chess binding of each piece to still "work" in checkers?
This is a _default_ key binding we're talking about. It is not _expected_ to
work in every possible mode. It's especially narrow-sighted to demand that
Emacs default key bindings have their default effects in an _emulator_ mode such
as Viper.
Expecting default Emacs key bindings to all just "work" in a `vi' mode is
ridiculous - and you should know that.
You use Emacs as if it were `vi', and yet you expect all of Emacs, even its
default keys, to keep your personal practice front and center - all attention on
Lennart and what he's doing. It's not about your own favorite mode or your very
UN-default use of Emacs. This is about a _default_ key binding.
If Viper mode cannot handle a default key that you think it should be able to
handle, then fix Viper mode to fit your wish. Don't ask default Emacs to worry
about Viper special needs.
An alternative: break out of the emulator closet once and for all. Just use
`vi' itself. Then you don't need to worry at all about Emacs and its krazy
keys.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 14:13 ` Drew Adams
@ 2011-04-21 18:49 ` Lennart Borgman
2011-04-21 19:34 ` Reuben Thomas
2011-04-22 20:44 ` Sean Sieger
0 siblings, 2 replies; 60+ messages in thread
From: Lennart Borgman @ 2011-04-21 18:49 UTC (permalink / raw)
To: Drew Adams; +Cc: 8492, Reuben Thomas
On Thu, Apr 21, 2011 at 4:13 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> >> > Currently, the "usable default" is ESC TAB.
>> >>
>> >> Which does not work at all if you use Viper.
>> >
>> > We should not change Emacs default bindings based on the
>> > bindings of Viper - or of any other emulator - or of any
>> > other mode etc.
>>
>> Thanks for your view, Drew, but I found this statement of you just
>> unusable and unnecessary here.
>
> You claim that a given default key "does not work at all" if you put yourself in
> a special emulation mode. So what? If I play chess in checkers mode should I
> expect the default, chess binding of each piece to still "work" in checkers?
This is just plain stupid. Viper is not just any emulation mode. It
happen to be key bindings a lot of potential and current Emacs users
knows.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 18:49 ` Lennart Borgman
@ 2011-04-21 19:34 ` Reuben Thomas
2011-04-21 19:54 ` Lennart Borgman
2011-04-22 20:44 ` Sean Sieger
1 sibling, 1 reply; 60+ messages in thread
From: Reuben Thomas @ 2011-04-21 19:34 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 8492
On 21 April 2011 19:49, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 4:13 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>> >> > Currently, the "usable default" is ESC TAB.
>>> >>
>>> >> Which does not work at all if you use Viper.
>>> >
>>> > We should not change Emacs default bindings based on the
>>> > bindings of Viper - or of any other emulator - or of any
>>> > other mode etc.
>>>
>>> Thanks for your view, Drew, but I found this statement of you just
>>> unusable and unnecessary here.
>>
>> You claim that a given default key "does not work at all" if you put yourself in
>> a special emulation mode. So what? If I play chess in checkers mode should I
>> expect the default, chess binding of each piece to still "work" in checkers?
>
> This is just plain stupid. Viper is not just any emulation mode. It
> happen to be key bindings a lot of potential and current Emacs users
> knows.
I don't understand why there's even an argument here. Viper is a mode
with a radically different approach to keybinding, so what does it
have to do with the default keybindings? It's clearly unreasonable to
expect default single-chord keybindings to take it into account.
--
http://rrt.sc3d.org
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 19:34 ` Reuben Thomas
@ 2011-04-21 19:54 ` Lennart Borgman
2011-04-21 20:14 ` Reuben Thomas
2011-04-22 21:01 ` Sean Sieger
0 siblings, 2 replies; 60+ messages in thread
From: Lennart Borgman @ 2011-04-21 19:54 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 8492
On Thu, Apr 21, 2011 at 9:34 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 21 April 2011 19:49, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>> On Thu, Apr 21, 2011 at 4:13 PM, Drew Adams <drew.adams@oracle.com> wrote:
>>>> >> > Currently, the "usable default" is ESC TAB.
>>>> >>
>>>> >> Which does not work at all if you use Viper.
>>>> >
>>>> > We should not change Emacs default bindings based on the
>>>> > bindings of Viper - or of any other emulator - or of any
>>>> > other mode etc.
>>>>
>>>> Thanks for your view, Drew, but I found this statement of you just
>>>> unusable and unnecessary here.
>>>
>>> You claim that a given default key "does not work at all" if you put yourself in
>>> a special emulation mode. So what? If I play chess in checkers mode should I
>>> expect the default, chess binding of each piece to still "work" in checkers?
>>
>> This is just plain stupid. Viper is not just any emulation mode. It
>> happen to be key bindings a lot of potential and current Emacs users
>> knows.
>
> I don't understand why there's even an argument here. Viper is a mode
> with a radically different approach to keybinding, so what does it
> have to do with the default keybindings? It's clearly unreasonable to
> expect default single-chord keybindings to take it into account.
The same has been said about CUA-bindings. Both cua-mode and viper are
parts of Emacs and parts that many users depends on. There are other
emulations that are not that important. In fact I do not know of any
people still using the other emulations.
But the fact is that many people using Emacs depends on cua-mode and
viper. Not taking facts into account is not a good real world
reasoning.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 19:54 ` Lennart Borgman
@ 2011-04-21 20:14 ` Reuben Thomas
2011-04-21 20:55 ` Lennart Borgman
2011-04-22 21:01 ` Sean Sieger
1 sibling, 1 reply; 60+ messages in thread
From: Reuben Thomas @ 2011-04-21 20:14 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 8492
On 21 April 2011 20:54, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>
> The same has been said about CUA-bindings. Both cua-mode and viper are
> parts of Emacs and parts that many users depends on. There are other
> emulations that are not that important. In fact I do not know of any
> people still using the other emulations.
>
> But the fact is that many people using Emacs depends on cua-mode and
> viper.
Sure, so from time to time those bindings have to be updated when new
incompatibilities arise with the default Emacs bindings. How is that a
big deal?
--
http://rrt.sc3d.org
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 20:14 ` Reuben Thomas
@ 2011-04-21 20:55 ` Lennart Borgman
2011-04-21 21:08 ` Reuben Thomas
0 siblings, 1 reply; 60+ messages in thread
From: Lennart Borgman @ 2011-04-21 20:55 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 8492
On Thu, Apr 21, 2011 at 10:14 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 21 April 2011 20:54, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>
>> The same has been said about CUA-bindings. Both cua-mode and viper are
>> parts of Emacs and parts that many users depends on. There are other
>> emulations that are not that important. In fact I do not know of any
>> people still using the other emulations.
>>
>> But the fact is that many people using Emacs depends on cua-mode and
>> viper.
>
> Sure, so from time to time those bindings have to be updated when new
> incompatibilities arise with the default Emacs bindings. How is that a
> big deal?
The big deal is that it is Emacs that has to accommodate its default
bindings since the world outside is so much bigger.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 20:55 ` Lennart Borgman
@ 2011-04-21 21:08 ` Reuben Thomas
2011-04-22 13:47 ` Lennart Borgman
0 siblings, 1 reply; 60+ messages in thread
From: Reuben Thomas @ 2011-04-21 21:08 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 8492
On 21 April 2011 21:55, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 10:14 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>> On 21 April 2011 20:54, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>
>>>
>>> But the fact is that many people using Emacs depends on cua-mode and
>>> viper.
>>
>> Sure, so from time to time those bindings have to be updated when new
>> incompatibilities arise with the default Emacs bindings. How is that a
>> big deal?
>
>
> The big deal is that it is Emacs that has to accommodate its default
> bindings since the world outside is so much bigger.
How is Viper or CUA the world outside? I filed this bug because of a
clash between Emacs and the "world outside", in this case, standard
window-manager bindings. But Viper and CUA are a) part of Emacs and b)
both have (to a greater extent in Viper's case, a lesser in CUA's) a
different and fundamentally incompatible approach to key binding from
Emacs's default. I still don't see, therefore, why it's necessary, or
even how it's possible for Emacs's default keybindings to take account
of them.
To give just one example each, Viper is, following vi, modal: keys
that in Emacs are always bound to self-insert-command are bound to
editing commands in viper's command mode; in CUA, C-x is used for cut,
whereas in Emacs's default bindings it's a prefix. So it's not even
hypothetical: there are already fundamental incompatibilities. Why,
therefore, the fuss about another (potential) incompatibility?
--
http://rrt.sc3d.org
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 21:08 ` Reuben Thomas
@ 2011-04-22 13:47 ` Lennart Borgman
2011-04-22 17:33 ` Reuben Thomas
0 siblings, 1 reply; 60+ messages in thread
From: Lennart Borgman @ 2011-04-22 13:47 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 8492
On Thu, Apr 21, 2011 at 11:08 PM, Reuben Thomas <rrt@sc3d.org> wrote:
> On 21 April 2011 21:55, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>> On Thu, Apr 21, 2011 at 10:14 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>>> On 21 April 2011 20:54, Lennart Borgman <lennart.borgman@gmail.com> wrote:
>>>>
>>>>
>>>> But the fact is that many people using Emacs depends on cua-mode and
>>>> viper.
>>>
>>> Sure, so from time to time those bindings have to be updated when new
>>> incompatibilities arise with the default Emacs bindings. How is that a
>>> big deal?
>>
>>
>> The big deal is that it is Emacs that has to accommodate its default
>> bindings since the world outside is so much bigger.
>
> How is Viper or CUA the world outside?
They are mirrors of the outside world. And users of them want this
mirror to be exact in certain cases.
> To give just one example each, Viper is, following vi, modal: keys
> that in Emacs are always bound to self-insert-command are bound to
> editing commands in viper's command mode; in CUA, C-x is used for cut,
> whereas in Emacs's default bindings it's a prefix. So it's not even
> hypothetical: there are already fundamental incompatibilities. Why,
> therefore, the fuss about another (potential) incompatibility?
If you do not think this is a problem then I guess you also could
accept an argument for moving for example C-x in Emacs to another key?
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-22 13:47 ` Lennart Borgman
@ 2011-04-22 17:33 ` Reuben Thomas
2011-04-22 18:12 ` Lennart Borgman
0 siblings, 1 reply; 60+ messages in thread
From: Reuben Thomas @ 2011-04-22 17:33 UTC (permalink / raw)
To: Lennart Borgman; +Cc: 8492
On 22 April 2011 14:47, Lennart Borgman <lennart.borgman@gmail.com> wrote:
> On Thu, Apr 21, 2011 at 11:08 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>> How is Viper or CUA the world outside?
>
> They are mirrors of the outside world. And users of them want this
> mirror to be exact in certain cases.
We're talking at cross-purposes then.
> If you do not think this is a problem then I guess you also could
> accept an argument for moving for example C-x in Emacs to
> another key?
No, because that would change the default Emacs bindings in a major
way. No-one is suggesting changing them in a major way, and no-one is
suggesting changing Viper or CUA at all!
--
http://rrt.sc3d.org
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-22 17:33 ` Reuben Thomas
@ 2011-04-22 18:12 ` Lennart Borgman
0 siblings, 0 replies; 60+ messages in thread
From: Lennart Borgman @ 2011-04-22 18:12 UTC (permalink / raw)
To: Reuben Thomas; +Cc: 8492
On Fri, Apr 22, 2011 at 7:33 PM, Reuben Thomas <rrt@sc3d.org> wrote:
>
>> If you do not think this is a problem then I guess you also could
>> accept an argument for moving for example C-x in Emacs to
>> another key?
>
> No, because that would change the default Emacs bindings in a major
> way. No-one is suggesting changing them in a major way, and no-one is
> suggesting changing Viper or CUA at all!
Not in short time. But in the longer time we have been discussing
adjustment. I think the most probable way is to have a way to adjust
all key bindings so that they fit better with CUA. Though I doubt it
will be the default in our life time ;-)
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 19:54 ` Lennart Borgman
2011-04-21 20:14 ` Reuben Thomas
@ 2011-04-22 21:01 ` Sean Sieger
2011-04-22 21:09 ` Lennart Borgman
1 sibling, 1 reply; 60+ messages in thread
From: Sean Sieger @ 2011-04-22 21:01 UTC (permalink / raw)
To: bug-gnu-emacs
Lennart Borgman <lennart.borgman@gmail.com> writes:
The same has been said about CUA-bindings. Both cua-mode and viper are
parts of Emacs and parts that many users depends on. There are other
emulations that are not that important. In fact I do not know of any
people still using the other emulations.
Oh, no, Lennart, you still don't know what I'm doing with Emacs in
private, let alone how `important' doing it is to me.
But the fact is that many people using Emacs depends on cua-mode and
viper. Not taking facts into account is not a good real world
reasoning.
I'm trying to use my imagination to get my head around how you've come
to know this.
^ permalink raw reply [flat|nested] 60+ messages in thread* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-22 21:01 ` Sean Sieger
@ 2011-04-22 21:09 ` Lennart Borgman
0 siblings, 0 replies; 60+ messages in thread
From: Lennart Borgman @ 2011-04-22 21:09 UTC (permalink / raw)
To: Sean Sieger; +Cc: bug-gnu-emacs
On Fri, Apr 22, 2011 at 11:01 PM, Sean Sieger <sean.sieger@gmail.com> wrote:
> Lennart Borgman <lennart.borgman@gmail.com> writes:
>
> The same has been said about CUA-bindings. Both cua-mode and viper are
> parts of Emacs and parts that many users depends on. There are other
> emulations that are not that important. In fact I do not know of any
> people still using the other emulations.
>
> Oh, no, Lennart, you still don't know what I'm doing with Emacs in
> private, let alone how `important' doing it is to me.
>
> But the fact is that many people using Emacs depends on cua-mode and
> viper. Not taking facts into account is not a good real world
> reasoning.
>
> I'm trying to use my imagination to get my head around how you've come
> to know this.
If you try harder you may succeed.
^ permalink raw reply [flat|nested] 60+ messages in thread
* bug#8492: 23.3; Time to use a different binding for completion?
2011-04-21 18:49 ` Lennart Borgman
2011-04-21 19:34 ` Reuben Thomas
@ 2011-04-22 20:44 ` Sean Sieger
1 sibling, 0 replies; 60+ messages in thread
From: Sean Sieger @ 2011-04-22 20:44 UTC (permalink / raw)
To: bug-gnu-emacs
Lennart Borgman <lennart.borgman@gmail.com> writes:
This is just plain stupid. Viper is not just any emulation mode. It
happen to be key bindings a lot of potential and current Emacs users
knows.
Your valorization of Viper is no more valid than another's
devalorization of it. I think Vi's great, what's so great about Emacs
that you cause it to behave like Vi?
^ permalink raw reply [flat|nested] 60+ messages in thread
