Keybinding nit

Keybinding nit

[David Kastrup]

C-x 4 0 and C-x 5 0 are not at all symmetric, and C-x 4 0 is not
really intuitive.

Maybe one should rather have C-x 4 k and C-x 5 k for killing both
buffer and window/frame?

That would be quite closer to

C-x k RET C-x 0
and
C-x k RET C-x 5 0

in my opinion.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Keybinding nit

[Peter Lee]

>>>> David Kastrup writes:

    > C-x 4 0 and C-x 5 0 are not at all symmetric, and C-x 4 0 is not
    > really intuitive.
    > Maybe one should rather have C-x 4 k and C-x 5 k for killing both
    > buffer and window/frame?
    > That would be quite closer to
    > C-x k RET C-x 0
    > and
    > C-x k RET C-x 5 0

I use:

C-x 4 k - kill other buffer
C-x 4 K - kill other buffer and delete the window

C-x k - kill buffer
C-x K - kill buffer and delete the window

If I were to use frames, I would probably use the same scheme.  I'm not sure why
Emacs, in general, doesn't leverage the upper-case binding for variations on a
command.  It seems intuitive to me.

e.g. if C-x C-s -> save-buffer
why not  C-x C-S -> save-some-buffers

Re: Keybinding nit

[Miles Bader]

Peter Lee <pete.a.lee@gmail.com> writes:
> I'm not sure why Emacs, in general, doesn't leverage the upper-case
> binding for variations on a command.  It seems intuitive to me.

Well at least historically, I suppose one reason is because such
combinations (control + shift) don't work on ttys.

Perhaps they'd make sense as "optional" bindings these days, but if you
do that _too_ much, there's a risk of tilting the entire keybinding
scheme in a way that makes tty usage more difficult.

-Miles
-- 
`To alcohol!  The cause of, and solution to,
 all of life's problems' --Homer J. Simpson

Re: Keybinding nit

[Richard Stallman]

    C-x 4 0 and C-x 5 0 are not at all symmetric, and C-x 4 0 is not
    really intuitive.

    Maybe one should rather have C-x 4 k and C-x 5 k for killing both
    buffer and window/frame?

Since C-x k reads a buffer name, I would expect C-x 4 k to
read a buffer name also.

Re: Keybinding nit

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     C-x 4 0 and C-x 5 0 are not at all symmetric, and C-x 4 0 is not
>     really intuitive.
>
>     Maybe one should rather have C-x 4 k and C-x 5 k for killing both
>     buffer and window/frame?
>
> Since C-x k reads a buffer name, I would expect C-x 4 k to
> read a buffer name also.

Well, I wouldn't (there are quite a few keybindings where "k" just
kills something).  And since neither C-x 0 nor C-x 5 0 kills a buffer,
I would not expect C-x 4 0 to do it, either.

It all boils down to what feels more natural and expected.  Of course
that is a matter of personal taste, and I like to think my taste is
not too far out here.  Other opinions?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Keybinding nit

[Kevin Rodgers]

Miles Bader wrote:
> Peter Lee <pete.a.lee@gmail.com> writes:
>> I'm not sure why Emacs, in general, doesn't leverage the upper-case
>> binding for variations on a command.  It seems intuitive to me.
> 
> Well at least historically, I suppose one reason is because such
> combinations (control + shift) don't work on ttys.

But that's not what Peter wrote; he's using the same `C-x' prefix
in all cases, just varying the case of the final key:

 >> C-x 4 k - kill other buffer
 >> C-x 4 K - kill other buffer and delete the window
 >>
 >> C-x k - kill buffer
 >> C-x K - kill buffer and delete the window

-- 
Kevin

Re: Keybinding nit

[Nick Roberts]

 > >     C-x 4 0 and C-x 5 0 are not at all symmetric, and C-x 4 0 is not
 > >     really intuitive.
 > >
 > >     Maybe one should rather have C-x 4 k and C-x 5 k for killing both
 > >     buffer and window/frame?
 > >
 > > Since C-x k reads a buffer name, I would expect C-x 4 k to
 > > read a buffer name also.
 > 
 > Well, I wouldn't (there are quite a few keybindings where "k" just
 > kills something).  And since neither C-x 0 nor C-x 5 0 kills a buffer,
 > I would not expect C-x 4 0 to do it, either.
 > 
 > It all boils down to what feels more natural and expected.  Of course
 > that is a matter of personal taste, and I like to think my taste is
 > not too far out here.  Other opinions?

If you mean move C-x 4 0 to C-x 5 k, I agree.  (I'm not sure what you want
C-x 4 k to do).

