Is it possible to make counsel-yank-pop act similarly to evil-insert?

[Custodia]

I have never used emacs without evil mode but I assume normal emacs yank works by inserting the yanked contents before the cursor. In evil mode evil-insert yanks the contents after the cursor, making using counsel-yank-pop feel inconsistent.

Would it be possible to make counsel-yank-pop use evil-insert or otherwise to change the functionality to paste the contents after the cursor? I don't mind setting these up as configurations but I'm not sure as to where to start looking into.

[basil-conto]

I assume normal emacs yank works by inserting the yanked contents before the cursor

Yes, but only when called without C-u (universal-argument). Quoth its docstring:

Reinsert ("paste") the last stretch of killed text.
More precisely, reinsert the most recent kill, which is the
stretch of killed text most recently killed OR yanked.  Put point
at the end, and set mark at the beginning without activating it.
With just C-u as argument, put point at beginning, and mark at end.
With argument N, reinsert the Nth most recent kill.

Quoth (emacs) Yanking:

   The basic yanking command is ‘C-y’ (‘yank’).  It inserts the most
recent kill, leaving the cursor at the end of the inserted text.  It
also sets the mark at the beginning of the inserted text, without
activating the mark; this lets you jump easily to that position, if you
wish, with ‘C-u C-<SPC>’ (see Mark Ring).

   With a plain prefix argument (‘C-u C-y’), the command instead leaves
the cursor in front of the inserted text, and sets the mark at the end.
Using any other prefix argument specifies an earlier kill; e.g., ‘C-u 4
C-y’ reinserts the fourth most recent kill.  See Earlier Kills.

In evil mode evil-insert yanks the contents after the cursor, making using counsel-yank-pop feel inconsistent.

Given the above documentation and that vanilla yank-pop preserves the relative ordering of point and mark after C-uC-y, counsel-yank-pop is inconsistent with Emacs even in the absence of evil-mode.

Would it be possible to make counsel-yank-pop use evil-insert

No, browsing the source of evil-insert indicates that it is a wildly different beast to what we're after here, in addition to coming from an unrelated third-party package which shouldn't be added as a Counsel dependency.

or otherwise to change the functionality to paste the contents after the cursor?

Yes, this should be possible and should be done, given the aforementioned inconsistency with yank/yank-pop. I might have something to show later today (UTC+1) if no-one beats me to it.

[basil-conto]

Perhaps the outcome of this issue can be reported in reply to the following related question on Reddit, if there are any Reddit users here inclined to do so (I'm not a user): https://www.reddit.com/r/emacs/comments/8n3shq/how_to_modify_counselyankpop_evilpasteafter_and/

[basil-conto]

Oh, apparently this has already been brought up in #884, whose resolution I disagree with, given the above.

[basil-conto]

@abo-abo counsel-yank-pop doesn't actually need to set ivy-completion-beg and ivy-completion-end, does it? Aren't those only relevant to in-buffer completion?

[abo-abo]

Thanks.

[Custodia]

Thanks for the quick response,

We're talking about different things though, what I wanted is the same as in #884 to insert the text after point, what you we're talking about and fixed was where the point is after yanking. So my issue isn't solved as the solution for #884 does not work anymore.

Would it be possible to add a boolean variable like counsel-yank-pop-yank-after-point/counsel-yank-pop-paste-after-point that would make the yanked text appear after point? Should I re open this issue?

I'll look at this myself if I get some time later on but I'm currently still very unexperienced with elisp.

[Custodia]

Defining my own custom function wrapping counsel-yank-pop seems to work. Is this an okay way to achieve what I want or is there a better way?

  (defun asdf (&optional arg)
    "Insert S into the buffer, overwriting the previous yank."
    (interactive "P")
    (undo-boundary)
    (forward-char)
    (counsel-yank-pop arg))

[basil-conto]

We're talking about different things though, what I wanted is the same as in #884 to insert the text after point, what you we're talking about and fixed was where the point is after yanking.

Emacs always inserts text before point. The difference between functions which seem to insert before and after point is where they leave point when they're done. Inserting text after point is as simple as saving the initial value of point, inserting the text, and then restoring the saved value of point. So I don't see how we're talking about different things.

So my issue isn't solved as the solution for #884 does not work anymore.

The "solution" to #884 was a user-specific and now obsolete kludge, not a general solution.

Would it be possible to add a boolean variable like counsel-yank-pop-yank-after-point/counsel-yank-pop-paste-after-point that would make the yanked text appear after point?

#1762 added the user option counsel-yank-pop-after-point, which defaults to nil. Setting it to non-nil means counsel-yank-pop defaults to leaving point at the beginning of the yank, and mark at its end. Passing a plain prefix argument (e.g. C-u) to counsel-yank-pop temporarily toggles the value of counsel-yank-pop-after-point.

Should I re open this issue?

If #1762 does not address your feature request, then yes. But please provide a precise, detailed, and reproducible set of steps, along with a description of your expected vs Counsel's actual behaviour at each step, so that we can better understand what you're after.

Defining my own custom function wrapping counsel-yank-pop seems to work. Is this an okay way to achieve what I want or is there a better way?

I understand neither what asdf is meant to achieve, nor how it achieves it. Does Evil redefine forward-char or insert or something? Can you please try out counsel-yank-pop-after-point or, failing that, provide a more detailed description of your issue? I don't understand what you are trying to do that wasn't already covered by #1762, and I don't use Evil, so I don't know how that might be getting in the way.

[basil-conto]

This reminded me that I failed to explain here what #1762 was adding from a user's perspective; I'm sorry about that.

[dieggsy]

The "solution" to #884 was a user-specific and now obsolete kludge, not a general solution.

Can confirm, am no longer using this.