Another keybinding nit for afterwards

Another keybinding nit for afterwards

[David Kastrup]

Hi,

C-y takes a prefix argument where one can indicate what in the
kill-stack to yank.

This is likely rarely used since people will not often remember the
right number.  Instead M-y will normally be used for rotating the
kills around.  M-y refuses to work when the last command has not been
a kill.

I propose changing this in the following manner after the release:

C-y only yanks the top of the kill stack, nothing else.  A prefix
argument will just get used as a multiplicator, like with
self-insert-command.

M-y becomes the command to access the kill stack.  It is _not_
required to follow C-y.  If you don't use it immediately after a yank
command, it will just produce (rather than replace) the top of the
kill stack.

That way, the key sequence for rotating through the stack does not
need to switch between C-y and M-y, and C-y can take a multiplier as a
prefix argument.

I think that is both a more convenient as well as more logical
interface.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Another keybinding nit for afterwards

[Dieter Wilhelm]

David Kastrup <dak@gnu.org> writes:
>
> C-y takes a prefix argument where one can indicate what in the
> kill-stack to yank.
>
> This is likely rarely used since people will not often remember the
> right number.  Instead M-y will normally be used for rotating the
> kills around.  M-y refuses to work when the last command has not been
> a kill.

Thank you David for taking this subject from gnu-emacs-help to
emacs-devel.  (gmane.emacs.help:38196)

> I propose changing this in the following manner after the release:
>
> C-y only yanks the top of the kill stack, nothing else.  A prefix
> argument will just get used as a multiplicator, like with
> self-insert-command.
>
> M-y becomes the command to access the kill stack.  It is _not_
> required to follow C-y.  If you don't use it immediately after a yank
> command, it will just produce (rather than replace) the top of the
> kill stack.

I suggest that M-y should inserts the second entry of the kill-ring by
default, this would be in the line of the previous usage (without--of
course--the need to type C-y beforehand), the first entry in the
kill-ring could be accessed by the argument 0 (C style counting).

Otherwise C-y and M-y would have an unnecessary overlap, in my
opinion.

> That way, the key sequence for rotating through the stack does not
> need to switch between C-y and M-y, and C-y can take a multiplier as a
> prefix argument.
>
> I think that is both a more convenient as well as more logical
> interface.

Moreover, it's an extension of the functionality!

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: Another keybinding nit for afterwards

[Richard Stallman]

    C-y only yanks the top of the kill stack, nothing else.  A prefix
    argument will just get used as a multiplicator, like with
    self-insert-command.

I don't want to make an incompatible change like this without taking a
poll.

RE: Another keybinding nit for afterwards

[Drew Adams]

        C-y only yanks the top of the kill stack, nothing else.  A prefix
        argument will just get used as a multiplicator, like with
        self-insert-command.

    I don't want to make an incompatible change like this without taking a
    poll.

For the poll, I agree with such a change. I also agree that M-y should start
with the 2nd, not the top, kill-ring item.

For the discussion, someone else I think suggested on help-gnu-emacs that a
positive prefix arg to C-y could multiply pastes (like the above proposal)
and a negative prefix arg could continue to pull items from deeper in the
kill-ring. I prefer the simple proposal made above.

I would be curious to know, however, if there was a particular reason for
the current treatment of the C-y prefix arg - what was the rationale? Was it
perhaps done before M-y did what it does?

Re: Another keybinding nit for afterwards

[Richard Stallman]

	I don't want to make an incompatible change like this without taking a
	poll.

    For the poll, I agree with such a change.

The point is to poll the users.  NOT just this list!

    I would be curious to know, however, if there was a particular reason for
    the current treatment of the C-y prefix arg - what was the rationale? Was it
    perhaps done before M-y did what it does?

M-y was in the original Emacs in 1975.  I am pretty sure
that the argument to C-y was equally old.

Re: Another keybinding nit for afterwards

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     C-y only yanks the top of the kill stack, nothing else.  A
>     prefix argument will just get used as a multiplicator, like with
>     self-insert-command.
>
> I don't want to make an incompatible change like this without taking
> a poll.

Certainly.  Personally, I think the proposal an improvement, but it is
an incompatible change.  I was not intending it for Emacs 22: we have
the manuals and reference cards up to date and translated and
proofread.

The whole point was to bring it up so that we can have an opinion poll
before the deadline for Emacs 23 closes.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Another keybinding nit for afterwards

[Dieter Wilhelm]

Richard Stallman <rms@gnu.org> writes:

