From: Eli Zaretskii <eliz@gnu.org>
To: Spencer Baugh <sbaugh@janestreet.com>
Cc: 62958@debbugs.gnu.org
Subject: bug#62958: [PATCH] Set PAGER=cat in comint.el
Date: Thu, 20 Apr 2023 18:56:45 +0300 [thread overview]
Message-ID: <83zg724kea.fsf@gnu.org> (raw)
In-Reply-To: <iermt32zhb5.fsf@janestreet.com> (message from Spencer Baugh on Thu, 20 Apr 2023 11:47:42 -0400)
> From: Spencer Baugh <sbaugh@janestreet.com>
> Cc: 62958@debbugs.gnu.org
> Date: Thu, 20 Apr 2023 11:47:42 -0400
>
> Eli Zaretskii <eliz@gnu.org> writes:
>
> > Sorry, this default cannot be universally correct. You assume that
> > 'cat' is always available, which is not true on non-Posix platforms.
> > So at the very least the value should be set according to
> > executable-find.
>
> executable-find is not correct in the case of "cat" unfortunately,
> because there are programs (git, for one) which if they see PAGER=cat,
> just don't start a pager at all, for greater efficiency. (which is
> desirable behavior)
Is this about removing the leading directories from the value of
executable-find? If so, that is trivial to do, and is not the main
point of what I wrote.
> > Should this test that comint-pager is a string?
>
> I don't think that's necessary; doing
> (if (stringp comint-pager) (list (format "PAGER=%s" comint-pager)))
> would have unexpected behavior if comint-pager was accidentally set to a
> non-string; doing
> (when comint-pager (progn (assert (stringp comint-pager))
> (list (format "PAGER=%s" comint-pager))))
> is a bit verbose and looks weird and is probably not that important.
So we are okay with the user setting the variable to a symbol or a
list or a vector?
Thanks.
next prev parent reply other threads:[~2023-04-20 15:56 UTC|newest]
Thread overview: 31+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-19 21:57 bug#62958: [PATCH] Set PAGER=cat in comint.el Spencer Baugh
2023-04-20 6:43 ` Eli Zaretskii
2023-04-20 15:47 ` Spencer Baugh
2023-04-20 15:56 ` Eli Zaretskii [this message]
2023-04-20 16:01 ` Spencer Baugh
2023-05-05 6:35 ` Eli Zaretskii
2023-05-08 19:38 ` Spencer Baugh
2023-05-09 5:08 ` Eli Zaretskii
2023-05-09 14:55 ` sbaugh
2023-05-09 15:46 ` Eli Zaretskii
2023-05-09 16:30 ` Spencer Baugh
2023-05-09 16:43 ` Eli Zaretskii
2023-05-09 16:53 ` Spencer Baugh
2023-05-09 16:59 ` Eli Zaretskii
2023-05-09 17:01 ` Spencer Baugh
2023-05-09 17:05 ` Eli Zaretskii
2023-05-09 17:13 ` Spencer Baugh
2023-05-09 18:58 ` Eli Zaretskii
2023-05-16 19:49 ` Spencer Baugh
2023-05-17 11:32 ` Eli Zaretskii
2023-05-17 14:55 ` Spencer Baugh
2023-05-19 6:09 ` Eli Zaretskii
2023-05-26 11:31 ` Eli Zaretskii
2023-05-09 17:03 ` Eli Zaretskii
2023-05-10 16:39 ` Juri Linkov
2023-05-10 16:59 ` Eli Zaretskii
2023-05-10 18:13 ` Gregory Heytings
2023-05-12 17:49 ` Juri Linkov
2023-05-12 22:21 ` Gregory Heytings
2023-04-26 7:54 ` Philip Kaludercic
2023-04-26 9:15 ` Eli Zaretskii
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=83zg724kea.fsf@gnu.org \
--to=eliz@gnu.org \
--cc=62958@debbugs.gnu.org \
--cc=sbaugh@janestreet.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.