GNU bug report logs -
#50286
[RFC PATCH] Let 'package-location' returns location of surrounding 'let'.
Previous Next
Reported by: Maxime Devos <maximedevos <at> telenet.be>
Date: Mon, 30 Aug 2021 21:28:01 UTC
Severity: normal
Tags: patch
Done: Ludovic Courtès <ludo <at> gnu.org>
Bug is archived. No further changes may be made.
Full log
View this message in rfc822 format
Hi Sarah,
Sarah Morgensen <iskarian <at> mgsn.dev> skribis:
> However... it doesn't work for unexported packages. It looks there are
> about 200 such packages:
>
> ~/guix$ rg -U '\(define [^\(]+\n.*?\(package' gnu/packages --count --no-filename | awk '{a+=$1} END {print a}'
> 233
Ah, hmm, well. I’d have said these are beyond our scope :-), and in
fact we’d need to know how many among these 233 packages use the
(let ((commit …)) …) idiom, but if this is deemed important, we can
replace ‘define’ similarly.
> And, to play the pessimist:
>
> What do we get out of this that couldn't be done by "go to package
> location; read backwards one sexp until we reach a defining form"
> (like Emacs' 'beginning-of-defun')?
Nothing! It’s just easier to implement and more accurate—we’re sure to
get the exact location of the ‘define-public’ form that surrounds the
package record we’re looking at.
Now, longer-term, I’d like to have Emacs/paredit-like features and more
tools to correlate source and live objects. I found myself doing a bit
of that in ‘guix style’, and I think that’s a fun area to explore so we
can improve our package maintenance tools.
Thanks,
Ludo’.
This bug report was last modified 3 years and 336 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.