>     C-y only yanks the top of the kill stack, nothing else.  A prefix
>     argument will just get used as a multiplicator, like with
>     self-insert-command.
>
> I don't want to make an incompatible change like this without taking a
> poll.

FYI:

Discussion at gnu.emacs.help:

In favour: 8 (list below),
against: none 

 Baurzhan Ismagulov <ibr@radix50.net>
 Dieter Wilhelm <dieter@duenenhof-wilhelm.de>
 Mathias Dahl <brakjoller@gmail.com>
 Drew Adams <drew.adams@oracle.com>
 rgb <rbielaws@i1.net>
 Shanks N <shanks.n@gmail.com>   
 David Kastrup <dak@gnu.org>
 Sam Peterson <skpeterson@nospam.please.ucdavis.edu>

(Archived-At: <http://permalink.gmane.org/gmane.emacs.help/38196> and
 Archived-At: <http://permalink.gmane.org/gmane.emacs.help/38265>)
-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: Another keybinding nit for afterwards

[Richard Stallman]

8 people is just a start at a poll.  Usually we get hundreds of answers.

Re: Another keybinding nit for afterwards

[Dieter Wilhelm]

Richard Stallman <rms@gnu.org> writes:

> 8 people is just a start at a poll.  Usually we get hundreds of answers.

Admitted, only the start but a promising one (8:0) 8-)

Could you please give an example how to arrange such a poll after the
release?

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: Another keybinding nit for afterwards

[Richard Stallman]

    Could you please give an example how to arrange such a poll after the
    release?

We will do this poll, after the release.
Please remind me then.

Re: Another keybinding nit for afterwards

[Dieter Wilhelm]

Richard Stallman <rms@gnu.org> writes:
>
> We will do this poll, after the release.
> Please remind me then.

Is 3 month after the release OK, or better more?

-- 
    Best wishes

    H. Dieter Wilhelm
    Darmstadt, Germany

Re: Another keybinding nit for afterwards

[Richard Stallman]

    Is 3 month after the release OK, or better more?

We can do it 1 month after the release, or whenever someone
has time to do the work.

Re: Another keybinding nit for afterwards

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     C-y only yanks the top of the kill stack, nothing else.  A prefix
>     argument will just get used as a multiplicator, like with
>     self-insert-command.
>
> I don't want to make an incompatible change like this without taking a
> poll.

Could we wait with this until after the release.

There are other ways to modify C-y / M-y that make sense to me.
But I don't have time to discuss it now.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Another keybinding nit for afterwards

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>>     C-y only yanks the top of the kill stack, nothing else.  A
>>     prefix argument will just get used as a multiplicator, like
>>     with self-insert-command.
>>
>> I don't want to make an incompatible change like this without
>> taking a poll.
>
> Could we wait with this until after the release.

With things that takes considerable from the developers, sure.  I
don't know the details of doing polls.  If they take a lot of time and
effort, maybe we are doing something wrong.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Another keybinding nit for afterwards

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> With things that takes considerable from the developers, sure.  I
> don't know the details of doing polls.  If they take a lot of time and
> effort, maybe we are doing something wrong.

Before making a poll, we need to present and discuss different
alternatives.  Doing that will take attention off the release.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Another keybinding nit for afterwards

[Richard Stallman]

The need for a poll about a proposed change has nothing to do with how
much WORK it takes to implement the change.  It is because an
incompatible change can make users unhappy.

Re: Another keybinding nit for afterwards

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> The need for a poll about a proposed change has nothing to do with
> how much WORK it takes to implement the change.  It is because an
> incompatible change can make users unhappy.

But the question was how much work it was doing a poll.  Kim explained
some of that: talking out which options to offer at a poll would be
what could be distracting now.

Implementing the change should be rather trivial, checking the callers
and seeing where their interactive arguments should likely be made to
follow suit is more work, changing the documentation throughout even
more, in particular since translations of refcard/tutorial might be
involved.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Another keybinding nit for afterwards

[Richard Stallman]

    But the question was how much work it was doing a poll.

It is a substantial amount of work.  The answers are not just votes,
and they have to be studied thoughtfully.

Re: Another keybinding nit for afterwards

[Neil Roberts]

On Fri, Oct 27, 2006 at 10:58:30PM +0200, David Kastrup wrote:

> C-y only yanks the top of the kill stack, nothing else.  A prefix
> argument will just get used as a multiplicator, like with
> self-insert-command.

Can I suggest that a similar change be made for insert-register? At
the moment the prefix argument makes insert-register leave the point
after the inserted text, but you could still acheive the same affect
with very few extra keystrokes by typing 'C-x x' after the insert to
swap the point and mark. Using the prefix to make it insert multiple
copies seems more intuitive and is like vi.

