From unknown Tue Jun 17 01:32:00 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#34821 <34821@debbugs.gnu.org> To: bug#34821 <34821@debbugs.gnu.org> Subject: Status: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer Reply-To: bug#34821 <34821@debbugs.gnu.org> Date: Tue, 17 Jun 2025 08:32:00 +0000 retitle 34821 discard_input_tty does not discard pending input, resulting i= n garbage inserted into the buffer reassign 34821 emacs submitter 34821 Platon Pronko severity 34821 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Tue Mar 12 04:09:48 2019 Received: (at submit) by debbugs.gnu.org; 12 Mar 2019 08:09:48 +0000 Received: from localhost ([127.0.0.1]:39743 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3cTs-0004db-Fq for submit@debbugs.gnu.org; Tue, 12 Mar 2019 04:09:48 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53652) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3cTq-0004dO-LV for submit@debbugs.gnu.org; Tue, 12 Mar 2019 04:09:47 -0400 Received: from lists.gnu.org ([209.51.188.17]:39110) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1h3cTl-0006mJ-AZ for submit@debbugs.gnu.org; Tue, 12 Mar 2019 04:09:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:39421) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1h3cTj-0006j4-Rf for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 04:09:41 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: ** X-Spam-Status: No, score=2.3 required=5.0 tests=BAYES_50,FREEMAIL_FROM, RCVD_IN_SORBS_WEB autolearn=disabled version=3.3.2 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1h3cEA-0002wI-3v for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 03:53:35 -0400 Received: from mail-lf1-x141.google.com ([2a00:1450:4864:20::141]:35553) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1h3cE9-0002vI-JZ for bug-gnu-emacs@gnu.org; Tue, 12 Mar 2019 03:53:33 -0400 Received: by mail-lf1-x141.google.com with SMTP id h6so1309400lfc.2 for ; Tue, 12 Mar 2019 00:53:33 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=to:from:subject:message-id:date:user-agent:mime-version :content-language; bh=Kwug2zGxYtX2UQLAbzyLK9fpQ0KWwh4t1DU9NPGGnlA=; b=pMx5z2yZtcbRwW0ILwgR2iDDVT1chW2p6C043KRfuSp2GmjH3ef5BG6j1UqUgSDHqq AfrMljQpBb2Egk/YUCxIWnDAZcAAUM+tZCv336sHO7A1A3HaDXTsxoqLfiq0eB0L6H7I H3GFBUKTOfRgXi1HefaaywG7XjIEO2wOm83PhwuuUo1NwQd7c8kLfDcyMqQ/mtPPzaiT DvXQIamFhcgsvmdDi/7ZWlrzNHjcZhpBFJxmkz9o36vufRDQSIHljPOH/wrwRPilNUwO l7cdFU3EW0q5beRxnmGlGo7K+QnDn/iJEuaN0eH99T9LJpmsd824D3D0Kip881S+JbNu bmAQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:to:from:subject:message-id:date:user-agent :mime-version:content-language; bh=Kwug2zGxYtX2UQLAbzyLK9fpQ0KWwh4t1DU9NPGGnlA=; b=CRSae7DxuFVMgyIGe2/IUVmtjbAxcBhLaPut/wXpvJ0+PrJlMwznB90bTnGxPQox3m 6/VWL1BkdjPE7ICXIPaViTDFs9sIYL+8EtN+Mj9AadN69yCq6gBIJQMlgvoqyt5IMVEp Bc4klhh/OvrKDk1EuzVpM3+4Gb6zxfjCXuCyQGY/M6TQLPERSqQN+i5f7Gi8GwB7sHz1 ngJxkWnIv2rSvV86ap7IAUhMj1d6qJN4GgHTMsxiu0B182TrpTjSKhF83DAi9JQUjz+O 4T5kbublIENr15Nr+x/7Ufmod8V0eOF+oS9PCK3hwjhVnB8GaANpT8OWQ1vCEjAT7rBg oolQ== X-Gm-Message-State: APjAAAXVOaYSUkLMBPhRHhtc3+d6w6nmJ2E5JIfBJXhrUVoHgwv7n41L NvRoyh9DXB9qTYgJ3M5QavvNYf6T X-Google-Smtp-Source: APXvYqxuLJWWd5EscdQXEWDvo8TrFQXCWzp4K34cz/V1PR8S2RuLOBTUso9depObF+OpZvVMFVtAiQ== X-Received: by 2002:a19:ec17:: with SMTP id b23mr10601803lfa.76.1552377211461; Tue, 12 Mar 2019 00:53:31 -0700 (PDT) Received: from [192.168.1.65] ([109.252.80.126]) by smtp.gmail.com with ESMTPSA id q22sm1232920ljc.59.2019.03.12.00.53.30 for (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Tue, 12 Mar 2019 00:53:30 -0700 (PDT) To: bug-gnu-emacs@gnu.org From: Platon Pronko Subject: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer Message-ID: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> Date: Tue, 12 Mar 2019 10:53:29 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------0646CE0A69D45F1D55B1CA10" Content-Language: en-US X-detected-operating-system: by eggs.gnu.org: Genre and OS details not recognized. X-Received-From: 2a00:1450:4864:20::141 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Spam-Score: 2.5 (++) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: Hi! Steps to reproduce: 1. Add dummy autosave file (needed for additional delay when starting and reliable bug reproduction): $ touch /tmp/#test.txt# Content analysis details: (2.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [109.252.80.126 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (platon7pronko[at]gmail.com) 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) X-Debbugs-Envelope-To: submit 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.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: Hi! Steps to reproduce: 1. Add dummy autosave file (needed for additional delay when starting and reliable bug reproduction): $ touch /tmp/#test.txt# Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [109.252.80.126 listed in dnsbl.sorbs.net] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (platon7pronko[at]gmail.com) 1.0 SPF_SOFTFAIL SPF: sender does not match SPF record (softfail) -1.0 MAILING_LIST_MULTI Multiple indicators imply a widely-seen list manager This is a multi-part message in MIME format. --------------0646CE0A69D45F1D55B1CA10 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Hi! Steps to reproduce: 1. Add dummy autosave file (needed for additional delay when starting and reliable bug reproduction): $ touch /tmp/#test.txt# 2. Launch daemon: ./src/emacs -Q --fg-daemon 3. Start the client: ./lib-src/emacsclient -t /tmp/test.txt 4. type 'a' while emacsclient is starting 5. observe "65;5403;1c" inserted at the start of the new file. I hunted for the bug and traced it down to terminal-init-xterm and xterm--query. It makes a "Secondary Device Attributes" query, and expects a response with a specific prefix - but if there were characters waiting in input buffer the handler will never see that prefix, and all the bytes will be sent directly to default keyboard handler and inserted into the buffer. To mitigate the problem xterm--query calls discard-input before sending the query, however for some reason the bytes are still there when read_char is called. I added a workaround in xterm--query, simple `(while (read-event nil nil 0.01))` (see patch attached). Setting `(setq xterm-query-timeout nil)` switches querying to async mode and also helps (the typed character is not discarded that way, which is even better). However, I suspect that the real problem lurks in the discard_tty_input, that for some reason does not actually discard the input - but I'm not sure how to debug it. System details below: In GNU Emacs 27.0.50 (build 27, x86_64-pc-linux-gnu, GTK+ Version 3.24.5)  of 2019-03-12 built on the-big-maker Repository revision: d2270d8fc93b5fb0b82fec4d85d122ea4e38dff3 Repository branch: master System Description: Arch Linux Recent messages: Starting Emacs daemon. test.txt has auto save data; consider M-x recover-this-file When done with a buffer, type C-x # Quit completing-read-default: Command attempted to use minibuffer while in minibuffer Configured features: XPM JPEG TIFF GIF PNG RSVG IMAGEMAGICK SOUND GPM DBUS GSETTINGS GLIB NOTIFY INOTIFY ACL GNUTLS LIBXML2 FREETYPE M17N_FLT LIBOTF XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 XDBE XIM THREADS LIBSYSTEMD JSON PDUMPER LCMS2 GMP Important settings:   value of $LC_TIME: en_SE.UTF-8   value of $LANG: en_US.UTF-8   locale-coding-system: utf-8-unix Major mode: Text Minor modes in effect:   tooltip-mode: t   global-eldoc-mode: t   electric-indent-mode: t   mouse-wheel-mode: t   tool-bar-mode: t   menu-bar-mode: t   file-name-shadow-mode: t   global-font-lock-mode: t   font-lock-mode: t   auto-composition-mode: t   auto-encryption-mode: t   auto-compression-mode: t   line-number-mode: t   transient-mark-mode: t Load-path shadows: None found. Features: (shadow sort mail-extr emacsbug message rmc puny seq byte-opt gv bytecomp byte-compile cconv dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs time-date mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils term/xterm xterm server elec-pair mule-util tooltip eldoc electric uniquify ediff-hook vc-hooks lisp-float-type mwheel term/x-win x-win term/common-win x-dnd tool-bar dnd fontset image regexp-opt fringe tabulated-list replace newcomment text-mode elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow isearch timer select scroll-bar mouse jit-lock font-lock syntax facemenu font-core term/tty-colors frame cl-generic cham georgian utf-8-lang misc-lang vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932 hebrew greek romanian slovak czech european ethiopic indian cyrillic chinese composite charscript charprop case-table epa-hook jka-cmpr-hook help simple abbrev obarray minibuffer cl-preloaded nadvice loaddefs button faces cus-face macroexp files text-properties overlay sha1 md5 base64 format env code-pages mule custom widget hashtable-print-readable backquote threads dbusbind inotify lcms2 dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 50376 6377)  (symbols 48 6051 1)  (strings 32 15598 1886)  (string-bytes 1 511783)  (vectors 16 7797)  (vector-slots 8 77209 12548)  (floats 8 28 256)  (intervals 56 175 0)  (buffers 992 13)) --------------0646CE0A69D45F1D55B1CA10 Content-Type: text/x-patch; name="xterm--query_discard.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="xterm--query_discard.patch" diff --git a/lisp/term/xterm.el b/lisp/term/xterm.el index c4b0a8fb6e..30919988e9 100644 --- a/lisp/term/xterm.el +++ b/lisp/term/xterm.el @@ -804,6 +804,7 @@ xterm--query ;; Pending input can be mistakenly returned by the calls to ;; read-event below: discard it. (discard-input) + (while (read-event nil nil 0.01)) (send-string-to-terminal query) (while handlers (let ((handler (pop handlers)) --------------0646CE0A69D45F1D55B1CA10-- From debbugs-submit-bounces@debbugs.gnu.org Wed Mar 13 04:04:39 2019 Received: (at 34821) by debbugs.gnu.org; 13 Mar 2019 08:04:39 +0000 Received: from localhost ([127.0.0.1]:40995 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3ysR-0006hT-32 for submit@debbugs.gnu.org; Wed, 13 Mar 2019 04:04:39 -0400 Received: from mail-lj1-f170.google.com ([209.85.208.170]:42178) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1h3ysO-0006hF-Dn for 34821@debbugs.gnu.org; Wed, 13 Mar 2019 04:04:37 -0400 Received: by mail-lj1-f170.google.com with SMTP id v3so662143ljk.9 for <34821@debbugs.gnu.org>; Wed, 13 Mar 2019 01:04:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:from:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=8zkWjz2TsXGZmtJYRcm0jhfklydHeHcNMPH7hUMdc1o=; b=ZYPLsZFQEKAhME7wqZLDoWF7DSaet/49clQ5OZgcHRnW/uS5aDOjJGI1oFVHDMN0aE jMGViuAtAWo2VGsVUZFfF9vOBabBSIOL/sTosGIP30ErKAOMT79RoZZIhWMQff6HB8i9 7HuMVpBOEpFjMQuQtzz7W5Ikq3P19Gq0ZY1rvxzdIckoSflkfp7e9LllMsdGpYPEp/DP 5OrESXmqVmTM72dUNvcAY3XH3T6dGbeifZOWbVABX/CiPVitFhceoFyrBmj3LQkycqLh xc4gO+mN4CVvF9GUPzGGVnFKLWVpvboTzLFK3xc7GMvLq9XQyTyHN+hDMTt61TpxTWVn vzag== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:from:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=8zkWjz2TsXGZmtJYRcm0jhfklydHeHcNMPH7hUMdc1o=; b=I0DmVY14ermRqL7fl+gJdpOJickEHbT3M0C7bxCvU4lkdnPxgicML6nR/Uyka8bAvJ hV8gZzZsS996BfEhyZm1JqVsmQZKqH+a65TtYp9HyfkcLiD3CnzWiZX6irFgRt0FS9yR z+czEJ87yAQyDCx86OZdQWyoI6DlSJFMt+rD3cjQAy2hJ4gIeftrREkH9Qjsmwj280LS 6G1j4vJdbtYRr4W9GdBgmtkRvKwweiVroEuyaZ/RY8ri4DGTDopsBRnhpO+n1FS53wQU vLqrQADq5oC+RVaMoewYpap56RhXPWUGlpXPPxnlLzQ19R6FukFWH6XlaVniebY/AbkI AJqA== X-Gm-Message-State: APjAAAVGFSHvGwtMPjbduWPuuZ/oEh96SR0hquv3zU+ibTI7YE3I/6Yi werwXxm8fQfy4HZa0Ni4H/XaZNEE X-Google-Smtp-Source: APXvYqyk2A47vul+0MgsU7WrY4eoTDVpktRovH8zDNvLQSPRMt9Feo+v5B+K7Lmnb0GWAPSZ+NJU/g== X-Received: by 2002:a2e:9607:: with SMTP id v7mr15536062ljh.154.1552464270074; Wed, 13 Mar 2019 01:04:30 -0700 (PDT) Received: from [192.168.1.65] (109-252-80-126.nat.spd-mgts.ru. [109.252.80.126]) by smtp.gmail.com with ESMTPSA id m16sm1680622ljb.50.2019.03.13.01.04.28 for <34821@debbugs.gnu.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Wed, 13 Mar 2019 01:04:29 -0700 (PDT) Subject: Re: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer From: Platon Pronko To: 34821@debbugs.gnu.org References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> Message-ID: <66917314-4c95-f2e3-1faa-49154772e197@gmail.com> Date: Wed, 13 Mar 2019 11:04:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.1 MIME-Version: 1.0 In-Reply-To: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: Found two problems with current workarounds. 1. Simply reading and discarding events before xterm--query call still leaves small timing window while single typed character breaks response parsing and garbage still ends up in the buffer. Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.208.170 listed in list.dnswl.org] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (platon7pronko[at]gmail.com) 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [109.252.80.126 listed in dnsbl.sorbs.net] X-Debbugs-Envelope-To: 34821 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: 0.5 (/) Found two problems with current workarounds. 1. Simply reading and discarding events before xterm--query call still leaves small timing window while single typed character breaks response parsing and garbage still ends up in the buffer. 2. Thus async querying is prefererrable, and it works most of the time, but sometimes "65;5403;1c" ends up in input buffer (even if no characters are typed at all). From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 12:07:04 2019 Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 16:07:04 +0000 Received: from localhost ([127.0.0.1]:48615 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDAJz-00077h-WB for submit@debbugs.gnu.org; Sun, 07 Apr 2019 12:07:04 -0400 Received: from mail-lj1-f172.google.com ([209.85.208.172]:42422) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDAJx-00077C-2G for 34821@debbugs.gnu.org; Sun, 07 Apr 2019 12:07:01 -0400 Received: by mail-lj1-f172.google.com with SMTP id v22so9058268lje.9 for <34821@debbugs.gnu.org>; Sun, 07 Apr 2019 09:07:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:subject:to:references:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=36TTsJpKmHVZ1K4Kq8oIMo8bEQyq9UMECgGxuKSq+rw=; b=PR+d3HkcLY6IHf96SFVXy44w+Q0NVEB9XqkYLVpLkmRdUZAjjz3V8n5tmbKdox/aGW wsZu3ZdJs4VSnZVcEQRx4nRnqs/JFT64weVSVzgjR/qKV36XxL14rGaV8v5/1cPHyj3s e34+jBSeVGZ6qzxHKhoQZ8R+AgVLST8Dukl0m15/mzZ+tIyaIqEqMBk6VSb1cpGgAjbE L9OkUNNvNwfa90n10XpCocS6gFq/FciyMHPlPLQEvjxDpQt0qFkZVSdlmVHkpdG7QkIf jSiNtvNErxoHs1s1yDhI4sXrCDO8SZPvQS2ZUuZNzjaDl7DgeH2SFr5orU51urvFfKLP GDhA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:subject:to:references:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=36TTsJpKmHVZ1K4Kq8oIMo8bEQyq9UMECgGxuKSq+rw=; b=ukKlSPxJCmODlZvE2OLgvg/Vxysf9gmG8p+td1Z9vg8u5dCJBaAelA752ySb9a5zK9 O4S711ArGTX1e15OKF3FHdiA0/Oc+7CQpoI3Op+gfpNLeT6X57n8xbCzmtpchP57wevX p8oOzWzDww7xJmKYpDXkz3zfaoZgdoU9tOOywc3AFICClcBsWDJG9J/kd9LSAZAYURwj b931tVVV2REIFwsxdWVlEm9JiekrjdSPhciMa6pVihODtQww+OXXGnXWKUEJ2JMtwSxH tFWBuCKsSDH3sg3EPZk/qhQzZ3YECKqFRUpySHcY1MCQI/nuJpUSOQH6uMEzfTRxgeBH dTZQ== X-Gm-Message-State: APjAAAUkp95rLRZTI8+bd+KW3e9Qj6J9aMrQfnXnEnkADgp0YPRc2fOq pX7nuN9MtnZrWLBoO0NEyIkTzaHv X-Google-Smtp-Source: APXvYqx1Vb0ycH11KdDqs8Qvn+1SGZqmeqSLNrzTf/wf+y29vlkg8usp2FenSoH52cjAMnCDzkVn8w== X-Received: by 2002:a2e:3803:: with SMTP id f3mr13778692lja.165.1554653214747; Sun, 07 Apr 2019 09:06:54 -0700 (PDT) Received: from [192.168.1.65] (109-252-80-126.nat.spd-mgts.ru. [109.252.80.126]) by smtp.gmail.com with ESMTPSA id z13sm5798771ljk.41.2019.04.07.09.06.53 for <34821@debbugs.gnu.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 07 Apr 2019 09:06:53 -0700 (PDT) From: Platon Pronko Subject: Re: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer To: 34821@debbugs.gnu.org References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> Message-ID: Date: Sun, 7 Apr 2019 19:06:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Content-Language: en-US X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: I decided to go with async approach, since it is the one that is at least theoretically fool-proof. Currently I am trying to debug the problem of "[>65;5600;1c" appearing sporadically (10%) of the tim [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [109.252.80.126 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.208.172 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (platon7pronko[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record X-Debbugs-Envelope-To: 34821 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: 0.5 (/) I decided to go with async approach, since it is the one that is at least theoretically fool-proof. Currently I am trying to debug the problem of "[>65;5600;1c" appearing sporadically (10%) of the times in the input buffer. The test case is below: 1. Start the daemon and set it to use async term query: $ ./src/emacs -Q --fg-daemon --eval "(setq xterm-query-timeout nil)" 2. Launch emacsclient: $ ./lib-src/emacsclient -t /tmp/test.txt 3. About 1 in 10 times, observe "[>65;5600;1c" appearing in the buffer. I tracked the problem to src/keyboard.c:read_key_sequence() function. In normal case, the following happens: 1. read_ke_sequence() is called for the first time. 2. Current input_decode_map is copied: indec.map =  indec.map = indec.parent = KVAR (current_kboard, Vinput_decode_map); 3. It calls read_char() and blocks. 4. When emacsclient is invoked, read_char() returns the "buffer" object as per this comment: /* When switching to a new tty (with a new keyboard),   read_char returns the new buffer, rather than -2   (Bug#5095).  This is because `terminal-init-xterm'   calls read-char, which eats the wrong_kboard_jmpbuf   return.  Any better way to fix this? -- cyd */ 5. `interrupted_kboard != current_kboard` condition is triggered, this read_char() result is discarded and we jump to replay_entire_sequence. 6. read_char() is called again. 7. (terminal-init-xterm) function is invoked. 8. (xterm-query) registeres a handlers for "\e[?" and "\e[>" escape sequences. 9. read_char() returns the "buffer" object the second time. 10. That read_char() result triggers `interrupted_kboard != current_kboard` condition again, and we jump to replay_entire_sequence again. 11. Immediately after that jump, we reset the input map: `indec.map =  indec.map = indec.parent = KVAR (current_kboard, Vinput_decode_map);`, thus pulling in handlers from step 8. 12. The subsequent read_char() calls return the next SDA response characters, match is found in indec.map and xterm--verision-handler is executed. For a situation when bug manifests steps 1-8 are the same, however at step 9 the difference happens - read_char() does not return a buffer, instead it returns the first character of the response (0x1b). `interrupted_kboard != current_kboard` is still true at that moment, thus this character is discarded. Subsequent SDA response characters (0x5b, 0x3e) fail to find a prefix match in input_decode_map, and are inserted into the buffer as-is. I tried changing condition `interrupted_kboard != current_kboard` to `interrupted_kboard != current_kboard && BUFFERP(key)`, but that does not trigger `goto replay_entire_sequence` and thus new handlers are not pulled in from Vinput_decode_map, and so the characters are still inserted into the buffer. Can somebody please advise me about the right course of action in this case? Should I figure out a way to load Vinput_decode_map when new character arrives and `interrupted_kboard != current_kboard`? Or should I look into why read_char() does not return a buffer the second time? From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 12:37:27 2019 Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 16:37:27 +0000 Received: from localhost ([127.0.0.1]:48643 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDAnO-0007sE-ML for submit@debbugs.gnu.org; Sun, 07 Apr 2019 12:37:26 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41398) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDAnL-0007s2-Ap for 34821@debbugs.gnu.org; Sun, 07 Apr 2019 12:37:23 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:56759) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDAnG-0002on-3l; Sun, 07 Apr 2019 12:37:18 -0400 Received: from [176.228.60.248] (port=4396 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hDAnF-0006ZT-3A; Sun, 07 Apr 2019 12:37:17 -0400 Date: Sun, 07 Apr 2019 19:37:09 +0300 Message-Id: <83v9zp93gq.fsf@gnu.org> From: Eli Zaretskii To: Platon Pronko In-reply-to: (message from Platon Pronko on Sun, 7 Apr 2019 19:06:52 +0300) Subject: Re: bug#34821: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34821 Cc: 34821@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 (-) > From: Platon Pronko > Date: Sun, 7 Apr 2019 19:06:52 +0300 > > Can somebody please advise me about the right course of action in this case? Should I figure out a way to load Vinput_decode_map when new character arrives and `interrupted_kboard != current_kboard`? Or should I look into why read_char() does not return a buffer the second time? The latter, I think. But I'm far from being an expert on this, so caveat emptor. Thanks for looking into this tricky problem. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 13:14:33 2019 Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 17:14:33 +0000 Received: from localhost ([127.0.0.1]:48658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDBNJ-0000J7-Bu for submit@debbugs.gnu.org; Sun, 07 Apr 2019 13:14:33 -0400 Received: from mail-lf1-f65.google.com ([209.85.167.65]:41753) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDBNH-0000Is-AO for 34821@debbugs.gnu.org; Sun, 07 Apr 2019 13:14:32 -0400 Received: by mail-lf1-f65.google.com with SMTP id 10so7705184lfr.8 for <34821@debbugs.gnu.org>; Sun, 07 Apr 2019 10:14:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=5Mw5MJxDhneoHs5xtlkiSwOiiZPYMuo3s7B5LDCGfZo=; b=RrF1pVulwbgxUASZ7p6u9VPPp9CbBmBi11BWKlfCJnE0uAN0p/ljYyZrrNB1lBed+d +OzsJr2JTAz3pYbtfuzlvcLQR8mcK69Iso/dV31QMAb8PQIlUyGraKSbY6qHfeh1aTbM kfAP/WbVzneHDUxwMXKxbp7JaBG6gKCKDN7m0LreN0P95rEr4SgADgvXf62QU8HUgr/2 qzOES/Y+ER+X2nUiNtfoPMB5MQj7M81uVs5DQho5ZHfyJtikqSbk4oFlyRAheI/3zm4S nfPrl8hKctWag8n15DO1l3d/c8Uur/mBGa8V2QCmZ3OqvVVlHP/BA+YoSkTCZlJp3bXE mDNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5Mw5MJxDhneoHs5xtlkiSwOiiZPYMuo3s7B5LDCGfZo=; b=i273vOHdYyJBV0EViSZ4qV7Xmy9ZRCsHEwmAchwlt59Ucvr/dmXadM6CMYvy+84sFl 9qz17VeA872LYEcO4TwsWcr9ClvYXV3rYdl88+fiDUgWRmZMJXBoDSxgj8F6L3OmCnzI d+yt8UFj+mUVQx4XRPQjiXtYM94v1tcAiczhbQP1fS1FOtCDQ8mN2sPgfvBiitu68Aml nWMomBfYFBpGxnW5vaoXHi2tctmiTjOtpqhcNC1i3sY1qGaQ+cFEOyeSHzj4jqgxCug7 j82ih2ZMjuLtZCpXhzqTVJmxAUJAxADILTEKDFCZnh7s45M1MER7JYc99gSp9eyWNJTk JC8w== X-Gm-Message-State: APjAAAWMvsG2K3vWJ3PV8kGCg52ekM1va+40o/lnRykobdyYpbqDN9Ek LuLmIbtv6WCxB+QfD2bHnVHWFOWk X-Google-Smtp-Source: APXvYqxLzO+3hvnZAisJxuQEqglJ7TnO7XPWkHKIrYC6mhH9f1mxu+kmPQlUc2N2vBitjWNS8dh9TQ== X-Received: by 2002:ac2:4421:: with SMTP id w1mr13349627lfl.97.1554657264886; Sun, 07 Apr 2019 10:14:24 -0700 (PDT) Received: from [192.168.1.65] (109-252-80-126.nat.spd-mgts.ru. [109.252.80.126]) by smtp.gmail.com with ESMTPSA id i66sm5881781lji.43.2019.04.07.10.14.23 for <34821@debbugs.gnu.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 07 Apr 2019 10:14:24 -0700 (PDT) Subject: Re: bug#34821: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer To: 34821@debbugs.gnu.org References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> <83v9zp93gq.fsf@gnu.org> From: Platon Pronko Message-ID: <492c723c-6ba9-24da-108f-b25cef0dd54e@gmail.com> Date: Sun, 7 Apr 2019 20:14:21 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <83v9zp93gq.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: I guess that something in (terminal-init-xterm) hooks results in some buffer switch event being fired, that triggers the second return from read_char(). But since (terminal-init-xterm) and read_key_se [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.65 listed in list.dnswl.org] 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (platon7pronko[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [109.252.80.126 listed in dnsbl.sorbs.net] -0.3 RCVD_IN_MSPIKE_H2 RBL: Average reputation (+2) [209.85.167.65 listed in wl.mailspike.net] X-Debbugs-Envelope-To: 34821 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: 0.2 (/) I guess that something in (terminal-init-xterm) hooks results in some buffer switch event being fired, that triggers the second return from read_char(). But since (terminal-init-xterm) and read_key_sequence() run concurrently, we have a race condition - if the terminal responds quickly enough, second buffer switch does not trigger quick enough and this problem happens. I verified this by adding (sleep-for 0.1) to (defun xterm--query) or (defun terminal-init-xterm) - this resulted in 100% reproduction of the bug (thanks for the directions, by the way - my hands already hurt after trying to trigger that 1-in-10 bug so many times). Maybe trying to rely on terminal being slow with the response is not the best solution? Even if I find a cause of the buffer switch event, we won't have a way to ensure that it always arrives before the response to SDA query (because multithreading). From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 14:25:16 2019 Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 18:25:16 +0000 Received: from localhost ([127.0.0.1]:48683 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDCTk-0001zx-72 for submit@debbugs.gnu.org; Sun, 07 Apr 2019 14:25:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:58260) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDCTi-0001zj-Cl for 34821@debbugs.gnu.org; Sun, 07 Apr 2019 14:25:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:57832) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDCTb-00075E-4n; Sun, 07 Apr 2019 14:25:08 -0400 Received: from [176.228.60.248] (port=3422 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hDCTY-0007wr-SB; Sun, 07 Apr 2019 14:25:06 -0400 Date: Sun, 07 Apr 2019 21:24:58 +0300 Message-Id: <83r2ad8yh1.fsf@gnu.org> From: Eli Zaretskii To: Platon Pronko In-reply-to: <492c723c-6ba9-24da-108f-b25cef0dd54e@gmail.com> (message from Platon Pronko on Sun, 7 Apr 2019 20:14:21 +0300) Subject: Re: bug#34821: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> <83v9zp93gq.fsf@gnu.org> <492c723c-6ba9-24da-108f-b25cef0dd54e@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34821 Cc: 34821@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 (-) > From: Platon Pronko > Date: Sun, 7 Apr 2019 20:14:21 +0300 > > I guess that something in (terminal-init-xterm) hooks results in some buffer switch event being fired, that triggers the second return from read_char(). But since (terminal-init-xterm) and read_key_sequence() run concurrently, we have a race condition - if the terminal responds quickly enough, second buffer switch does not trigger quick enough and this problem happens. What do you mean by "run concurrently"? Emacs is pretty much a single threaded program, and there's only one Lisp thread running at any given time, which will execute both calls. > Maybe trying to rely on terminal being slow with the response is not the best solution? Even if I find a cause of the buffer switch event, we won't have a way to ensure that it always arrives before the response to SDA query (because multithreading). You may be right, but my reasoning was that without knowing why there's a second buffer-switch event sometimes, we will be unable to devise a good solution. IOW, I think we need to understand the issue better before we are ready to discuss a solution. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 15:06:36 2019 Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 19:06:36 +0000 Received: from localhost ([127.0.0.1]:48713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDD7k-00052O-Ha for submit@debbugs.gnu.org; Sun, 07 Apr 2019 15:06:36 -0400 Received: from mail-lf1-f54.google.com ([209.85.167.54]:43509) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDD7i-00052B-TN for 34821@debbugs.gnu.org; Sun, 07 Apr 2019 15:06:35 -0400 Received: by mail-lf1-f54.google.com with SMTP id g7so7799441lfh.10 for <34821@debbugs.gnu.org>; Sun, 07 Apr 2019 12:06:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-transfer-encoding:content-language; bh=5KaOg8/b8Xu5tKM+/HrbKN5zZ5l32j8ezfeiEqXJ4WQ=; b=eJlGQCT4PqznscI7Kmk20DjeQ9bP7f3TYDGdpsQSLdRigIkckmRlwrstkMku4y9oUw LngcWy9bW425cmWTJSEzp8q72+hM+w+Fqtzis3PuZ34OC2MuRxk56SUirgN+P1gmJMp1 YWiW0+M4LI7LR/Bl1EhfYmh8gtFckV3x1/LI8miDSkkuYO/XIW1v/9Wjr/bNY+Qua4/L Ng3yN8s2VTWKvRVw5XO8WJCN5pbRVnUoKRv2wppY4OaPCMlZfWQnVyx7Yw5HpF7M5ri8 Q9Ue2IdOaj5YKo5atvg+8NfOPlAdsggDtGBxX5vMfT/z6TCh8TEhy5xDMEEmKVRsrMcK yrQw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-transfer-encoding :content-language; bh=5KaOg8/b8Xu5tKM+/HrbKN5zZ5l32j8ezfeiEqXJ4WQ=; b=mINHGlXEUfliVYgbiGvIsphveRsGJSJLKT9oR0VRQOjinrOR+fYyemay+5L0aiOy5+ FYxZInj0qL7sySNxpAiS0vxJoDdFoGsqjShYz40j78469rsGkUTsYpktGbq9jA8mxIfv f4NL39/wF3LtY9fqzLotpgBbSCvqjaPxwQ06xfZ4HFaglmPErwnZXCw9/PZeAYRDyXYy t7JsLt5sBBcTrN7pYRtHSrkF1EBfyF+FgFOy3EN1Wm03Sfu4ia4rWJv4W5S6KpYKeqpN HHn5BdE+AOVDL3Nh0w53UVKZyjzF2XAbaeGxlPG66cN4HSFWMWOXYYAuZG7xkU//eFCr uhPA== X-Gm-Message-State: APjAAAVlbRK5BXJkZdCHwiU8BBqoT0Py77CP3aXBlcLl3cD8wycnrgBp 0OrNPaltio7MLUgOB9CfuF4NC8Kc X-Google-Smtp-Source: APXvYqyhh7eNQLi2rCf/MM9JEGsjgvqAsK5BRpwPlzau1vynyUz8r2XWtV9J4BBNTdCcvgMytz/wkw== X-Received: by 2002:ac2:4850:: with SMTP id 16mr4356090lfy.70.1554663988136; Sun, 07 Apr 2019 12:06:28 -0700 (PDT) Received: from [192.168.1.65] (109-252-80-126.nat.spd-mgts.ru. [109.252.80.126]) by smtp.gmail.com with ESMTPSA id u19sm5634638lfg.74.2019.04.07.12.06.26 for <34821@debbugs.gnu.org> (version=TLS1_3 cipher=AEAD-AES128-GCM-SHA256 bits=128/128); Sun, 07 Apr 2019 12:06:26 -0700 (PDT) Subject: Re: bug#34821: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer To: 34821@debbugs.gnu.org References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> <83v9zp93gq.fsf@gnu.org> <492c723c-6ba9-24da-108f-b25cef0dd54e@gmail.com> <83r2ad8yh1.fsf@gnu.org> From: Platon Pronko Message-ID: <0029f748-36b6-e344-9aef-53f0e2101200@gmail.com> Date: Sun, 7 Apr 2019 22:06:23 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:60.0) Gecko/20100101 Thunderbird/60.5.3 MIME-Version: 1.0 In-Reply-To: <83r2ad8yh1.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Content-Language: en-US X-Spam-Score: 1.5 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.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 the administrator of that system for details. Content preview: > What do you mean by "run concurrently"? Emacs is pretty much a single > threaded program, and there's only one Lisp thread running at any > given time, which will execute both calls. My knowledge of Emacs internals is pretty thin indeed. But since adding sleep-for results in reordering of events, I thought that there are at least different threads that compete for execution (concu [...] Content analysis details: (1.5 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (platon7pronko[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 1.5 RCVD_IN_SORBS_WEB RBL: SORBS: sender is an abusable web server [109.252.80.126 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_DNSWL_NONE RBL: Sender listed at https://www.dnswl.org/, no trust [209.85.167.54 listed in list.dnswl.org] X-Debbugs-Envelope-To: 34821 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: 0.5 (/) > What do you mean by "run concurrently"? Emacs is pretty much a single > threaded program, and there's only one Lisp thread running at any > given time, which will execute both calls. My knowledge of Emacs internals is pretty thin indeed. But since adding sleep-for results in reordering of events, I thought that there are at least different threads that compete for execution (concurrent, maybe not parallel). Also I noticed that for example read_char() calls can block for quite a lot of time, while Lisp code continues to run. Perhaps there is one Lisp thread and some other background C threads? > You may be right, but my reasoning was that without knowing why > there's a second buffer-switch event sometimes, we will be unable to > devise a good solution. IOW, I think we need to understand the issue > better before we are ready to discuss a solution. I agree. I'll look at what causes that second event, I'm quite interested in the mechanics of it anyway. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 07 15:25:48 2019 Received: (at 34821) by debbugs.gnu.org; 7 Apr 2019 19:25:48 +0000 Received: from localhost ([127.0.0.1]:48725 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDDQJ-0005Ys-Px for submit@debbugs.gnu.org; Sun, 07 Apr 2019 15:25:47 -0400 Received: from eggs.gnu.org ([209.51.188.92]:40378) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1hDDQH-0005Ye-2O for 34821@debbugs.gnu.org; Sun, 07 Apr 2019 15:25:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58869) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1hDDQB-0002AI-KO; Sun, 07 Apr 2019 15:25:39 -0400 Received: from [176.228.60.248] (port=3162 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_256_CBC_SHA1:256) (Exim 4.82) (envelope-from ) id 1hDDQ7-0008IO-4N; Sun, 07 Apr 2019 15:25:35 -0400 Date: Sun, 07 Apr 2019 22:25:28 +0300 Message-Id: <83ftqt8vo7.fsf@gnu.org> From: Eli Zaretskii To: Platon Pronko In-reply-to: <0029f748-36b6-e344-9aef-53f0e2101200@gmail.com> (message from Platon Pronko on Sun, 7 Apr 2019 22:06:23 +0300) Subject: Re: bug#34821: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> <83v9zp93gq.fsf@gnu.org> <492c723c-6ba9-24da-108f-b25cef0dd54e@gmail.com> <83r2ad8yh1.fsf@gnu.org> <0029f748-36b6-e344-9aef-53f0e2101200@gmail.com> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 34821 Cc: 34821@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 (-) > From: Platon Pronko > Date: Sun, 7 Apr 2019 22:06:23 +0300 > > > What do you mean by "run concurrently"? Emacs is pretty much a single > > threaded program, and there's only one Lisp thread running at any > > given time, which will execute both calls. > > My knowledge of Emacs internals is pretty thin indeed. But since adding sleep-for results in reordering of events, I thought that there are at least different threads that compete for execution (concurrent, maybe not parallel). Also I noticed that for example read_char() calls can block for quite a lot of time, while Lisp code continues to run. Perhaps there is one Lisp thread and some other background C threads? No, there's just one thread. The only other one I can think of is the code of xterm itself. From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 02:24:06 2020 Received: (at 34821) by debbugs.gnu.org; 24 May 2020 06:24:06 +0000 Received: from localhost ([127.0.0.1]:36194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jck3K-00020p-7d for submit@debbugs.gnu.org; Sun, 24 May 2020 02:24:06 -0400 Received: from mail-lf1-f47.google.com ([209.85.167.47]:37985) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jck3I-00020M-GX for 34821@debbugs.gnu.org; Sun, 24 May 2020 02:24:04 -0400 Received: by mail-lf1-f47.google.com with SMTP id 202so8815088lfe.5 for <34821@debbugs.gnu.org>; Sat, 23 May 2020 23:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=subject:to:references:from:message-id:date:user-agent:mime-version :in-reply-to:content-language:content-transfer-encoding; bh=k9rwanSCp2vnaR8AbqiJGWH138lOlYowrK+ob+V7fS8=; b=R4t+azKVkyT3yTD1PHnacMYc3kvIVmbTpGS5h1kA8o0mbc1VCBM3fBaTXB0PGPFkl5 07AfKwMiFaMi452PZ7Dv5Rv7PqSz+qogNbdkHgTQuZcRJZ0+09BqxBUbhHI6uWOrWnMo uzNY0jjyQWpK1w7T0rMozgzFe/cmodhZwka7gIPaYhaFuR4TPjlyCB9fIP8+8YT5vYh0 PlY+zfl6tniZnx2FQ2/pGzAORR9Cd7U6z0DlPzSZiQm4P4psFD3HlB0I/I+F3Tqrit5H kogF2vhBw9oBXQtQLdoY00OCBWg4jOXWNe3P0tLWzkG6xB7fxxeZlswIllXKT+VMrISF xOvQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:subject:to:references:from:message-id:date :user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=k9rwanSCp2vnaR8AbqiJGWH138lOlYowrK+ob+V7fS8=; b=retXV/M7BfeVu4WvNbOA2TuPg7sQfQzEl7ArQYyQaQmydk12oAJTUtgDoRyDR3dvFY OZeLU7cZ4JtJ0TOs2aGcJrj/tqnd/NQaPuC0XSBeOSbAkxyfsweaK2aIkBza9fE9xR5E plMoXOShpZ/1w1wAJJ1ssyS6/EqK3CltdlE8wS8p3kYh3sc1sXwOB/YAOCd9fk3Hnmwd Ycws5MTb5YHbCYZafaN2zI3LWU3Gms/06G6zPTP0R9CcK3y4B31887VyBLMteFwMJdu0 K2SOjR0uEkyzGiKEXGepiRS5i6wUewLjs7gulHUX6NPiT1q/w2RJG0gDThOO+73tikHz zQuA== X-Gm-Message-State: AOAM530kssXbhsOZeqrHInvb/z7fXY25tJWGY4kgR4hXnMLmHyea81DL w3Wl6s2xZjnWD06CZTvjHWilEXC5 X-Google-Smtp-Source: ABdhPJxwUxMzix1p4DbgxdhlYxSekXdJZEdytDBlsCn5Qs3WVHHQCfq8IphvVJD8bY5ChfT6zgm5sQ== X-Received: by 2002:ac2:5dcb:: with SMTP id x11mr6777860lfq.110.1590301437946; Sat, 23 May 2020 23:23:57 -0700 (PDT) Received: from [192.168.1.65] (109-252-79-161.nat.spd-mgts.ru. [109.252.79.161]) by smtp.gmail.com with ESMTPSA id j14sm3475351lji.5.2020.05.23.23.23.56 for <34821@debbugs.gnu.org> (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 23 May 2020 23:23:57 -0700 (PDT) Subject: Re: bug#34821: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer To: 34821@debbugs.gnu.org References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> <83v9zp93gq.fsf@gnu.org> <492c723c-6ba9-24da-108f-b25cef0dd54e@gmail.com> <83r2ad8yh1.fsf@gnu.org> <0029f748-36b6-e344-9aef-53f0e2101200@gmail.com> <83ftqt8vo7.fsf@gnu.org> From: Platon Pronko Message-ID: Date: Sun, 24 May 2020 09:23:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.7.0 MIME-Version: 1.0 In-Reply-To: <83ftqt8vo7.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34821 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 (-) I am unable to reproduce the issue with the latest build (28.0.50). I think this issue can be closed now. Thanks to the developers for their work! From debbugs-submit-bounces@debbugs.gnu.org Sun May 24 03:08:45 2020 Received: (at 34821-done) by debbugs.gnu.org; 24 May 2020 07:08:45 +0000 Received: from localhost ([127.0.0.1]:36353 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jckkX-000368-BD for submit@debbugs.gnu.org; Sun, 24 May 2020 03:08:45 -0400 Received: from mail-yb1-f177.google.com ([209.85.219.177]:44053) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jckkV-00035w-KJ for 34821-done@debbugs.gnu.org; Sun, 24 May 2020 03:08:44 -0400 Received: by mail-yb1-f177.google.com with SMTP id 67so6824523ybn.11 for <34821-done@debbugs.gnu.org>; Sun, 24 May 2020 00:08:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:in-reply-to:references:mime-version:date:message-id:subject:to; bh=LEr3vSGnAwWv/F0qwhZ2YpZ0Pit2rInCg1yCHtlLMyc=; b=Zfi1ADNhM5J/nfX4JUwgScOejTjGAVv2J0SKyC/OyLGZWtGukQPQb1Cw6HHmcWgI82 yMF6AmOz4k0D9yVmDuFrC5zl8u4rHa5ft3Hq0wHmsbWSBhJxzEiRJFtcmY+qMSIwP+Y7 MYJaezTCcphUF+VjNOivSr6GCdOAghTLrw783ulCfUszmg++afbMRvxj6WWe1IW/aO2L 6YWbpiZI4J5PyyG4w2lsLZj1zPCVWtiLd7BwRCWnPep0Oam2RlGOe11PZ2me2uozFaJB 0DObLK33X90+7cMzNTC1R1UbJVtQOwEADQZdysBcYi6Z5iCwKox3m54hRdAFSgSFP04+ JTrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:in-reply-to:references:mime-version:date :message-id:subject:to; bh=LEr3vSGnAwWv/F0qwhZ2YpZ0Pit2rInCg1yCHtlLMyc=; b=q32PLOIbyg41JWv0PSqCZg6Nr0HuFjAvXGb3wP1fUCBRR5060U+TBYRdfWbcgH5bVw gHAVZ+cV422EWlsIZM/DQ8am2Rhg7DZPQXcT8Gx2wtdmu3s+8Y3iyFKVjj8T0PQxO76X Zm/EHi3OIl9pYuUYGKz8TCnI2WaEQdr042mekZjgoljQ08RCTzoPEwpGsjx5CTpvSnwo S/HE2IJT4qzsCHOKDp1TEHJJ1o081iPe9apY9F+0G20YAXRGgjBXCccL7258tf2zkyuG qNDFQOzyGweIuJbZn4oYNyBCVhsEBEGuLmKXKsymPNJ0W0cOkXSKGXFv+97mLKYnlg3t 6BuQ== X-Gm-Message-State: AOAM532iqyIBgX3VYWdGwfNngaRZY3vRKZl1tJ7OQmlmil4iqEDUmLMS RzyvJcK2vl7UX9xt4+M2jgpS4hpfGl2t8mWBtyk= X-Google-Smtp-Source: ABdhPJxsG+5zhh+5RroI/UznLjXtHLFqzMm2mUT3ytFiv+i/Nj5exU8g1XUOiwPn2ccJXYylMuckHPmY8GhbXQenMfk= X-Received: by 2002:a25:9304:: with SMTP id f4mr34497360ybo.309.1590304118156; Sun, 24 May 2020 00:08:38 -0700 (PDT) Received: from 753933720722 named unknown by gmailapi.google.com with HTTPREST; Sun, 24 May 2020 00:08:37 -0700 From: Stefan Kangas In-Reply-To: References: <6e2317c9-5063-3718-740e-f53c70f5db5b@gmail.com> <83v9zp93gq.fsf@gnu.org> <492c723c-6ba9-24da-108f-b25cef0dd54e@gmail.com> <83r2ad8yh1.fsf@gnu.org> <0029f748-36b6-e344-9aef-53f0e2101200@gmail.com> <83ftqt8vo7.fsf@gnu.org> MIME-Version: 1.0 Date: Sun, 24 May 2020 00:08:37 -0700 Message-ID: Subject: Re: bug#34821: discard_input_tty does not discard pending input, resulting in garbage inserted into the buffer To: Platon Pronko , 34821-done@debbugs.gnu.org Content-Type: text/plain; charset="UTF-8" X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 34821-done 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 (-) Platon Pronko writes: > I am unable to reproduce the issue with the latest build (28.0.50). I > think this issue can be closed now. Thanks, I'm closing the bug with this email. Best regards, Stefan Kangas From unknown Tue Jun 17 01:32:00 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Sun, 21 Jun 2020 11:24:04 +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