$EDITOR and “guix edit”

$EDITOR and “guix edit”

[Simon Tournier]

Hi,

The command “guix edit” returns “+N path/to/file” that is then passed to
$EDITOR.  Therefore $EDITOR needs the command line:

    $ $EDITOR +N /path/to/file

Well, that is accepted by many $EDITOR, to my knowledge.  At least,
Emacs, Vi or less are fine with it.

However, some other $EDITOR does not.  I have in mind “kate” or
“VSCode“,

    $ kate -l N path/to/file
    $ code --goto path/to/file:N

This had been raised in #44272 [1].  The current fix is to wrap $EDITOR
and then make the current correct call.

The question is:

  do we tweak “guix edit” for behaving differently depending on $EDITOR?

or

  do we provide some wrappers for the issues that already popped up?

WDYT?

Cheers,
simon

1: https://issues.guix.gnu.org/44272

Re: $EDITOR and “guix edit”

[Liliana Marie Prikler]

Am Donnerstag, dem 02.11.2023 um 10:43 +0100 schrieb Simon Tournier:
> Hi,
> 
> The command “guix edit” returns “+N path/to/file” that is then passed
> to $EDITOR.  Therefore $EDITOR needs the command line:
> 
>     $ $EDITOR +N /path/to/file
> 
> Well, that is accepted by many $EDITOR, to my knowledge.  At least,
> Emacs, Vi or less are fine with it.
This appears to be a somewhat archaic convention.  Since less used +N,
many other tools inherited it from it; POSIX requires -p for more since
2008 instead (ironically, it laments the incompatibility with vi and
ex, which use -c).

> However, some other $EDITOR does not.  I have in mind “kate” or
> “VSCode“,
> 
>     $ kate -l N path/to/file
>     $ code --goto path/to/file:N
> 
> This had been raised in #44272 [1].  The current fix is to wrap
> $EDITOR and then make the current correct call.
> 
> The question is:
> 
>   do we tweak “guix edit” for behaving differently depending on
> $EDITOR?
> 
> or
> 
>   do we provide some wrappers for the issues that already popped up?
I think we should at least document our behaviour, so that there's
"less surprise" (at the very least, we can point surprised folk towards
the manual/cookbook then).  Going forward, we might want to call upon
some standards committee to finally have +LINE:COL or similar
standardized behaviour for $EDITOR and $VISUAL and then use that.

Cheers

Re: $EDITOR and “guix edit”

[Ludovic Courtès]

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Am Donnerstag, dem 02.11.2023 um 10:43 +0100 schrieb Simon Tournier:
>> Hi,
>> 
>> The command “guix edit” returns “+N path/to/file” that is then passed
>> to $EDITOR.  Therefore $EDITOR needs the command line:
>> 
>>     $ $EDITOR +N /path/to/file
>> 
>> Well, that is accepted by many $EDITOR, to my knowledge.  At least,
>> Emacs, Vi or less are fine with it.
> This appears to be a somewhat archaic convention.

“Archaic” is one way to describe it; I’d have said “standard”.  :-)
(Implemented by Vi(m), Emacs, Nano, less, more, etc.)

>> However, some other $EDITOR does not.  I have in mind “kate” or
>> “VSCode“,
>> 
>>     $ kate -l N path/to/file
>>     $ code --goto path/to/file:N

It’d be nice to support these as well.  However, how do we know we’re
dealing with kate or VSCode?  By checking the basename of $EDITOR?
Kinda ugly and brittle, but probably better than nothing.

Thanks,
Ludo’.

Re: $EDITOR and “guix edit”

[Liliana Marie Prikler]

Am Donnerstag, dem 16.11.2023 um 16:25 +0100 schrieb Ludovic Courtès:
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> 
> > Am Donnerstag, dem 02.11.2023 um 10:43 +0100 schrieb Simon
> > Tournier:
> > > Hi,
> > > 
> > > The command “guix edit” returns “+N path/to/file” that is then
> > > passed to $EDITOR.  Therefore $EDITOR needs the command line:
> > > 
> > >     $ $EDITOR +N /path/to/file
> > > 
> > > Well, that is accepted by many $EDITOR, to my knowledge.  At
> > > least, Emacs, Vi or less are fine with it.
> > This appears to be a somewhat archaic convention.
> 
> “Archaic” is one way to describe it; I’d have said “standard”.  :-)
> (Implemented by Vi(m), Emacs, Nano, less, more, etc.)
I said “archaic”, because POSIX specifically says “all options should
be preceded by the '-' character”, with special exceptions for more,
etc. for backwards compatibility.  It's a bit of a pain, because the
argument that used to be standard among all those tools has (in POSIX
at least) been replaced by several dashed ones.

