bug#7700: 24.0.50; C-y binding withing Isearch mode

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Dani Moncayo]

[-- Attachment #1: Type: text/plain, Size: 997 bytes --]

Severity: wishlist

Two common task performed when editing with Emacs are (a) Visit some file
and (b) search for some text.

In my case it often happens that the path of the file to visit or the text
to search for is previously copied to the kill ring (or system clipboard),
so that I, intuitively, yank it with C-y.

This works OK when the operation at hand is to visit a file, but it doesn't
in the search case, because in Isearch mode, C-y is bounded to another
command: One that takes the text from point to the end of line as search
text (which is of little use, IMO).

Personally, I find this behavior inconsistent/annoying: I would expect that
C-y within Isearch add text X to the search text, where X is the text that
would be yanked in normal editing.

One solution to fix this would be to swap the bindings of C-y and M-y
withing Isearch mode. Of course I can do that in my .emacs, but if you agree
with my reasoning, it could be make the default.

What do you think?


-- 
Dani Moncayo

[-- Attachment #2: Type: text/html, Size: 1343 bytes --]

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Dani Moncayo]

> One solution to fix this would be to swap the bindings of C-y and M-y withing Isearch mode.

Or even better: make C-y and M-y behave in Isearch "like" in normal
editing (including minibuffer input):
- C-y --> Add text X to the seach text, being X the text that would be
yanked by C-y in normal editing.
- M-y --> If last command was C-y, replace just-yanked text (X) with
the previous text from kill ring.


In this case, the command currently bound to C-y (within Isearch mode)
would have to be bound to another key.

--
Dani Moncayo

PS: My previous post was in HTML format. I'm sorry.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Stefan Monnier]

> Personally, I find this behavior inconsistent/annoying: I would expect that
> C-y within Isearch add text X to the search text, where X is the text that
> would be yanked in normal editing.

FWIW, I'd agree.  I've always found the C-y binding in isearch "useless"
and counter-intuitive.  I'd much rather make C-y and M-y behave like
they do in the minibuffer.


        Stefan

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Lennart Borgman]

On Thu, Dec 23, 2010 at 4:30 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> Personally, I find this behavior inconsistent/annoying: I would expect that
>> C-y within Isearch add text X to the search text, where X is the text that
>> would be yanked in normal editing.
>
> FWIW, I'd agree.  I've always found the C-y binding in isearch "useless"
> and counter-intuitive.  I'd much rather make C-y and M-y behave like
> they do in the minibuffer.


Could we then (if this change is made) please also let C-v do in
isearch what it usually does in cua-mode if cua-mode is on?

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Leo]

On 2010-12-23 15:30 +0000, Stefan Monnier wrote:
> FWIW, I'd agree. I've always found the C-y binding in isearch
> "useless" and counter-intuitive. I'd much rather make C-y and M-y
> behave like they do in the minibuffer.

That's one of the worst and most useless key bindings and surprisingly
it has survived that long.

Leo

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Andreas Schwab]

Leo <sdl.web@gmail.com> writes:

> On 2010-12-23 15:30 +0000, Stefan Monnier wrote:
>> FWIW, I'd agree. I've always found the C-y binding in isearch
>> "useless" and counter-intuitive. I'd much rather make C-y and M-y
>> behave like they do in the minibuffer.
>
> That's one of the worst and most useless key bindings and surprisingly
> it has survived that long.

It's the natural extension of C-w, and I use it very often.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Leo]

On 2010-12-23 17:05 +0000, Andreas Schwab wrote:
> 
> It's the natural extension of C-w, and I use it very often.
>
> Andreas.

Sorry I take my comment back. The issue is that it is on the wrong key.

Leo

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Alan Mackenzie]

Hi, Stefan,

On Thu, Dec 23, 2010 at 10:30:50AM -0500, Stefan Monnier wrote:
> > Personally, I find this behavior inconsistent/annoying: I would expect that
> > C-y within Isearch add text X to the search text, where X is the text that
> > would be yanked in normal editing.

> FWIW, I'd agree.  I've always found the C-y binding in isearch "useless"
> and counter-intuitive.  I'd much rather make C-y and M-y behave like
> they do in the minibuffer.

I use C-y ("grab to next end of line") quite a bit.  But it annoys me
that it's bound to C-y.  I'd prefer C-y to do what M-y currently does,
but please don't unbind "grab to end of line" completely.  How about
swapping C-y and M-y, like the OP suggested?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Stefan Monnier]

> I use C-y ("grab to next end of line") quite a bit.

I'd much rather have a prefix key that lets me use any standard movement
to select the text to grab from the buffer (so "<prefix> C-e" would do
what C-y does and "<prefix> M-f" would do more or less what C-w does).


        Stefan

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Lennart Borgman]

On Fri, Dec 24, 2010 at 3:39 AM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>> I use C-y ("grab to next end of line") quite a bit.
>
> I'd much rather have a prefix key that lets me use any standard movement
> to select the text to grab from the buffer (so "<prefix> C-e" would do
> what C-y does and "<prefix> M-f" would do more or less what C-w does).