-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Keybinding nit

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > >     C-x 4 0 and C-x 5 0 are not at all symmetric, and C-x 4 0 is not
>  > >     really intuitive.
>  > >
>  > >     Maybe one should rather have C-x 4 k and C-x 5 k for killing both
>  > >     buffer and window/frame?
>  > >
>  > > Since C-x k reads a buffer name, I would expect C-x 4 k to
>  > > read a buffer name also.
>  > 
>  > Well, I wouldn't (there are quite a few keybindings where "k" just
>  > kills something).  And since neither C-x 0 nor C-x 5 0 kills a buffer,
>  > I would not expect C-x 4 0 to do it, either.
>  > 
>  > It all boils down to what feels more natural and expected.  Of course
>  > that is a matter of personal taste, and I like to think my taste is
>  > not too far out here.  Other opinions?
>
> If you mean move C-x 4 0 to C-x 5 k, I agree.  (I'm not sure what you want
> C-x 4 k to do).

Serves me right.  If it weren't for disagreement, I'd have no
agreement at all.  I'd have proposed to move C-x 4 0
(`kill-buffer-and-window') to C-x 4 k and have C-x 5 k be mapped to
`kill-buffer-and-frame' (which does not yet exist).

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Keybinding nit

[Nick Roberts]

 > > If you mean move C-x 4 0 to C-x 5 k, I agree.  (I'm not sure what you want
 > > C-x 4 k to do).
 > 
 > Serves me right.  If it weren't for disagreement, I'd have no
 > agreement at all.  I'd have proposed to move C-x 4 0
 > (`kill-buffer-and-window') to C-x 4 k and have C-x 5 k be mapped to
 > `kill-buffer-and-frame' (which does not yet exist).

Sorry, I misunderstood what C-x 4 0 does (I don't use it).  Yes, C-x 5 k
for kill-buffer-and-frame seems a good idea.


-- 
Nick                                           http://www.inet.net.nz/~nickrob

Re: Keybinding nit

[David Kastrup]

Nick Roberts <nickrob@snap.net.nz> writes:

>  > > If you mean move C-x 4 0 to C-x 5 k, I agree.  (I'm not sure
>  > > what you want C-x 4 k to do).
>  > 
>  > Serves me right.  If it weren't for disagreement, I'd have no
>  > agreement at all.  I'd have proposed to move C-x 4 0
>  > (`kill-buffer-and-window') to C-x 4 k and have C-x 5 k be mapped to
>  > `kill-buffer-and-frame' (which does not yet exist).
>
> Sorry, I misunderstood what C-x 4 0 does (I don't use it).  Yes, C-x
> 5 k for kill-buffer-and-frame seems a good idea.

Well, I checked the age of the binding C-x 4 0, and it is about 10
years old, so it has quite a bit of history and should probably not be
removed in one step, but rather get a companion binding.  I think I
might have discovered `kill-buffer-and-window' quite sooner would it
have had the proposed binding C-x 4 k which I find easier to remember
(that's where I would have suspected the binding to be in the first
place).

Whether or not we do this for Emacs 22 (it would imply messing with
the refcards, but it should be sufficient to just replace the binding
itself and none of the text), I think this should be done eventually.
Keybindings are hard enough to remember, and when they get more
logical, people are more likely to use them.  I find the relation
between C-x k and C-x 4 k much more logical than that of C-x 0 and C-x
4 0 (C-x 4 k implies "do something similar to C-x k, but involving a
window" which is better than C-x 4 0 implying something similar to C-x
0, but involving a buffer).

In fact we have:

`iswitchb-mode' Minor Mode Bindings Starting With C-x 4:
key             binding
---             -------

C-x 4 C-o	iswitchb-display-buffer
C-x 4 b		iswitchb-buffer-other-window

Global Bindings Starting With C-x 4:

---             -------

C-x 4 C-f	find-file-other-window
C-x 4 C-j	dired-jump-other-window
C-x 4 .		find-tag-other-window
C-x 4 0		kill-buffer-and-window
C-x 4 a		add-change-log-entry-other-window
C-x 4 c		clone-indirect-buffer-other-window
C-x 4 d		dired-other-window
C-x 4 f		find-file-other-window
C-x 4 m		compose-mail-other-window
C-x 4 r		find-file-read-only-other-window

[back]

And most commands starting with C-x 4 are variations of C-x or C-x C-
on a window.


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Keybinding nit

[Jan D.]

David Kastrup skrev:
> Richard Stallman <rms@gnu.org> writes:
> 
>>     C-x 4 0 and C-x 5 0 are not at all symmetric, and C-x 4 0 is not
>>     really intuitive.
>>
>>     Maybe one should rather have C-x 4 k and C-x 5 k for killing both
>>     buffer and window/frame?
>>
>> Since C-x k reads a buffer name, I would expect C-x 4 k to
>> read a buffer name also.
> 
> Well, I wouldn't (there are quite a few keybindings where "k" just
> kills something).  And since neither C-x 0 nor C-x 5 0 kills a buffer,
> I would not expect C-x 4 0 to do it, either.
> 
> It all boils down to what feels more natural and expected.  Of course
> that is a matter of personal taste, and I like to think my taste is
> not too far out here.  Other opinions?
> 

I think changing C-x 4 0 to just kill the window and adding C-x 4 k to kill
buffer and window makes sense.

But I have a question for C-x 5 k.  If you have more than one window showing
different buffers in the frame, shall it kill all the buffers, or prompt for
the one to kill?  I'd assume the latter.  The prompt could be skipped if there
is just one buffer shown in that frame.

	Jan D.

Re: Keybinding nit

[David Kastrup]

"Jan D." <jan.h.d@swipnet.se> writes:

> David Kastrup skrev:
>> Richard Stallman <rms@gnu.org> writes:
>> 
>>>     C-x 4 0 and C-x 5 0 are not at all symmetric, and C-x 4 0 is not
>>>     really intuitive.
>>>
>>>     Maybe one should rather have C-x 4 k and C-x 5 k for killing both
>>>     buffer and window/frame?
>>>
>>> Since C-x k reads a buffer name, I would expect C-x 4 k to
>>> read a buffer name also.
>> 
>> Well, I wouldn't (there are quite a few keybindings where "k" just
>> kills something).  And since neither C-x 0 nor C-x 5 0 kills a buffer,
>> I would not expect C-x 4 0 to do it, either.
>> 
>> It all boils down to what feels more natural and expected.  Of course
>> that is a matter of personal taste, and I like to think my taste is
>> not too far out here.  Other opinions?
>
> I think changing C-x 4 0 to just kill the window and adding C-x 4 k to kill
> buffer and window makes sense.
>
> But I have a question for C-x 5 k.  If you have more than one window
> showing different buffers in the frame, shall it kill all the
> buffers, or prompt for the one to kill?  I'd assume the latter.  The
> prompt could be skipped if there is just one buffer shown in that
> frame.

Good catch.  I'd just kill the selected window of the frame.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Keybinding nit

[Stuart D. Herring]

> Serves me right.  If it weren't for disagreement, I'd have no
> agreement at all.  I'd have proposed to move C-x 4 0
> (`kill-buffer-and-window') to C-x 4 k and have C-x 5 k be mapped to
> `kill-buffer-and-frame' (which does not yet exist).

It's obviously of little real importance, what with such convenient
functions as `global-set-key', but in case anyone's interested: obviously
the 0 in C-x 4 0 doesn't parallel the 0 in C-x 0 or C-x 5 0, but it's
possible to think of the 4 as a modifier on the 0 instead of the other way
around.  Since C-x 0 is already a window command, and 4 is a window
modifier, I treat it as an emphatic; -kill- this window (by which I mean
`kill-buffer-and-window', of course) rather than merely -close- it.

(4 also has the meaning of "other window" sometimes, as in C-x 4 f; in
that sense, I have C-x 4 k bound to my own command
`kill-other-buffer-and-window' with obvious semantics.  I frequently use
it after using ediff or help so as to quickly clear my workspace of both
windows and buffers I no longer need.)

Davis

-- 
This product is sold by volume, not by mass.  If it appears too dense or
too sparse, it is because mass-energy conversion has occurred during
shipping.

RE: Keybinding nit

[Drew Adams]

This topic seems to me like something that should be discussed after the
release - it apparently involves a possible new feature or two.

FWIW -

I have no objection to `C-x 4 k' and `C-x 5 k' as proposed. I won't use
them, but I don't object to them.

Personally, I do this, which I find sufficient:

`C-x 0' deletes the selected window. If the window is alone in its frame,
then the frame is also deleted. (I use non-nil `pop-up-frames', so windows
are typically alone, and this typically deletes the frame.)

`C-u C-x 0' reads a buffer name with completion, and deletes all windows
showing that buffer, wherever they are. The current buffer is the default.

`C-x k' reads a buffer name with completion, kills the buffer, and deletes
all of its windows. This is used only interactively; it is not a change to
`kill-buffer'.

Interactively, I never need to kill a buffer and keep its window. If I
really want to keep the window, then I just switch to a different buffer,
without killing the first one.

That's really all I need. `C-x 0' gets rid of windows and frames, and `C-x
k' gets rid of buffers and their windows (and frame, if `one-window-p'). I
think the only case it doesn't cover is deleting a frame when there are
multiple windows - for that I do use `C-x 5 0'.

[FWIW2 - When these commands read a buffer name with completion, you can in
fact kill multiple buffers or delete their windows, by using `C-mouse-2' or
`C-RET' in *Completions*.]

Re: Keybinding nit

[Miles Bader]

Kevin Rodgers <ihs_4664@yahoo.com> writes:
>> Well at least historically, I suppose one reason is because such
>> combinations (control + shift) don't work on ttys.
>
> But that's not what Peter wrote; he's using the same `C-x' prefix
> in all cases, just varying the case of the final key:

Hmmm, good point... :-)

In that case I'd just offer a weaker reason:  It's annoying to type key
sequences where the two components use _different_ modifier keys.

Indeed, even MOD + NO-MOD sequences can be a problem, as it's quite easy
to mis-time releasing the modifier key when typing quickly (I very often
mistype "C-x b" as "C-x C-b"); MOD + DIFFERENT-MOD would be even worse.

[It might be tempting to answer "Well, just don't type those sequences
quickly!" but I find such admonitions simply don't work well in practice
-- people will slow down eventually because they'll get annoyed at all
the times they mistype, but then they'll be annoyed too, and I think
inherently annoying key-sequences should be avoided. :-]

-Miles

-- 
"Nah, there's no bigger atheist than me.  Well, I take that back.
I'm a cancer screening away from going agnostic and a biopsy away
from full-fledged Christian."  [Adam Carolla]

Re: Keybinding nit

[Kevin Rodgers]

Miles Bader wrote:
> Kevin Rodgers <ihs_4664@yahoo.com> writes:
>>> Well at least historically, I suppose one reason is because such
>>> combinations (control + shift) don't work on ttys.
>> But that's not what Peter wrote; he's using the same `C-x' prefix
>> in all cases, just varying the case of the final key:
> 
> Hmmm, good point... :-)
> 
> In that case I'd just offer a weaker reason:  It's annoying to type key
> sequences where the two components use _different_ modifier keys.
> 
> Indeed, even MOD + NO-MOD sequences can be a problem, as it's quite easy
> to mis-time releasing the modifier key when typing quickly (I very often
> mistype "C-x b" as "C-x C-b"); MOD + DIFFERENT-MOD would be even worse.

That all makes perfect sense, but in actual practice I find that there
are commands I use frequently use that aren't bound to keys, and that
the most mnemonic, available keys are C-<foo> Shift-<bar> sequences.

Here are some real examples I've had in my .emacs for years:

(global-set-key "\C-hA" 'apropos)
(global-set-key "\C-xB" 'bury-buffer)
(global-set-key "\C-xI" 'insert-buffer)

And before Emacs 22 (which binds `C-x C-k r' to 
apply-macro-to-region-lines),
I had:

(global-set-key "\C-xE" 'apply-macro-to-region-lines))

I guess you would find those far too annoying to use, but for me they
are just fine.

> [It might be tempting to answer "Well, just don't type those sequences
> quickly!" but I find such admonitions simply don't work well in practice
> -- people will slow down eventually because they'll get annoyed at all
> the times they mistype, but then they'll be annoyed too, and I think
> inherently annoying key-sequences should be avoided. :-]

I learned to touch type in 9th or 10th grade, but I guess I don't type
as quickly as you!

-- 
Kevin

Re: Keybinding nit

[Miles Bader]

Kevin Rodgers <ihs_4664@yahoo.com> writes:
>> Indeed, even MOD + NO-MOD sequences can be a problem, as it's quite easy
>> to mis-time releasing the modifier key when typing quickly (I very often
>> mistype "C-x b" as "C-x C-b"); MOD + DIFFERENT-MOD would be even worse.
>
> That all makes perfect sense, but in actual practice I find that there
> are commands I use frequently use that aren't bound to keys, and that
> the most mnemonic, available keys are C-<foo> Shift-<bar> sequences.

Well of course your MMV.  Still I think it's sufficient reason to be
cautious about using such key sequences in _default_ bindings.

> I learned to touch type in 9th or 10th grade, but I guess I don't type
> as quickly as you!

Or I'm just much more clumsy ... :-)

-Miles

-- 
`Life is a boundless sea of bitterness'

Re: Keybinding nit

[Kevin Rodgers]

Miles Bader wrote:
> Kevin Rodgers <ihs_4664@yahoo.com> writes:
>>> Indeed, even MOD + NO-MOD sequences can be a problem, as it's quite easy
>>> to mis-time releasing the modifier key when typing quickly (I very often
>>> mistype "C-x b" as "C-x C-b"); MOD + DIFFERENT-MOD would be even worse.
>> That all makes perfect sense, but in actual practice I find that there
>> are commands I use frequently use that aren't bound to keys, and that
>> the most mnemonic, available keys are C-<foo> Shift-<bar> sequences.
> 
> Well of course your MMV.  Still I think it's sufficient reason to be
> cautious about using such key sequences in _default_ bindings.

Agreed.

>> I learned to touch type in 9th or 10th grade, but I guess I don't type
>> as quickly as you!
> 
> Or I'm just much more clumsy ... :-)

:-)

-- 
Kevin