From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#36591: 26.2; Term's pager seems broken Date: Wed, 24 Jul 2019 18:07:53 +0300 Message-ID: <83y30no4hi.fsf@gnu.org> References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> <87imrsw5gj.fsf@gmail.com> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="14344"; mail-complaints-to="usenet@blaine.gmane.org" Cc: abliss@gmail.com, 36591@debbugs.gnu.org To: Noam Postavsky , Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Wed Jul 24 17:09:21 2019 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([209.51.188.17]) by blaine.gmane.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hqItM-0003aX-3L for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jul 2019 17:09:20 +0200 Original-Received: from localhost ([::1]:52480 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqItK-0002D9-CA for geb-bug-gnu-emacs@m.gmane.org; Wed, 24 Jul 2019 11:09:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:41141) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqItG-0002D0-To for bug-gnu-emacs@gnu.org; Wed, 24 Jul 2019 11:09:16 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hqIt9-0002pM-Bw for bug-gnu-emacs@gnu.org; Wed, 24 Jul 2019 11:09:11 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57286) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hqIt4-0002n0-JI for bug-gnu-emacs@gnu.org; Wed, 24 Jul 2019 11:09:04 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hqIt4-0008JN-De for bug-gnu-emacs@gnu.org; Wed, 24 Jul 2019 11:09:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 24 Jul 2019 15:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 36591 X-GNU-PR-Package: emacs Original-Received: via spool by 36591-submit@debbugs.gnu.org id=B36591.156398089431836 (code B ref 36591); Wed, 24 Jul 2019 15:09:02 +0000 Original-Received: (at 36591) by debbugs.gnu.org; 24 Jul 2019 15:08:14 +0000 Original-Received: from localhost ([127.0.0.1]:37873 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqIsH-0008HP-Td for submit@debbugs.gnu.org; Wed, 24 Jul 2019 11:08:14 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:56684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqIsG-0008HC-3P for 36591@debbugs.gnu.org; Wed, 24 Jul 2019 11:08:12 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:52394) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hqIsA-000254-Gt; Wed, 24 Jul 2019 11:08:06 -0400 Original-Received: from [176.228.60.248] (port=4488 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hqIs7-0008Sm-CV; Wed, 24 Jul 2019 11:08:04 -0400 In-reply-to: <87imrsw5gj.fsf@gmail.com> (message from Noam Postavsky on Tue, 23 Jul 2019 22:07:24 -0400) X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:163667 Archived-At: > From: Noam Postavsky > Cc: abliss@gmail.com, 36591@debbugs.gnu.org > Date: Tue, 23 Jul 2019 22:07:24 -0400 > > static void > set_process_filter_masks (struct Lisp_Process *p) > { > if (EQ (p->filter, Qt) && !EQ (p->status, Qlisten)) > delete_read_fd (p->infd); > else if (EQ (p->filter, Qt) > /* Network or serial process not stopped: */ > && !EQ (p->command, Qt)) > add_process_read_fd (p->infd); > } > > In Emacs 25 it looks like the 'if' cases are the same, but there is a > subtle difference: the first 'if' checks 'filter', while the second > checks 'p->filter'. And furthermore note that pset_filter is called > after this check against 'p->filter', so it is checking the "original" > 'p->filter' value (which means that Emacs 25 has a bug that the fd is > incorrectly enabled if setting the filter to t twice, i.e., (progn > (set-process-filter PROC t) (set-process-filter PROC t))). > > DEFUN ("set-process-filter", Fset_process_filter, Sset_process_filter, > ... > (register Lisp_Object process, Lisp_Object filter) > { > ... > if (p->infd >= 0) > { > if (EQ (filter, Qt) && !EQ (p->status, Qlisten)) > { > FD_CLR (p->infd, &input_wait_mask); > FD_CLR (p->infd, &non_keyboard_wait_mask); > } > else if (EQ (p->filter, Qt) > /* Network or serial process not stopped: */ > && !EQ (p->command, Qt)) > { > FD_SET (p->infd, &input_wait_mask); > FD_SET (p->infd, &non_keyboard_wait_mask); > } > } > > pset_filter (p, filter); 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: current emacs-26: if (EQ (p->filter, Qt) && !EQ (p->status, Qlisten)) delete_read_fd (p->infd); previous code: if (EQ (filter, Qt) && !EQ (p->status, Qlisten)) { FD_CLR (p->infd, &input_wait_mask); FD_CLR (p->infd, &non_keyboard_wait_mask); } Am I missing something? > The patch found by Adam's bisect put the pset_filter call before this > check, so that Emacs 26 checks the 'p->filter' after it's been set > (i.e., the value of the 'filter' parameter). So the second case is no > longer entered when calling (set-filter-process PROC FILTER). Right, this part is clear. My problem was with the solution that just reverses the 2nd test. See below. > > Also, the same function is called in another > > place, so what will this change do to that other caller? > > Hmm, it's difficult to say, there are a lot of optional code paths. I > suspect socket subprocesses might suffer from the same bug, but there > are also some (redundant?) calls add_process_read_fd that might cover it > up (notice that all calls are guarded by !EQ (p->filter, Qt), i.e., the > corrected version of the check in set_process_filter_masks). Yes, that's another small mess. I think we need to be more careful here if we want to have this fixed in Emacs 26.3. The problem with your proposal is that it has potentially far-reaching consequences: . if the filter is not t, we will now call add_process_read_fd every time, for no good reason . the patch changes how connect_network_socket works in ways that we don't sufficiently understand 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? 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?)