Hi Michael, Michael Albinus writes: > Arsen Arsenović writes: > > Hi Arsen, > >>>> 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. >>> >>> I disagree with your disagreement, and agree with Michael here. I see >>> no maintainer's complexity in using file-name handlers that could be >>> avoided by not using them: file-name handlers are, and will always be, >>> an integral part of Emacs internals, so thinking about them as >>> "complexity" makes no more sense than, say, thinking about GC as >>> complexity. >> >> In that case, auth-source-pass should ensure it's there. This is where >> the complexity I refer to creeps in. Now auth-source-pass needs to >> alter and restore file-name-handler-alist as appropriate. This means >> that it has to get involved with global state, potentially impacting >> other functions it calls. > > No, auth-source-pass should not enable it on its own I believe. It > should fire an error, which hopefully produces a backtrace. This > backtrace would help us to understand, what's up. I doubt that it would produce a useful backtrace, because I doubt a well-behaved let-binding is causing an error (as I said, when I notice this bug, epa-file stops working everywhere, even long after a potential let-binding would've been unbound, implying that it gets unset via some other means). Nonetheless, it is worth a shot. I will inject a check into my currently running Emacs and see what happens. I think erroring is an acceptable solution, though (but I do not think the same of returning nil). >> It seems to me more reliable to alter EPA to provide an >> insert-file-contents functions for direct use. This is less composable >> and elegant than file-name handlers, naturally, but it is also exactly >> what a password-store read requires. > > No. There is no reason to implement this. It would prevent a potential error (the one suggested above) when it is clear how a file must be read (which is always, as password-store entries are always exactly PGP-encrypted files). I'm also not sure how complex the heuristic for emitting this error would be. (memq epa-file-handler file-name-handler-alist) is not adequate as non-EPA handlers for PGP files could be active and/or preferred. (assoc (car epa-file-handler) file-name-handler-alist) is also not quite correct as regexes not exactly equal to (car epa-file-handler) could still match PGP files. I'm willing to implement a solution if you know a better heuristic. Thanks, have a lovely day. -- Arsen Arsenović