CopyQ clipboard only completes on number, not on content
rpatterson opened this issue · comments
When the CopyQ history is selected via clipboard, typing only completes on the CopyQ item number and not on the item contents as I would expect and as is the case for other lists:
┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ ╭──────────────────────────────────────────────────────╮ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ │ │ │
│ 0/94 (0) │ │ │
│ > fzf ╰──────────────────────────────────────────────────────╯ │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
The contents are correct in the "box" to the right:
┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ 45 ╭──────────────────────────────────────────────────────╮ │
│ 35 │ set -g @plugin 'sainnhe/tmux-fzf' │ │
│ 25 │ │ │
│ 15 │ │ │
│ 59 │ │ │
│ 58 │ │ │
│ 57 │ │ │
│ 56 │ │ │
│ 55 │ │ │
│ 54 │ │ │
│ 53 │ │ │
│ 52 │ │ │
│ 51 │ │ │
│ 50 │ │ │
│ > 5 │ │ │
│ 18/92 (0) │ │ │
│ > 5 ╰──────────────────────────────────────────────────────╯ │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
Versions:
$ fzf --version
0.29 (devel)
$ copyq --version
CopyQ Clipboard Manager 7.0.0~jammy
Qt: 5.15.3
KNotifications: 5.92.0
Compiler: GCC
Arch: x86_64-little_endian-lp64
OS: Pop!_OS 22.04 LTS
$ (cd ~/.tmux/plugins/tmux-fzf/ && git log -n 1)
commit 51081a2688579228d860b3cb410f4437e857fc6e (HEAD -> master, origin/master, origin/HEAD)
Author: Sainnhe Park <i@sainnhe.dev>
Date: Thu Jul 6 06:06:31 2023
Fix $TMUX_FZF_ORDER when not in copy mode
┌───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┐
│ 45 ╭──────────────────────────────────────────────────────╮ │
│ 35 │ set -g @plugin 'sainnhe/tmux-fzf' │ │
│ 25 │ │ │
│ 15 │ │ │
│ 59 │ │ │
│ 58 │ │ │
│ 57 │ │ │
│ 56 │ │ │
│ 55 │ │ │
│ 54 │ │ │
│ 53 │ │ │
│ 52 │ │ │
│ 51 │ │ │
│ 50 │ │ │
│ > 5 │ │ │
│ 18/92 (0) │ │ │
│ > 5 ╰──────────────────────────────────────────────────────╯ │
└───────────────────────────────────────────────────────────────────────────────────────────────────────────────────┘
What if you type "plugin" here?
What if you type "plugin" here?
Thanks for the follow up!
I assume you mean instead of 5? Well, I tried it both ways and get the same result, no match. I'm guessing that your thinking is that the quotes might make a difference? To eliminate the variable of special characters all together, I copied foo simple text item to the clipboard, confirmed it was item 0 in the tmux-fzf list and then typed foo, still no match.
LMK if there's anything else I can do to help.
I see. The current implementation will only search for index, doesn't include content. Searching for content and return related index is a bit difficult, and there is no plan to support this yet. PR is welcome :)
Gotcha, may I suggest the help wanted label? Regarding index vs content, can you explain further what tmux-fzf needs from CopyQ that would make this easier to implement? Put another way, what does CopyQ not provide that would make this easier to implement?
I'm guessing that tmux-fzf if currently getting the count of items from CopyQ, using that to assemble the list of indexes and then getting the individual content for each index from CopyQ to fill the box to the right as each item is highlighted in the index list. Can you elaborate on what I got right and wrong there? Would it make this easier to implement if we could get the full contents of all the CopyQ items in one "call", IOW do away with the indexes all together?
Thanks for your time!
Sorry for late reply. I just found a possible solution, I may implement this feature later.
I just tried my previous idea, it doesn't work very well.
What I thought was that we can pipe content from CopyQ to fzf like this:
1 this
1 is
1 the first copy
2 this
2 is
2 the second copy
3 this
3 is
3 the third copy
The first column is the index of a copy and the other columns is the content of a copy.
Then use fzf to select a line and get the index of the copy, and then paste it.
But there is a problem, if the content is too long, for example 1000 rows, the other copies will be hard to view because they are at the bottom.
IMO this is not a good solution.
Regarding index vs content, can you explain further what tmux-fzf needs from CopyQ that would make this easier to implement? Put another way, what does CopyQ not provide that would make this easier to implement?
It's not the case of CopyQ, it's the case of fzf itself. The crux of the problem is how to efficiently search while ensuring that users can view each copy conveniently.
I'm guessing that tmux-fzf if currently getting the count of items from CopyQ, using that to assemble the list of indexes and then getting the individual content for each index from CopyQ to fill the box to the right as each item is highlighted in the index list. Can you elaborate on what I got right and wrong there?
Yes, exactly.
Would it make this easier to implement if we could get the full contents of all the CopyQ items in one "call", IOW do away with the indexes all together?
Do you mean the solution I mentioned above? If so, users cannot browse each copy conveniently.
But there is a problem, if the content is too long, for example 1000 rows, the other copies will be hard to view because they are at the bottom.
...
If so, users cannot browse each copy conveniently.
I'm not sure I'm understanding you correctly yet. How would this be different from the process list which can get quite a large number of items and whose items can be quite long? I thought narrowing down in large lists is tmux-fzf's main use case. It certainly works well in the process list including scrolling forward to the matching bit of long lines and trimming off both the beginning and ending. This is certainly exactly how I want to use tmux-fzf with CopyQ. ;-) Can you elaborate?
Let's say you have 3 copies. Copy 0 has 1000 rows, copy 1 has 20 rows and copy 2 has 3 rows. If a user want to see what's the content in copy 2, he needs to press Down arrow 1020 times. It is unreasonable.
How would this be different from the process list which can get quite a large number of items and whose items can be quite long?
Each line of process list represents a single process, while multiple lines of copyq may represent the same copy.
This is certainly exactly how I want to use tmux-fzf with CopyQ.
People like me may also want to conveniently navigate through each copy.
Each line of process list represents a single process, while multiple lines of copyq may represent the same copy.
Ah, I think I see where we're misunderstanding each other here. What I propose is for each clipboard item, regardless of how many lines it has, to be one line/item in tmux-fzf and to have it's representation in tmux-fzf be just one line, again regardless of how many lines the clipboard item contains, trimmed with ellipses in the same manner as the process list. Newlines in a clipboard item could be represented as \n or something similar in the representation in tmux-fzf. This way as the user, I can use fuzzy matching to narrow the clipboard items to match on and use one arrow press per item to select between them.
...he needs to press Down arrow 1020 times. It is unreasonable
I don't think the small "window" tmux-fzf currently uses to display clipboard item contents is a reasonable or good UX for browsing large clipboard items. I would argue that such use cases are best served outside of tmux-fzf. When a user needs that fine grained inspection of clipboard items, they're better served by using the GUI or CLI that CopyQ provides.
OK, I got it. This sounds reasonable. I'll try to implement this feature later.
Done.