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

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

[Jan Synacek]

Hello,

I'm going to give honest feedback, since I still care about some things.

I decided to check the new guix-1.1.0 and one of the first things that I ran was:

$ guix package -s firefox

The resulting message was infuriating to say the least. The code says:

(if (and (not (getenv "INSIDE_EMACS"))
    ...
      ...
      (display-hint (format #f (G_ "Run @code{~a ... | less} \
to view all the results.")
                            command)))

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

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.

There is a thread on guix-devel [1] titled "Medium-term road map". It contains:

> What would you like to see?

and

> ... Here are the areas I hope to focus on (and
> embarking as many of you as possible ...

and

> ... User interface.  Let’s get our act together with ‘guix shell’ and
>     ‘guix run-script’, and let’s address other annoyances that
>     newcomers keep stumbling upon! ...

I'm selectively quoting parts that I consider lead to the same direction - more
guix users and possibly developers.

Here's my suggestion: Don't make idiosyncratic decisions like the one I
described above. I don't think that your target audience is people completely
new to linux-like systems. I'm definitely not new. And I'm used to tools that
just simply (remember the KISS principle?) give me output when I run them.

Please, keep making guix (and guile) a great tool.

[1] https://lists.gnu.org/archive/html/guix-devel/2020-04/msg00400.html

Regards,
Jan

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

[zimoun]

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.

Thank you for sharing your opinion.

After a discussion [6] on other opinions than yours, another strategy
is implemented [7] and yes the default behaviour could be discussed
(see bottom [8] and elswhere I am too lazy to find them :-)).

[6] https://issues.guix.gnu.org/issue/35551#11
[7] https://issues.guix.gnu.org/issue/36390
[8] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00378.html


> Here's my suggestion: Don't make idiosyncratic decisions like the one I
> described above. I don't think that your target audience is people completely
> new to linux-like systems. I'm definitely not new. And I'm used to tools that
> just simply (remember the KISS principle?) give me output when I run them.

Your suggestion is to implement "Guix honours $PAGER", right?
And to test on another environment variable name than $INSIDE_EMACS, right?


Thank you for your feedback.

All the best,
simon

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

[Bengt Richter]

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?

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.

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.

I think preference similarities will be noticed, and
gradually factored out of apps and put into system and user
preference configs, like themes, for better and worse. PAGER
is probably an example of that.

But I'm wondering whether environment variables per se
really ever should be used for global preference info. ISTM
it becomes an overused "top-level" (define ...) name space.
Hygiene becomes a problem. NOT_SURE_PREFIXES_SCALE_WELL_ ... :)

> Thank you for sharing your opinion.
> 
> After a discussion [6] on other opinions than yours, another strategy
> is implemented [7] and yes the default behaviour could be discussed
> (see bottom [8] and elswhere I am too lazy to find them :-)).
> 
> [6] https://issues.guix.gnu.org/issue/35551#11
> [7] https://issues.guix.gnu.org/issue/36390
> [8] https://lists.gnu.org/archive/html/guix-devel/2020-02/msg00378.html
> 
> 
> > Here's my suggestion: Don't make idiosyncratic decisions like the one I
> > described above. I don't think that your target audience is people completely
> > new to linux-like systems. I'm definitely not new. And I'm used to tools that
> > just simply (remember the KISS principle?) give me output when I run them.
> 
> Your suggestion is to implement "Guix honours $PAGER", right?
> And to test on another environment variable name than $INSIDE_EMACS, right?
>

I do think the name smells fishy, unless it's emacs
privately avoiding a recursion problem. IMO if an app needs
to know *who* is calling it, to adjust its behaviour, that's
a design entanglement. If the app can behave in alternate
ways, that can be part of its API, which emacs or any other
caller can make use of.

OTOH if a shape-shifting app wants to change personalities
for different known callers, why not ask the system (ps) who
is calling, and not mess with the caller at all?

I'm not sure who is setting $INSIDE_EMACS, but right now I
am in some sense "inside emacs" (and a lot more) and I can
ask ps[1] to find out[2], so why is $INSIDE_EMACS being used
to pass that info bit? Or is there more to it?
I may be totally misunderstanding the issue, but I think
the general points are valid.

[1]
--8<---------------cut here---------------start------------->8---
#!/usr/bin/bash
# ~/bin/pidparents

pid=${1:-$$}	#this process if no pid specified as $1

while [ $(($pid)) -gt 0 ]; do    
      ps h -p $pid -o comm,tt,pid,stat,args
      pid=$(ps -q $pid -o ppid=)
done
--8<---------------cut here---------------end--------------->8---

[2]
--8<---------------cut here---------------start------------->8---
pidparents      ?         6727 Ss   /usr/bin/bash /home/bokr/bin/pidparents
emacs           pts/0     6556 Sl+  emacs /home/bokr/.mutt/temp/mutt-LionPure-1000-4379-382192783617502847
sh              pts/0     6555 S+   sh -c emacs '/home/bokr/.mutt/temp/mutt-LionPure-1000-4379-382192783617502847'
mutt            pts/0     4379 S+   mutt
bash            pts/0     2822 Ss   /bin/bash
tilix           ?         2817 Sl   /usr/bin/tilix --gapplication-service
systemd         ?         1441 Ss   /lib/systemd/systemd --user
systemd         ?            1 Ss   /sbin/init splash
--8<---------------cut here---------------end--------------->8---

