From unknown Tue Jun 17 01:26:36 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#36591 <36591@debbugs.gnu.org> To: bug#36591 <36591@debbugs.gnu.org> Subject: Status: 26.2; Term's pager seems broken Reply-To: bug#36591 <36591@debbugs.gnu.org> Date: Tue, 17 Jun 2025 08:26:36 +0000 retitle 36591 26.2; Term's pager seems broken reassign 36591 emacs submitter 36591 Adam Bliss severity 36591 normal tag 36591 fixed thanks From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 11 00:27:07 2019 Received: (at submit) by debbugs.gnu.org; 11 Jul 2019 04:27:07 +0000 Received: from localhost ([127.0.0.1]:36916 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlQfj-0008SN-3S for submit@debbugs.gnu.org; Thu, 11 Jul 2019 00:27:07 -0400 Received: from lists.gnu.org ([209.51.188.17]:55266) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hlMbN-0006Ol-TX for submit@debbugs.gnu.org; Wed, 10 Jul 2019 20:06:23 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:44248) by lists.gnu.org with esmtp (Exim 4.86_2) (envelope-from ) id 1hlMbM-0005Ds-0x for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 20:06:21 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=0.8 required=5.0 tests=BAYES_50,FREEMAIL_FROM, HTML_MESSAGE,URIBL_BLOCKED autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1hlMbK-0008Qg-05 for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 20:06:19 -0400 Received: from mail-lj1-x232.google.com ([2a00:1450:4864:20::232]:34750) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1hlMbI-0008N5-Pu for bug-gnu-emacs@gnu.org; Wed, 10 Jul 2019 20:06:17 -0400 Received: by mail-lj1-x232.google.com with SMTP id p17so3883589ljg.1 for ; Wed, 10 Jul 2019 17:06:15 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:from:date:message-id:subject:to; bh=4Bmx2JrGiJtRmcJ5WazppmoqWfHhtgO/BiD+GKjcOsE=; b=dmSNweJJnT3qBZsEJdj4XkHR2UY6MwNtQVeWBpHWd/6V7jueh4mx/nZHBrB/8bL+YR iis7rc8Onj/MXOZs+M7p68CdCWS7eWpd6zVlaMSuIYfpkieuDMSpZGw6CjMXhj6GZzj0 i4X6ktzS6Np34FBoEBh7Yu8tIc7oveOSBHZuF4K7Xcu6vCOUq0KXZWCxAh5515pC2mOX Mk0L6LGDEUu1jnygz2Op1hYoNxmA49c/uQ7hfPixjuEglx3G+GAObV5/3i3H2rcg6C0Q gNmweF3f+G0nw0plwASC4dTaxCIDPtjJdqvYsS2RJLmV6NzILJSLJEodhiP+6SoqBzo9 hfyg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:from:date:message-id:subject:to; bh=4Bmx2JrGiJtRmcJ5WazppmoqWfHhtgO/BiD+GKjcOsE=; b=bR7sLMgH5wtuK9MJ7CMPHsNDt+LJby25XBPK58ujmsbQWv0ak1e5HFYzE7ESO+5gi7 afaUO7LoIW5vsr6P7uDCMkvG6AUdkZU2HMEeNbmomuZtE0tZuyTxWy3k+HzOZAU6MjXC ki7uti5cKeQDuioK1+KcqSrvMGEVUSxts9Ohop+3rYPoI4KFb9nSivR6tji/cvwPgCkP URL5sjsww66NRS/niUSO6ODPExGr2Wpzd9gcVnUtkxYaesMyE82fuldqZzXddshVUKvZ Y/QFm8sii8htuKKiRdUmqmT9iDNgX1sjdMif3+sGxHtJoWsxKDOHuhQtCsS+D93mKKuM zHDg== X-Gm-Message-State: APjAAAVPe7ctWsAnWjxqfQO1rIZ+adQkOnmflI1z5DdGRqACIGl0nyD2 okV9imeFIj1YIAcbmoa5f9qMWSxY3yhqS+MeXbqXdYWb X-Google-Smtp-Source: APXvYqybBRdm68+vfDJwY35qG52h9n36w9Po9bszcDUSGw3G51/f5zd8HZro/lDjc+5JJfQcpOcEm8IQhuSeIvekqk0= X-Received: by 2002:a2e:b0d0:: with SMTP id g16mr489015ljl.161.1562803573505; Wed, 10 Jul 2019 17:06:13 -0700 (PDT) MIME-Version: 1.0 From: Adam Bliss Date: Wed, 10 Jul 2019 20:06:00 -0400 Message-ID: Subject: 26.2; Term's pager seems broken To: bug-gnu-emacs@gnu.org Content-Type: multipart/alternative; boundary="000000000000da4110058d5c8f1f" X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::232 X-Spam-Score: -1.3 (-) X-Debbugs-Envelope-To: submit X-Mailman-Approved-At: Thu, 11 Jul 2019 00:27:03 -0400 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.3 (--) --000000000000da4110058d5c8f1f Content-Type: text/plain; charset="UTF-8" Hello, Recently I learned about the pager-mode built into M-x term. I tried it with some excitement, but discovered that, while it works fine in emacs 24, it seems completely broken in emacs 25-26. To reproduce, simply open a terminal (M-x term); enable the pager (C-c C-q); and run any command that outputs more than a screenful (like `seq 100`). After paging to the end (with the spacebar), try to type another command (like `echo foo`). The terminal appears to hang until killed. (Actually, the inferior process is still running and receiving your input, but the term buffer displays no further output. You can force it to dump some output with C-c M-x term-continue subjob, but it goes back to being hung after.) I hacked up this little elisp function to demonstrate the bug: ``` (defun test-bug () "demonstrate bug" (interactive) (progn (term "/bin/bash") (sit-for 2) (term-pager-enable) (term-send-raw-string "seq 50\n") (sit-for 2) (term-pager-page 50) (term-send-raw-string "echo foo\n") (sit-for 2) (term-line-mode) (move-beginning-of-line nil) (forward-line -1) (let ((code (if (= (string-to-char "f") (char-after)) 0 1))) (kill-emacs code) ;;(message "answer: %d" code) ) ) ) (test-bug) ``` Then, I wrote this little bash script for use in `git bisect`: ``` #!/bin/bash set -euxo pipefail date git clean -dxf ./autogen.sh || exit 125 ./configure --with-x=no --without-makeinfo --with-gnutls=yes || exit 125 make -j4 || exit 125 exec src/emacs -Q -l ../bisect.el ``` The bisect was a bit rougher than I expected, for three reasons: (1) my dumb elisp has some kind of race condition, and sometimes will neither pass nor fail but hang waiting for further input; (2) the repo's autogen/autotools/Makefile don't seem to agree with `git checkout` about timestamps, so I had pretty much had to do a clean build rather than an incremental build at each step; (3) several commits in the vicinity of the First Bad Commit have builds which are broken without gnutls. However, I was eventually able to get this output as the First Bad Commit: 9755b75300b7c451bc79984eed2e346ce0a4ffb5 is the first bad commit commit 9755b75300b7c451bc79984eed2e346ce0a4ffb5 Author: Lars Ingebrigtsen Date: Tue Feb 16 13:37:33 2016 +1100 Allow setting the filter masks later * src/process.c (Fset_process_filter): Don't set the socket masks here, because we may not have a socket yet. (set_process_filter_masks): New function. (connect_network_socket): Set the filter masks here. I hope that this is helpful in tracking down the bug. Please let me know if any further details are required. Thanks, --Adam --000000000000da4110058d5c8f1f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable 
Hel=
lo,=20

Recently I learned about the pager-mode built into M-x term. I tried
it with some excitement, but discovered that, while it works fine in
emacs 24, it seems completely broken in emacs 25-26.

To reproduce, simply open a terminal (M-x term); enable the pager (C-c
C-q); and run any command that outputs more than a screenful (like
`seq 100`). After paging to the end (with the spacebar), try to type
another command (like `echo foo`). The terminal appears to hang until
killed. (Actually, the inferior process is still running and receiving
your input, but the term buffer displays no further output. You can
force it to dump some output with C-c M-x term-continue subjob, but it
goes back to being hung after.)

I hacked up this little elisp function to demonstrate the bug:


```
(defun test-bug () "demonstrate bug" (interactive)
  (progn
    (term "/bin/bash")
    (sit-for 2)
    (term-pager-enable)
    (term-send-raw-string "seq 50\n")
    (sit-for 2)
    (term-pager-page 50)
    (term-send-raw-string "echo foo\n")
    (sit-for 2)
    (term-line-mode)
    (move-beginning-of-line nil)
    (forward-line -1)
    (let ((code  (if (=3D (string-to-char "f") (char-after)) 0 1)=
))
      (kill-emacs code)
      ;;(message "answer: %d" code)
      )
    )
  )
(test-bug)
```

Then, I wrote this little bash script for use in `git bisect`:

