GNU bug report logs - #68412
[PATCH] scripts: edit: Accept generic formatting parameter.

Previous Next

Package: guix-patches;

Reported by: Liliana Marie Prikler <liliana.prikler <at> gmail.com>

Date: Fri, 12 Jan 2024 23:47:01 UTC

Severity: normal

Tags: patch

Full log


Message #23 received at 68412 <at> debbugs.gnu.org (full text, mbox):

From: Liliana Marie Prikler <liliana.prikler <at> gmail.com>
To: Simon Tournier <zimon.toutoune <at> gmail.com>, 68412 <at> debbugs.gnu.org
Cc: Ludovic Courtès <ludo <at> gnu.org>
Subject: Re: [bug#68412] [PATCH v2] scripts: edit: Accept generic formatting
 parameter.
Date: Mon, 29 Jan 2024 18:58:31 +0100
Am Montag, dem 29.01.2024 um 12:10 +0100 schrieb Simon Tournier:
> Hi,
> 
> On sam., 13 janv. 2024 at 00:35, Liliana Marie Prikler
> <liliana.prikler <at> 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.

> 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.

> > +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




This bug report was last modified 1 year and 120 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.