> 
> Thank you for your feedback.
> 
> All the best,
> simon
> 
-- 
Regards,
Bengt Richter

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

[Jan Synacek]

[-- 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 --]

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

[zimoun]

Dear

On Mon, 27 Apr 2020 at 10:39, Jan Synacek <jsynacek@redhat.com> wrote:

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

There is a difference: "guix search" computes a relevance score
depending on the query and the result is sorted by relevance.
Therefore, the few first items should be the most relevant with the
query and page the result should not be "useful" (yes it is debatable!
:-))

There is room of improvement!
For example, 'aptitutde search <query>' returns (by default): name TAB
synopsis. I find that really handy. Even if it would not be the
default, it should be possible to display differently the result of
"guix search".
Another example, it should be possible to sort the result by another
key than the relevance, e.g., to group them by file origin or license
or your-name-it.

Patches welcome. :-)



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

Does Git work the way you suggest all the tools are working?


All the best,
simon

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

[pinoaffe]

On 2020-04-27 08:38, Jan Synacek wrote:
> 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.
imo the best option would be to page, print or truncate depending on
an envvar and/or a commandline flag

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

[Vincent Legoll]

Hello,

On Mon, Apr 27, 2020 at 1:59 PM <pinoaffe@airmail.cc> wrote:
> imo the best option would be to page, print or truncate depending on
> an envvar and/or a commandline flag

PAGER="head -20" maybe ?

I'm also of the opinion to respect PAGER. Untruncated ouput if unset.

-- 
Vincent Legoll

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

[Vagrant Cascadian]

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

On 2020-04-27, Jan Synacek wrote:
> 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.

I don't think PAGER is an indicator of weather to paginate output, it's
a variable to allow the user to specify which pager they want to use
when the program chooses to output paginated output.

live well,
  vagrant

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 227 bytes --]

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

[Jan Synacek]

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

On Sun, Apr 26, 2020 at 11:38 AM zimoun <zimon.toutoune@gmail.com> 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].
>
> Why do you want to make things complicated? What's wrong with *just
showing the entire output*? And let users decide if they want to use a
pager, recsel, emacs or redirect the output somewhere else.

I mean you run a command and the command shows its output. It makes me kind
of sad that there even has to be a discussion about this.

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

Good, I actually like that recommendation.


> Thank you for sharing your opinion.
>

You're welcome.

Regards,
-- 
Jan Synacek
Software Engineer, Red Hat

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

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

[zimoun]

Dear,

On Mon, 27 Apr 2020 at 08:12, Jan Synacek <jsynacek@redhat.com> wrote:
> On Sun, Apr 26, 2020 at 11:38 AM zimoun <zimon.toutoune@gmail.com> wrote:
>> 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].
>>
> Why do you want to make things complicated? What's wrong with *just showing the entire output*? And let users decide if they want to use a pager, recsel, emacs or redirect the output somewhere else.
>
> I mean you run a command and the command shows its output. It makes me kind of sad that there even has to be a discussion about this.
>
>> [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


I do not have a strong opinion.
Personally, I do not find the default behaviour really handy and I
(almost) always pipe with 'recsel -C -P name' because I do not find
handy neither to display all the package fields by default. Well,
taste and colour. :-)
And my answer was just to point you that it is not an arbitrary
choice. And all choices can be discussed. ;-)


All the best,
simon

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

[Robin Templeton]

Jan Synacek <jsynacek@redhat.com> writes:

> Hello,
>
> I'm going to give honest feedback, since I still care about some things.
>
> I decided to check the new guix-1.1.0 and one of the first things that I ran was:
>
> $ guix package -s firefox
>
> The resulting message was infuriating to say the least. The code says:
>
> (if (and (not (getenv "INSIDE_EMACS"))
>     ...
>       ...
>       (display-hint (format #f (G_ "Run @code{~a ... | less} \
> to view all the results.")
>                             command)))
>
> 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? 
> 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.
>
> 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.

Seconded! The current behavior seems exactly backwards compared to most
*nix tools; if I wanted *less* information from "guix search" I'd
manually pipe the output into head or recsel. Perhaps Git-style
auto-pagination (i.e. page the results when outputting to a terminal)
would be a good compromise as a default.

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

[Marius Bakke]

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

Robin Templeton <robin@terpri.org> writes:

> Seconded! The current behavior seems exactly backwards compared to most
> *nix tools; if I wanted *less* information from "guix search" I'd
> manually pipe the output into head or recsel. Perhaps Git-style
> auto-pagination (i.e. page the results when outputting to a terminal)
> would be a good compromise as a default.

I think this is exactly what 'guix search' does as of a few weeks ago?

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 487 bytes --]

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

[Robin Templeton]

Marius Bakke <marius@gnu.org> writes:

> Robin Templeton <robin@terpri.org> writes:
>
>> Seconded! The current behavior seems exactly backwards compared to most
>> *nix tools; if I wanted *less* information from "guix search" I'd
>> manually pipe the output into head or recsel. Perhaps Git-style
>> auto-pagination (i.e. page the results when outputting to a terminal)
>> would be a good compromise as a default.
>
> I think this is exactly what 'guix search' does as of a few weeks ago?

Yes, I upgraded *just* after sending this message and noticed that it
now works the way I'd expect :-) Thanks for changing this, Ludo'!