```
#!/bin/bash
set -euxo pipefail
date
git clean -dxf
./autogen.sh || exit 125
./configure --with-x=3Dno --without-makeinfo --with-gnutls=3Dyes || exit 12=
5
make -j4 || exit 125
exec src/emacs -Q -l ../bisect.el
```

The bisect was a bit rougher than I expected, for three reasons: (1)
my dumb elisp has some kind of race condition, and sometimes will
neither pass nor fail but hang waiting for further input; (2) the
repo's autogen/autotools/Makefile don't seem to agree with `git
checkout` about timestamps, so I had pretty much had to do a clean
build rather than an incremental build at each step; (3) several
commits in the vicinity of the First Bad Commit have builds which are
broken without gnutls.

However, I was eventually able to get this output as the First Bad
Commit:

9755b75300b7c451bc79984eed2e346ce0a4ffb5 is the first bad commit
commit 9755b75300b7c451bc79984eed2e346ce0a4ffb5
Author: Lars Ingebrigtsen <larsi@gnus.=
org>
Date:   Tue Feb 16 13:37:33 2016 +1100

    Allow setting the filter masks later
    * src/process.c (Fset_process_filter): Don't set the socket
    masks here, because we may not have a socket yet.
    (set_process_filter_masks): New function.
    (connect_network_socket): Set the filter masks here.

