From: ludo@gnu.org (Ludovic Courtès)
To: Alex Kost <alezost@gmail.com>
Cc: guix-devel@gnu.org
Subject: Re: [PATCH 3/3] emacs: Add "Source" field to 'guix-info' buffers.
Date: Tue, 11 Nov 2014 00:29:48 +0100 [thread overview]
Message-ID: <87y4riiqhf.fsf@gnu.org> (raw)
In-Reply-To: <878ujj2nyo.fsf@gmail.com> (Alex Kost's message of "Mon, 10 Nov 2014 16:18:39 +0300")
Alex Kost <alezost@gmail.com> skribis:
> Ludovic Courtès (2014-11-10 01:43 +0300) wrote:
>
>> Alex Kost <alezost@gmail.com> skribis:
[...]
>> I don’t think it’s natural for a user to think in terms of downloads.
>> Personally, when I want to see the source of a package, I do:
>>
>> tar xf $(guix build -S foo)
>
> I think later we can provide some variable to choose if pushing a
> "source file" button will open a tarball in a ‘tar-mode’ (a usual
> 'find-file' way) or will untar it in “/tmp” or something.
OK.
>> and that’s it. If it’s taking too long or something, I can still hit
>> C-c. But typically, I don’t ask myself “is this already in the store?”.
>
> I typically ask myself this question :-)
OK, fair enough!
>>>> With the interface you propose, things might be slightly confusing:
>>>> sometimes clicking on “Download” will do nothing (because the source is
>>>> already there), sometime “Show” will work without “Download”, sometimes
>>>> not, etc. Also it takes up quite a bit of space.
>>>
>>> Sorry, I didn't get it. What space do you mean?
>>
>> I meant visual space in the user interface; visual clutter.
>
> Is that "too much information is bad"? Do you suggest to remove
> something?
I think a single button is clearer than two buttons plus a label, but
that’s OK here since we can’t really do just one button.
>> But note that derivation outputs not obtained by a ‘build-derivations’
>> call with the current store connection may be garbage-collected anytime.
>> That makes it more difficult to reliably determine whether the
>> “Download” button should be displayed; to be safe, it would have to be
>> displayed by default. Then we’re very close to the current patch, I
>> think, no?
>
> I just check whether a final source file exists in the store and that's
> all. I think it's reliable, isn't it?
There’s still the possibility that (1) the source is there, so no
“Download” button, (2) the source is GC’d, and (3) there’s still no
“Download” button and trying to access the source fails gracelessly.
That’s probably not very common in practice, and easily fixed by hitting
‘g’, so maybe it’s not worth worrying. WDYT?
>> If that’s fine with you, perhaps let’s just commit the patch as is, and
>> see in another patch whether “Download” can be made to disappear in safe
>> cases?
>
> I modified the patch (attached) to display “Show” and “Download” buttons
> only when needed. WDYT?
Sounds good!
> +(define (package-source-names package)
> + "Return a list of source names (URLs) of the PACKAGE."
> + (let ((source (package-source package)))
> + (and (origin? source)
> + (filter-map (lambda (uri)
> + (cond ((string? uri)
> + uri)
> + ((git-reference? uri)
> + (git-reference-url uri))
> + (else #f)))
> + (list-maybe (origin-uri source))))))
The #f case above just leads to degraded display, not breakage, right?
(I’m asking because of the other things beyond string? and
git-reference?.)
Thanks,
Ludo’.
next prev parent reply other threads:[~2014-11-10 23:30 UTC|newest]
Thread overview: 10+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-11-09 8:40 [PATCH 3/3] emacs: Add "Source" field to 'guix-info' buffers Alex Kost
2014-11-09 17:45 ` Ludovic Courtès
2014-11-09 18:48 ` Alex Kost
2014-11-09 22:43 ` Ludovic Courtès
2014-11-10 13:18 ` Alex Kost
2014-11-10 23:29 ` Ludovic Courtès [this message]
2014-11-11 19:13 ` Alex Kost
2014-11-11 19:57 ` Ludovic Courtès
2014-11-12 6:56 ` Alex Kost
2014-11-12 9:55 ` Ludovic Courtès
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=87y4riiqhf.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=alezost@gmail.com \
--cc=guix-devel@gnu.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this external index
https://git.savannah.gnu.org/cgit/guix.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.