GNU bug report logs - #36591
26.2; Term's pager seems broken

Previous Next

Full log

View this message in rfc822 format

From: Noam Postavsky <npostavs <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: Lars Ingebrigtsen <larsi <at> gnus.org>, abliss <at> gmail.com, 36591 <at> debbugs.gnu.org
Subject: bug#36591: 26.2; Term's pager seems broken
Date: Wed, 24 Jul 2019 20:55:38 -0400

[Message part 1 (text/plain, inline)]

Eli Zaretskii <eliz <at> gnu.org> writes:

> I see that it's a small mess, but I don't think I understand your
> reasoning about setting the filter to t twice: it looks to me that
> both calls will clear the bit of p->infd, because they both will
> trigger this clause:
>
>       if (EQ (p->filter, Qt) && !EQ (p->status, Qlisten))

> Am I missing something?

Argh, no, I was confused.  The code in Emacs 25 is correct, although
(IMO) somewhat misleading.

>   . if the filter is not t, we will now call add_process_read_fd every
>     time, for no good reason

(This is a moot point due to the second problem, but)
add_process_read_fd just sets some bits, which is harmless even if
repeated.

>   . the patch changes how connect_network_socket works in ways that we
>     don't sufficiently understand

Yes, I agree this is a serious problem.

> I would like to leave connect_network_socket alone on the release
> branch, and just fix the problem with set-process-filter.  I think the
> easiest way is simply not to call set_process_filter_masks in
> set-process-filter, and instead restore the way that code worked
> before 9755b753, i.e. let it test the argument FILTER _before_ that
> filter is installed.  Do you see any problems with this fix?

I think that makes sense, patch attached.

[0001-Fix-subproc-listening-when-setting-filter-to-non-t-B.patch (text/plain, attachment)]

[Message part 3 (text/plain, inline)]

> On the master branch we should clean up the confusing set of if
> clauses, both in set-process-filter and in connect_network_socket.
> Perhaps Lars could describe his reasoning for making the change which
> introduced set_process_filter_masks and what problem it tried to
> solve.  (Btw, the log message for that change seems to imply that
> set-process-filter should not have called set_process_filter_masks,
> something that the change itself disagrees with.  An omission?)

Hmm, true, I didn't pay that close attention to the log message.
Maybe "we may not have a socket yet" refers to the already existing
'if (p->infd >= 0)' check?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.