I like the logic/mnemonic but wouldn't it would be cumbersome to use it?

I suggest instead that any standard forward movement command while in
isearch forward mode should select the text to grab WITHOUT any prefix
key. For backward movement I suggest a similar logic.

Would not that be both easy to use and remember? (And I think the
logic is so easy for the mind that it would be quick to relearn. In
addition to this is rather similar to how extending the region works
which should make it even easier to remember.)

In addition to this I suggest that standard paste commands (i.e. C-y
yank/C-v cua-paste) paste into isearch search string.

And that M-y (i.e. yank-pop/cua-yank-pop) does the yank popping on the
isearch search string as suggested here.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Dani Moncayo]

On Fri, Dec 24, 2010 at 04:25, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Fri, Dec 24, 2010 at 3:39 AM, Stefan Monnier
> <monnier@iro.umontreal.ca> wrote:
>>> I use C-y ("grab to next end of line") quite a bit.
>>
>> I'd much rather have a prefix key that lets me use any standard movement
>> to select the text to grab from the buffer (so "<prefix> C-e" would do
>> what C-y does and "<prefix> M-f" would do more or less what C-w does).
>
>
> I like the logic/mnemonic but wouldn't it would be cumbersome to use it?
>

Not much, provided that the <prefix> key was required only one time. I
think would be good to have that key as a switch to turn "grabbing
mode" on/off.


> I suggest instead that any standard forward movement command while in
> isearch forward mode should select the text to grab WITHOUT any prefix
> key. For backward movement I suggest a similar logic.
>

I prefer Stefan's proposal because with that there would be no need to
alter the current meaning of prefix arguments in movement commands,
and thus, you could use movement commands _even with prefix arguments_
to both (a) grab text from the buffer, and (b) leave Isearch mode and
move point (all in a single operation, as you can do currently).

I think it would be more consistent/intuitive/powerful.

-- 
Dani Moncayo

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Lennart Borgman]

On Fri, Dec 24, 2010 at 12:39 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
> On Fri, Dec 24, 2010 at 04:25, Lennart Borgman
> <lennart.borgman@gmail.com> wrote:
>> On Fri, Dec 24, 2010 at 3:39 AM, Stefan Monnier
>> <monnier@iro.umontreal.ca> wrote:
>>>> I use C-y ("grab to next end of line") quite a bit.
>>>
>>> I'd much rather have a prefix key that lets me use any standard movement
>>> to select the text to grab from the buffer (so "<prefix> C-e" would do
>>> what C-y does and "<prefix> M-f" would do more or less what C-w does).
>>
>>
>> I like the logic/mnemonic but wouldn't it would be cumbersome to use it?
>>
>
> Not much, provided that the <prefix> key was required only one time. I
> think would be good to have that key as a switch to turn "grabbing
> mode" on/off.

You have to do it every time you want to grab something more. A common
situation is that you have moved from the last hit and then want to
grab more.

>> I suggest instead that any standard forward movement command while in
>> isearch forward mode should select the text to grab WITHOUT any prefix
>> key. For backward movement I suggest a similar logic.
>>
>
> I prefer Stefan's proposal because with that there would be no need to
> alter the current meaning of prefix arguments in movement commands,
> and thus, you could use movement commands _even with prefix arguments_
> to both (a) grab text from the buffer,

Why should that be different from my proposal?

> and (b) leave Isearch mode and
> move point (all in a single operation, as you can do currently).

You just leave isearch once after the search so this way of solving
the problems leads to more key strokes, doesn't it?

And besides, if you happen to forget to leave isearch before a forward
movement command you are still at the right point after it. So you can
just leave it there.

> I think it would be more consistent/intuitive/powerful.

I fail to see why, but I may be biased ;-)

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Dani Moncayo]

On Fri, Dec 24, 2010 at 13:13, Lennart Borgman
<lennart.borgman@gmail.com> wrote:
> On Fri, Dec 24, 2010 at 12:39 PM, Dani Moncayo <dmoncayo@gmail.com> wrote:
>> On Fri, Dec 24, 2010 at 04:25, Lennart Borgman
>> <lennart.borgman@gmail.com> wrote:
>>> On Fri, Dec 24, 2010 at 3:39 AM, Stefan Monnier
>>> <monnier@iro.umontreal.ca> wrote:
>>>>> I use C-y ("grab to next end of line") quite a bit.
>>>>
>>>> I'd much rather have a prefix key that lets me use any standard movement
>>>> to select the text to grab from the buffer (so "<prefix> C-e" would do
>>>> what C-y does and "<prefix> M-f" would do more or less what C-w does).
>>>
>>>
>>> I like the logic/mnemonic but wouldn't it would be cumbersome to use it?
>>>
>>
>> Not much, provided that the <prefix> key was required only one time. I
>> think would be good to have that key as a switch to turn "grabbing
>> mode" on/off.
>
> You have to do it every time you want to grab something more. A common
> situation is that you have moved from the last hit and then want to
> grab more.
>
Maybe there was a misunderstanding here: I didn't mean <prefix> to be
a prefix argument only for the following command. I meant it to be a
command to switch "grabbing" on/off (for the entire Isearch session).


