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: Thu, 25 Jul 2019 16:01:01 +0300 Message-ID: <83imrqnu9e.fsf@gnu.org> References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> <87imrsw5gj.fsf@gmail.com> <83y30no4hi.fsf@gnu.org> <87ftmvvsol.fsf@gmail.com> <875znqctzy.fsf@mouse.gnus.org> Injection-Info: blaine.gmane.org; posting-host="blaine.gmane.org:195.159.176.226"; logging-data="252621"; mail-complaints-to="usenet@blaine.gmane.org" Cc: abliss@gmail.com, 36591@debbugs.gnu.org, npostavs@gmail.com To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Thu Jul 25 15:02:17 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 1hqdNw-0013aN-LG for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Jul 2019 15:02:17 +0200 Original-Received: from localhost ([::1]:59960 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqdNv-0006Yv-JG for geb-bug-gnu-emacs@m.gmane.org; Thu, 25 Jul 2019 09:02:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42653) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hqdNp-0006Hs-99 for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2019 09:02:14 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hqdNn-0003f3-5m for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2019 09:02:09 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:57949) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hqdNi-0003at-RS for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2019 09:02:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1hqdNi-0003Ta-H8 for bug-gnu-emacs@gnu.org; Thu, 25 Jul 2019 09:02: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: Thu, 25 Jul 2019 13:02: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.156405967813302 (code B ref 36591); Thu, 25 Jul 2019 13:02:02 +0000 Original-Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 13:01:18 +0000 Original-Received: from localhost ([127.0.0.1]:38536 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqdN0-0003SU-17 for submit@debbugs.gnu.org; Thu, 25 Jul 2019 09:01:18 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:57953) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqdMy-0003SH-T9 for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 09:01:17 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:43453) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hqdMt-00038k-La; Thu, 25 Jul 2019 09:01:11 -0400 Original-Received: from [176.228.60.248] (port=4822 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hqdMr-00032X-0I; Thu, 25 Jul 2019 09:01:09 -0400 In-reply-to: <875znqctzy.fsf@mouse.gnus.org> (message from Lars Ingebrigtsen on Thu, 25 Jul 2019 12:02:09 +0200) 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:163703 Archived-At: > From: Lars Ingebrigtsen > Cc: Eli Zaretskii , abliss@gmail.com, 36591@debbugs.gnu.org > Date: Thu, 25 Jul 2019 12:02:09 +0200 > > Noam Postavsky writes: > > >> 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? > > Let's see... this was part of the patch series that allowed for > asynchronous connection setup? > > I think Noam is right -- the "we may not have the socket yet" refers to > this bit: > > if (p->infd >= 0) > set_process_filter_masks (p); So you are saying that the commit log message wanted to explain the code which existed there already? Because the condition that tested p->infd was already there before you refactored the code into set_process_filter_masks. That's somewhat strange, but I guess is OK. However, I still wonder what was the rationale for making the code change in the first place. It seems to me that the real reason was the addition of the call to set_process_filter_masks in connect_network_socket, but why was that necessary? IOW, what was missing from this code in connect_network_socket, which already existed and manipulated some of the same flags and descriptor bits: if (p->is_non_blocking_client) { /* We may get here if connect did succeed immediately. However, in that case, we still need to signal this like a non-blocking connection. */ if (! (connecting_status (p->status) && EQ (XCDR (p->status), addrinfos))) pset_status (p, Fcons (Qconnect, addrinfos)); if ((fd_callback_info[inch].flags & NON_BLOCKING_CONNECT_FD) == 0) add_non_blocking_write_fd (inch); } else /* A server may have a client filter setting of Qt, but it must still listen for incoming connects unless it is stopped. */ if ((!EQ (p->filter, Qt) && !EQ (p->command, Qt)) || (EQ (p->status, Qlisten) && NILP (p->command))) add_process_read_fd (inch); And in what use case did you see the need for the additional handling in set_process_filter_masks? I'd like to have a good understanding of this, so that we could make this code less confusing on the master branch. TIA