Hi Michael, Michael Albinus writes: >> No. >> >> This patch/bug report addresses a real problem that exists independently >> of what triggered it in my case. > > The problem happens when epa-file-handler is removed from > file-name-handler-alist, and no other handler responsible for *.gpg > files is active. Understood. > > However, in normal use cases, nobody removes this handler. If I'm wrong, > I'd like to iunderstand those use cases. Based on observations during the last 24h I've noticed that many Emacs functions do, in fact, reset f-n-h-a to nil. I'm yet to spot the combination of calls that leaves epa-file not added back in. I know that it happens sporadically, though, and that it does not appear to be via a let-binding, following passwords failing to fetch correctly, I can't open PGP-encrypted files. The latter fact is how I initially figured to inspect auth-source-pass. > So we must document, that auth-source-pass.el depends on such a > handler. We could also add a check, that there is such a handler, and > return either nil if it is missing, or return an error. As a first step, > we could add a note in the manual, see (info "(auth) The Unix password store") An error is preferable. IIRC, auth-source caches negatives too. > Just implementing an alternative doesn't sound the right way. This would > also increase maintainance burden, if something changes how *.gpg files > shall be handled. I see where you're coming from. I propose refactoring EPA to expose a function to insert encrypted file contents as if via i-f-c, but without requiring f-n-h-a as a solution to that issue. That could lead to a more consistent user experience, too. > As example, remote files won't work when tramp-file-name-handler is > removed from file-name-handler-alist. It would be a strange approach to > implement a Tramp alternative in packades depending on Tramp, just in case. Correct. The difference here is that password store entries are by definition PGP-encrypted files. They are not by definition possibly remote files exposed via TRAMP. The latter working is a nicety of Emacs design. The former is crucial to interacting with the password store. >> Your gut's nearly certainly right here :-) I am still hunting for the >> cause of that issue. > > Good. > >> Regardless, what I said initially holds true ultimately: either epa-file >> should not be relied on, or a-s-p should ensure it is present. I >> gravitate towards the former, as it reduces the complexity of getting a >> password-store entry. > > I vote for the latter, because it simplifies overall maintainability. I disagree. I think that involving the f-n-h-a mechanism for handling PGP files ultimately introduces implicitly far more complexity, even if the code is slightly briefer, precisely because of this dependency. In addition, the user can't reasonably customize reading PGP files substantially without breaking the contract with the password store. This, to me, means that supporting that scenario isn't very useful, especially in a program like Emacs, where any component can be changed on the fly, leaving the user with the option of customizing more directly. Thanks, have a lovely day! -- Arsen Arsenović