Thank you for the feedback!
Users with a strong need to access often to one particular
field, are better served with a new specific command
(possibly, with a new keybinding for it).
I see what you mean, but the patch was written for specifically those
field which you *don't* often need to access, just to make it a bit
easier to locate them. In case I wasn't clear before, let me clarify a
bit.
Say I often need to access the password, username and url fields in an
entry, but some entries have a few other fields. I can use the
relevant commands specifically for getting the password, username or
url, but I very rarely need to access the 'employee number' field, say
(because only one entry has it maybe).
Then to get the employee number I can use the command to get an
arbitrary field (`ivy-pass--choose-field-action`) and choose 'employee
number'. But obviously, if I had needed the username/password/url I
would have just used the commands that get them, so it can't be any of
the I'm looking for. To make it easier to find what I *am* looking for
then, it's useful if I could always filter them out. Of course, the
list of fields used often might be different for different people, so
I thought a variable was best.
I don't think this is the responsability of `password-store':
it should be implemented on top of it.
Yes, you're right. Ideally this would just be implemented on top in
the interface application, like ivy-pass. That was what I tried to do
originally when I was writing `ivy-pass--choose-field-action`. I
implemented it with `password-store-read-field`. But ivy then just
augments the `completing-read` that `password-store-read-field` uses,
my function doesn't call ivy-read. This meant that the list of
completions had to be set inside `password-store-read-field`,
including any filtering. Hence the patch.
Of course, I could just re-implement the function in ivy-pass, but
that seems like a wasted effort only to duplicate code (which is never
a good thing right?!). I also wonder if being able to filter out
certain fields might be useful for other people with similar
clients. I've never used helm, but I know helm-pass exists and I can
imagine its users might want similar functionality? I don't know.
Either way, if you still don't think it's worth including in pass.el
then that's cool, just so long as I've sent it your way.
Blue skies, Hugo
