Ludovic Courtès (2015-08-25 23:59 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> Ludovic Courtès (2015-08-18 16:50 +0300) wrote:
>>
>>> Alex Kost <alezost@gmail.com> skribis:
>>>
>>>> And finally, I'm afraid building guix package in a Geiser REPL may not
>>>> be very useful because of <https://github.com/jaor/geiser/issues/28>
>>>> (you have wait for the REPL command to be finished before continuing to
>>>> edit .scm-file).
>>>
>>> Bummer, indeed.  I wonder if that could be worked around by spawning a
>>> new Guile server thread that would be used to build the package, and
>>> opening a new Geiser REPL connected to that thread?  Maybe too complex,
>>> though.
>>
>> That's what I did for *Guix REPL*: it is a server by default, and there
>> is *Guix Internal REPL* which connects to it (there is a commentary
>> about it in "emacs/guix-backend.el").
>>
>> But I don't think it should be done here: as a user I expect that the
>> building will be performed in the current Geiser REPL, so it's up to me
>> (as a user) to decide what repl it is.
>>
>> Also to avoid that limitation, a user can just run another Geiser REPL
>> after the building begins, and can continue to edit a scheme file with
>> the help of the current REPL, while the building will continue in the
>> previous one.  (I will mention this in the manual)
>
> OK, sounds good!

Done.

Ludovic Courtès (2015-09-09 23:11 +0300) wrote:

> Alex Kost <alezost@gmail.com> skribis:
>
>> As a workaround for this issue it was proposed¹ to transform
>> ‘current-build-output-port’ into a procedure (I have checked that it
>> solves the problem).  What do you think about it?  Perhaps to make sure
>> that the port will be always the same define it like this:
>>
>> (define current-build-output-port (memoize current-error-port))
>>
>> Is it acceptable?
>
> No, ‘current-build-output-port’ should remain a SRFI-39 parameter so
> that callers can easily rebind it.
>
> However, perhaps the guix.el code could do:
>
>   (current-build-output-port (current-error-port))
>
> at startup; would that be doable?

Also done.  The workaround appeared to be not so ugly as I thought at
first, thanks for the pointer!