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 <address@hidden> 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