Pass contrib layer

[oppenlander]

Adds pass functionality under the SPC P s prefix.

[robbyoconnor]

👍 I want this!

[darkfeline]

I'm a fellow pass user who submitted a duplicate PR here: #3341

I'd like to suggest two changes:

1. Change password-store's completing read function to Helm.
2. Add the command in the linked PR, which is a combination of copy and show: it copies the password (the first line in the output) to the clipboard, and displays the remaining lines (information such as username) in a temporary buffer. This is something that I use a lot, and I think other pass users would benefit from it. If not, I can always keep it in my personal config.

[oppenlander]

Updated to follow new layer layout.

Also added some functions, which provide access to pass's multi-line entries.
Thanks @darkfeline, I didn't know about it!

[darkfeline]

Looks good, looking forward to merge.

[robbyoconnor]

❤️

[darkfeline]

I think you have a "security vulnerability" in your describe function. Namely, you're outputting sensitive information to Emacs's Messages buffer. This means that if someone gets access to your computer in any way, they'll have all of your passwords, in plain text, sitting in Emacs's memory.

Also bump for attention.

[bogdanteleaga]

What's the status of this atm?

[oppenlander]

@bogdanteleaga Forgot about this, and have been using it as a private layer.

@darkfeline Wouldn't this be true for the temporary buffer solution you were using?

I don't use the multi-line feature, so I don't know what would be useful here.
Do people mostly use it for multiple passwords, or for describing passwords?

[darkfeline]

@oppenlander My layer outputs the description multi-lines to a temporary buffer that is killed when "q"uitted, unlike the Messages buffer which tends to persist unless manually killed or cleared.

[divansantana]

@oppenlander are you aware of auth-password-store to:

 Integrate Emacs' auth-source with password-store 

It seems fitting to include it in this layer. Adds really nice integration between the two for crendentials lookup.

[jellelicht]

Will this till be merged, or does it make more sense to just include the relevant code in one of my private layers?

[robbyoconnor]

There's a lot of stuff that should be merged...we don't want to burn out @syl20bnr

If you want it NOW -- put in your private layer until it's merged...patience grasshopper.

[rgrinberg]

This PR was submitted in 2015. I don't believe that asking for patience is appropriate.

[robbyoconnor]

@rgrinberg it's one or two people merging pull requests...cut them some slack. They're giving you a product for free..

[rgrinberg]

And I'm extremely grateful for their work. That doesn't mean I shouldn't ask questions.

So while I very much disagree with your first comment that what we need is more patience, I'm also in total agreement with you against burning out @syl20bnr and his co-maintainer. Which is exactly why I'm questioning the necessity of one person reviewing every single new layer. There's a good chance the maintainers will never use this layer personally. And it goes without saying that they're still free to change the layer as they wish after a merge. The only difference is that they'd have a lot more experience reports from users and even contributions.

[robbyoconnor]

@rgrinberg -- I don't know why it sat for so long -- The policy is (or used to be?) that new layers must be approved by @syl20bnr himself...which is where the bottleneck currently stands... I see that this is already assigned to him...so he knows it exists -- I don't know how he's priorititizing PRs right now...I'm sure he has his own stuff he wants to do PLUS make sure community layers get merged...since it's wat spacemacs is about after all. The plea for patience was/is is still going to be there -- because I wouldn't wanna see him burn. or his maintainers burn out.

[rgrinberg]

I agree with that you said but we must recognize that current policy will burn out both the maintainers and the contributors. It's a simple fact that while @syl20bnr has been extremely generous with his time, he only has a finite amount of it. So if the project gets popular enough, there will be a point where the stream of contributions will surely start accumulating. The only question here is that are we at that point yet? I think we're way past it. Which is why I believe the policy is suspect and has to be re-examined.

[robbyoconnor]

I mean I would volunteer to look at PRs if @syl20bnr allowed me to...we can all review and triage PRs/issues.

[robbyoconnor]

There are a lot of long-time community members around here.

[fiveNinePlusR]

As it stands there are over 1000 issues and over 300 pull requests. that's simply too much for one person to do as a side project. perhaps something akin to how Linus handles linux... each sub-group has a responsibility and then when the pull requests/patches look good it will be pushed up the ladder for Linus to merge it into the kernel.

[rgrinberg]

I agree. I think if a new layer has been well tested by users and reviewed by a long time contributor like @robbyoconnor then he should be able to merge it. The question is, where do we have the discussion about how to amend the merge policy?

[fiveNinePlusR]

you could do it in a separate issue or on the gitter chat I suppose.

[robbyoconnor]

See #8686

[syl20bnr]

Thank you ! 👍
I moved the key bindings under SPC A p introducing the new prefix SPC A for "other applications".
Cherry-picked into develop branch, you can safely delete your branch.