From: "Ludovic Courtès" <ludo@gnu.org>
To: Pierre Neidhardt <mail@ambrevar.xyz>
Cc: Guix Devel <guix-devel@gnu.org>
Subject: Re: Guix search, colors and INSIDE_EMACS
Date: Mon, 24 Feb 2020 21:54:04 +0100 [thread overview]
Message-ID: <874kvfg103.fsf@gnu.org> (raw)
In-Reply-To: <875zfwc4up.fsf@ambrevar.xyz> (Pierre Neidhardt's message of "Mon, 24 Feb 2020 17:44:30 +0100")
Hi Pierre,
I’m happy to discuss it further (to some extent at least, because there
are other patches waiting for us to be reviewed :-)), but first, as I
wrote in another message, I think the topic was not consensual and thus
the series wasn’t ready to be pushed.
Pierre Neidhardt <mail@ambrevar.xyz> skribis:
> Ludovic Courtès <ludo@gnu.org> writes:
>
>>> - Leave colors when INSIDE_EMACS is set.
>>
>> Like Ricardo wrote before, this is not desirable for shell-mode. Also,
>> all or most GNU command-line tools behave that way.
>
> There might be a misunderstanding because M-x shell supports ANSI
> terminal colors explicitly. Why disable them then?
>
> Many command line tools print colors properly in M-x shell. I think
> it's a misfeature to disable them in Emacs; I don't see any benefits.
I understand the Eshell use case. The shell-mode use case is one I’m
interested in keeping as-is, that is: disable colors when INSIDE_EMACS,
just like Coreutils, GNU grep, etc. do.
>>> - Disable pager hint and display all search results when INSIDE_EMACS is set.
>>
>> I have a preference for something that doesn’t fill the screen,
>> especially since the last answers (those that remain visible without
>> scrolling) are the least relevant. Emacs makes it easier to scroll up
>> and search, but still.
>>
>> Thoughts?
>
> I find that printing just 1 result to be of little use in general.
> So between printing all results and just 1, I have a preference for
> printing all results. But there are other solutions, see below.
It’s not printing one result; it’s printing as many results as can fit
on the screen.
> Note that `less` does not work well neither in Eshell nor in M-x shell.
> Which is what started this discussion ;)
>
> Another option for M-x shell is to do
>
> guix search foo | cat
>
> which gives us the same result as the patch I've sent, with more typing :(
>
> Eshell has a "smart-scrolling" mode (the point stays at the first prompt
> until validated).
>
> For M-x shell, going to the first result is just one keypress away.
I understand all this. However, we’re not optimizing just for Eshell
and shell-mode; in fact, I’d argue that Emacs users should just use
Emacs-Guix (we need to add M-x guix-search, actually!).
For regular terminals, I think the two options that work well are:
1. Print (by default) as much as fits on the screen.
2. Automatically start a pager.
I went with option #1, which was submitted at
<https://issues.guix.gnu.org/issue/36390>. The suggestion actually came
from Bruno Haible: <https://issues.guix.gnu.org/issue/35551>.
Just to say that there’s already been some thought put into it, and we
have to carry the baggage of these past discussions now!
> Another option would be to reverse the order of the result: print the
> most relevant result last, so that neither Eshell nor M-x shell have to
> scroll back.
I think UIs generally print the most relevant result first. It wouldn’t
feel right to me to reverse it.
Thanks!
Ludo’.
next prev parent reply other threads:[~2020-02-24 20:54 UTC|newest]
Thread overview: 46+ messages / expand[flat|nested] mbox.gz Atom feed top
2020-02-04 15:23 Guix search, colors and INSIDE_EMACS Pierre Neidhardt
2020-02-04 16:12 ` Ricardo Wurmus
2020-02-04 16:37 ` Pierre Neidhardt
2020-02-04 16:51 ` zimoun
2020-02-04 19:16 ` Ricardo Wurmus
2020-02-04 19:18 ` Ricardo Wurmus
2020-02-06 9:51 ` Pierre Neidhardt
2020-02-13 9:30 ` zimoun
2020-02-13 13:41 ` Alex Griffin
2020-02-13 14:22 ` zimoun
2020-02-14 7:17 ` Pierre Neidhardt
2020-02-14 7:21 ` Pierre Neidhardt
2020-02-17 7:51 ` Pierre Neidhardt
2020-02-17 7:54 ` zimoun
2020-02-17 13:42 ` Pierre Neidhardt
2020-02-17 18:33 ` zimoun
2020-02-24 10:19 ` Pierre Neidhardt
2020-02-24 16:22 ` Ludovic Courtès
2020-02-24 16:44 ` Pierre Neidhardt
2020-02-24 17:11 ` zimoun
2020-02-24 20:54 ` Ludovic Courtès [this message]
2020-02-24 21:32 ` Pierre Neidhardt
2020-02-24 16:53 ` zimoun
2020-02-05 15:13 ` Ludovic Courtès
2020-02-06 9:56 ` Pierre Neidhardt
2020-02-07 21:33 ` Ludovic Courtès
2020-02-08 16:34 ` Pierre Neidhardt
2020-02-04 16:40 ` zimoun
2020-02-10 19:36 ` Pierre Neidhardt
2020-02-10 23:24 ` zimoun
2020-02-11 6:22 ` Pierre Neidhardt
2020-02-11 14:11 ` Ludovic Courtès
2020-02-11 14:19 ` Pierre Neidhardt
2020-02-11 15:14 ` zimoun
2020-02-11 16:37 ` Jack Hill
2020-02-11 18:09 ` zimoun
2020-02-11 19:04 ` Jack Hill
2020-02-12 13:39 ` Pierre Neidhardt
2020-02-12 16:30 ` zimoun
2020-02-13 9:35 ` zimoun
2020-02-24 16:18 ` Ludovic Courtès
2020-02-24 16:45 ` Pierre Neidhardt
2020-02-24 16:59 ` zimoun
2020-02-24 16:50 ` zimoun
2020-02-11 15:11 ` zimoun
2020-02-11 15:06 ` zimoun
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=874kvfg103.fsf@gnu.org \
--to=ludo@gnu.org \
--cc=guix-devel@gnu.org \
--cc=mail@ambrevar.xyz \
/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).