Overhaul counsel-yank-pop

[basil-conto]

Changelog

Please see each commit message in order. The last and most significant commit in particular addresses this Emacs SE question and closes #1190.

Before merging

The function counsel--yank-pop-position is also useful in #1133. If that PR lands first, the function should be removed from this PR. Conversely, if this PR lands first, then #1133 should be rebased to avail of the function.

Question

Is completely ignoring blank kills really that useful? Thoughts on lifting this restriction or making it configurable?

[basil-conto]

Woops, this is wrong for negative ARGs; I'll fix it later today.

[ambihelical]

Potentially replaceable with string-blank-p

[ambihelical]

potentially use string-blank-p here.

[basil-conto]

@ambihelical I would have used string-blank-p too, but the [:blank:] character class matches Unicode whitespace in addition to just tabs and spaces in Emacs 25+. Probably string-blank-p should be updated to use [:blank:].

I'm more concerned about whether we should unconditionally be removing all blank kills from the candidates offered.

[basil-conto]

While trying to fix the :preselect calculation, I realised that filtering kill-ring elements only for the sake of Ivy completion is Doing The Wrong Thing. In particular, it makes relative offsets into the kill-ring inconsistent and meaningless and does not integrate nicely with Emacs.

Nevertheless, I understand why users may want to ignore certain kill-ring elements. I can think of three approaches counsel.el can take in order to Do The Right Thing:

1. Leave the kill ring alone

(elisp) Kill Functions explains that Emacs offers mechanisms for filtering killed text which users can modify to suit their preferences, though I'm not sure whether these can omit blank strings altogether.

Pros:

• Less to worry about.
• Consistent and reliable candidate preselecting.
• Consistency and integration with broader kill ring ecosystem.

Cons:

• Less convenient for and friendly to users.
• Potentially offers no automated way to ignore blank kills.

2. Modify the kill ring; long live the kill ring!

If counsel.el does not want to offer blank kills during completion, it should completely and destructively remove them from the kill ring. Perhaps a regexp/function user option can be provided for customising the filtering operation.

Pros:

• Consistent and reliable candidate preselecting. Kind of; the user has to keep in mind that relative positions into the kill ring skip blank kills.
• Consistency and integration with broader kill ring ecosystem.

Cons:

• Some users (including myself) are opposed to / squeamish about modifying the kill ring.
• Intrusive / non-Emacsy.

3. All of the above

Provide a toggle between leaving the kill ring untouched and destructively filtering it.

Pros:

• Union of pros of approaches 1 and 2.

Cons:

• Intersection of cons of approaches 1 and 2.

---

My personal favorite is 3, for which I'd be happy to provide the code. Thoughts?

[basil-conto]

I've fixed the :preselect calculation for now with a bit of a hack.

[abo-abo]

Thanks.

I realised that filtering kill-ring elements only for the sake of Ivy completion is Doing The Wrong Thing

You mean deleting blanks from the kill-ring? I have no problem with doing that. If it's an issue for you, PR with removing blanks non-destructively.

[basil-conto]

You mean deleting blanks from the kill-ring?

Not exactly. What I think is The Wrong Thing is a) not giving users the choice to complete kill-ring contents without any filtering; and b) having differences between the contents of kill-ring and the completion collection which counsel-yank-pop offers.

Point (a) is simply about user preference. Point (b), on the other hand, is a more subtle problem because many kill/yank commands operate in terms of relative offsets of kill-ring-yank-pointer within kill-ring. When, for example, counsel-yank-pop only displays half the contents of kill-ring, then commands like rotate-yank-pointer, which operate on an unfiltered kill-ring, are likely to give unexpected results.

This is why I think it is important to accompany filtering of kill-ring with actual deletion of filtered elements, so that all kill/yank commands remain consistent and correct.

If that sounds good to you I'll submit another PR to allow toggling kill-ring filtering and accompanying filtering with actual deletion.

[abo-abo]

If that sounds good to you I'll submit another PR to allow toggling kill-ring filtering and accompanying filtering with actual deletion.

Thanks for the explanation. Please PR, with deletion on by default.