>>> I suggest instead that any standard forward movement command while in
>>> isearch forward mode should select the text to grab WITHOUT any prefix
>>> key. For backward movement I suggest a similar logic.
>>>
>>
>> I prefer Stefan's proposal because with that there would be no need to
>> alter the current meaning of prefix arguments in movement commands,
>> and thus, you could use movement commands _even with prefix arguments_
>> to both (a) grab text from the buffer,
>
> Why should that be different from my proposal?
>
>> and (b) leave Isearch mode and
>> move point (all in a single operation, as you can do currently).
>
> You just leave isearch once after the search so this way of solving
> the problems leads to more key strokes, doesn't it?
>
> And besides, if you happen to forget to leave isearch before a forward
> movement command you are still at the right point after it. So you can
> just leave it there.
>
I definitively misunderstood you.

Your proposal is basically what I had in my mind, but always with
"grabbing" switched on.

In that case I like it, but I would make a small adjustment: Let's
suppose that you are in forward Isearch mode and have grabbed a couple
of words after the point. Then you change your mind and want to grab
only the first word. In that case, would be convenient to allow M-b
without exiting Isearch mode.

Thus, I propose two alternatives:
a) In Isearch (forward or backward), every movement command would
update the grabbed text. If the last grabbed text was in a different
side of the point than current, switch the direction of the Isearch.
b) The same, but replacing the direction switching with "exit Isearch
mode and move point in the buffer".


-- 
Dani Moncayo

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Juri Linkov]

> Thus, I propose two alternatives:
> a) In Isearch (forward or backward), every movement command would
> update the grabbed text. If the last grabbed text was in a different
> side of the point than current, switch the direction of the Isearch.
> b) The same, but replacing the direction switching with "exit Isearch
> mode and move point in the buffer".

