Re: Bug in elpher/ERC integration

[F . Jason Park]

Hi Troels,

Troels Henriksen <athas@sigkill.dk> writes:

> Sometimes I click on a gopher:// link to a binary file in ERC (the Emacs
> IRC client), which will then invoke elpher to download it.  However,
> it'll eventually fail in `elpher-render-download` because
> `(elpher-page-address elpher-current-page)` returns NIL, and this is not
> a valid value for `elpher-address-gopher-p`.  I think the problem is
> that whatever mechanism invokes elpher through ERC (which I didn't
> manage to trace) doesn't actually switch to an elpher buffer.  Any ideas
> on how to fix it?

By default, ERC relies on `browse-url-button-open-url' for visiting most
links, gemini or otherwise. That is, clicking any "buttonized" URL
should be no different than running M-x browse-url RET. Unfortunately, I
don't know enough about Elpher to be of much use debugging your issue
(although, FWIW, I was unable to reproduce it).

Just glancing at the code in `elpher-get-host-response', I see the
response processor runs outside of the `elpher-with-clean-buffer'
context.

   928  (response-string-parts
   929   (elpher-with-clean-buffer
   930    (insert "Data received.  Rendering..."))
   931   (funcall response-processor
   932            (apply #'concat (reverse response-string-parts)))

Any idea which buffer is supposed to be current during this `funcall'?
Asking because, offhand, I don't see any `set-buffer' calls between that
frame and `elpher-render-download', where it runs by way of
`elpher-visit-previous-page'. But that only happens after the failed
`elpher-page-address' call you highlighted. Maybe try moving it before?

Anyway, chances are that's just unrelated nonsense. Hopefully someone
familiar with the code will chime in.

Good luck!
J.P.