Item deduplication needed on output
remyrd opened this issue · 4 comments
Simply put: name
is not a unique id in bitwarden, and shouldn't be used to retrieve items.
Eg. https://github.com/mattydebie/bitwarden-rofi/blob/master/bwmenu#L97
id
should be used instead.
Problem is I'm not sure rofi can hide part of the input it's been given...
Problem is I'm not sure rofi can hide part of the input it's been given...
It can not. I've tried this before.
fzf
can do it --nth
and --with-nth
options:
-n, --nth=N[,..] Comma-separated list of field index expressions
for limiting search scope. Each can be a non-zero
integer or a range expression ([BEGIN]..[END]).
--with-nth=N[,..] Transform the presentation of each line using
field index expressions
I wish rofi had something similar to this. :(
Just a thought, I believe there are other ways out of this...
- I commented on another issue #12 (comment) and well, assuming the user can "visually" deduplicate the entries since there is more metadata on each item and some templating maps the format to the fields in
ITEMS
, one could use additionalselect()
statements (functions?) injq
to return the one good entry. Still, the user can't expect to get a different entry when selecting the second identical option - Deduplication could be offloaded to another rofi instance, offering initially a list of entries uniquely identified by whatever string the user configures.
When I did Mange/rofi-lpass (LastPass in Rofi) I added the ID to each entry like this:
Some Site [
<ID>
]
Copy password [
<ID>
]
Copy username [<ID>
]
…
Then I could extract the ID on each line.
We could also use the built-in support for Pango markup (with the -markup-rows
option to Rofi) to make the ID markers really small so it doesn't stick out as much.
Maybe the most generic way to handle this is to indeed use a second rofi to finetune the selection.
When you use bwmenu for searching folders this actually already happens. This could be really easy to add imo.