=20
I hope that this is helpful in tracking down the bug. 
Please let me know if any further details are required=
.
Thanks,
--Adam
--000000000000da4110058d5c8f1f-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 23 09:53:45 2019 Received: (at 36591) by debbugs.gnu.org; 23 Jul 2019 13:53:45 +0000 Received: from localhost ([127.0.0.1]:34168 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hpvEf-0007Nx-LA for submit@debbugs.gnu.org; Tue, 23 Jul 2019 09:53:45 -0400 Received: from mail-io1-f48.google.com ([209.85.166.48]:37367) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hpvEe-0007Nm-Ic for 36591@debbugs.gnu.org; Tue, 23 Jul 2019 09:53:45 -0400 Received: by mail-io1-f48.google.com with SMTP id q22so81953240iog.4 for <36591@debbugs.gnu.org>; Tue, 23 Jul 2019 06:53:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=Zj7VnKU6+k8CELV+G23ZWLeyUxc9BBRJhsm3hMw9zjM=; b=vWJI6AmcIqu0867RIhsChKfkNbqPeFLut4aBSrq4gLtRxUbstBjEHp+TXIF7ujeIlD QtDKMb26c6s3ZJ2w6tgoKw1jOJ2m+z017CtRT77/4gquBHnpxpradUOODp1q8Sk0FJ7e 05N51lj8nURGj5AEDnVsDB/zMcw8qBj8WL/6P/FXrJKF4Mcvdh9jEC2F8uNce2jVKhsb 86KOvLN9J2orQttN4DKL6NOM+44OxNPuO71lDrhzkNb55e7AqrHagdoE27bpvVh645CW Piq3l+R5KGxkVaEODGk9ol/G+/kNuQi0cMBBO7n/nYXfrg1+W5WY0XN3f4pRHwnrEu/N RAVg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=Zj7VnKU6+k8CELV+G23ZWLeyUxc9BBRJhsm3hMw9zjM=; b=ZstckhiersVVweGQSPqL9fVuclb0yVaK9z7OsH3QIpDfxdFp1DZJJMPzJibIInvBr0 9dEDGhcVLnxPGF5ivUx5rc68BnQS7MS0bATC7OulbgEbVXN4dRx/5zPoDeZWtKHRD7Su RB4XyIK9Q/WPtFAjVlg0pW+sRr0y46ByBqf9dMK0CMtvl5uRdILN57/oknHc5ABJoF6i iD3KFBG4KVFM+N4MuQPKKG+4bdt28JGjsXLq5iiUXZPU9PSlNfhCCmCJ2EY5TfBbP4K1 lIAFx1idgxDo8m+qfzunOVFEdEEMZtQFS7pbX9zd3lZh48yylGnUWNbnMpS+h9d64l02 FcNQ== X-Gm-Message-State: APjAAAVkLI3mM1Pn+oG8BvC15B3yst+9C6+RIH5sAcKiSgoCQO13GvlT NdzXMh08e43RwiFqtOnxdngwB9rM X-Google-Smtp-Source: APXvYqxtqSpD3NIIthYpN+LUdiOotlpFKELbVOT/Z4RbcBhr762fAPo3GxjcAElmw78S6KGjAVHilw== X-Received: by 2002:a5e:9304:: with SMTP id k4mr73198626iom.206.1563890018709; Tue, 23 Jul 2019 06:53:38 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id u17sm40435349iob.57.2019.07.23.06.53.37 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Jul 2019 06:53:37 -0700 (PDT) From: Noam Postavsky To: Adam Bliss Subject: Re: bug#36591: 26.2; Term's pager seems broken References: Date: Tue, 23 Jul 2019 09:53:37 -0400 In-Reply-To: (Adam Bliss's message of "Wed, 10 Jul 2019 20:06:00 -0400") Message-ID: <87lfwox3fi.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Adam Bliss writes: > I hope that this is helpful in tracking down the bug. Thanks for doing this, it was very helpful. That commit looks like a pretty innocent refactoring, but it actually reverses the sense of the EQ (p->filter, Qt) check, because the pset_filter call is moved earlier. So the bug can be fixed by adding a single '!'. Eli, any chance of having this fix in the release branch? --- i/src/process.c +++ w/src/process.c @@ -1230,7 +1230,7 @@ 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) + else if (!EQ (p->filter, Qt) /* Network or serial process not stopped: */ && !EQ (p->command, Qt)) add_process_read_fd (p->infd); From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 23 13:41:03 2019 Received: (at 36591) by debbugs.gnu.org; 23 Jul 2019 17:41:03 +0000 Received: from localhost ([127.0.0.1]:35585 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hpymc-0001Ok-TC for submit@debbugs.gnu.org; Tue, 23 Jul 2019 13:41:03 -0400 Received: from eggs.gnu.org ([209.51.188.92]:43021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hpymZ-0001O7-UM for 36591@debbugs.gnu.org; Tue, 23 Jul 2019 13:41:01 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:59002) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hpymT-0002F8-LL; Tue, 23 Jul 2019 13:40:54 -0400 Received: from [176.228.60.248] (port=1791 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hpymT-0008J5-5Q; Tue, 23 Jul 2019 13:40:53 -0400 Date: Tue, 23 Jul 2019 20:40:41 +0300 Message-Id: <838ssops2u.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: <87lfwox3fi.fsf@gmail.com> (message from Noam Postavsky on Tue, 23 Jul 2019 09:53:37 -0400) Subject: Re: bug#36591: 26.2; Term's pager seems broken References: <87lfwox3fi.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 36591 Cc: abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Noam Postavsky > Date: Tue, 23 Jul 2019 09:53:37 -0400 > Cc: 36591@debbugs.gnu.org > > Adam Bliss writes: > > > I hope that this is helpful in tracking down the bug. > > Thanks for doing this, it was very helpful. That commit looks like a > pretty innocent refactoring, but it actually reverses the sense of the > EQ (p->filter, Qt) check, because the pset_filter call is moved earlier. > > So the bug can be fixed by adding a single '!'. Eli, any chance of > having this fix in the release branch? I don't think I understand why the change fixes the bug, sorry. Can you tell in more detail? Also, the same function is called in another place, so what will this change do to that other caller? And how come we lived with this bug for 3 years without having noticed it? From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 23 18:34:01 2019 Received: (at 36591) by debbugs.gnu.org; 23 Jul 2019 22:34:02 +0000 Received: from localhost ([127.0.0.1]:35787 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hq3M7-0004eE-Bk for submit@debbugs.gnu.org; Tue, 23 Jul 2019 18:34:01 -0400 Received: from mail-lf1-f44.google.com ([209.85.167.44]:42957) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hq3M4-0004dX-Qk for 36591@debbugs.gnu.org; Tue, 23 Jul 2019 18:33:57 -0400 Received: by mail-lf1-f44.google.com with SMTP id s19so30500094lfb.9 for <36591@debbugs.gnu.org>; Tue, 23 Jul 2019 15:33:56 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oJrSGJVcgafaIP1ZcTw2m+eUgOPU0lPQ3nlb5CDuLgw=; b=R4qzWu6yzWhIR2BMpqpDI/zumAKcQOayKwX+m47lGACZqWQ/OV44AFYPUJDjx6UGkN VgBY1853uy5HxB/VLX7YFj3Npj5JtxeRf4duxOhAeJLSPIgBG7n0lB3g/I3R2fYwp+H6 b+J0FMjGULsJWQKuvFSKNpGIAjC/GM1zJZW7ECcySYYdom5AXQ7h9cmIlxK+xLri6rsf rh3WE0GQW53rUUequSNW1m16JSk5ORetZj2Ib3gmVDcXPnl+K3X07zlsDgogxv/OBxdp /X3S7mOt/87eKYxcURKxlYiwrLyLG/sqBC4RJD/PFSeXEkoBYYg+4MHCYn6lnrJ30rvQ Ma6A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oJrSGJVcgafaIP1ZcTw2m+eUgOPU0lPQ3nlb5CDuLgw=; b=FBwL+OnkyKLKWA0XIousy5/uJ17P1GiCK88bTIrT7aaBo99hLVzHXlUlLeZPmAaO3W 4KQ0nI7jdyB9atBIHZ3gjIX94VObCpahS6yKUKZfElJGRrKNw7MUc/wMPbh+U3HOv1SX cuPk3nY0dYlAdH4FKpAlR0fiLTwZy09fSNdZR1KrcgingF+BD3dmJm4t2SlVCey0Dr5F tlh5Wz7Qsgp8zaPZM1JM6P2fv98JvtCDz5m9FTMqgDqZtPplF/Jh+945cAuM5TiarEZ/ 0HQoEbJrqqV8PJTPbntH4abW+vI7U6HhNsaoB6IABHmAa4Kv8mXexmUAd3E1dVKfWeJ4 aXPA== X-Gm-Message-State: APjAAAVRxu3bNiImB0o1M9uPxXfkbXfFr0Olc5ruPviq0dOtulrhP7M2 U5HxpLnSsxwt1iizGVIowjgEZP5qi8jfYUEJ2Ik= X-Google-Smtp-Source: APXvYqyVdsfuEHfQ3UF3X/raal6a4oWsW+wI3sXR5j4UJxMOB4JdQIDrwp8s5AxfANkQEWF0nwZhJ2yd3UaJlruPsr0= X-Received: by 2002:a19:6557:: with SMTP id c23mr22611821lfj.12.1563921230708; Tue, 23 Jul 2019 15:33:50 -0700 (PDT) MIME-Version: 1.0 References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> In-Reply-To: <838ssops2u.fsf@gnu.org> From: Adam Bliss Date: Tue, 23 Jul 2019 18:33:38 -0400 Message-ID: Subject: Re: bug#36591: 26.2; Term's pager seems broken To: Eli Zaretskii Content-Type: multipart/alternative; boundary="00000000000069c4dc058e60c9cb" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Noam Postavsky , 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --00000000000069c4dc058e60c9cb Content-Type: text/plain; charset="UTF-8" On Tue, Jul 23, 2019, 13:40 Eli Zaretskii wrote: > > From: Noam Postavsky > > Date: Tue, 23 Jul 2019 09:53:37 -0400 > > Cc: 36591@debbugs.gnu.org > > > > So the bug can be fixed by adding a single '!'. Eli, any chance of > > having this fix in the release branch? > > I don't think I understand why the change fixes the bug, sorry. Can > you tell in more detail? Also, the same function is called in another > place, so what will this change do to that other caller? > > And how come we lived with this bug for 3 years without having noticed > it? > I don't understand it either, and I can't answer your questions; however I can confirm that the proposed patch, atop my local build of 26.2, does seem to fix the bug. Thanks, --Adam > --00000000000069c4dc058e60c9cb Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Tue, = Jul 23, 2019, 13:40 Eli Zaretskii <eliz@= gnu.org> wrote:
> From: N= oam Postavsky <npostavs@gmail.com>
> Date: Tue, 23 Jul 2019 09:53:37 -0400
> Cc: 36591@debbugs.gnu.org
>
> So the bug can be fixed by adding a single '!'.=C2=A0 Eli, any= chance of
> having this fix in the release branch?

I don't think I understand why the change fixes the bug, sorry.=C2=A0 C= an
you tell in more detail?=C2=A0 Also, the same function is called in another=
place, so what will this change do to that other caller?

And how come we lived with this bug for 3 years without having noticed
it?

I don't understand it either, and I can't answer your questions;= however I can confirm that the proposed patch, atop my local build of 26.2= ,=C2=A0does seem to fix the bug.

Thanks,
--Adam=C2=A0
--00000000000069c4dc058e60c9cb-- From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 23 22:07:34 2019 Received: (at 36591) by debbugs.gnu.org; 24 Jul 2019 02:07:34 +0000 Received: from localhost ([127.0.0.1]:35868 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hq6go-0003fC-Bf for submit@debbugs.gnu.org; Tue, 23 Jul 2019 22:07:34 -0400 Received: from mail-io1-f51.google.com ([209.85.166.51]:43709) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hq6gm-0003ex-Da for 36591@debbugs.gnu.org; Tue, 23 Jul 2019 22:07:32 -0400 Received: by mail-io1-f51.google.com with SMTP id k20so86157802ios.10 for <36591@debbugs.gnu.org>; Tue, 23 Jul 2019 19:07:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=idHm9N47XEyOeOfjnXBvKAlyJ4hl4RgCBn3xebX+diI=; b=oS3bbYojuS/YCCwDxydSDDOYVPmEx32UJJHGR3x0a4Pbs6DGZSaPDGBy5WrHlIqi2K 7a+1dMdMCldenh98+v10yl6yks5UNjhjRAi1SvZCf3L3u1MnSE4PVKkTAiZ+F8qqPu4J ModbQpNFXtLY2saIVWFkmT1qDAx/Sjy8YWzhpOPZSRiEoqYiC0HbwDew4536wbtIslQx 8VpBD3KD1KEw7e923VC0oskra3LFB36xY9EpXVipcp3DCYZPqXwDCsv7PWIy6gyPuAIX c5FPx+yJtG8amcoHnN0R6eZBBHTDiE0XXsC0S5NAjLE9icDn/3tASWUxflhIrpi9iv36 h3VA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=idHm9N47XEyOeOfjnXBvKAlyJ4hl4RgCBn3xebX+diI=; b=OJPrqJD3eouoPvIT6B9F70WpLwxV1+gh7CVzlpRNWiBJuEhf4nR+i8QTRQiy0p0R3Q OcyFNt+WaUhSyQdIgK5lt9/Lya6/XtmdtdACFCRK6s8gvXJ7BkBouxlOWXmKMOWj524j 48257aQJMepiTIRiiCjPWauVe4fH0VCOnPPGuiIpukE39lqC2rHkbyHpeY+pIDJwwB1v eBtqCO01uE6/ADvgaDK6Pr4mXtTeJdkZl5kE2Da/TDiglQkk/z5WDXVYAhXTVUslRhRP CL7JbC+rvQZDn8QI37jZW2HC9la7GUm0mXLZyqom3IDXX8ebvC7g7r91aeA/tKrGCnnq Pydg== X-Gm-Message-State: APjAAAWXs8PbucxwxiGTvM+zuN1nCDqRd4BFNBhCl1dsIt/5pNid7NW4 Gas0mztvTyTwPxeE04l1B+SfE5j6 X-Google-Smtp-Source: APXvYqxDIjVmnxoxB8RJHsMiJGGQLKBF4FP746UlFGl4wSXTUsswTzt4X8K14vlNLBhLSBwZDLUKwg== X-Received: by 2002:a02:13c3:: with SMTP id 186mr80964913jaz.30.1563934046605; Tue, 23 Jul 2019 19:07:26 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id t133sm65945121iof.21.2019.07.23.19.07.24 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Tue, 23 Jul 2019 19:07:25 -0700 (PDT) From: Noam Postavsky To: Eli Zaretskii Subject: Re: bug#36591: 26.2; Term's pager seems broken References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> Date: Tue, 23 Jul 2019 22:07:24 -0400 In-Reply-To: <838ssops2u.fsf@gnu.org> (Eli Zaretskii's message of "Tue, 23 Jul 2019 20:40:41 +0300") Message-ID: <87imrsw5gj.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: > I don't think I understand why the change fixes the bug, sorry. Can > you tell in more detail? Okay. First, see attached reduced test case which demonstrates the bug. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=bug-36591-proc-filter-t.el Content-Description: demo for bug (with-current-buffer (get-buffer-create "*test buffer*") (let* ((oldproc (get-buffer-process (current-buffer)))) (when oldproc (kill-process oldproc) (accept-process-output oldproc))) (erase-buffer) (display-buffer (current-buffer)) (let* ((print-level nil) (print-length nil) (proc (start-process "test proc" (current-buffer) (concat invocation-directory invocation-name) "-Q" "--batch" "--eval" (prin1-to-string '(let (s) (while (setq s (read-from-minibuffer "$ ")) (princ s) (princ "\n"))))))) (send-string proc "one\n") (sit-for 0.5) ; Read "one". (set-process-filter proc t) ; Stop reading from proc. (send-string proc "two\n") (sit-for 1) ; Can't read "two" yet. (set-process-filter proc ; Resume reading from proc. #'internal-default-process-filter) (sit-for 0.5) ; Read "two" from proc. )) --=-=-= Content-Type: text/plain In Emacs 25 it shows a buffer named "*test buffer*" with contents $ one $ two $ In Emacs 26, the "two" never gets read, so the result is $ one $ Calling (set-process-filter PROC t) is supposed to turn off reading for PROC. This works fine. But (set-process-filter PROC FILTER) doesn't turn on reading again in Emacs 26. Neither of the cases in set_process_filter_masks are taken in the case when FILTER is not t. DEFUN ("set-process-filter", Fset_process_filter, Sset_process_filter, ... (Lisp_Object process, Lisp_Object filter) { ... pset_filter (p, filter); // <-- sets p->filter = filter; if (p->infd >= 0) set_process_filter_masks (p); ... } 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); 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). > 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). static void connect_network_socket (Lisp_Object proc, Lisp_Object addrinfos, Lisp_Object use_external_socket_p) { ... if (p->is_non_blocking_client) {...} 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); ... } ... static void server_accept_connection (Lisp_Object server, int channel) { ... /* Client processes for accepted connections are not stopped initially. */ if (!EQ (p->filter, Qt)) add_process_read_fd (s); ... } ... int wait_reading_process_output (intmax_t time_limit, int nsecs, int read_kbd, bool do_display, Lisp_Object wait_for_cell, struct Lisp_Process *wait_proc, int just_wait_proc) { ... if (0 <= p->infd && !EQ (p->filter, Qt) && !EQ (p->command, Qt)) add_process_read_fd (p->infd); ... } ... DEFUN ("continue-process", Fcontinue_process, Scontinue_process, 0, 2, 0, ...) (Lisp_Object process, Lisp_Object current_group) { ... if (EQ (p->command, Qt) && p->infd >= 0 && (!EQ (p->filter, Qt) || EQ (p->status, Qlisten))) { add_process_read_fd (p->infd); > And how come we lived with this bug for 3 years without having noticed > it? I think there is very little use of t as a process filter value. Maybe term.el is the only user of it. As to why nobody noticed the problem in term.el earlier, I have the impression that most users just assume term.el will be buggy and don't even bother reporting problems with it (typical suggestions are "run screen or tmux to handle escape codes properly", or "use the libvterm Emacs extension instead"). --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 24 11:08:14 2019 Received: (at 36591) by debbugs.gnu.org; 24 Jul 2019 15:08:14 +0000 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 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 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 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 Date: Wed, 24 Jul 2019 18:07:53 +0300 Message-Id: <83y30no4hi.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky , Lars Ingebrigtsen In-reply-to: <87imrsw5gj.fsf@gmail.com> (message from Noam Postavsky on Tue, 23 Jul 2019 22:07:24 -0400) Subject: Re: bug#36591: 26.2; Term's pager seems broken References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> <87imrsw5gj.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 36591 Cc: abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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?) From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 24 20:55:47 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 00:55:47 +0000 Received: from localhost ([127.0.0.1]:38195 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqS2t-0004ur-DR for submit@debbugs.gnu.org; Wed, 24 Jul 2019 20:55:47 -0400 Received: from mail-io1-f41.google.com ([209.85.166.41]:40364) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqS2r-0004ue-Vk for 36591@debbugs.gnu.org; Wed, 24 Jul 2019 20:55:46 -0400 Received: by mail-io1-f41.google.com with SMTP id h6so7037317iom.7 for <36591@debbugs.gnu.org>; Wed, 24 Jul 2019 17:55:45 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=XliK3vqoTNw4wGdMu4zfBlV12h3j5GLQFbi5f9DceyQ=; b=c19W7YFxVE0b2jHmUG7nqHjRfNlgTXQg1c5FdUqXargfDS6kKLkkUqoZIMAcGIV/q6 lQjHjLiABBHs4OWkcM0z6lW9Dhn0224O5Wv5AN+dwePDr2H/Ct+xLkT7s4ea8udybTpk 8afu6B2YCBBuuSqrzgP4Kvc1XXEHyrBLud7C1gfju9FbGwP3LYMUcZS31g9+rK54CZHE Uwki0x2c+FSh4vpFNpDnEJKeORBSb0sMq5/OAlGpxMsZbjNO/nATiYs5G5jPpmI1t24c Z82VgrV2zIZNh8kiOFGZAa6yj8ANH+D1t/x+GHM7T9zQRpmLXYNB/KSz5I562lO5lScQ R4nA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=XliK3vqoTNw4wGdMu4zfBlV12h3j5GLQFbi5f9DceyQ=; b=f3bCRRURMyO6b5fFeI793nTUr/jOo9XGTLtSXnSIDVj7N3GRaD5wkgyqhVNdBo2IGb B4Jbntr6OAunfsQRglkj07Nov+GaMDvcqb63j4DsEKDFOtTzvsvwJhRUOvqRulYqQnUf YyU2DZzknfXH61uwBIF1URCHNcOcBWXlaDnR9EIVoKOw6RmCFf7Nm6c3JaMyt2sO3zBd HrbSE9x5CapPz0YEZ/pkMD13It+m8PMUiouwxUbwC1RSBBt4zNBp3J2dzDuUF0JFZMWQ RxJzrzcfnekpitClfIj3Q2+ONfJ89wUhSt0FaOlMRhxQkNvLzsTPjlTVWQ64nFvrTpJY /9gQ== X-Gm-Message-State: APjAAAVg5CamUgF30yBS2LHZfxlcoRVx3YQxX2+lzVyNAhdNxrjHp835 imqk/LQvbUwgx+2fgEKjNSeI5Vpm X-Google-Smtp-Source: APXvYqzwMWOcfMA/R+lXOeUzKmaJDiqocDFbesL9UgTbuSW5bOQSFt9W0O7dO4x2vhzmk89seo+bwg== X-Received: by 2002:a02:b68f:: with SMTP id i15mr58674051jam.107.1564016140071; Wed, 24 Jul 2019 17:55:40 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id j1sm45331809iop.14.2019.07.24.17.55.38 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Wed, 24 Jul 2019 17:55:39 -0700 (PDT) From: Noam Postavsky To: Eli Zaretskii Subject: Re: bug#36591: 26.2; Term's pager seems broken References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> <87imrsw5gj.fsf@gmail.com> <83y30no4hi.fsf@gnu.org> Date: Wed, 24 Jul 2019 20:55:38 -0400 In-Reply-To: <83y30no4hi.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 24 Jul 2019 18:07:53 +0300") Message-ID: <87ftmvvsol.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Lars Ingebrigtsen , abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii 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. --=-=-= Content-Type: text/plain Content-Disposition: attachment; filename=0001-Fix-subproc-listening-when-setting-filter-to-non-t-B.patch Content-Description: patch >From ee13774efa2ac4b288f339c668b6002e27fbbe8f Mon Sep 17 00:00:00 2001 From: Noam Postavsky Date: Wed, 24 Jul 2019 20:33:18 -0400 Subject: [PATCH] Fix subproc listening when setting filter to non-t (Bug#36591) * src/process.c (Fset_process_filter): Call add_process_read_fd according to the state of process filter before it's updated. This restores the correct functioning as it was before 2016-02-16 "Allow setting the filter masks later". Inline the set_process_filter_masks call instead of fixing it that function, because it is also called from connect_network_socket, and we don't want to change the behavior of that function so close to release. --- src/process.c | 15 ++++++++++++--- 1 file changed, 12 insertions(+), 3 deletions(-) diff --git a/src/process.c b/src/process.c index 2df51cfd99..b602507765 100644 --- a/src/process.c +++ b/src/process.c @@ -1268,10 +1268,19 @@ DEFUN ("set-process-filter", Fset_process_filter, Sset_process_filter, if (NILP (filter)) filter = Qinternal_default_process_filter; - pset_filter (p, filter); - if (p->infd >= 0) - set_process_filter_masks (p); + { + /* If filter WILL be t, stop reading output. */ + if (EQ (filter, Qt) && !EQ (p->status, Qlisten)) + delete_read_fd (p->infd); + else if (/* If filter WAS t, then resume reading output. */ + EQ (p->filter, Qt) + /* Network or serial process not stopped: */ + && !EQ (p->command, Qt)) + add_process_read_fd (p->infd); + } + + pset_filter (p, filter); if (NETCONN1_P (p) || SERIALCONN1_P (p) || PIPECONN1_P (p)) pset_childp (p, Fplist_put (p->childp, QCfilter, filter)); -- 2.11.0 --=-=-= Content-Type: text/plain > 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? --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 06:02:18 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 10:02:18 +0000 Received: from localhost ([127.0.0.1]:38404 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqaZm-0003EV-6Y for submit@debbugs.gnu.org; Thu, 25 Jul 2019 06:02:18 -0400 Received: from quimby.gnus.org ([80.91.231.51]:41920) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqaZk-0003EF-Gv for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 06:02:16 -0400 Received: from 109.179.27.28.tmi.telenormobil.no ([109.179.27.28] helo=sandy) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hqaZg-0003OP-31; Thu, 25 Jul 2019 12:02:14 +0200 From: Lars Ingebrigtsen To: Noam Postavsky Subject: Re: bug#36591: 26.2; Term's pager seems broken References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> <87imrsw5gj.fsf@gmail.com> <83y30no4hi.fsf@gnu.org> <87ftmvvsol.fsf@gmail.com> Date: Thu, 25 Jul 2019 12:02:09 +0200 In-Reply-To: <87ftmvvsol.fsf@gmail.com> (Noam Postavsky's message of "Wed, 24 Jul 2019 20:55:38 -0400") Message-ID: <875znqctzy.fsf@mouse.gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: 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 cha [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP 0.0 TVD_RCVD_IP Message was received from an IP address -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Eli Zaretskii , abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) 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); But it does indeed look like I was confused with filter/p->filter and assumed they were the same. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 09:01:18 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 13:01:18 +0000 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 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 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 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 Date: Thu, 25 Jul 2019 16:01:01 +0300 Message-Id: <83imrqnu9e.fsf@gnu.org> From: Eli Zaretskii To: Lars Ingebrigtsen In-reply-to: <875znqctzy.fsf@mouse.gnus.org> (message from Lars Ingebrigtsen on Thu, 25 Jul 2019 12:02:09 +0200) Subject: Re: bug#36591: 26.2; Term's pager seems broken 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> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 36591 Cc: 36591@debbugs.gnu.org, npostavs@gmail.com, abliss@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > 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 From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 09:02:06 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 13:02:06 +0000 Received: from localhost ([127.0.0.1]:38541 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqdNm-0003U0-Ew for submit@debbugs.gnu.org; Thu, 25 Jul 2019 09:02:06 -0400 Received: from mail-io1-f54.google.com ([209.85.166.54]:44177) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqdNj-0003TO-Pe for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 09:02:05 -0400 Received: by mail-io1-f54.google.com with SMTP id s7so96890036iob.11 for <36591@debbugs.gnu.org>; Thu, 25 Jul 2019 06:02:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=phuB3cq6oDOKhhMCwx97+JSoSCp70LQPN4S245JtDKA=; b=mxlda7yg6fNvwV+Yd05y7nuBsqeVK6HIa+QSPAt9ksj0K/FR2s/qPYzTwUY5v9VTdk +g2IPtX6zSGz2Nord50HhyE/vg/mb/U6aVJeKzqKTywCYwG+jmkaTXsC/GnjyAZoB5dR vNWtz+JJG9mXPOsHFBSBsVhaTUXvwrrPDFYB3FTE4wXXx4MkHbTcinpAZbfTcT3qdzat Yyk3XMGc/+o6759V2RWw8HrLgxZ7fyTRsvYRW0LYnqK/2LUZ8N0xjZT03L/p6MfqnreE sCe7g07IqTYisNsIJ55GLurdYarnRLTwhiCAIx/AeAb+e+JOpkrV3/ZMkh4ix6pNUSJh EsDA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=phuB3cq6oDOKhhMCwx97+JSoSCp70LQPN4S245JtDKA=; b=PA5mEtl5ulNcEDq2ysk4PRJXDxIMZBgZz9gtCtYswldUulHSJCL0VAcBrY9JTV668U 1NdGvTDkCQbiuXep1bGBMaqYqfE6zVtMkhk2ofbqHtORNipFBmenF+rlx9bLZ+p6I5Ta 7R1jWxxofkBtu9pN7lhdW1AIKDQWJtzpYz6BKN80kSQQJ/qKWYuFGdU4/VLkVYwpPBNU gyYoLBid5bh2+of+LVnGeWZ5wq1iRJKVolaA6QsiQpg3I7jXDriAAlOW1lR9KUwlLIsE nTR4H/PCGgfDVdJDe3dbsTeGUSL9ZM6AwrzBxtf3Cyl/mBul6tgoHN/olxhuVXQbIBr9 B+aw== X-Gm-Message-State: APjAAAWGTlOAVKqMBf1FB/L2yrmDxMDHDr+4KNRN1xct11DgfitqY1xf zxXAAUfUj5w1dicZmuhxKlCHU6Mv X-Google-Smtp-Source: APXvYqxxGGJBRD/BDva+XqPC0HlHbeoDgAG9j3+kqx8cQNc5SOLHYRxLXowX+5gveou8Ooy1v6B4kg== X-Received: by 2002:a02:bb08:: with SMTP id y8mr46404598jan.51.1564059717907; Thu, 25 Jul 2019 06:01:57 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id o7sm41834446ioo.81.2019.07.25.06.01.56 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jul 2019 06:01:57 -0700 (PDT) From: Noam Postavsky To: Lars Ingebrigtsen Subject: Re: bug#36591: 26.2; Term's pager seems broken 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> Date: Thu, 25 Jul 2019 09:01:56 -0400 In-Reply-To: <875znqctzy.fsf@mouse.gnus.org> (Lars Ingebrigtsen's message of "Thu, 25 Jul 2019 12:02:09 +0200") Message-ID: <87a7d2w9mj.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Eli Zaretskii , abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > the "we may not have the socket yet" refers to this bit: > > if (p->infd >= 0) > set_process_filter_masks (p); > > But it does indeed look like I was confused with filter/p->filter and > assumed they were the same. Do you think the reversed check in set_process_filter_masks could cause bugs for sockets too then? From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 09:11:29 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 13:11:29 +0000 Received: from localhost ([127.0.0.1]:38570 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqdWr-0003j1-3l for submit@debbugs.gnu.org; Thu, 25 Jul 2019 09:11:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60800) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqdWp-0003ip-US for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 09:11:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43622) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hqdWk-00077V-OK; Thu, 25 Jul 2019 09:11:22 -0400 Received: from [176.228.60.248] (port=1465 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hqdWj-0005hS-IV; Thu, 25 Jul 2019 09:11:22 -0400 Date: Thu, 25 Jul 2019 16:11:15 +0300 Message-Id: <83ftmuntsc.fsf@gnu.org> From: Eli Zaretskii To: Noam Postavsky In-reply-to: <87ftmvvsol.fsf@gmail.com> (message from Noam Postavsky on Wed, 24 Jul 2019 20:55:38 -0400) Subject: Re: bug#36591: 26.2; Term's pager seems broken References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> <87imrsw5gj.fsf@gmail.com> <83y30no4hi.fsf@gnu.org> <87ftmvvsol.fsf@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 36591 Cc: larsi@gnus.org, abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Noam Postavsky > Cc: Lars Ingebrigtsen , abliss@gmail.com, 36591@debbugs.gnu.org > Date: Wed, 24 Jul 2019 20:55:38 -0400 > > > 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. Thanks, this patch is OK for the emacs-26 branch. > > 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 what Lars remembers, and let's then take it from there. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 12:58:36 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 16:58:36 +0000 Received: from localhost ([127.0.0.1]:40331 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqh4d-0003RP-Sh for submit@debbugs.gnu.org; Thu, 25 Jul 2019 12:58:36 -0400 Received: from quimby.gnus.org ([80.91.231.51]:46668) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqh4c-0003RH-ME for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 12:58:35 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hqh4Y-0006JG-2Z; Thu, 25 Jul 2019 18:58:32 +0200 From: Lars Ingebrigtsen To: Eli Zaretskii Subject: Re: bug#36591: 26.2; Term's pager seems broken 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> <83imrqnu9e.fsf@gnu.org> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEXEvr0jISsREBtVUlcI CBKHhIc+O0JgYGOkoKKxra6SPbW5AAACRklEQVQ4jVWUPW/bMBCGuaS1x2MMdiYhZHeE0HMN/oHA oOQxjNAzuiUQLKGbi8KwvAko0tj/tkeRtOWbqPfhe8evE2vbcxfj7CMMD5a17TrqR5JPcVxoAnY0 P5I9EqjXIz2SP4gJHBMYijSVi8ArPZv2gRxQR4efz3xMB9JgSpV0ChpShQiOPk+M6anECxjp7KDd GFzmrzDo7gr21pZtiwgOcwiOowcf3UcNfCkFOa6gZ/bY1Q5AOKVEquEzffq0FRHEBoSoXAJN1Wr+ 3ZFDtxpEFR39HT71BRcI0GxtjcDBAyrxd7PbfUL+NAex6cocgJsADltar9Rvv4XQ21KTEyJod4wB vH0RmK/cHGQE5zL/1U+42Db3m/Wp4FKCG8C01IsfBObZt58T9pVLJSEBRN3kXOGL7Uq+TDXObY26 XrxL7sRi0SiTapCj0oVf5FLSCfBlZrJYnFK5TEoCtHmujDHhSAhoZwxwycnnde/o+r7NcyQgOCWH V54A64tNDWjMvVJZhm5mzFIN4PzPX5xRDxntwFuNieCOboJnRs4kHTEfAfZM2ZURjw/OgddTKjoG WqbUTjoyej0BthouerbkQVY8ACIHDBtTIQawG97VdF/nC7p12uDIkZ7i3RwgkGHn0+sbncz9kQSw Zqfrq6bH7rK4qjWbXPqAzKfiAvpJaEEWenD/SMAXt2wy6k3q2hXPBocHF+K7eV/OvSO3lOrmh2Ht syOgbd/dhLV2JQdg7fpWtxYiuKL98GXfX1mta8Qqp2ivsS3cf0H6gIg6x/rGAAAAAElFTkSuQmCC Date: Thu, 25 Jul 2019 18:58:29 +0200 In-Reply-To: <83imrqnu9e.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 25 Jul 2019 16:01:01 +0300") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: >> 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 wante [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: 36591@debbugs.gnu.org, npostavs@gmail.com, abliss@gmail.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> 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? Yes, it was refactored out into its own function so that we can call it from connect_network_socket, too. I think the logic is slowly coming back to me... Lisp programs typically call `set-process-filter' after calling `make-network-process' -- even when opening an asynchronous connection. This worked before because the connection wouldn't really be all that synchronous -- it would do name resolution, and then open the socket, so when `make-network-process' had returned, then p->infd would (almost) always be valid. When `make-network-process' was made more asynchronous, then p->infd typically not be initialised yet, so `set-process-filter' would not do the main bit any more. To avoid having to rewrite all the callers of `set-process-filter' with async connections, I just made it do the filter setup in connect_network_socket, by which time we really have a p->infd. Logically speaking, it would make more sense if nobody called `set-process-filter' until we have a connection, but that wouldn't be backwards compatible. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 13:01:43 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 17:01:43 +0000 Received: from localhost ([127.0.0.1]:40335 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqh7f-0003Xl-DK for submit@debbugs.gnu.org; Thu, 25 Jul 2019 13:01:43 -0400 Received: from quimby.gnus.org ([80.91.231.51]:46716) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqh7d-0003Xd-Pb for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 13:01:42 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hqh7Y-0006Jp-Tn; Thu, 25 Jul 2019 19:01:40 +0200 From: Lars Ingebrigtsen To: Noam Postavsky Subject: Re: bug#36591: 26.2; Term's pager seems broken 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> <87a7d2w9mj.fsf@gmail.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEXEvr0jISsREBtVUlcI CBKHhIc+O0JgYGOkoKKxra6SPbW5AAACRklEQVQ4jVWUPW/bMBCGuaS1x2MMdiYhZHeE0HMN/oHA oOQxjNAzuiUQLKGbi8KwvAko0tj/tkeRtOWbqPfhe8evE2vbcxfj7CMMD5a17TrqR5JPcVxoAnY0 P5I9EqjXIz2SP4gJHBMYijSVi8ArPZv2gRxQR4efz3xMB9JgSpV0ChpShQiOPk+M6anECxjp7KDd GFzmrzDo7gr21pZtiwgOcwiOowcf3UcNfCkFOa6gZ/bY1Q5AOKVEquEzffq0FRHEBoSoXAJN1Wr+ 3ZFDtxpEFR39HT71BRcI0GxtjcDBAyrxd7PbfUL+NAex6cocgJsADltar9Rvv4XQ21KTEyJod4wB vH0RmK/cHGQE5zL/1U+42Db3m/Wp4FKCG8C01IsfBObZt58T9pVLJSEBRN3kXOGL7Uq+TDXObY26 XrxL7sRi0SiTapCj0oVf5FLSCfBlZrJYnFK5TEoCtHmujDHhSAhoZwxwycnnde/o+r7NcyQgOCWH V54A64tNDWjMvVJZhm5mzFIN4PzPX5xRDxntwFuNieCOboJnRs4kHTEfAfZM2ZURjw/OgddTKjoG WqbUTjoyej0BthouerbkQVY8ACIHDBtTIQawG97VdF/nC7p12uDIkZ7i3RwgkGHn0+sbncz9kQSw Zqfrq6bH7rK4qjWbXPqAzKfiAvpJaEEWenD/SMAXt2wy6k3q2hXPBocHF+K7eV/OvSO3lOrmh2Ht syOgbd/dhLV2JQdg7fpWtxYiuKL98GXfX1mta8Qqp2ivsS3cf0H6gIg6x/rGAAAAAElFTkSuQmCC Date: Thu, 25 Jul 2019 19:01:36 +0200 In-Reply-To: <87a7d2w9mj.fsf@gmail.com> (Noam Postavsky's message of "Thu, 25 Jul 2019 09:01:56 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Noam Postavsky writes: > Lars Ingebrigtsen writes: > >> the "we may not have the socket yet" refers to this bit: >> >> if (p->infd >= 0) >> set_process_filter_masks (p); >> >> But it does indeed look like I [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Eli Zaretskii , abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Noam Postavsky writes: > Lars Ingebrigtsen writes: > >> the "we may not have the socket yet" refers to this bit: >> >> if (p->infd >= 0) >> set_process_filter_masks (p); >> >> But it does indeed look like I was confused with filter/p->filter and >> assumed they were the same. > > Do you think the reversed check in set_process_filter_masks could cause > bugs for sockets too then? Do you mean Unix domain socket? Hm... I don't think I follow... -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 13:28:33 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 17:28:33 +0000 Received: from localhost ([127.0.0.1]:40370 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqhXd-0004Fl-9W for submit@debbugs.gnu.org; Thu, 25 Jul 2019 13:28:33 -0400 Received: from mail-io1-f48.google.com ([209.85.166.48]:36498) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqhXc-0004Fa-5s for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 13:28:32 -0400 Received: by mail-io1-f48.google.com with SMTP id o9so99020339iom.3 for <36591@debbugs.gnu.org>; Thu, 25 Jul 2019 10:28:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=aE/M8LO8S1UglSDPV+TyZ6vk2giFXr/ude00jC2B86w=; b=Usanc7wIxM7Crqb3eev24DlJevs8Dnssq2Rsmd5zSiXoAOt9vwR3jjK3jmVYosUsr9 46Gb7ypyo4SulLQ9L2nqEk4IXKfM+pMN1WQgXPri9ohQGz0Bo6MKy0i/rnzsYnWJHh7G 7HB0F2eaDS4Oz+BYpn/X/xhPe598u2ymvhFkw7qwLRuOAi8os83Orf43MOD/OCs4xRrn +jQXR9t0rUe5Qc+n6QLVGjZqAhmxPL9Uwd+lUggjM6atUvk38H8sToAS0+O7QO0btsAC RTP6S+NjgprF/ybt2PyFs0a82dxpnjvSF1Mx8WN1P+WeYVxBBgxAH+Kn58E6kYg0esfa Q0JQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=aE/M8LO8S1UglSDPV+TyZ6vk2giFXr/ude00jC2B86w=; b=lFOl/nPbt9BUd7ehb8yn4/O/FQOZcdt3RIlL4w6as6ZPMVMo2ouS6pWejoadi/pTOf eINV+oQBTtrXhFW7I9cCQcj3hx3peoF3oqAXhwFuxfpwAXoKanwNcDM6OrAjXzNgVZ0s fEho7E7raDDHWOlg1xkWgF1Qg1Xh2sPGbEdeG8YQCmrfEeUnDC8fpqQKxC3z57Uu5lDj aEI+VDUKJakQ9F8BDiZXN6PUiwE6RvXS8ZRgHT4J69QXhR99KdszJP5kdWzSdELoEi5i ItL9aqQSB//aRM7GKKVkcGQTvEmOxs039MI8QfHiUzxgZZXtPHjxXI7KJtPJubmE9MSC QGtQ== X-Gm-Message-State: APjAAAXZPjWJbyS6A4TdFjeBicSImmUblFLyituqMwQ5F771InRsnlFo Qd+sQopGhs+d8XeLEeR7l9ruCRwN X-Google-Smtp-Source: APXvYqxlVmWlj4Kvug/ZxlnJNVwdEFXOjETXCoav9XwGM64SGmmfj90+FIsi1wSjivCszm3b486Bbg== X-Received: by 2002:a05:6602:2289:: with SMTP id d9mr2636166iod.47.1564075706355; Thu, 25 Jul 2019 10:28:26 -0700 (PDT) Received: from vhost2 (CPE001143542e1f-CMf81d0f809fa0.cpe.net.cable.rogers.com. [99.230.51.196]) by smtp.gmail.com with ESMTPSA id y20sm40671603ion.77.2019.07.25.10.28.25 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jul 2019 10:28:25 -0700 (PDT) From: Noam Postavsky To: Lars Ingebrigtsen Subject: Re: bug#36591: 26.2; Term's pager seems broken 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> <87a7d2w9mj.fsf@gmail.com> Date: Thu, 25 Jul 2019 13:28:25 -0400 In-Reply-To: (Lars Ingebrigtsen's message of "Thu, 25 Jul 2019 19:01:36 +0200") Message-ID: <85h87aja6e.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.92 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Eli Zaretskii , abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: >> Do you think the reversed check in set_process_filter_masks could cause >> bugs for sockets too then? > > Do you mean Unix domain socket? Hm... I don't think I follow... Not specifically, it's just that set_process_filter_masks is called in two places, connect_network_socket and Fset_process_filter. We're only fixing the latter (in the release branch at least), so I was wondering whether there could be problems stemming from the connect_network_socket call. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 13:44:24 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 17:44:25 +0000 Received: from localhost ([127.0.0.1]:40411 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqhmy-0004i0-KY for submit@debbugs.gnu.org; Thu, 25 Jul 2019 13:44:24 -0400 Received: from quimby.gnus.org ([80.91.231.51]:47366) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqhmu-0004hq-RN for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 13:44:23 -0400 Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=stories) by quimby.gnus.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.89) (envelope-from ) id 1hqhmp-0006gh-Dv; Thu, 25 Jul 2019 19:44:19 +0200 From: Lars Ingebrigtsen To: Noam Postavsky Subject: Re: bug#36591: 26.2; Term's pager seems broken 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> <87a7d2w9mj.fsf@gmail.com> <85h87aja6e.fsf@gmail.com> Face: iVBORw0KGgoAAAANSUhEUgAAADAAAAAwBAMAAAClLOS0AAAAHlBMVEXEvr0jISsREBtVUlcI CBKHhIc+O0JgYGOkoKKxra6SPbW5AAACRklEQVQ4jVWUPW/bMBCGuaS1x2MMdiYhZHeE0HMN/oHA oOQxjNAzuiUQLKGbi8KwvAko0tj/tkeRtOWbqPfhe8evE2vbcxfj7CMMD5a17TrqR5JPcVxoAnY0 P5I9EqjXIz2SP4gJHBMYijSVi8ArPZv2gRxQR4efz3xMB9JgSpV0ChpShQiOPk+M6anECxjp7KDd GFzmrzDo7gr21pZtiwgOcwiOowcf3UcNfCkFOa6gZ/bY1Q5AOKVEquEzffq0FRHEBoSoXAJN1Wr+ 3ZFDtxpEFR39HT71BRcI0GxtjcDBAyrxd7PbfUL+NAex6cocgJsADltar9Rvv4XQ21KTEyJod4wB vH0RmK/cHGQE5zL/1U+42Db3m/Wp4FKCG8C01IsfBObZt58T9pVLJSEBRN3kXOGL7Uq+TDXObY26 XrxL7sRi0SiTapCj0oVf5FLSCfBlZrJYnFK5TEoCtHmujDHhSAhoZwxwycnnde/o+r7NcyQgOCWH V54A64tNDWjMvVJZhm5mzFIN4PzPX5xRDxntwFuNieCOboJnRs4kHTEfAfZM2ZURjw/OgddTKjoG WqbUTjoyej0BthouerbkQVY8ACIHDBtTIQawG97VdF/nC7p12uDIkZ7i3RwgkGHn0+sbncz9kQSw Zqfrq6bH7rK4qjWbXPqAzKfiAvpJaEEWenD/SMAXt2wy6k3q2hXPBocHF+K7eV/OvSO3lOrmh2Ht syOgbd/dhLV2JQdg7fpWtxYiuKL98GXfX1mta8Qqp2ivsS3cf0H6gIg6x/rGAAAAAElFTkSuQmCC Date: Thu, 25 Jul 2019 19:44:15 +0200 In-Reply-To: <85h87aja6e.fsf@gmail.com> (Noam Postavsky's message of "Thu, 25 Jul 2019 13:28:25 -0400") Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Noam Postavsky writes: > Lars Ingebrigtsen writes: > >>> Do you think the reversed check in set_process_filter_masks could cause >>> bugs for sockets too then? >> >> Do you mean Unix domain socket? Hm... I [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Eli Zaretskii , abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Noam Postavsky writes: > Lars Ingebrigtsen writes: > >>> Do you think the reversed check in set_process_filter_masks could cause >>> bugs for sockets too then? >> >> Do you mean Unix domain socket? Hm... I don't think I follow... > > Not specifically, it's just that set_process_filter_masks is called in > two places, connect_network_socket and Fset_process_filter. We're only > fixing the latter (in the release branch at least), so I was wondering > whether there could be problems stemming from the connect_network_socket > call. Oh, right. Hm... the problem was really when you call `set-process-filter' more than once? I do not think connect_network_socket is called more than once per process... so I don't think it should be a problem? But the logic is rather difficult to follow. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 13:58:01 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 17:58:01 +0000 Received: from localhost ([127.0.0.1]:40415 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqi08-0007BM-TF for submit@debbugs.gnu.org; Thu, 25 Jul 2019 13:58:01 -0400 Received: from mail-io1-f67.google.com ([209.85.166.67]:36724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqi06-0007B9-Jp for 36591@debbugs.gnu.org; Thu, 25 Jul 2019 13:57:59 -0400 Received: by mail-io1-f67.google.com with SMTP id o9so99206677iom.3 for <36591@debbugs.gnu.org>; Thu, 25 Jul 2019 10:57:58 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=XlFRN3/WF0QVW0m9EqJtc0JXkTKpRzTpJoZCV4NTtLA=; b=isikCrTbp1GFUOCgfplzoREIg2rhOMNAGzcOpqCowxDw6LyVzlUY+0dHHNO9IQYQta Dy5DGTZTlL+6jM4nq0UoIRTpyKZyIYDrtJV1izgahknqX9Rn4KEeyDTBtLSxUXLCL074 Z1vo+1TqA2iY0SO/mwzuW9VW9hZBtJrCk9knPE+/DvZVTF4BQM/ahxuGxcHfPlrSt4hD ttIvk//YrWS+WNzmroNVsAtYK39mLUdZF8zN5f4oHJtM8pF5ruDQKVLdl3OUcdurtTz0 plKu8hZXPccetbZEOnzk9gv37AWp79SIma75FgfZzxLY8/UpaMz7zF+4g+s/Dt19tTdY jM7A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=XlFRN3/WF0QVW0m9EqJtc0JXkTKpRzTpJoZCV4NTtLA=; b=t84Ubhe3V8Nuu4REDLxsg1KY3LDqGU942K/ZpGo7jVpXCQ3qGbPfO+VTRGYFkIdper w4lkF6q1RhR5traVLyAkjC30E1L5l8YyevcwOvpA87n4/aG5+7ZzyvM0DcFntDB4Ns7b i+hyUhd4xzuiB2+lQ8ILwhN6RzdfhXdytsxfVa1zZmgTVDz9Fu8EDdatCfVxtzEBwQX1 2jK1GstJ+DuZ5J4+erPTSswqxpyCdPW/8Yf0r5zOD3jXK8dW2zxqkYTNzbKPf24aClS8 EKMoC0WX1CNni+bMBQCzHeM/5RRlpT7r4gdCMsYtJgiQcxQucmV2Vky/BaMV6TdOEICh Ht3A== X-Gm-Message-State: APjAAAWzn7kpcliboIo2fhXsv9MPXSZGSvGAtN/8xxsRoWeOqSlpe+FA tfQ87H5hCunslGtRXXvkPHKxEHvS X-Google-Smtp-Source: APXvYqxpYRi+O2107JVy8IBTSvc7v3xVv1ajbOG1N+8yLJs2CGpELAwvn/vGNPK/zwz/cMwBhrj88Q== X-Received: by 2002:a6b:790a:: with SMTP id i10mr78797936iop.150.1564077472772; Thu, 25 Jul 2019 10:57:52 -0700 (PDT) Received: from vhost2 (CPE001143542e1f-CMf81d0f809fa0.cpe.net.cable.rogers.com. [99.230.51.196]) by smtp.gmail.com with ESMTPSA id k2sm43637420iom.50.2019.07.25.10.57.51 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jul 2019 10:57:52 -0700 (PDT) From: Noam Postavsky To: Lars Ingebrigtsen Subject: Re: bug#36591: 26.2; Term's pager seems broken 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> <87a7d2w9mj.fsf@gmail.com> <85h87aja6e.fsf@gmail.com> Date: Thu, 25 Jul 2019 13:57:52 -0400 In-Reply-To: (Lars Ingebrigtsen's message of "Thu, 25 Jul 2019 19:44:15 +0200") Message-ID: <85blxij8tb.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1.92 (windows-nt) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Eli Zaretskii , abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Lars Ingebrigtsen writes: > Hm... the problem was really when you call `set-process-filter' more > than once? The problem is when you call (set-process-filter PROC t) and then (set-process-filter PROC FILTER), where FILTER is not t. The first time we correctly do delete_read_fd, but on the second time, we don't call add_process_read_fd on PROC's fd, so we never hear from it again. For a minimal example with subprocesses (not sockets), see https://debbugs.gnu.org/cgi/bugreport.cgi?msg=17;att=1;bug=36591;filename=bug-36591-proc-filter-t.el > I do not think connect_network_socket is called more than once per > process... so I don't think it should be a problem? But the logic is > rather difficult to follow. Yeah, quite difficult. I guess the question is whether connect_network_socket will call add_process_read_fd even the first time though. I think not. But there are other calls to add_process_read_fd, so it's possible that we end up listening to the socket anyway. From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 25 18:38:50 2019 Received: (at 36591) by debbugs.gnu.org; 25 Jul 2019 22:38:50 +0000 Received: from localhost ([127.0.0.1]:40566 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqmNu-0003np-1C for submit@debbugs.gnu.org; Thu, 25 Jul 2019 18:38:50 -0400 Received: from mail-io1-f51.google.com ([209.85.166.51]:43497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hqmNr-0003nT-5B; Thu, 25 Jul 2019 18:38:47 -0400 Received: by mail-io1-f51.google.com with SMTP id k20so100686823ios.10; Thu, 25 Jul 2019 15:38:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=1kX/v/YhR8SlMEw+qGHP++6puhzD8Lce7/AC7k35jmQ=; b=kBrp7YeyGwefArhQBYoUvvXjpN492FdFxgBbZEkFiIRuOJ2BBd7uDmcvzAn3HNXh+W 7JD5KtMaG7w2mVEwq7Rt4zRYFPbDbRRdIe1kpAI5l+q4RM7ed0Q5AhCe2zPoUJqhVr0b 3MaR/J7mfl0iXCdqFseUIG3WPAJ/EjgRaQ1htP9EO1pIKeQwPXwMACmNbyeHEdJsUW2b wbbKyT5JRtvekc8uD4C/PsZOQeMfIHrP/c3h+R5nCDMq0swBLfSvxH6nZcDc6QhYYdEr KfIWPB5dRNPR+rJDQqyRTeNSOkVoBSFyUR8BiB+uNVjbwnkAnFvfI0aJDfspnB21LslT LoOQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=1kX/v/YhR8SlMEw+qGHP++6puhzD8Lce7/AC7k35jmQ=; b=muU38B9Hi/M7wmCHoiCADYkRAG3Uk2bUiQwpXdpwkmhzjSFkbFmAsE5ml+ovqVnjxK Gn7FNqADHObcfV/DCxn1CeriJE2NIZrCAfvCpBmid9IY1mw3uSnp0P6nU9wE5Esg/37U AbYOHWO0uF8K6l3xhOwKffyjN4neyFougAie1zydIRtJFrmnbgIDhp/ivQzNSk7G/FsV Y0OyDteNXE+Nqj0gvz6KnoT4kX3r0HIIaaW1VYKlduL6jefq1u+Y/1FMnkIU3G78eYAS wWxI4uyxkN3BrZtmXc6J0MpcJ8NrxjSoG5rnFoDg/J7FQfCckHPjHX5GVVLxJmvKzkjY ItCg== X-Gm-Message-State: APjAAAXRVUyl0IoI3ZL5BugzpNTJGEZtieRPBJ+6FqmGKZGEv5p2WjPE GzUmcBOwQ8kYF5oFrukn6yQyCEs5 X-Google-Smtp-Source: APXvYqwyauooujgDO8ikiVmV63FsEmsJCkMlKszxaYWuYaTKRXcKl3UEUPwnAAuQFhN64uUOtKiFEw== X-Received: by 2002:a6b:3b89:: with SMTP id i131mr34100483ioa.33.1564094321583; Thu, 25 Jul 2019 15:38:41 -0700 (PDT) Received: from minid (cbl-45-2-119-34.yyz.frontiernetworks.ca. [45.2.119.34]) by smtp.gmail.com with ESMTPSA id a1sm40672802ioo.5.2019.07.25.15.38.40 (version=TLS1_2 cipher=ECDHE-RSA-CHACHA20-POLY1305 bits=256/256); Thu, 25 Jul 2019 15:38:41 -0700 (PDT) From: Noam Postavsky To: Eli Zaretskii Subject: Re: bug#36591: 26.2; Term's pager seems broken References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> <87imrsw5gj.fsf@gmail.com> <83y30no4hi.fsf@gnu.org> <87ftmvvsol.fsf@gmail.com> <83ftmuntsc.fsf@gnu.org> Date: Thu, 25 Jul 2019 18:38:40 -0400 In-Reply-To: <83ftmuntsc.fsf@gnu.org> (Eli Zaretskii's message of "Thu, 25 Jul 2019 16:11:15 +0300") Message-ID: <87y30lvixb.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.2.90 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: larsi@gnus.org, abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) fixed 36591 26.3 quit Eli Zaretskii writes: >> >> I think that makes sense, patch attached. > > Thanks, this patch is OK for the emacs-26 branch. Okay, pushed. b3e20737d8 2019-07-25T18:36:03-04:00 "Fix subproc listening when setting filter to non-t (Bug#36591)" https://git.savannah.gnu.org/cgit/emacs.git/commit/?id=b3e20737d83acbbbec372645e2a951293d84bd29 From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 08:59:10 2020 Received: (at 36591) by debbugs.gnu.org; 21 Aug 2020 12:59:10 +0000 Received: from localhost ([127.0.0.1]:45378 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k96dS-0002K6-Gp for submit@debbugs.gnu.org; Fri, 21 Aug 2020 08:59:10 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42308) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k96dR-0002Jr-2u for 36591@debbugs.gnu.org; Fri, 21 Aug 2020 08:59:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=8YlWis8z6jNjijx2TM5aAnsd69P9C3B6lPZZ1T0F970=; b=FHVRqOcO+jVWlkRrfuadk51+YX D7H7ik+um00aQ+nuJ49R0ITtzndMb0NRoBPjjQXcUiTPElNTXN1Iwj7L4+/mzGcOfz5N9mvg2uVX2 ITR1AokJY4s9r6qHPAoCvkUl8ZLpoHhzvQOELA8zFOlZ8Gkfi1363zihFLVh0HMj67Tk=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k96dI-0003tV-Bc; Fri, 21 Aug 2020 14:59:02 +0200 From: Lars Ingebrigtsen To: Noam Postavsky Subject: Re: bug#36591: 26.2; Term's pager seems broken References: <87lfwox3fi.fsf@gmail.com> <838ssops2u.fsf@gnu.org> <87imrsw5gj.fsf@gmail.com> <83y30no4hi.fsf@gnu.org> <87ftmvvsol.fsf@gmail.com> <83ftmuntsc.fsf@gnu.org> <87y30lvixb.fsf@gmail.com> X-Now-Playing: The Raincoats's _The Raincoats_: "You're a Million" Date: Fri, 21 Aug 2020 14:58:58 +0200 In-Reply-To: <87y30lvixb.fsf@gmail.com> (Noam Postavsky's message of "Thu, 25 Jul 2019 18:38:40 -0400") Message-ID: <87y2m840kt.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Noam Postavsky writes: > fixed 36591 26.3 > quit I guess the intention was to close this bug, so I'm doing that now. (I've only lightly skimmed the thread, but it seems like this commit fixed the problem being discussed.) Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 36591 Cc: Eli Zaretskii , abliss@gmail.com, 36591@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Noam Postavsky writes: > fixed 36591 26.3 > quit I guess the intention was to close this bug, so I'm doing that now. (I've only lightly skimmed the thread, but it seems like this commit fixed the problem being discussed.) -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From debbugs-submit-bounces@debbugs.gnu.org Fri Aug 21 08:59:21 2020 Received: (at control) by debbugs.gnu.org; 21 Aug 2020 12:59:22 +0000 Received: from localhost ([127.0.0.1]:45381 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k96dd-0002KY-Nr for submit@debbugs.gnu.org; Fri, 21 Aug 2020 08:59:21 -0400 Received: from quimby.gnus.org ([95.216.78.240]:42324) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1k96db-0002KI-9k for control@debbugs.gnu.org; Fri, 21 Aug 2020 08:59:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Subject:From:To:Message-Id:Date:Sender:Reply-To:Cc: MIME-Version:Content-Type:Content-Transfer-Encoding:Content-ID: Content-Description:Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc :Resent-Message-ID:In-Reply-To:References:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=v0cN0I65phd7q+K7oPOwtUdxDu67agwJr2EUM1mQL94=; b=atdqZmRf5H4CCcKjz6cvnr1UBj jTyvh1jfVt25MYazldMez1NtK22zzvJspjS5fmNS7vRN5ftKKNyHmNU7nZkLWbDErr+OYluXbmEsd K72z5puto323lG3vwEcwOlp0vrnQXqqR9bo3kb0FBdHrBr1j5wWvVj0TT1DKoR4eNd7g=; Received: from cm-84.212.202.86.getinternet.no ([84.212.202.86] helo=xo) by quimby with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1k96dT-0003tl-DQ for control@debbugs.gnu.org; Fri, 21 Aug 2020 14:59:13 +0200 Date: Fri, 21 Aug 2020 14:59:10 +0200 Message-Id: <87wo1s40kh.fsf@gnus.org> To: control@debbugs.gnu.org From: Lars Ingebrigtsen Subject: control message for bug #36591 X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: tags 36591 fixed close 36591 26.3 quit Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: control X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) tags 36591 fixed close 36591 26.3 quit From unknown Tue Jun 17 01:26:36 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sat, 19 Sep 2020 11:24:10 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator