unofficial mirror of guix-devel@gnu.org 
 help / color / mirror / code / Atom feed
From: Bengt Richter <bokr@bokr.com>
To: zimoun <zimon.toutoune@gmail.com>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: hint: Run `guix search ... | less' to view all the results
Date: Mon, 27 Apr 2020 03:26:35 +0200	[thread overview]
Message-ID: <20200427012635.GA4379@LionPure> (raw)
In-Reply-To: <CAJ3okZ3dmyeadR09PRe-M0XbzcHF3yJH0RRQcfJ2DyVgZBVftQ@mail.gmail.com>

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

  reply	other threads:[~2020-04-27  1:26 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-04-26  7:59 hint: Run `guix search ... | less' to view all the results Jan Synacek
2020-04-26  9:38 ` zimoun
2020-04-27  1:26   ` Bengt Richter [this message]
2020-04-27  8:38     ` Jan Synacek
2020-04-27  9:44       ` zimoun
2020-04-27 11:58       ` pinoaffe
2020-04-27 17:21         ` Vincent Legoll
2020-04-27 18:36       ` Vagrant Cascadian
2020-04-27  6:12   ` Jan Synacek
2020-04-27  9:29     ` zimoun
2020-06-23 16:05 ` Robin Templeton
2020-06-23 21:06   ` Marius Bakke
2020-06-24  5:30     ` Robin Templeton

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

  List information: https://guix.gnu.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20200427012635.GA4379@LionPure \
    --to=bokr@bokr.com \
    --cc=guix-devel@gnu.org \
    --cc=zimon.toutoune@gmail.com \
    /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 public inbox

	https://git.savannah.gnu.org/cgit/guix.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).