[PATCH] scripts: edit: Accept generic formatting parameter.

  • Open
  • quality assurance status badge
Details
3 participants
  • Liliana Marie Prikler
  • Ludovic Courtès
  • Simon Tournier
Owner
unassigned
Submitted by
Liliana Marie Prikler
Severity
normal
L
L
Liliana Marie Prikler wrote on 13 Jan 00:35 +0100
(address . guix-patches@gnu.org)
9a666abbf1cb4b7548c1a117eaa04b0de02145ae.1705103171.git.liliana.prikler@gmail.com
This will hopefully end the opening of unwanted files.

* guix/scripts/edit.scm (%location-format): New parameter.
(location->location-specification): Use %location-format.
(spawn-editor): Adjust accordingly.

Fixes: Pass special flags to ‘kate’ https://bugs.gnu.org/44272#14
---
doc/guix.texi | 18 ++++++++++++++++++
guix/scripts/edit.scm | 20 ++++++++++++++------
2 files changed, 32 insertions(+), 6 deletions(-)

Toggle diff (84 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index 811edd0bf7..8dca1272a2 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -13987,6 +13987,24 @@ Invoking guix edit
@var{directory}}) allows you to add @var{directory} to the front of the
package module search path and so make your own packages visible.
+By default, Guix assumes that @env{EDITOR} uses the
+``+@var{LINE} @var{FILE}'' convention to scroll to a particular line
+within a file. However, not all editors use this convention.
+For instance, @command{kate} instead wants you to use @code{--line}.
+Some minimal editors may not even have an option to pass the line.
+In both cases, an additional file named ``+@var{LINE}'' would be
+opened instead. To prevent this from happening, you can customize
+@env{GUIX_EDITOR_LOCATION_FORMAT}, using the literal strings
+`${FILE}' to denote @var{FILE} and `${LINE}' to denote @var{LINE}
+respectively.
+For instance:
+
+@example
+GUIX_EDITOR_LOCATION_FORMAT='${FILE}' guix edit gnome
+# will open @var{directory}/gnu/packages/gnome.scm, but not scroll to
+# the definition of gnome
+@end example
+
@node Invoking guix download
@section Invoking @command{guix download}
diff --git a/guix/scripts/edit.scm b/guix/scripts/edit.scm
index b7b4cd2514..13b8a4559c 100644
--- a/guix/scripts/edit.scm
+++ b/guix/scripts/edit.scm
@@ -25,6 +25,7 @@ (define-module (guix scripts edit)
#:use-module ((guix diagnostics)
#:select (location-file location-line))
#:use-module (gnu packages)
+ #:use-module (ice-9 string-fun)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-37)
#:export (%editor
@@ -62,6 +63,10 @@ (define %editor
;; For development, user can set custom value for $EDITOR.
(make-parameter (or (getenv "VISUAL") (getenv "EDITOR") "nano")))
+(define %location-format
+ (make-parameter (or (getenv "GUIX_EDITOR_LOCATION_FORMAT")
+ "+${LINE} ${FILE}")))
+
(define (search-path* path file)
"Like 'search-path' but exit if FILE is not found."
(let ((absolute-file-name (or (search-path path file)
@@ -78,18 +83,21 @@ (define (search-path* path file)
(define (location->location-specification location)
"Return the location specification for LOCATION for a typical editor command
line."
- (list (string-append "+"
- (number->string
- (location-line location)))
- (search-path* %load-path (location-file location))))
+ (let* ((spec (peek (%location-format)))
+ (spec (string-replace-substring
+ spec "${LINE}"
+ (number->string (location-line location))))
+ (spec (string-replace-substring
+ spec "${FILE}"
+ (search-path* %load-path (location-file location)))))
+ spec))
(define (spawn-editor locations)
"Spawn (%editor) to edit the code at LOCATIONS, a list of <location>
records, and exit."
(catch 'system-error
(lambda ()
- (let ((file-names (append-map location->location-specification
- locations)))
+ (let ((file-names (map location->location-specification locations)))
;; Use `system' instead of `exec' in order to sanely handle
;; possible command line arguments in %EDITOR.
(exit (system (string-join (cons (%editor) file-names))))))

base-commit: 3619dd7d059d1141acf39872f57e55b458dc8257
--
2.41.0
L
L
Ludovic Courtès wrote on 27 Jan 15:07 +0100
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87bk96lvit.fsf@gnu.org
Hi Liliana,

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

Toggle quote (8 lines)
> This will hopefully end the opening of unwanted files.
>
> * guix/scripts/edit.scm (%location-format): New parameter.
> (location->location-specification): Use %location-format.
> (spawn-editor): Adjust accordingly.
>
> Fixes: Pass special flags to ‘kate’ <https://bugs.gnu.org/44272#14>

Toggle quote (11 lines)
> +By default, Guix assumes that @env{EDITOR} uses the
> +``+@var{LINE} @var{FILE}'' convention to scroll to a particular line
> +within a file. However, not all editors use this convention.
> +For instance, @command{kate} instead wants you to use @code{--line}.
> +Some minimal editors may not even have an option to pass the line.
> +In both cases, an additional file named ``+@var{LINE}'' would be
> +opened instead. To prevent this from happening, you can customize
> +@env{GUIX_EDITOR_LOCATION_FORMAT}, using the literal strings
> +`${FILE}' to denote @var{FILE} and `${LINE}' to denote @var{LINE}
> +respectively.

I’d word it slightly differently, like:

@vindex GUIX_EDITOR_LOCATION_FORMAT
The default convention used by @code{guix edit} when invoking
@code{$EDITOR} is to pass it @code{+@VAR{line} @var{file}} to open
@var{file} at the given @var{line}. You can change this convention
for editors that do not support it by setting
@env{GUIX_EDITOR_LOCATION_FORMAT}. For example, when using Kate, you
should set:

@example
# Convention for ‘kate’.
export GUIX_EDITOR_LOCATION_FORMAT='--whatever ${FILE}'
@end example

Likewise, for @command{guix edit} to invoke VSCode, you must specify
this setting:

@example
# Settings for VSCode.
export GUIX_EDITOR_LOCATION_FORMAT='--whatever ${FILE}'
@end example
Toggle quote (2 lines)
> + (let* ((spec (peek (%location-format)))

Leftover debugging statement?

I’m still wondering about the relative merits of this approach vs. the
less generic but ready-to-use special-casing of Kate and VSCode based on
the basename of $EDITOR, but I don’t have a strong opinion.

Otherwise LGTM, thanks!

Ludo’.
L
L
Liliana Marie Prikler wrote on 13 Jan 00:35 +0100
[PATCH v2] scripts: edit: Accept generic formatting parameter.
(address . 68412@debbugs.gnu.org)
86b13fd4916ffecb1947d0879805a6d0c32542bf.1706386650.git.liliana.prikler@gmail.com
This will hopefully end the opening of unwanted files.

* guix/scripts/edit.scm (%location-format): New parameter.
(location->location-specification): Use %location-format.
(spawn-editor): Adjust accordingly.

Fixes: Pass special flags to ‘kate’ https://bugs.gnu.org/44272#14
---
Am Samstag, dem 27.01.2024 um 15:07 +0100 schrieb Ludovic Courtès:
Toggle quote (13 lines)
> Hi Liliana,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
>
> > This will hopefully end the opening of unwanted files.
> >
> > * guix/scripts/edit.scm (%location-format): New parameter.
> > (location->location-specification): Use %location-format.
> > (spawn-editor): Adjust accordingly.
> >
> > Fixes: Pass special flags to ‘kate’ <https://bugs.gnu.org/44272#14>
>
> Rather: “Fixes <https://issues.guix.gnu.org/44272>.”
I'm using a convention that I've proposed earlier in [1].
Since we're currently adding ChangeIds without any of the supported
infra (AFAIK), I think following my own proposal here is fair game.
As for why I took the message instead of the bug itself, the bug was
marked as done without resolving it, so I think linking to the
message is more correct.

Toggle quote (3 lines)
> [...]
> I’d word it slightly differently, like:
> [...]
I changed the wording. Let me know WDYT.

Toggle quote (1 lines)
> Leftover debugging statement?
Yup.

Toggle quote (3 lines)
> I’m still wondering about the relative merits of this approach vs.
> the less generic but ready-to-use special-casing of Kate and VSCode
> [...]
With every decade bringing a new hot editor, we'd be special-casing
a lot.

Cheers


doc/guix.texi | 29 +++++++++++++++++++++++++++++
guix/scripts/edit.scm | 20 ++++++++++++++------
2 files changed, 43 insertions(+), 6 deletions(-)

Toggle diff (95 lines)
diff --git a/doc/guix.texi b/doc/guix.texi
index c458befb76..2ae3871464 100644
--- a/doc/guix.texi
+++ b/doc/guix.texi
@@ -13989,6 +13989,35 @@ Invoking guix edit
@var{directory}}) allows you to add @var{directory} to the front of the
package module search path and so make your own packages visible.
+@vindex GUIX_EDITOR_LOCATION_FORMAT
+The default convention used by @code{guix edit} when invoking
+@code{$EDITOR} is to pass it @code{+@var{line} @var{file}} to open
+@var{file} at the given @var{line}.
+You can change this convention for editors that do not support it
+by setting @env{GUIX_EDITOR_LOCATION_FORMAT}.
+For instance, to set things up with kate, use:
+
+@example
+export VISUAL=kate
+export GUIX_EDITOR_LOCATION_FORMAT='--line=$@{LINE@} $@{FILE@}'
+# Assume you want to hack on kate
+guix edit kate
+@end example
+
+Alternatively, for gnome-text-editor, which has no such flag, simply
+skip it:
+
+@example
+export VISUAL=gnome-text-editor
+export GUIX_EDITOR_LOCATION_FORMAT='$@{FILE@}'
+# Assume you want to hack on gnome
+guix edit gnome
+@end example
+
+Note, that Guix only matches the literal strings @code{$@{LINE@}} and
+@code{$@{FILE@}} here. These may look like shell parameters, but their
+short form is currently not supported.
+
@node Invoking guix download
@section Invoking @command{guix download}
diff --git a/guix/scripts/edit.scm b/guix/scripts/edit.scm
index b7b4cd2514..130470dbc1 100644
--- a/guix/scripts/edit.scm
+++ b/guix/scripts/edit.scm
@@ -25,6 +25,7 @@ (define-module (guix scripts edit)
#:use-module ((guix diagnostics)
#:select (location-file location-line))
#:use-module (gnu packages)
+ #:use-module (ice-9 string-fun)
#:use-module (srfi srfi-1)
#:use-module (srfi srfi-37)
#:export (%editor
@@ -62,6 +63,10 @@ (define %editor
;; For development, user can set custom value for $EDITOR.
(make-parameter (or (getenv "VISUAL") (getenv "EDITOR") "nano")))
+(define %location-format
+ (make-parameter (or (getenv "GUIX_EDITOR_LOCATION_FORMAT")
+ "+${LINE} ${FILE}")))
+
(define (search-path* path file)
"Like 'search-path' but exit if FILE is not found."
(let ((absolute-file-name (or (search-path path file)
@@ -78,18 +83,21 @@ (define (search-path* path file)
(define (location->location-specification location)
"Return the location specification for LOCATION for a typical editor command
line."
- (list (string-append "+"
- (number->string
- (location-line location)))
- (search-path* %load-path (location-file location))))
+ (let* ((spec (%location-format))
+ (spec (string-replace-substring
+ spec "${LINE}"
+ (number->string (location-line location))))
+ (spec (string-replace-substring
+ spec "${FILE}"
+ (search-path* %load-path (location-file location)))))
+ spec))
(define (spawn-editor locations)
"Spawn (%editor) to edit the code at LOCATIONS, a list of <location>
records, and exit."
(catch 'system-error
(lambda ()
- (let ((file-names (append-map location->location-specification
- locations)))
+ (let ((file-names (map location->location-specification locations)))
;; Use `system' instead of `exec' in order to sanely handle
;; possible command line arguments in %EDITOR.
(exit (system (string-join (cons (%editor) file-names))))))

base-commit: dc8aa525174d25331d74576faf0643e45bc152c4
--
2.41.0
S
S
Simon Tournier wrote on 29 Jan 12:10 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)
87v87ciedd.fsf@gmail.com
Hi,

On sam., 13 janv. 2024 at 00:35, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Toggle quote (15 lines)
> +@vindex GUIX_EDITOR_LOCATION_FORMAT
> +The default convention used by @code{guix edit} when invoking
> +@code{$EDITOR} is to pass it @code{+@var{line} @var{file}} to open
> +@var{file} at the given @var{line}.
> +You can change this convention for editors that do not support it
> +by setting @env{GUIX_EDITOR_LOCATION_FORMAT}.
> +For instance, to set things up with kate, use:
> +
> +@example
> +export VISUAL=kate
> +export GUIX_EDITOR_LOCATION_FORMAT='--line=$@{LINE@} $@{FILE@}'
> +# Assume you want to hack on kate
> +guix edit kate
> +@end example

First, it appears to me inconsistent to speak about EDITOR and then to
use VISUAL in the example. I suggest to have:

The default convention used by @code{guix edit} when invoking
@code{$EDITOR} or @code{VISUAL} is to pass it @code{+@var{line} @var{file}} to open

and the same example. Or change the example and replace with:

export EDITOR=kate
export GUIX_EDITOR_LOCATION_FORMAT='--line=$@{LINE@} $@{FILE@}'


Second, I think that using markers that can be interpreted by Bash shell
can lead to confusion. For instance,

$ LINE=foo; FILE=bar # somewhere in my config for whatever reasons

then:

Toggle snippet (9 lines)
$ export GUIX_EDITOR_LOCATION_FORMAT='--line=${LINE} ${FILE}'
$ echo $GUIX_EDITOR_LOCATION_FORMAT
--line=${LINE} ${FILE}

$ export GUIX_EDITOR_LOCATION_FORMAT="--line=${LINE} ${FILE}"
$ echo $GUIX_EDITOR_LOCATION_FORMAT
--line=foo bar

Well, simple quote versus double quote appears to me subtle.


Since it is an hard text replacement, why not remove $ and just have the
placeholder {LINE} or {FILE}? Or <LINE> and <FILE>? Or whatever that
is not interpreted by common shells.


Toggle quote (4 lines)
> +Note, that Guix only matches the literal strings @code{$@{LINE@}} and
> +@code{$@{FILE@}} here. These may look like shell parameters, but their
> +short form is currently not supported.

Therefore, it would make that more clear or even obsolete.


Cheers,
simon
L
L
Ludovic Courtès wrote on 29 Jan 14:24 +0100
Re: [PATCH v2] scripts: edit: Accept generic formatting parameter.
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87zfwop91c.fsf@gnu.org
Hi,

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

Toggle quote (8 lines)
> This will hopefully end the opening of unwanted files.
>
> * guix/scripts/edit.scm (%location-format): New parameter.
> (location->location-specification): Use %location-format.
> (spawn-editor): Adjust accordingly.
>
> Fixes: Pass special flags to ‘kate’ <https://bugs.gnu.org/44272#14>

LGTM!

Toggle quote (7 lines)
>> > Fixes: Pass special flags to ‘kate’ https://bugs.gnu.org/44272#14
>>
>> Rather: “Fixes <https://issues.guix.gnu.org/44272>.”
> I'm using a convention that I've proposed earlier in [1].
> Since we're currently adding ChangeIds without any of the supported
> infra (AFAIK), I think following my own proposal here is fair game.

It’s not: conventions, by definition, are agreed upon collectively.
Regardless of the merits of a proposal, we first have to build consensus
for the proposal before starting using it.

Thanks,
Ludo’.
S
S
Simon Tournier wrote on 29 Jan 15:07 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ1CRxwWJMyjJWDZRvu5h67peTvo8FnftZDCB5VgBHd3bA@mail.gmail.com
Hi,

On Mon, 29 Jan 2024 at 14:24, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (2 lines)
> LGTM!

This does not LGTM for the reason I invoked earlier: single-quote
versus double-quote and the interpretation of ${LINE}.

I think it would be less confusing to have another placeholder, as
just {LINE} or whatever else.

For what my opinion is worth.

Cheers,
simon
L
L
Liliana Marie Prikler wrote on 29 Jan 18:58 +0100
Re: [bug#68412] [PATCH v2] scripts: edit: Accept generic formatting parameter.
(name . Ludovic Courtès)(address . ludo@gnu.org)
8422a68ebc6545a4587232c404efcfee86337df3.camel@gmail.com
Am Montag, dem 29.01.2024 um 12:10 +0100 schrieb Simon Tournier:
Toggle quote (31 lines)
> Hi,
>
> On sam., 13 janv. 2024 at 00:35, Liliana Marie Prikler
> <liliana.prikler@gmail.com> wrote:
>
> > +@vindex GUIX_EDITOR_LOCATION_FORMAT
> > +The default convention used by @code{guix edit} when invoking
> > +@code{$EDITOR} is to pass it @code{+@var{line} @var{file}} to open
> > +@var{file} at the given @var{line}.
> > +You can change this convention for editors that do not support it
> > +by setting @env{GUIX_EDITOR_LOCATION_FORMAT}.
> > +For instance, to set things up with kate, use:
> > +
> > +@example
> > +export VISUAL=kate
> > +export GUIX_EDITOR_LOCATION_FORMAT='--line=$@{LINE@} $@{FILE@}'
> > +# Assume you want to hack on kate
> > +guix edit kate
> > +@end example
>
> First, it appears to me inconsistent to speak about EDITOR and then
> to use VISUAL in the example.  I suggest to have:
>
>     The default convention used by @code{guix edit} when invoking
>     @code{$EDITOR} or @code{VISUAL} is to pass it @code{+@var{line}
> @var{file}} to open
>
> and the same example.  Or change the example and replace with:
>
>     export EDITOR=kate
>     export GUIX_EDITOR_LOCATION_FORMAT='--line=$@{LINE@} $@{FILE@}'
I think "or VISUAL" would be acceptable, but repeating what we wrote
earlier. I wouldn't set EDITOR=kate, because it is graphical after
all.

Toggle quote (23 lines)
> Second, I think that using markers that can be interpreted by Bash
> shell can lead to confusion.  For instance,
>
>     $ LINE=foo; FILE=bar # somewhere in my config for whatever
> reasons
>
> then:
>
> --8<---------------cut here---------------start------------->8---
> $ export GUIX_EDITOR_LOCATION_FORMAT='--line=${LINE} ${FILE}'
> $ echo $GUIX_EDITOR_LOCATION_FORMAT
> --line=${LINE} ${FILE}
>
> $ export GUIX_EDITOR_LOCATION_FORMAT="--line=${LINE} ${FILE}"
> $ echo $GUIX_EDITOR_LOCATION_FORMAT
> --line=foo bar
> --8<---------------cut here---------------end--------------->8---
>
> Well, simple quote versus double quote appears to me subtle.
>
> Since it is an hard text replacement, why not remove $ and just have
> the placeholder {LINE} or {FILE}?  Or <LINE> and <FILE>?  Or whatever
> that is not interpreted by common shells.
Because it is only a hard text replacement *for now*. We might find
that there's merit to having gash interpret these later on. I know
there's like fifty conventions for formatting strings and we have to
pick one, but I'd like to think that this isn't just a pointless
exercise in forward compatibility.

Toggle quote (7 lines)
> > +Note, that Guix only matches the literal strings @code{$@{LINE@}}
> > and
> > +@code{$@{FILE@}} here.  These may look like shell parameters, but
> > their
> > +short form is currently not supported.
>
> Therefore, it would make that more clear or even obsolete.
/me hints at "currently"

Cheers
L
L
Ludovic Courtès wrote on 7 Feb 23:22 +0100
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87h6ij3of4.fsf@gnu.org
Hi,

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

Toggle quote (3 lines)
>> Second, I think that using markers that can be interpreted by Bash
>> shell can lead to confusion.  For instance,

[...]

Toggle quote (16 lines)
>> $ export GUIX_EDITOR_LOCATION_FORMAT="--line=${LINE} ${FILE}"
>> $ echo $GUIX_EDITOR_LOCATION_FORMAT
>> --line=foo bar
>> --8<---------------cut here---------------end--------------->8---
>>
>> Well, simple quote versus double quote appears to me subtle.
>>
>> Since it is an hard text replacement, why not remove $ and just have
>> the placeholder {LINE} or {FILE}?  Or <LINE> and <FILE>?  Or whatever
>> that is not interpreted by common shells.
> Because it is only a hard text replacement *for now*. We might find
> that there's merit to having gash interpret these later on. I know
> there's like fifty conventions for formatting strings and we have to
> pick one, but I'd like to think that this isn't just a pointless
> exercise in forward compatibility.

It’s true that someone not well versed in shell or someone distracted
could easily find themselves having ${LINE} and ${FILE} shell-expanded
even though we precisely don’t want that.

One way out would be to use a different syntax, say, %LINE% and %FILE%.
With the syntax clearly different from shell variables, we’d avoid those
easy mistakes.

WDYT?

Ludo’.
L
L
Liliana Marie Prikler wrote on 8 Feb 19:09 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)
15c08b6053676777c8457ff247b0ab214465cedc.camel@gmail.com
Am Mittwoch, dem 07.02.2024 um 23:22 +0100 schrieb Ludovic Courtès:
Toggle quote (35 lines)
> Hi,
>
> Liliana Marie Prikler <liliana.prikler@gmail.com> skribis:
>
> > > Second, I think that using markers that can be interpreted by
> > > Bash
> > > shell can lead to confusion.  For instance,
>
> [...]
>
> > > $ export GUIX_EDITOR_LOCATION_FORMAT="--line=${LINE} ${FILE}"
> > > $ echo $GUIX_EDITOR_LOCATION_FORMAT
> > > --line=foo bar
> > > --8<---------------cut here---------------end--------------->8---
> > >
> > > Well, simple quote versus double quote appears to me subtle.
> > >
> > > Since it is an hard text replacement, why not remove $ and just
> > > have the placeholder {LINE} or {FILE}?  Or <LINE> and <FILE>?  Or
> > > whatever that is not interpreted by common shells.
> > Because it is only a hard text replacement *for now*.  We might
> > find that there's merit to having gash interpret these later on.  I
> > know there's like fifty conventions for formatting strings and we
> > have to pick one, but I'd like to think that this isn't just a
> > pointless exercise in forward compatibility.
>
> It’s true that someone not well versed in shell or someone distracted
> could easily find themselves having ${LINE} and ${FILE} shell-
> expanded even though we precisely don’t want that.
>
> One way out would be to use a different syntax, say, %LINE% and
> %FILE%. With the syntax clearly different from shell variables, we’d
> avoid those easy mistakes.
>
> WDYT?
Well, I said my opinion already in reply to Simon, but if y'all
strongly feel that preventing this confusion is preferable and can
agree to a common syntax, by all means go ahead and commit it with that
change.

I do think there's value in having this interpretable by gash at some
point, but maybe I'm thinking too far into the future.

Cheers
L
L
Ludovic Courtès wrote on 10 Feb 10:58 +0100
(name . Liliana Marie Prikler)(address . liliana.prikler@gmail.com)
87eddkk5do.fsf@gnu.org
Hi,

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

Toggle quote (5 lines)
> Well, I said my opinion already in reply to Simon, but if y'all
> strongly feel that preventing this confusion is preferable and can
> agree to a common syntax, by all means go ahead and commit it with that
> change.

Conventionally the submitter would push the patches past the final line.
If you agree with the proposal, please go ahead; if you don’t, we can
discuss it further, though I think the discussion should be proportional
to the stakes. (Personally I agree there’s a risk of confusion like
Simon noted but I’m fine either way.)

Thanks,
Ludo’.
S
S
Simon Tournier wrote on 10 Feb 12:01 +0100
(name . Ludovic Courtès)(address . ludo@gnu.org)
CAJ3okZ3WJUf-RT7m-Pr8bJuLi1xLfUBY6gzJDqENS9Dem4UUMg@mail.gmail.com
Hi,

On Sat, 10 Feb 2024 at 10:58, Ludovic Courtès <ludo@gnu.org> wrote:

Toggle quote (6 lines)
> Conventionally the submitter would push the patches past the final line.
> If you agree with the proposal, please go ahead; if you don’t, we can
> discuss it further, though I think the discussion should be proportional
> to the stakes. (Personally I agree there’s a risk of confusion like
> Simon noted but I’m fine either way.)

I agree with this paragraph.

1. I think that the current placeholder can be confusing (quote vs
double-quote).

2. The envisioned future feature with Gash is not clear for me. So I
do not know what would be better.

3. I do not have a strong opinion and I can live with whatever choice
-- although I would live better if there is no confusion. ;-)

I propose {LINE} as placeholder because in case of #2 it would easy to
support both {LINE} and ${LINE} then reducing some backward
compatibilities issue.

WDYT?

Cheers,
simon
L
L
Liliana Marie Prikler wrote on 13 Feb 16:04 +0100
(address . 68412@debbugs.gnu.org)
e6677ad7d12ea40eebcb479d1e43ffc866d5a3ca.camel@gmail.com
Am Samstag, dem 10.02.2024 um 12:01 +0100 schrieb Simon Tournier:
Toggle quote (14 lines)
> Hi,
>
> On Sat, 10 Feb 2024 at 10:58, Ludovic Courtès <ludo@gnu.org> wrote:
>
> > Conventionally the submitter would push the patches past the final
> > line. If you agree with the proposal, please go ahead; if you
> > don’t, we can discuss it further, though I think the discussion
> > should be proportional to the stakes.  (Personally I agree there’s
> > a risk of confusion like Simon noted but I’m fine either way.)
>
> I agree with this paragraph.
>
> 1. I think that the current placeholder can be confusing (quote vs
> double-quote).
Is this something we can fix by pointing out the single quotes, or is
it better not to try that?

Toggle quote (2 lines)
> 2. The envisioned future feature with Gash is not clear for me.  So 
> I do not know what would be better.
To make it a little clearer, we currently have more or less
implementation-defined behaviour through calling system with a string-
join'ed command. (This is not the best way of invoking an editor, but
it works, and it also works with EDITORs like "emacsclient -c" if your
shell is Bash – which Guix System has by default.) If we were to pull
in Gash, we could process the command line a priori and then use
system* or invoke.

Toggle quote (6 lines)
> 3. I do not have a strong opinion and I can live with whatever choice
> -- although I would live better if there is no confusion. ;-)
>
> I propose {LINE} as placeholder because in case of #2 it would easy
> to support both {LINE} and ${LINE} then reducing some backward
> compatibilities issue.
What would be the way forward if we use {LINE} now?

Cheers
S
S
Simon Tournier wrote on 14 Feb 12:19 +0100
(address . 68412@debbugs.gnu.org)
87r0hfmgxc.fsf@gmail.com
Hi,

On mar., 13 févr. 2024 at 16:04, Liliana Marie Prikler <liliana.prikler@gmail.com> wrote:

Toggle quote (6 lines)
>> 1. I think that the current placeholder can be confusing (quote vs
>> double-quote).
>
> Is this something we can fix by pointing out the single quotes, or is
> it better not to try that?

Well, even if it would be using Gash, the issue quote/double-quote would
be still there because it is too late – it does not depend on Guix
internals but only user Shell script.

If you are envisioning the user Shell would be Gash, well for what it is
worth, I am not convinced that – as an user – I would switch; I will
still use Bash, almost surely. ;-)

Therefore, GUIX_EDITOR_LOCATION_FORMAT needs to support Bash compatible
syntax. And thus, the placeholder will stay – at least for backward
compatibility.

I propose {LINE} because it seems familiar with ${LINE}. Or I proposed
<LINE>. Ludo proposes %LINE%.

Last, I am not sure to understand the idea behind Gash. And if is
something about Guix internals, then the best will be to have an
internal replacement from ’PLACEHOLDER’ to ’${PLACEHOLDER}’ and not to
have something that the user Shell can interpret.

All in all, IMHO, let pick one of them: {LINE} <LINE> %LINE% :-)

Cheers,
simon
?
Your comment

Commenting via the web interface is currently disabled.

To comment on this conversation send an email to 68412@debbugs.gnu.org

To respond to this issue using the mumi CLI, first switch to it
mumi current 68412
Then, you may apply the latest patchset in this issue (with sign off)
mumi am -- -s
Or, compose a reply to this issue
mumi compose
Or, send patches to this issue
mumi send-email *.patch