Hi,
On Mon, 20 Nov 2023 at 20:33, Liliana Marie Prikler <liliana.prik...@gmail.com>
wrote:
>> 2. Do we put this code in some etc/vscode-wrapper that user can
>> install? (or that we could automatically installl) Or maybe revamp
>> it
>> for calling this code via some shell function?
>
> With VSCode et al. not being Guix packages, I see little point in
> providing these wrappers through Guix itself.
I do not want to address here where to keep VSCode support and instead I
would like to address $EDITOR which does not follow the good ol’
fashion.
Well, I see how to write specific Scheme wrapper around $EDITOR; as I
did in [1].
Or, I see how to tweak guix/scripts/edit.scm for running specific
launcher depending on $EDITOR.
Liliana, could you provide a proof-of-concept about « the shell-esque
"${LINE}" and "${FILE}" that would get replaced by Scheme code looking
for those strings »? Because I do not see what you mean.
Cheers,
simon
1:
https://gitlab.com/zimoun/advanced-packages-2023/-/blob/main/vscode-wrapper?ref_type=heads
PS:
About VSCode. Somehow, it is a chicken-or-the-eggs problem. “We“
cannot complain with lengthy threads about the lack of contributor
diversity, or that many Guix tools are Emacs-centric, etc. and in the
same time say no because VSCode is not packaged in Guix proper.
We like it or not – I do not like it and do not use it! – for sure,
VSCode is currently one of the most used editor around. Being friendly
with VSCode users would help to have more contributions from them.