- Neil

Re: Another keybinding nit for afterwards

[Juri Linkov]

> That way, the key sequence for rotating through the stack does not need
> to switch between C-y and M-y, and C-y can take a multiplier as
> a prefix argument.
>
> I think that is both a more convenient as well as more logical
> interface.

I for one appreciate such improvements, since the combination C-y/M-y
is not perfect yet.

Meanwhile, after rereading the docstring of C-y, I propose a small
improvement for its documentation in the coming release - to replace
part of its docstring:

  See also the command M-y.

with

  See also the command `yank-pop' (M-y).

i.e. to apply a patch like below:

-See also the command \\[yank-pop]."
+See also the command `yank-pop' (\\[yank-pop])."

-- 
Juri Linkov
http://www.jurta.org/emacs/

Re: Another keybinding nit for afterwards

[Richard Stallman]

    -See also the command \\[yank-pop]."
    +See also the command `yank-pop' (\\[yank-pop])."

That is ok; please do.

Re: Another keybinding nit for afterwards

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> Hi,
>
> C-y takes a prefix argument where one can indicate what in the
> kill-stack to yank.
>
> This is likely rarely used since people will not often remember the
> right number.  Instead M-y will normally be used for rotating the
> kills around.  M-y refuses to work when the last command has not been
> a kill.
>
> I propose changing this in the following manner after the release:
>
> C-y only yanks the top of the kill stack, nothing else.  A prefix
> argument will just get used as a multiplicator, like with
> self-insert-command.
>
> M-y becomes the command to access the kill stack.  It is _not_
> required to follow C-y.  If you don't use it immediately after a yank
> command, it will just produce (rather than replace) the top of the
> kill stack.
>
> That way, the key sequence for rotating through the stack does not
> need to switch between C-y and M-y, and C-y can take a multiplier as a
> prefix argument.
>
> I think that is both a more convenient as well as more logical
> interface.


I often find that after using C-y M-y ..., the next time I use C-y, I
usually want to insert the previous head of the kill-ring (as yanked
by the first C-y).  To facilitate this, I want a M-y following the C-y
to only temporarily rotate the kill ring.

To permanently rotate the kill-ring, I would like to use M-y M-y ... (i.e.
start with M-y rather than C-y).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Another keybinding nit for afterwards

[Slawomir Nowaczyk]

On Wed, 01 Nov 2006 14:16:39 +0100
storm@cua.dk (Kim F. Storm) wrote:

#> > I think that is both a more convenient as well as more logical
#> > interface.
#> 
#> I often find that after using C-y M-y ..., the next time I use C-y, I
#> usually want to insert the previous head of the kill-ring (as yanked
#> by the first C-y). To facilitate this, I want a M-y following the C-y
#> to only temporarily rotate the kill ring.
#> 
#> To permanently rotate the kill-ring, I would like to use M-y M-y ...
#> (i.e. start with M-y rather than C-y).

FWIW, I think this is a great idea... I too am often annoyed by
kill-ring getting rotated.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

If at first you don't succeed, redefine success.

Re: Another keybinding nit for afterwards

[David Kastrup]

Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:

> On Wed, 01 Nov 2006 14:16:39 +0100
> storm@cua.dk (Kim F. Storm) wrote:
>
> #> > I think that is both a more convenient as well as more logical
> #> > interface.
> #> 
> #> I often find that after using C-y M-y ..., the next time I use C-y, I
> #> usually want to insert the previous head of the kill-ring (as yanked
> #> by the first C-y). To facilitate this, I want a M-y following the C-y
> #> to only temporarily rotate the kill ring.
> #> 
> #> To permanently rotate the kill-ring, I would like to use M-y M-y ...
> #> (i.e. start with M-y rather than C-y).
>
> FWIW, I think this is a great idea... I too am often annoyed by
> kill-ring getting rotated.

It sounds obscure to make this difference by the initial C-y/M-y
choice.  Maybe instead C-u M-y should revert the last rotation?  Then
one would not need to think in advance about whether one wants it
undone later.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Another keybinding nit for afterwards

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> I often find that after using C-y M-y ..., the next time I use C-y, I
> usually want to insert the previous head of the kill-ring (as yanked
> by the first C-y).  To facilitate this, I want a M-y following the C-y
> to only temporarily rotate the kill ring.
>
> To permanently rotate the kill-ring, I would like to use M-y M-y ... (i.e.
> start with M-y rather than C-y).

I have created a new option cua-paste-pop-rotate-temporarily which
implements this functionality for C-y (and C-v) + M-y when cua-mode is
enabled.

Of course, it is off by default, but people may give it a try...

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Another keybinding nit for afterwards

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> storm@cua.dk (Kim F. Storm) writes:
>
>> I often find that after using C-y M-y ..., the next time I use C-y,
>> I usually want to insert the previous head of the kill-ring (as
>> yanked by the first C-y).  To facilitate this, I want a M-y
>> following the C-y to only temporarily rotate the kill ring.
>>
>> To permanently rotate the kill-ring, I would like to use M-y M-y
>> ... (i.e.  start with M-y rather than C-y).
>
> I have created a new option cua-paste-pop-rotate-temporarily which
> implements this functionality for C-y (and C-v) + M-y when cua-mode
> is enabled.
>
> Of course, it is off by default, but people may give it a try...

I think it a mistake to sneak functionality like that in by going
through packages that are pretty much unrelated.  People who want to
try something like that are quite orthogonal to people who would want
to use cua-mode.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Another keybinding nit for afterwards

[Miles Bader]

David Kastrup <dak@gnu.org> writes:
>> I have created a new option cua-paste-pop-rotate-temporarily which
>> implements this functionality for C-y (and C-v) + M-y when cua-mode
>> is enabled.
>
> I think it a mistake to sneak functionality like that in by going
> through packages that are pretty much unrelated.  People who want to
> try something like that are quite orthogonal to people who would want
> to use cua-mode.

Especially since cua-mode _already_ has way too many "commingled"
features which are conceptually unrelated -- cua-mode should be split
up, not more "features" added to it...

-Miles

-- 
Everywhere is walking distance if you have the time.  -- Steven Wright

Re: Another keybinding nit for afterwards

[Kim F. Storm]

Miles Bader <miles@gnu.org> writes:

> David Kastrup <dak@gnu.org> writes:
>>> I have created a new option cua-paste-pop-rotate-temporarily which
>>> implements this functionality for C-y (and C-v) + M-y when cua-mode
>>> is enabled.
>>
>> I think it a mistake to sneak functionality like that in by going
>> through packages that are pretty much unrelated.  People who want to
>> try something like that are quite orthogonal to people who would want
>> to use cua-mode.
>
> Especially since cua-mode _already_ has way too many "commingled"
> features which are conceptually unrelated -- cua-mode should be split
> up, not more "features" added to it...

I have tried to split them apart, but it is very hard to do!

The problem is that with CUA, C-x, C-c, C-v works seamlessly with both
normal regions and rectangles, so there is no easy way to split CUA's
rectangle handling from the rest of CUA.  Likewise, the CUA's global
mark commands use the same keys in an equally seamless way.
And on top of that, CUA register prefixes work seamless with all of
those commands.

I have gone part of the way by splitting the rectangle and global mark
commands into separate .el files, but the base functionality still has
to "commingle" all of them together.

Sure, there are some tiny things like cursor control and tweaks to the
mark and yank commands which really don't belong in CUA, but again,
some of these also need to interact with e.g. the rectangle and global
mark functionality, so they are also non-trivial to un-commingle.

Maybe if we turn the bucket upside down and provide some form of hooks
directly into the basic yank, kill-region, etc commands, which the
various parts of CUA can use, then things might be done differently.

That may be something for Emacs 23, if I can find the right set of
hooks and RMS subsequently approves to make those changes.
It was hard enough for me to get the command remapping and
emulation-mode-map-alists functions into Emacs 22 just to allow the
current CUA mode to work as well as it actually does (check the mail
archives if you don't believe me :-).

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Another keybinding nit for afterwards

[Richard Stallman]

    Maybe if we turn the bucket upside down and provide some form of hooks
    directly into the basic yank, kill-region, etc commands, which the
    various parts of CUA can use, then things might be done differently.

It is an approach worth exploring.

Re: Another keybinding nit for afterwards

[Richard Stallman]

    Especially since cua-mode _already_ has way too many "commingled"
    features which are conceptually unrelated -- cua-mode should be split
    up, not more "features" added to it...

I agree.

Re: Another keybinding nit for afterwards

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> I think it a mistake to sneak functionality like that in by going
> through packages that are pretty much unrelated.  

I actually agree, but what's the alternative?  I'm sure nobody would
dare to suggest changing the standard yank and yank-pop commands now.

In any case, cua is mostly about "mark, cut and paste" ... so it's not
completely unrelated.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk