Re: $EDITOR and “guix edit”
On Fri, 12 Jan 2024 at 20:46, Liliana Marie Prikler 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
Re: $EDITOR and “guix edit”
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 > 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”
Hi, On Fri, 12 Jan 2024 at 18:39, Liliana Marie Prikler 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”
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 > 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”
Hi, On Mon, 20 Nov 2023 at 20:33, Liliana Marie Prikler 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”
Am Samstag, dem 09.12.2023 um 10:24 +0100 schrieb Ludovic Courtès: > Hi Liliana, > > Liliana Marie Prikler 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”
Hi Liliana, Liliana Marie Prikler 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”
Am Mittwoch, dem 22.11.2023 um 19:21 +0100 schrieb Ludovic Courtès: > Hello, > > Liliana Marie Prikler 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”
Hello, Liliana Marie Prikler 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”
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 > 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”
g-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 Thu, 02 Nov 2023 10:43:57 +0100 id:86wmv0o5gi@gmail.com https://lists.gnu.org/archive/html/guix-devel/2023-11 https://yhetil.org/guix/86wmv0o5gi@gmail.com 2: https://gitlab.com/zimoun/advanced-packages-2023/-/blob/670b81e9321ee4af2407babd985222cc37f33e31/vscode-wrapper
Re: $EDITOR and “guix edit”
Am Donnerstag, dem 16.11.2023 um 16:25 +0100 schrieb Ludovic Courtès: > Liliana Marie Prikler 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”
Liliana Marie Prikler 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”
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
$EDITOR and “guix edit”
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