> > > However, some other $EDITOR does not.  I have in mind “kate” or
> > > “VSCode“,
> > > 
> > >     $ kate -l N path/to/file
> > >     $ code --goto path/to/file:N
> 
> It’d be nice to support these as well.  However, how do we know we’re
> dealing with kate or VSCode?  By checking the basename of $EDITOR?
> Kinda ugly and brittle, but probably better than nothing.
Maybe we can check for a guix_editor shell function and invoke that
rather than EDITOR if defined?

Cheers 

Re: $EDITOR and “guix edit”

[Simon Tournier]

Hi,

On Thu, 16 Nov 2023 at 17:04, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

>> It’d be nice to support these as well.  However, how do we know we’re
>> dealing with kate or VSCode?  By checking the basename of $EDITOR?
>> Kinda ugly and brittle, but probably better than nothing.
>
> Maybe we can check for a guix_editor shell function and invoke that
> rather than EDITOR if defined?

Yeah, from my point of view, the two alternatives [1] are:

  1. do we tweak “guix edit” for behaving differently depending on $EDITOR?

or

  2. do we provide some wrappers for the issues that already popped up?

Where #1 is what Ludo suggests and #2 is what Liliana suggests. :-)

Well, see below the code [2] that we concretely need for VSCode.  The
question is:

 1. Do we put this code in guix/scripts/edit.scm?  And trigger on the
 basename of EDITOR?

or

 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?


WDYT?

Cheers,
simon

--8<---------------cut here---------------start------------->8---
#!/usr/bin/env -S guix repl -q --
;; -*- mode: scheme -*-
!#
;;; Copyright © 2023 Simon Tournier <zimon.toutoune@gmail.com>
;;;
;;;
;;; VSCode does not respect the convention:
;;;
;;;     $EDITOR +line file
;;;
;;; and instead relies on:
;;;
;;;     code --goto file:line
;;;
;;;
;;; This wrapper is a workaround.  It is Scheme but it could be whatever else
;;; as Bash, Python, etc.  It uses "guix repl" although no Guix library is
;;; required.  Because we assume the invokation,
;;;
;;;     EDITOR=./vscode-wrapper guix edit foo bar
;;;
;;; relying on "guix repl" allows to easily get Guile.
;;;