ISTR this feature discussed on emacs-devel some time ago as
`isearch-selection-mode'.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Stefan Monnier]

> Not much, provided that the <prefix> key was required only one time. I
> think would be good to have that key as a switch to turn "grabbing
> mode" on/off.

But then means that the equivalent to C-y wouldn't be "<prefix> C-e" but
"<prefix> C-e <prefix>", which is becoming significantly
more burdensome.  We're slowly getting to the point where M-e becomes
a worthy contender.  Maybe it's OK, but I was thinking of something more
lightweight that would only accept one command so as to avoid needing an
additional "exit" key.

>> I suggest instead that any standard forward movement command while in
>> isearch forward mode should select the text to grab WITHOUT any
>> prefix key.

That might be a good choice, but:
- we lack experimental evidence for that.
- it would probably be too big a change to have that as a default behavior.


        Stefan

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Dani Moncayo]

On Sat, Dec 25, 2010 at 05:06, Stefan Monnier <monnier@iro.umontreal.ca> wrote:
>> Not much, provided that the <prefix> key was required only one time. I
>> think would be good to have that key as a switch to turn "grabbing
>> mode" on/off.
>
> But then means that the equivalent to C-y wouldn't be "<prefix> C-e" but
> "<prefix> C-e <prefix>", which is becoming significantly
> more burdensome.  We're slowly getting to the point where M-e becomes
> a worthy contender.  Maybe it's OK, but I was thinking of something more
> lightweight that would only accept one command so as to avoid needing an
> additional "exit" key.
>
Indeed. I take back that suggestion.


>>> I suggest instead that any standard forward movement command while in
>>> isearch forward mode should select the text to grab WITHOUT any
>>> prefix key.
>
> That might be a good choice, but:
> - we lack experimental evidence for that.
> - it would probably be too big a change to have that as a default behavior.
>
IMHO, that proposal would make text grabbing in Isearch (a) More
powerful (you could use every movement command to grab text), and (b)
easier/simpler (you already know the movement commands).

The only drawback I can see is to give up the possibility of exit
Isearch mode with a movement command, but IMO, this loss is
insignificant compared with the benefits.


-- 
Dani Moncayo

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Stefan Monnier]

>>>> I suggest instead that any standard forward movement command while in
>>>> isearch forward mode should select the text to grab WITHOUT any
>>>> prefix key.
>> That might be a good choice, but:
>> - we lack experimental evidence for that.
>> - it would probably be too big a change to have that as a default behavior.
> IMHO, that proposal would make text grabbing in Isearch (a) More
> powerful (you could use every movement command to grab text), and (b)
> easier/simpler (you already know the movement commands).

Compared to the use of a prefix, there is an important difference: the
prefix tells isearch that the next command is a movement command, so it
can be used with *any* command (and can lead to surprises if the command
is not a movement command), whereas in the absence of a prefix, isearch
would need to know which commands are "movement commands", and this
knowledge would always tend to be partial, so it will fail with
some commands.

> The only drawback I can see is to give up the possibility of exit
> Isearch mode with a movement command, but IMO, this loss is
> insignificant compared with the benefits.

Depends significantly on your usage pattern.  I know such a change to
the default behavior would cause screams and never ending arguments.
So we'd fist have to see this change in action for a while to
demonstrate that the benefit is worth the cost of transitioning.


        Stefan

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Lennart Borgman]

On Sat, Dec 25, 2010 at 8:52 PM, Stefan Monnier
<monnier@iro.umontreal.ca> wrote:
>>>>> I suggest instead that any standard forward movement command while in
>>>>> isearch forward mode should select the text to grab WITHOUT any
>>>>> prefix key.
>>> That might be a good choice, but:
>>> - we lack experimental evidence for that.
>>> - it would probably be too big a change to have that as a default behavior.
>> IMHO, that proposal would make text grabbing in Isearch (a) More
>> powerful (you could use every movement command to grab text), and (b)
>> easier/simpler (you already know the movement commands).
>
> Compared to the use of a prefix, there is an important difference: the
> prefix tells isearch that the next command is a movement command, so it
> can be used with *any* command (and can lead to surprises if the command
> is not a movement command), whereas in the absence of a prefix, isearch
> would need to know which commands are "movement commands", and this
> knowledge would always tend to be partial, so it will fail with
> some commands.

Forgot to mention that. There is same problem with extending the
selected region. cua-mode solves this by attaching properties to
movement commands. I think that is a good and flexible solution
(though there could perhaps be custom support for it etc).

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Alan Mackenzie]

Hi Stefan,

On Sat, Dec 25, 2010 at 02:52:49PM -0500, Stefan Monnier wrote:
> >>>> I suggest instead that any standard forward movement command while in
> >>>> isearch forward mode should select the text to grab WITHOUT any
> >>>> prefix key.
> >> That might be a good choice, but:
> >> - we lack experimental evidence for that.
> >> - it would probably be too big a change to have that as a default behavior.
> > IMHO, that proposal would make text grabbing in Isearch (a) More
> > powerful (you could use every movement command to grab text), and (b)
> > easier/simpler (you already know the movement commands).

> Compared to the use of a prefix, there is an important difference: the
> prefix tells isearch that the next command is a movement command, so it
> can be used with *any* command (and can lead to surprises if the command
> is not a movement command), whereas in the absence of a prefix, isearch
> would need to know which commands are "movement commands", and this
> knowledge would always tend to be partial, so it will fail with
> some commands.

> > The only drawback I can see is to give up the possibility of exit
> > Isearch mode with a movement command, but IMO, this loss is
> > insignificant compared with the benefits.

> Depends significantly on your usage pattern.  I know such a change to
> the default behavior would cause screams and never ending arguments.
> So we'd fist have to see this change in action for a while to
> demonstrate that the benefit is worth the cost of transitioning.

I would like to express my strong opposition to all these wild and
visionary schemes which would radically alter isearch.  We don't need
them; isearch works very well as it currently is.

All this talk about encumbering standard commands with prefix keys
"telling isearch that the next command is a movement command", vi-style,
has drowned out the proper topic of this thread (a minimal change to
`isearch-key-map'), and has become tedious and depressing horribly
quickly (IMAO).

Experience shows that threads like this one go nowhere very slowly,
sometimes with 50 or 100 contributions.  They waste time, and make
participation in the list very tedious.  Can we not develop the
discipline not to allow threads like this one to explode out of control?

I think it would be best if proposed developments like this are
implemented rather than endlessly discussed.  We shouldn't really be
discussing big UI changes unless somebody has implemented them and
enthusiastically recommends them.

In the mean time, I would still not be against moving isearch-yank-line
to some key other than C-y.  How about this idea?

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Drew Adams]

> All this talk about encumbering standard commands with prefix
> keys ... has drowned out the proper topic of this thread

And in any case this thread, including its proper topic, is not about a bug.

It is a wishlist topic about a possibile enhancement: an enhancement request.
I'm surprised it wasn't simply summarily sent to the wishlist.

> Experience shows that threads like this one go nowhere...
> They waste time, and make participation in the list very tedious.
> Can we not develop the discipline not to allow threads like this
> one to explode out of control?

Well meant, Alan, but misguided.  The real question is this: Do we want to
discuss this?

If no, let's just send the thread to the wishlist graveyard.  There are plenty
of good suggestions there to keep it company. ;-)

If yes, then the proper list for the discussion (this is _design_, not bug
fixing) is emacs-devel@gnu.org.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Lennart Borgman]

On Mon, Dec 27, 2010 at 11:36 PM, Drew Adams <drew.adams@oracle.com> wrote:
>> All this talk about encumbering standard commands with prefix
>> keys ... has drowned out the proper topic of this thread
>
> And in any case this thread, including its proper topic, is not about a bug.
>
> It is a wishlist topic about a possibile enhancement: an enhancement request.
> I'm surprised it wasn't simply summarily sent to the wishlist.
>
>> Experience shows that threads like this one go nowhere...
>> They waste time, and make participation in the list very tedious.

