Re: hint: Run `guix search ... | less' to view all the results

[Jan Synacek <jsynacek@redhat.com>]

[-- Attachment #1: Type: text/plain, Size: 4604 bytes --]

On Mon, Apr 27, 2020 at 4:02 AM Bengt Richter <bokr@bokr.com> wrote:

> Hi zimoun, Jan,
>
> On +2020-04-26 11:38:01 +0200, zimoun wrote:
> > Dear,
> >
> > On Sun, 26 Apr 2020 at 10:35, Jan Synacek <jsynacek@redhat.com> wrote:
> >
> > > Seriously? Are you seriously forcing your users to either run emacs
> (or at least
> > > to set the env variable) or use pipes to get the entire search result?
> >
> > It is "known" that Guix should respect the PAGER variable [1,2] and it
> > is already a feature request [3].
> >
> > [1] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00039.html
> > [2] https://lists.gnu.org/archive/html/help-guix/2020-02/msg00150.html
> > [3] https://lists.gnu.org/archive/html/help-guix/2020-02/msg00154.html
> >
> >
> > > That's just... backwards. Also, it feels like as if the author of that
> code sort
> > > of assumed that whoever runs the command is stupid enough not to be
> able to deal
> > > with long output. I'm sure that it wasn't meant like that.
> >
> > The manual recommands to use "guix search" in combination with
> > 'recsels' (see [4] '--search' paragraph).
> >
> > Therefore, the current philosophy of searching is:
> >
> >   1) guix search <regexps> | recsel -P name,synopsis | grep
> <other-regexps>
> >   2) guix show <your-interest>
> >
> > I agree we could discuss that... as it was started for example see
> > this thread [5].
> >
> > [4] https://guix.gnu.org/manual/devel/en/guix.html#Invoking-guix-package
> > [5] https://lists.gnu.org/archive/html/guix-devel/2019-12/msg00141.html
> >
> >
> > > Pretty please, fix this. Don't force your users into usage patterns
> that might
> > > be completely foreign to them. Don't truncate output from programs by
> default.
> >
>
> I had been assuming it had just been allowed to scroll off
> screen due to unimpeded output, as IIUC Jan wants. Is it
> actually truncated?
>

Yes, it is truncated in the sense of it doesn't show all the output, unless
you use a pipe, redirect or set the env variable. If I run 'guix package
-A', it outputs all the available packages without truncating anything and
without giving me "helpful" hints. And that's currently 13201 lines on my
system. That's how I expect commands to behave and that has been pretty
much the normal thing to do since forever.

I believe in KISS for primitives, and I think the less they
> look at how they are being used the better for their design.
> Otherwise the implementation is implicitly getting ad hoc
> inputs from the environment, and incrementally it will grow
> messy.
>

> At the higher level, I think systems can be too eager to
> help, which can be really annoying to an advanced user, but
> really helpful to a noob.
>

In this particular case, I consider myself as an advanced user and yes,
it's annoying.

As I have already mentioned, I don't consider guix to be aimed at "noobs".
You would have to define what noob means here. If we consider a noob to be
someone who doesn't know how to use pipes or redirections, then, as I have
already mentioned, I don't believe it's the target audience of the guix
project. At least not for now. Currently, it actually takes a pretty
advanced linux user to use it.

So maybe Jan could be satisfied by a preference setting
> (USER_LEVEL expert) in that regard. Many apps have such
> features, E.g. emacs will want to take you into a tutorial
> until you tell it to stop pestering you.
>

This actually made me laugh, thanks for that! I'm not sure if it was meant
to be a joke or not, but I take it as you meant it. What you actually
suggest is: 1) I run 'guix package -s ...' which gives me the first few
results and a "helpful" hint that I should use pipes or emacs to get all of
it. 2) I get annoyed and happen to know about this USER_LEVEL configuration
option that I can use. 3) I set USER_LEVEL=expert and get the output that I
should have gotten in the first place.
If that's what you meant, then, please no, don't do that.

While we're at it, let me also give my opinion about supporting PAGER. If
it means that if PAGER is set, use it, otherwise don't page, then that's
perfectly valid and, in my opinion, how PAGER support is supposed to work.
If it means that *unless* something is set *not to use* a pager as some
tools currently do (I can only think of some of the systemd tools off top
of my head), use pager by default, then that's also backwards. But it's
still much better than truncating output by default.
Regards,
-- 
Jan Synacek
Software Engineer, Red Hat

[-- Attachment #2: Type: text/html, Size: 7232 bytes --]