(use-modules (ice-9 match)
             ((ice-9 string-fun) #:select (string-replace-substring))
             ((ice-9 ftw) #:select (scandir))
             )

(define %vscode--goto
  (let* ((vscode-server (string-append (getenv "HOME") "/.vscode-server"))
         (code (if (file-exists? vscode-server)
                   ;; Maybe Remote-SSH
                   (let* ((vscode-server/bin (string-append vscode-server "/bin"))
                          (hash         ;Guess the correct identifier
                           (car
                            (scandir vscode-server/bin
                                     (lambda (file)
                                       (not (member file (list "." ".."))))
                                     (lambda (x y)
                                       (> (stat:mtime
                                           (lstat (string-append vscode-server/bin "/" x)))
                                          (stat:mtime
                                           (lstat (string-append vscode-server/bin "/" y))))))))
                          (vscode (string-append
                                   vscode-server/bin "/" hash "/bin/remote-cli/code"))
                          (run/user/uid (string-append "/run/user/"
                                                       (number->string (getuid))))
                          (socket       ;Guess the correct socket, if required
                           (car
                            (scandir run/user/uid
                                     (lambda (file)
                                       (string-prefix? "vscode-ipc" file))
                                     (lambda (x y)
                                       (< (stat:mtime
                                           (lstat (string-append run/user/uid "/" x)))
                                          (stat:mtime
                                           (lstat (string-append run/user/uid "/" y)))))))))
                     ;; XXXX: Check VSCode API for something more robust
                     (if (getenv "VSCODE_IPC_HOOK_CLI")
                         vscode
                         (string-append
                          "VSCODE_IPC_HOOK_CLI=" socket " " vscode)))
                   ;; No Remote-SSH, try to find the local one in PATH
                   (search-path (string-split (getenv "PATH") #\:)
                                "code"))))
                                        ;(format #t "~a~%" code)
    (string-append code " --goto ")))

(define +line-files
  (match (command-line)
    ((wrapper rest ...)
     (if (eqv? 0 (modulo (length rest) 2))
         rest
         (begin
           (write "Error with 'guix edit'")
           (exit 1))))))

(define files
  (let loop ((files:lines '())
             (lst +line-files))
    (if (null? lst)
        (reverse files:lines)
        (match lst
          ((n file rest ...)
           (loop
            (cons (string-append
                   file ":" (string-replace-substring n "+" ""))
                  files:lines)
            rest))))))

(catch 'system-error
  (lambda ()
    (for-each (lambda (file)
                (system (string-append
                         %vscode--goto file)))
              files))
  (lambda _
    (write "failed to launch!")))
--8<---------------cut here---------------end--------------->8---



1: $EDITOR and “guix edit”
Simon Tournier <zimon.toutoune@gmail.com>
Thu, 02 Nov 2023 10:43:57 +0100
id:86wmv0o5gi.fsf@gmail.com
https://lists.gnu.org/archive/html/guix-devel/2023-11
https://yhetil.org/guix/86wmv0o5gi.fsf@gmail.com

2: https://gitlab.com/zimoun/advanced-packages-2023/-/blob/670b81e9321ee4af2407babd985222cc37f33e31/vscode-wrapper

Re: $EDITOR and “guix edit”

[Liliana Marie Prikler]

Am Montag, dem 20.11.2023 um 10:40 +0100 schrieb Simon Tournier:
> Hi,
> 
> On Thu, 16 Nov 2023 at 17:04, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> 
> > > It’d be nice to support these as well.  However, how do we know
> > > we’re dealing with kate or VSCode?  By checking the basename of
> > > $EDITOR?  Kinda ugly and brittle, but probably better than
> > > nothing.
> > 
> > Maybe we can check for a guix_editor shell function and invoke that
> > rather than EDITOR if defined?
> 
> Yeah, from my point of view, the two alternatives [1] are:
> 
>   1. do we tweak “guix edit” for behaving differently depending on
> $EDITOR?
> 
> or
> 
>   2. do we provide some wrappers for the issues that already popped
> up?
> 
> Where #1 is what Ludo suggests and #2 is what Liliana suggests. :-)
> 
> Well, see below the code [2] that we concretely need for VSCode.  The
> question is:
> 
>  1. Do we put this code in guix/scripts/edit.scm?  And trigger on the
>  basename of EDITOR?
> 
> or
> 
>  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.  With kate we could at
least install a "kate-for-guix-edit" wrapper through the package or
something.

Cheers

Re: $EDITOR and “guix edit”

[Ludovic Courtès]

Hello,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

> Am Donnerstag, dem 16.11.2023 um 16:25 +0100 schrieb Ludovic Courtès:

[...]

>> It’d be nice to support these as well.  However, how do we know we’re
>> dealing with kate or VSCode?  By checking the basename of $EDITOR?
>> Kinda ugly and brittle, but probably better than nothing.
> Maybe we can check for a guix_editor shell function and invoke that
> rather than EDITOR if defined?

‘guix edit’ cannot “invoke” a shell function though.

I was thinking of something more gross, like checking whether the
basename of $EDITOR is ‘kate’ or ‘vscode’ and in that case do whatever
is relevant for those editors.

WDYT?

Ludo’.

Re: $EDITOR and “guix edit”

[Liliana Marie Prikler]

Am Mittwoch, dem 22.11.2023 um 19:21 +0100 schrieb Ludovic Courtès:
> Hello,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> 
> > Am Donnerstag, dem 16.11.2023 um 16:25 +0100 schrieb Ludovic
> > Courtès:
> 
> [...]
> 
> > > It’d be nice to support these as well.  However, how do we know
> > > we’re
> > > dealing with kate or VSCode?  By checking the basename of
> > > $EDITOR?
> > > Kinda ugly and brittle, but probably better than nothing.
> > Maybe we can check for a guix_editor shell function and invoke that
> > rather than EDITOR if defined?
> 
> ‘guix edit’ cannot “invoke” a shell function though.
> 
> I was thinking of something more gross, like checking whether the
> basename of $EDITOR is ‘kate’ or ‘vscode’ and in that case do
> whatever is relevant for those editors.
> 
> WDYT?
I see your gross "checking whether the basename of $EDITOR is ‘kate’…"
and I raise my "use $GUIX_EDITOR which uses substring replacements for
${LINE} and ${FILE} implemented in pure Guile code"

Cheers

Re: $EDITOR and “guix edit”

[Ludovic Courtès]

Hi Liliana,

Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:

>> > Maybe we can check for a guix_editor shell function and invoke that
>> > rather than EDITOR if defined?
>> 
>> ‘guix edit’ cannot “invoke” a shell function though.
>> 
>> I was thinking of something more gross, like checking whether the
>> basename of $EDITOR is ‘kate’ or ‘vscode’ and in that case do
>> whatever is relevant for those editors.
>> 
>> WDYT?
> I see your gross "checking whether the basename of $EDITOR is ‘kate’…"
> and I raise my "use $GUIX_EDITOR which uses substring replacements for
> ${LINE} and ${FILE} implemented in pure Guile code"

I’m not sure I understand your proposal.  Are you suggesting that
‘GUIX_EDITOR’ would contain arbitrary Scheme code that ‘guix edit’ would
evaluate?

Ludo’.

Re: $EDITOR and “guix edit”

[Liliana Marie Prikler]

Am Samstag, dem 09.12.2023 um 10:24 +0100 schrieb Ludovic Courtès:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
> 
> > > > Maybe we can check for a guix_editor shell function and invoke
> > > > that
> > > > rather than EDITOR if defined?
> > > 
> > > ‘guix edit’ cannot “invoke” a shell function though.
> > > 
> > > I was thinking of something more gross, like checking whether the
> > > basename of $EDITOR is ‘kate’ or ‘vscode’ and in that case do
> > > whatever is relevant for those editors.
> > > 
> > > WDYT?
> > I see your gross "checking whether the basename of $EDITOR is
> > ‘kate’…" and I raise my "use $GUIX_EDITOR which uses substring
> > replacements for ${LINE} and ${FILE} implemented in pure Guile
> > code"
> 
> I’m not sure I understand your proposal.  Are you suggesting that
> ‘GUIX_EDITOR’ would contain arbitrary Scheme code that ‘guix edit’
> would evaluate?
No, it'd contain the shell-esque "${LINE}" and "${FILE}" that would get
replaced by Scheme code looking for those strings.

Cheers

Re: $EDITOR and “guix edit”

[Simon Tournier]

Hi,

On Mon, 20 Nov 2023 at 20:33, Liliana Marie Prikler <liliana.prikler@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.

Re: $EDITOR and “guix edit”

[Liliana Marie Prikler]

Am Freitag, dem 12.01.2024 um 10:35 +0100 schrieb Simon Tournier:
> Hi,
> 
> On Mon, 20 Nov 2023 at 20:33, Liliana Marie Prikler
> <liliana.prikler@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.
(let* ((editor (getenv "GUIX_EDITOR"))
       (editor (string-replace-substring editor "${FILE}" the-file))
       (editor (string-replace-substring editor "${LINE}" the-line)))
  editor)
with the-file and the-line being placeholders for the actual variable
names.  You could obviously do smarter things with gash, but let's not
go there at the moment.

> 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.
Speaking of diversity, how well does your wrapper work for Atom?  Or
Kate?  IMHO, going out of our way to specifically support VSCode would
break not one, but at least two of our core principles, whereas
offering an option that you can plug any $EDITOR into would not only be
the technically, but also morally superior choice.
 
Cheers

Re: $EDITOR and “guix edit”

[Simon Tournier]

Hi,

On Fri, 12 Jan 2024 at 18:39, Liliana Marie Prikler
<liliana.prikler@gmail.com> wrote:

> > 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.
>
> (let* ((editor (getenv "GUIX_EDITOR"))
>        (editor (string-replace-substring editor "${FILE}" the-file))
>        (editor (string-replace-substring editor "${LINE}" the-line)))
>   editor)
>
> with the-file and the-line being placeholders for the actual variable
> names.  You could obviously do smarter things with gash, but let's not
> go there at the moment.

I do not understand how it is different from the wrapper I already did:

https://gitlab.com/zimoun/advanced-packages-2023/-/blob/main/vscode-wrapper?ref_type=heads#L70-99

Cheers,
simon

Re: $EDITOR and “guix edit”

[Liliana Marie Prikler]

Am Freitag, dem 12.01.2024 um 19:49 +0100 schrieb Simon Tournier:
> Hi,
> 
> On Fri, 12 Jan 2024 at 18:39, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
> 
> > > 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.
> > 
> > (let* ((editor (getenv "GUIX_EDITOR"))
> >        (editor (string-replace-substring editor "${FILE}" the-
> > file))
> >        (editor (string-replace-substring editor "${LINE}" the-
> > line)))
> >   editor)
> > 
> > with the-file and the-line being placeholders for the actual
> > variable names.  You could obviously do smarter things with gash,
> > but let's not go there at the moment.
> 
> I do not understand how it is different from the wrapper I already
> did:
> 
> https://gitlab.com/zimoun/advanced-packages-2023/-/blob/main/vscode-wrapper?ref_type=heads#L70-99
Look at your wrapper, than back at my suggestion, then back at your
wrapper, then back at my suggestion.  Somehow, your wrapper isn't my
suggestion.  Instead, my suggestion is something else entirely, that
doesn't even mention the M$ editor.  Curious how that works.

Cheers

PS: I should probably just write the patch myself at this point, but I
feel like it'll be misunderstood either way.

Re: $EDITOR and “guix edit”

[Simon Tournier]

On Fri, 12 Jan 2024 at 20:46, Liliana Marie Prikler
<liliana.prikler@gmail.com> wrote:

> PS: I should probably just write the patch myself at this point, but I
> feel like it'll be misunderstood either way.

Sorry but I do not understand how your proposal would work in tandem
with the current "guix edit".  So yes, please send a patch for helping
me (us?) to understand what you suggest.

Cheers,
simon