Yes, implementing it often takes much less time.

I tested to implement this and it took me just a few minutes to get
the first part of it working. Now what do you want me to do with this?

I actually think submitting a new bug report is the best thing. It
might mean killing it as Drew suggested, but as some of us would love
this change it also reminds of Inanna. It will return.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Drew Adams]

> I tested to implement this and it took me just a few minutes to get
> the first part of it working. Now what do you want me to do with this?

Implemented what?

We were in the middle of an open-ended discussion of which binding to use for
what is currently C-y, etc.  AFAIK, nothing was decided.  At least I hope
nothing has been decided.  More discussion is needed of what the best approach
is, IMO.

But this is not the place to design.  If the discussion is to be continued, it
should be moved to emacs-devel.

> I actually think submitting a new bug report is the best thing.

Huh?  What for?  We already have one bug report about this.

The suggestion to use C-y for yank, which those who have discussed it so far
seem to agree on (without agreeing yet about where to put what is now on C-y) is
already logged as _this_ bug report (really an enhancement request).  Why would
we want an additional one?

> It might mean killing it as Drew suggested,

No idea what you mean.  I didn't suggest killing "it", whatever you might mean
by "it".  I didn't suggest killing anything.

My suggestion was to move the discussion of which key to use for what is now C-y
(yank to end of line) to the emacs-devel list.  Nothing more.

It is that discussion that might take a while and is currently incomplete (IMO).

The discussion of whether to let C-y and M-y do what they usually do finished
quickly - at least on the bug list.  Everyone participating so far agreed that
it is a good idea.

But before "implementing" that we should decide where to put the current C-y
behavior.

> but as some of us would love this change it also reminds of
> Inanna. It will return.

What change?  Use C-y in isearch for yanking?  Yes, but then what?

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Lennart Borgman]

On Tue, Dec 28, 2010 at 1:51 AM, Drew Adams <drew.adams@oracle.com> wrote:
>> I tested to implement this and it took me just a few minutes to get
>> the first part of it working. Now what do you want me to do with this?
>
> Implemented what?


You answered to Alan's comment about "wild and visionary schemes"
(which he said he strongly opposed). One of  this schemes were my
suggestion. I implemented that (or at least part of it, copying on
forward movement commands).


> But this is not the place to design.  If the discussion is to be continued, it
> should be moved to emacs-devel.
>
>> I actually think submitting a new bug report is the best thing.
>
> Huh?  What for?  We already have one bug report about this.


I think we now also use the bug list for wishes. Since I think this
discussion already have come to an end with regards to suggestions it
might be time to move it to a bug report.

But it might also be a bit to early.

The reason for moving it is that we otherwise might just forget it.
(If you do not like the suggestion then maybe that would be ok for
you. ;-)



>> It might mean killing it as Drew suggested,
>
> No idea what you mean.  I didn't suggest killing "it", whatever you might mean
> by "it".  I didn't suggest killing anything.


You said "let's just send the thread to the wishlist graveyard".


> It is that discussion that might take a while and is currently incomplete (IMO).


You might be right.


> But before "implementing" that we should decide where to put the current C-y
> behavior.


Sorry for the miscommunication. I just made a quick test
implementation for letting the movement commands copy things into the
search string. It is easily implemented with what we currently have. I
just wanted to tell that since that is an important thing to consider.


>> but as some of us would love this change it also reminds of
>> Inanna. It will return.
>
> What change?  Use C-y in isearch for yanking?  Yes, but then what?


The suggestion to let movement keys by themselves copy the part moved
over to the search prompt ... ;-)

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Drew Adams]

> >> It might mean killing it as Drew suggested,
> >
> > No idea what you mean.  I didn't suggest killing "it", 
> > whatever you might mean by "it".  I didn't suggest
> > killing anything.
> 
> You said "let's just send the thread to the wishlist graveyard".

No I did not.  I said _if_ we do not want to discuss it further then let's send
it there.  I said _if_ we do want to discuss it then let's discuss it at
emacs-devel.

As an enhancement request, this thread is done, IMO.  As a design discussion it
could continue, and the place for that is emacs-devel.

> > What change?  Use C-y in isearch for yanking?  Yes, but then what?
> 
> The suggestion to let movement keys by themselves copy the part moved
> over to the search prompt ... ;-)

That wasn't decided, AFAIK.  If you want to discuss it further, please move it
to emacs-devel.  That's all I was saying.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Andrew W. Nosenko]

On Thu, Dec 23, 2010 at 19:14, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Stefan,
>
> On Thu, Dec 23, 2010 at 10:30:50AM -0500, Stefan Monnier wrote:
>> > Personally, I find this behavior inconsistent/annoying: I would expect that
>> > C-y within Isearch add text X to the search text, where X is the text that
>> > would be yanked in normal editing.
>
>> FWIW, I'd agree.  I've always found the C-y binding in isearch "useless"
>> and counter-intuitive.  I'd much rather make C-y and M-y behave like
>> they do in the minibuffer.
>
> I use C-y ("grab to next end of line") quite a bit.  But it annoys me
> that it's bound to C-y.  I'd prefer C-y to do what M-y currently does,
> but please don't unbind "grab to end of line" completely.  How about
> swapping C-y and M-y, like the OP suggested?

C-e and C-E (aka Ctrl-E and Ctrl-Shift-E)?  C-e because I see no
useful meaning for "go to the end-of-line" inside isearch (if don't
count the real break isearch and go to the end of line), and C-E for
people with CUA "instincts".

-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Andrew W. Nosenko]

On Mon, Dec 27, 2010 at 01:13, Andrew W. Nosenko
<andrew.w.nosenko@gmail.com> wrote:
> On Thu, Dec 23, 2010 at 19:14, Alan Mackenzie <acm@muc.de> wrote:
>> Hi, Stefan,
>>
>> On Thu, Dec 23, 2010 at 10:30:50AM -0500, Stefan Monnier wrote:
>>> > Personally, I find this behavior inconsistent/annoying: I would expect that
>>> > C-y within Isearch add text X to the search text, where X is the text that
>>> > would be yanked in normal editing.
>>
>>> FWIW, I'd agree.  I've always found the C-y binding in isearch "useless"
>>> and counter-intuitive.  I'd much rather make C-y and M-y behave like
>>> they do in the minibuffer.
>>
>> I use C-y ("grab to next end of line") quite a bit.  But it annoys me
>> that it's bound to C-y.  I'd prefer C-y to do what M-y currently does,
>> but please don't unbind "grab to end of line" completely.  How about
>> swapping C-y and M-y, like the OP suggested?
>
> C-e and C-E (aka Ctrl-E and Ctrl-Shift-E)?  C-e because I see no
> useful meaning for "go to the end-of-line" inside isearch (if don't
> count the real break isearch and go to the end of line), and C-E for
> people with CUA "instincts".

Of course, I meant C-e and C-E as alternative key-bindings for the current C-y


-- 
Andrew W. Nosenko <andrew.w.nosenko@gmail.com>

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Drew Adams]

> > Personally, I find this behavior inconsistent/annoying: I 
> > would expect that C-y within Isearch add text X to the
> > search text, where X is the text that
> > would be yanked in normal editing.
> 
> FWIW, I'd agree.  I've always found the C-y binding in
> isearch "useless" and counter-intuitive.  I'd much rather
> make C-y and M-y behave like they do in the minibuffer.

1+

Why not bring it up in emacs-devel, to see what counter arguments there might
be?  I'm thinking that Richard, for example, might express some good reasons
behind the longstanding behavior.

---

Although I haven't used `C-y' in isearch in a long time, I'm not sure its
behavior is "useless".  It would probably be good to have some isearch key
binding for what C-y does now.

Juri might mention that there are few keys available. ;-)

One possibility might be `C-u C-y' (since the C-u behavior for C-y doesn't apply
during isearch), but that would mean sacrificing C-u's ability to exit isearch.
Worse, C-u is currently passed to any exiting key (e.g. `C-u C-n'), which can be
handy.

Personally, I wouldn't mind sacrificing `C-u' for this - I think there are
plenty of keys to exit a search.  But I know that others do object to losing any
exit keys, and `C-u' is also a special case wrt exiting.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Alan Mackenzie]

Hi, Drew!

On Thu, Dec 23, 2010 at 09:28:55AM -0800, Drew Adams wrote:
> > > Personally, I find this behavior inconsistent/annoying: I would
> > > expect that C-y within Isearch add text X to the search text,
> > > where X is the text that would be yanked in normal editing.

> > FWIW, I'd agree.  I've always found the C-y binding in isearch
> > "useless" and counter-intuitive.  I'd much rather make C-y and M-y
> > behave like they do in the minibuffer.

What do they do in the minibuffer?  C-h c doesn't seem to work in the
minibuffer (as it doesn't in isearch also).

> 1+

> Why not bring it up in emacs-devel, to see what counter arguments
> there might be?  I'm thinking that Richard, for example, might express
> some good reasons behind the longstanding behavior.

C-y (as it currently is) helps when you're trying to spot the difference
between two sequences of lines.  You do C-s, repeatedly followed by C-y
until the second occurrance is no longer highlit.  This identifies the
differing line, and C-w then helps pin down the difference within the
line.

> ---

> Although I haven't used `C-y' in isearch in a long time, I'm not sure its
> behavior is "useless".  It would probably be good to have some isearch key
> binding for what C-y does now.

How about M-y?

> Juri might mention that there are few keys available. ;-)

> One possibility might be `C-u C-y' (since the C-u behavior for C-y doesn't apply
> during isearch), but that would mean sacrificing C-u's ability to exit isearch.
> Worse, C-u is currently passed to any exiting key (e.g. `C-u C-n'), which can be
> handy.

C-u C-y is too cumbersome for a key sequence you're likely to want to
repeat.

> Personally, I wouldn't mind sacrificing `C-u' for this - I think there are
> plenty of keys to exit a search.  But I know that others do object to losing any
> exit keys, and `C-u' is also a special case wrt exiting.

C-u is potentially useable by an isearch command (including a
"scrolling" command) to enter a repeat count.  When
`isearch-allow-scroll' is enabled, C-u C-l is a useful key sequence -
for example.  Let's not lose this facility.

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Dani Moncayo]

On Thu, Dec 23, 2010 at 20:23, Alan Mackenzie <acm@muc.de> wrote:
>> Although I haven't used `C-y' in isearch in a long time, I'm not sure its
>> behavior is "useless".  It would probably be good to have some isearch key
>> binding for what C-y does now.
>
> How about M-y?
>

IMO, it would be more consistent that C-y _and M-y_ have an analogous
behavior of that when getting input from the minibuffer, as pointed
out previously.

The command currently bound to C-y can be rebound to another key
(other than C-y and M-y).

-- 
Dani Moncayo

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Drew Adams]

> > How about M-y?
> 
> IMO, it would be more consistent that C-y _and M-y_ have an analogous
> behavior of that when getting input from the minibuffer, as pointed
> out previously.
> 
> The command currently bound to C-y can be rebound to another key
> (other than C-y and M-y).

I agree with that.  If we want C-y to do what it usually does (thus simplifying
the UI for users - fewer things to remember), then we should do the same with
M-y.

The idea is to reduce the possibility of confusion, not increase it or replace
one such possibility with another.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Lennart Borgman]

On Thu, Dec 23, 2010 at 9:48 PM, Drew Adams <drew.adams@oracle.com> wrote:
>
> I agree with that.  If we want C-y to do what it usually does (thus simplifying
> the UI for users - fewer things to remember), then we should do the same with
> M-y.
>
> The idea is to reduce the possibility of confusion, not increase it or replace
> one such possibility with another.

+2 ;-)

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Alan Mackenzie]

Hi, Dani!

On Thu, Dec 23, 2010 at 08:30:41PM +0100, Dani Moncayo wrote:
> On Thu, Dec 23, 2010 at 20:23, Alan Mackenzie <acm@muc.de> wrote:
> >> Although I haven't used `C-y' in isearch in a long time, I'm not sure its
> >> behavior is "useless".  It would probably be good to have some isearch key
> >> binding for what C-y does now.

> > How about M-y?


> IMO, it would be more consistent that C-y _and M-y_ have an analogous
> behavior of that when getting input from the minibuffer, as pointed
> out previously.

> The command currently bound to C-y can be rebound to another key
> (other than C-y and M-y).

Yes, but you've got to suggest one!  Maybe C-M-y for "grab to next line
end".  That's an unused binding, similar to the existing C-y, and lends
itself to easy repetition.

> Dani Moncayo

-- 
Alan Mackenzie (Nuremberg, Germany).

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Drew Adams]

> Yes, but you've got to suggest one!  Maybe C-M-y for "grab to 
> next line end".  That's an unused binding, similar to the
> existing C-y, and lends itself to easy repetition.

It's unused by vanilla Emacs, but I use it. ;-)

No, that's not a great argument to convince the Vanillafold.  But here it is:

I bind `C-M-y' globally to a command that yanks the secondary selection.  (I
also use `C-M-' as the prefix for selecting the secondary.)

And in Isearch I bind `C-M-y' to a command that does the same thing for Isearch.
IOW, it does for the secondary selection just what `M-y' (soon to be `C-y'?)
does for the last kill: it yanks the secondary selection into the search string.

(I cannot understand that others don't bind any keyboard key to yank the
secondary selection, except in so far as they never use the secondary selection.
I use it all the time, including in Isearch.  And the logical binding for it
(for me) is `C-M-y'.)

So in vanilla Emacs too I'd rather see `C-M-y' yank the secondary than yank the
rest of the line.

---

Wrt suggesting some other binding for yanking the rest of the line:

Alan's `C-u C-l' thingy exempts `C-u' from its normal role of exiting Isearch,
_if_ the user customizes `isearch-allow-scroll' to allow it.

The dispensation of `C-u' from exiting is here amalgamated with the choice to
allow scrolling via `C-l'.  The two choices could instead be separated.

IOW, we could have a separate option, `isearch-C-u-exits' (default t), that if
nil exempts `C-u' from exiting in _all_ cases, allowing it to be used in other
ways than just for scrolling.

That's presumably what Alan had in mind when he said:

  C-u is potentially useable by an isearch command
  (including a "scrolling" command)

In that case (`isearch-C-u-exits' = nil, so `C-u' does not exit), we could come
back to my suggestion of letting `C-u C-y' do what `C-y' does now: insert the
rest of the current line.

Yes, that would mean that only users who chose to give up exiting Isearch via
`C-u' could use `C-u C-y' to yank the rest of the line.  Just as, today, only
users who choose to give up exiting via `C-u' can use `C-u C-l' for scrolling
during Isearch.

The other alternative about `C-u' would be, as I mentioned earlier, to just
sacrifice its exiting behavior altogether (no user option).

---

As I mentioned earlier, we are now doing design, and this discussion really
belongs in emacs-devel, IMO.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Dani Moncayo]

On Thu, Dec 23, 2010 at 22:28, Alan Mackenzie <acm@muc.de> wrote:
> Hi, Dani!
>
Hi Alan!  ;)


>> The command currently bound to C-y can be rebound to another key
>> (other than C-y and M-y).
>
> Yes, but you've got to suggest one!

I didn't suggest anyone because that rebinding was (is) not my main
concern here.

In any case, I agree with Drew: Here we are discussing more than just
fixing a bug. So this thread should be forwarded to emacs-devel.

-- 
Dani Moncayo

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Juri Linkov]

> IMO, it would be more consistent that C-y _and M-y_ have an analogous
> behavior of that when getting input from the minibuffer, as pointed
> out previously.
>
> The command currently bound to C-y can be rebound to another key
> (other than C-y and M-y).

C-k is the most natural key for that.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Stefan Monnier]

>> IMO, it would be more consistent that C-y _and M-y_ have an analogous
>> behavior of that when getting input from the minibuffer, as pointed
>> out previously.
>> The command currently bound to C-y can be rebound to another key
>> (other than C-y and M-y).
> C-k is the most natural key for that.

Indeed, it's sounds like a good candidate.


        Stefan

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Drew Adams]

sm>>> FWIW, I'd agree.  I've always found the C-y binding in isearch
sm>>> "useless" and counter-intuitive.  I'd much rather make C-y and M-y
sm>>> behave like they do in the minibuffer.
> 
> What do they do in the minibuffer?  C-h c doesn't seem to work in the
> minibuffer (as it doesn't in isearch also).

da>> Although I haven't used `C-y' in isearch in a long time, 
da>> I'm not sure its behavior is "useless".  It would probably
da>> be good to have some isearch key binding for what C-y does now.
> 
> How about M-y?

To both questions you raise above: C-y and M-y in the minibuffer are the same as
they are in any buffer: C-y yanks the last kill and M-y replaces the text just
yanked with a previous kill.

da>> One possibility might be `C-u C-y' (since the C-u behavior 
da>> for C-y doesn't apply during isearch), but that would mean
da>> sacrificing C-u's ability to exit isearch.
da>> Worse, C-u is currently passed to any exiting key (e.g. 
da>> `C-u C-n'), which can be handy.
> 
> C-u C-y is too cumbersome for a key sequence you're likely to want to
> repeat.

I was thinking that only one C-u would be needed to then let C-y do what it does
now.  IOW, C-u C-y C-y... to repeat.

But I suspect that proposing C-u for this is a non-starter.  I expect that there
will be significant attachment to the use of C-u to both exit isearch and be
passed along to the following command/key as prefix arg.

da>> Personally, I wouldn't mind sacrificing `C-u' for this - I 
da>> think there are plenty of keys to exit a search.  But I know
da>> that others do object to losing any exit keys, and `C-u' is
da>> also a special case wrt exiting.
> 
> C-u is potentially useable by an isearch command (including a
> "scrolling" command) to enter a repeat count.  When
> `isearch-allow-scroll' is enabled, C-u C-l is a useful key
> sequence - for example.  Let's not lose this facility.

OK by me.  I completely forgot about such scrolling.

bug#7700: 24.0.50; C-y binding withing Isearch mode

[Juri Linkov]

> Juri might mention that there are few keys available. ;-)

Yes, there are plenty of keys available :-)

Most often I use the key sequence `C-s M-e C-y C-s' because it allows to
edit the search string before searching.  But of course, `C-y' is the
best key when it's known that the exact search string is in the kill-ring.

The question is what key to use for `isearch-yank-line' instead of `C-y'.

> One possibility might be `C-u C-y' (since the C-u behavior for C-y doesn't apply
> during isearch)

Another possibility is `C-u C-w' because I noticed that I mostly use
`C-y' (with its current binding `isearch-yank-line') after a sequence of
`C-w's, i.e. switching from words to larger units - lines.  Maybe
`C-u C-w C-w C-w C-w ...' should `isearch-yank-line' for multiple lines.

bug#7700: 24.0.50; C-y binding in Isearch mode

[Dani Moncayo]

Hi,

I think this bug can be closed, because with the current trunk, I
already see the behavior requested in the OP, i.e. (within Isearch):
 * C-y is bound to `isearch-yank-kill'
 * M-y is bound to `isearch-yank-pop'


-- 
Dani Moncayo

bug#7700: 24.0.50; C-y binding in Isearch mode

[Stefan Monnier]

> I think this bug can be closed, because with the current trunk, I
> already see the behavior requested in the OP, i.e. (within Isearch):

Thanks, done,


        Stefan