From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Sep 2016 19:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 24372@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.147310301915212 (code B ref -1); Mon, 05 Sep 2016 19:17:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 Sep 2016 19:16:59 +0000 Received: from localhost ([127.0.0.1]:50636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgzO7-0003xI-7V for submit@debbugs.gnu.org; Mon, 05 Sep 2016 15:16:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgzO6-0003x3-3U for submit@debbugs.gnu.org; Mon, 05 Sep 2016 15:16:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgzNz-0004CB-Qe for submit@debbugs.gnu.org; Mon, 05 Sep 2016 15:16:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgzNz-0004C5-Mo for submit@debbugs.gnu.org; Mon, 05 Sep 2016 15:16:51 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgzNy-0005E8-7x for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 15:16:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgzNv-0004BC-Pj for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 15:16:49 -0400 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:38370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgzNv-0004Ap-Fu for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 15:16:47 -0400 Received: by mail-wm0-x22f.google.com with SMTP id 1so153967696wmz.1 for ; Mon, 05 Sep 2016 12:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=EuryU+nikTAGqoOjQDNzwFg6cmacLXReQWpb0mRX0Fg=; b=H1z4VnJqGBh1HcKFxQOO8xQrOcXtkssH3SCCzSrhOOSUIKjZSS79cvthbX600tceSj pvHNzNeCd1K2fgGX9x7Lt1oNt6rick5BPdaVZG774zIBw9EkY8lFduhFPMhlah1rTegU NrRJ6ZTCDGKXX4yUpmjb5vgBu7cpkfuwrRFMvMmMEHPXOrzdGxSwxIKSvzn6QDXhSr+O j9eYAhYdHw0/gTUmvfQpKJiTqpuKoIle6R8R3pE1xnQhD8EjW7iN/0LWmObnUJb67a8W spTuyabpZatxQApGYzcO1j+FkgJfL2LLUwduZukZXWReIc3yQHF82ppW/GspydlFE3s0 vj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=EuryU+nikTAGqoOjQDNzwFg6cmacLXReQWpb0mRX0Fg=; b=TzSZLPE+5Ll1It4buXUGXMge1xJdJw5xMRnV8tT08adNk+V92yMg9HF1LlLIY3/D9B 5ydPrbYqooAF0hf16FH5wbOydEpIXBHgX+eD/neSWRV9ASjpwNSiSLGiBTokrsg4VA0I yxTP6og+6W69q5NdfkhBhvh6dDBWm5roxJ83WwXYbEXe35s/XXwHca1ssPNZjUDOlW0U R2HJ/MLg+FPtMGRRs7cURecbJWeA00GzYLjn9uenJ24EbLAmlzg/dtMUKcUbVvAVRyt9 wig1bOQJl5mTszAqbxQmHBdPpbYNnY364niLlZ8DEvOWYe8AgWqJ0KHnL8yPQj6WcQ0i scPA== X-Gm-Message-State: AE9vXwOd9QuyfbJeecHxVn7MZsfaB/i52PSG4HsXFdnMhdgAOeQqe3qyGULtkQqFaMId+Q== X-Received: by 10.28.181.142 with SMTP id e136mr17739334wmf.61.1473103006304; Mon, 05 Sep 2016 12:16:46 -0700 (PDT) Received: from a.muc.corp.google.com ([2a00:79e0:15:4:c077:c733:b8e8:6e63]) by smtp.gmail.com with ESMTPSA id f187sm22359072wmf.15.2016.09.05.12.16.44 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 05 Sep 2016 12:16:44 -0700 (PDT) From: Philipp Stephani Date: Mon, 05 Sep 2016 21:16:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) 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.8 (---) I've tested this with a GTK build on GNU/Linux; other toolkits and OSes might also be affected (but terminal mode doesn't seem to be affected). emacs -Q -eval '(setq blink-cursor-delay 0.0)' Move point around in the scratch buffer (e.g. press C-b a couple of times): the cursor stays visible, as it should be. Then put the mouse focus on a different GTK window (not Emacs window), put the mouse focus back on Emacs, and move point again: the cursor is hidden, making it impossible to see until you stop moving. In GNU Emacs 25.1.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2016-09-05 built on unknown Repository revision: 6acff25280dbb97b5e9ddfd872b33ceb36b0470a Windowing system distributor 'The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04 LTS Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --with-modules' Configured features: XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction 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 blink-cursor-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 subr-x puny seq byte-opt gv bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date 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 newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow 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 charscript 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 inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 97852 8736) (symbols 48 20654 0) (miscs 40 325 194) (strings 32 17964 4666) (string-bytes 1 589251) (vectors 16 13794) (vector-slots 8 452872 5883) (floats 8 183 107) (intervals 56 211 0) (buffers 976 12) (heap 1024 48215 1026)) --=20 Google Germany GmbH Erika-Mann-Stra=C3=9Fe 33 80636 M=C3=BCnchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch=C3=A4ftsf=C3=BChrer: Matthew Scott Sucherman, Paul Terence Manicle Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und l=C3= =B6schen Sie die E-Mail und alle Anh=C3=A4nge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do = not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks. From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 05 Sep 2016 21:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 24372@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.147311097227286 (code B ref -1); Mon, 05 Sep 2016 21:30:02 +0000 Received: (at submit) by debbugs.gnu.org; 5 Sep 2016 21:29:32 +0000 Received: from localhost ([127.0.0.1]:50671 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bh1SO-000762-9g for submit@debbugs.gnu.org; Mon, 05 Sep 2016 17:29:32 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36209) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bh1SM-00075q-Rv for submit@debbugs.gnu.org; Mon, 05 Sep 2016 17:29:31 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bh1SG-0005B0-Kd for submit@debbugs.gnu.org; Mon, 05 Sep 2016 17:29:25 -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.4 required=5.0 tests=BAYES_40,FREEMAIL_FROM, RCVD_IN_SORBS_SPAM autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:35685) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh1SG-0005Ai-HA for submit@debbugs.gnu.org; Mon, 05 Sep 2016 17:29:24 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:55381) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh1SE-0002O3-Ca for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 17:29:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bh1SA-00059E-7a for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 17:29:22 -0400 Received: from mout.kundenserver.de ([212.227.17.24]:55665) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bh1S9-00057r-Sw for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 17:29:18 -0400 Received: from [18.189.118.169] ([18.189.118.169]) by mrelayeu.kundenserver.de (mreue103) with ESMTPSA (Nemesis) id 0MW8Zl-1ba4NZ0hib-00XOI2 for ; Mon, 05 Sep 2016 23:29:16 +0200 References: From: =?UTF-8?Q?Cl=C3=A9ment?= Pit--Claudel Message-ID: <942c2bb2-43ad-45a7-070f-8ea8797e13d0@gmail.com> Date: Mon, 5 Sep 2016 17:29:07 -0400 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2.0 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/signed; micalg=pgp-sha256; protocol="application/pgp-signature"; boundary="eE3hFp2R3w2pmVNePR2TgLr024su74CNi" X-Provags-ID: V03:K0:ck/C1FlAZ9Tu0M7R1CWC0qTq9LroM731XPV7VleiXd+HQnE0Joc Mqs2Yr2t+k2TnTcTk3AEEBQ1PsuheZMnqyLQwY9moKQUBQo9Ar/pgYo8pPsjVmSTd0685lV gcZR55X/vQP3cGlbK56Wc1Roqtg0Brb877YapiXy8LKtbCsObyaeDfKUQDtVxp4eq4Os5GW JM40vGwc/1ynr7SBwJfWA== X-UI-Out-Filterresults: notjunk:1;V01:K0:8L4ghWJepIM=:yuQxfnM3+re+v94We3vi95 ee/qG6JS2DEPtE8jNVDB8JaLqHFUoBgmqj5PXsYO0yIA77vT7tOapZNEfpB4YO4GIyjBCwxVp 1cptZHUND0VXHjj3gbJ9f1WhGhm3mmF3189GEIwjWOTRPBo+fetiARMdVCk/G8trLfQAvz5VD 0haMXPKXvZ/kc7S3HllZr6DeUE7pYjNLykCOLV+riuguqS15UzhKBe95yxkkkr7PYQ9cg+hCF wowt378bQKyNuzqtSXGMP5IiSEfnXHTF9Wo2pevOL4KCDRolybyxxey47I/zdH905O2XMJNeG c9Qvzt/20M42wq2RqM2PT0tg3bJdAYDLEs5ATsGPbjg/00fGvbD91taJzG1VP1Mq+i78FFbBZ RUHbbW6qWpEwE1aNXpQfL9MmEf8mUk9y61XtmiHqOtgxjgr4zbbkauAKHA+L2zLf7rcawrxBx 9goaYvAMbJZyLrgCfIM/hWCqkiqEmyBhj9FNE4WmgXVByMw6DpkZdTmj6vjl4b4RbqeNxvZv+ ChFJZA1ZsNSIyn756YS7rGojl8azJ+lu7vX3HQ6jfwoZpqutG2bs1KDsAFtpsGeB4uv1Dadc8 JJ9IFeFZvDKHABt7Fg2Lb9XYSRDzMk1rL+pYjPusivjsb8007VmoleS+LjJXMobkRZ2pzdbb2 uxSHKR6lxTjIQDHM/Fh1EGngZbG2d1R/UaEnvm9IpGgpffb3zRUkLwSf+9fm+oByIAoA= X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -1.6 (-) 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.6 (-) This is an OpenPGP/MIME signed message (RFC 4880 and 3156) --eE3hFp2R3w2pmVNePR2TgLr024su74CNi Content-Type: multipart/mixed; boundary="34j8caCvBWwQwtvkSW74BD3ubstUXa3LE"; protected-headers="v1" From: =?UTF-8?Q?Cl=c3=a9ment_Pit--Claudel?= To: bug-gnu-emacs@gnu.org Message-ID: <942c2bb2-43ad-45a7-070f-8ea8797e13d0@gmail.com> Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point References: In-Reply-To: --34j8caCvBWwQwtvkSW74BD3ubstUXa3LE Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable On 2016-09-05 15:16, Philipp Stephani wrote: > emacs -Q -eval '(setq blink-cursor-delay 0.0)' Indeed, I can reproduce this too. Cl=C3=A9ment. In GNU Emacs 25.1.50.7 (x86_64-pc-linux-gnu, GTK+ Version 3.18.9) of 2016-07-20 built on clem-w50-mint Repository revision: a1a0c208e3e895a6ea0942e8e5c4077faf12c7ad Windowing system distributor 'The X.Org Foundation', version 11.0.1180300= 0 System Description: Linux Mint 18 Sarah --34j8caCvBWwQwtvkSW74BD3ubstUXa3LE-- --eE3hFp2R3w2pmVNePR2TgLr024su74CNi Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc" -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iQIcBAEBCAAGBQJXzeOpAAoJEPqg+cTm90wjav0P/is9lwwnWQ6PxHaziFfGf+Lw gZE2GETNL6U96XporYt021UUIplZbINbfX/H8BB3xF+lllyYE604OVdbqMypSJcU IAmn4iewPEoNV9FYh6t4RV/ZU7O5ElncMvkxlEIZO8cLatlSgYfz2+HJ0rJXHfcv +eFtt18Lgs3p3vACuA6eOMvIy0KO7Ps14n3Ynkae9OIFLy6jJNYCv3DGESrsZWbr glmK3wDZRrb2UzZ/7yyI3N9LWCK1xQ2e0ajng3+mRPw6cvH8+43PL77r1sl4gRWD io8o+4VR9duVIXErzLEyRIwFrjcicui1tFQuJ3sqLQECo9iUCQ050SL5zYkc4Cme ygTReJdFZsRBRvpFu2O+Z6ZeUQ8pxOiKBgkIYQZZWDKcr20sn3SNwZvqjJ1Df84W dHBGcY78pe7+l5LXZHiHH79ZXAhfL5M3L7/Ag6TggvEfNBIQjjLR8i2akhveVM3l xzt8Mfvfx+ww97FvqTNvZQ7dGbJJa8wz+w1bXOVUOFzsMjSZmkZiRtPOqvDPzFjC kXz04ofskwDgtbeYHHdjbrBN6CX8opktR9JXlpEyERb7fZHQsTM2rjRW+GCUEsn3 +RzVROtN1JSf+B0YDCFgo4Dc8K9WipTK9+l5qi50WyXPlmTOn188qEqvvKh103N8 FWFsXNr8IZ22ep6Bbqke =Av88 -----END PGP SIGNATURE----- --eE3hFp2R3w2pmVNePR2TgLr024su74CNi-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 06 Sep 2016 16:04:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147317782111852 (code B ref 24372); Tue, 06 Sep 2016 16:04:01 +0000 Received: (at 24372) by debbugs.gnu.org; 6 Sep 2016 16:03:41 +0000 Received: from localhost ([127.0.0.1]:51559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhIqb-000356-Lz for submit@debbugs.gnu.org; Tue, 06 Sep 2016 12:03:41 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60414) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bhIqa-00034n-2o for 24372@debbugs.gnu.org; Tue, 06 Sep 2016 12:03:40 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bhIqR-0004xZ-Qd for 24372@debbugs.gnu.org; Tue, 06 Sep 2016 12:03:34 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.1 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56769) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bhIqR-0004xS-N8; Tue, 06 Sep 2016 12:03:31 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:4296 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bhIqQ-00017z-3f; Tue, 06 Sep 2016 12:03:30 -0400 Date: Tue, 06 Sep 2016 19:03:20 +0300 Message-Id: <83a8flaud3.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Mon, 05 Sep 2016 21:16:40 +0200) References: X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.1 (------) 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: -6.1 (------) > From: Philipp Stephani > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > Move point around in the scratch buffer (e.g. press C-b a couple of > times): the cursor stays visible, as it should be. Then put the mouse > focus on a different GTK window (not Emacs window), put the mouse focus > back on Emacs, and move point again: the cursor is hidden, making it > impossible to see until you stop moving. Does it happen even if you wait with cursor motion until after the cursor blinks one time, i.e. if you start moving point with the cursor already visible after Emacs gets focus? From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 16:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147343676027548 (code B ref 24372); Fri, 09 Sep 2016 16:00:02 +0000 Received: (at 24372) by debbugs.gnu.org; 9 Sep 2016 15:59:20 +0000 Received: from localhost ([127.0.0.1]:54804 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOD2-0007AG-EV for submit@debbugs.gnu.org; Fri, 09 Sep 2016 11:59:20 -0400 Received: from mail-wm0-f53.google.com ([74.125.82.53]:35279) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOD0-0007A2-JV for 24372@debbugs.gnu.org; Fri, 09 Sep 2016 11:59:19 -0400 Received: by mail-wm0-f53.google.com with SMTP id w12so39347738wmf.0 for <24372@debbugs.gnu.org>; Fri, 09 Sep 2016 08:59:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=MwQbQweyHSosM1WVs18fJp3LbPas7sll1zxaj7cQQTQ=; b=UlWP7cuYNYED0OopiWlVlBsTk+k6+Dl0yuYwOA+0U8KjiETWuxjEPhRwX6MOmAhCCk Ugy0fFIE1FURbdAUmIPeCFXxrCmZC9482a6Qxh2Vm2P9O+7Xhw5dO6XgwZGSyUNrf0C2 vvvZkw6la2/Ro8eJ5WMJgZBgUDbHv3PSzexbLES2JBdSC+mrgL9SjgXlGgN7Fr0/8ib8 zhKwzz+SFnrjTh2Lh82OtYDQBSmLAJ5K2toypxdS5nm0BZ3Z7ZL/Mnqrz/vAeHipaMPf 7HXHZGXM3yBsAifpRgPkWZLLc5mxAD2EQnl5muVZyukTJLorPeaUZhM/I0j07KX30lG8 AgJQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=MwQbQweyHSosM1WVs18fJp3LbPas7sll1zxaj7cQQTQ=; b=Ir0B7fjJP8anLFRHaNk9McMP1K+xKF7O8UaHMKnEY9M+ZLMn7JqVY8yrFB67HDDwRm EDOcMGZFuMMc/dIq73n1+nQDLdjQR7/wo1qM1u6/LZjfmBXSfyCev6dwl1nFVWykTVFS lTv+/K5cenMCVdOpl8eMqB59GjTLp9N4nfPdXoSGhPqjvnDdXXTF3w/FUUX5agMz75dP NTN+f8zzXZhaV44jI3q2IIx+5/vvSh/q8qwuateXhb9mpDkUdESywITM8tz3KlpDIDas v9JCB4tTH6Pw0s5fQpjs+1r0cTKYgVtiyGJS4jzKH9ChgnIxD5lJ6oIOj6e3ywM8mohs UkSQ== X-Gm-Message-State: AE9vXwN34dHTOhm+BRFUcdq0wCkq/us+fSzc21xgJJDuUif7x6kEVYMctrYiLN+VnX5lCJ0LY3mZIwXvmU+SDw== X-Received: by 10.28.31.208 with SMTP id f199mr3864348wmf.69.1473436752779; Fri, 09 Sep 2016 08:59:12 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> In-Reply-To: <83a8flaud3.fsf@gnu.org> From: Philipp Stephani Date: Fri, 09 Sep 2016 15:59:02 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a114b353a3f9ecc053c153aaa X-Spam-Score: 1.9 (+) 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: Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > From: Philipp Stephani > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > times): the cursor stays visible, as it should be. Then put the mouse > > focus on a different GTK window (not Emacs window), put the mouse focus > > back on Emacs, and move point again: the cursor is hidden, making it > > impossible to see until you stop moving. > > Does it happen even if you wait with cursor motion until after the > cursor blinks one time, i.e. if you start moving point with the cursor > already visible after Emacs gets focus? > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.53 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.53 listed in wl.mailspike.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.53 listed in list.dnswl.org] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 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.9 (+) 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: Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > From: Philipp Stephani > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > times): the cursor stays visible, as it should be. Then put the mouse > > focus on a different GTK window (not Emacs window), put the mouse focus > > back on Emacs, and move point again: the cursor is hidden, making it > > impossible to see until you stop moving. > > Does it happen even if you wait with cursor motion until after the > cursor blinks one time, i.e. if you start moving point with the cursor > already visible after Emacs gets focus? > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.53 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.53 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.53 listed in wl.mailspike.net] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid --001a114b353a3f9ecc053c153aaa Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > From: Philipp Stephani > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > times): the cursor stays visible, as it should be. Then put the mouse > > focus on a different GTK window (not Emacs window), put the mouse focus > > back on Emacs, and move point again: the cursor is hidden, making it > > impossible to see until you stop moving. > > Does it happen even if you wait with cursor motion until after the > cursor blinks one time, i.e. if you start moving point with the cursor > already visible after Emacs gets focus? > Yes. No matter what state the cursor is in and how often it has already blinked, it becomes invisible when moving. --001a114b353a3f9ecc053c153aaa Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Di., 6. Sep. 2016 um 18:03=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Mon, 05 Sep 2016 21:16:40 +0200
>
> emacs -Q -eval '(setq blink-cursor-delay 0.0)'
>
> Move point around in the scratch buffer (e.g. press C-b a couple of > times): the cursor stays visible, as it should be.=C2=A0 Then put the = mouse
> focus on a different GTK window (not Emacs window), put the mouse focu= s
> back on Emacs, and move point again: the cursor is hidden, making it > impossible to see until you stop moving.

Does it happen even if you wait with cursor motion until after the
cursor blinks one time, i.e. if you start moving point with the cursor
already visible after Emacs gets focus?


Yes. No matter what state the cursor is= in and how often it has already blinked, it becomes invisible when moving.= =C2=A0
--001a114b353a3f9ecc053c153aaa-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 16:08:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147343724628373 (code B ref 24372); Fri, 09 Sep 2016 16:08:01 +0000 Received: (at 24372) by debbugs.gnu.org; 9 Sep 2016 16:07:26 +0000 Received: from localhost ([127.0.0.1]:54810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOKs-0007NY-BG for submit@debbugs.gnu.org; Fri, 09 Sep 2016 12:07:26 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59068) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOKq-0007NJ-Fq for 24372@debbugs.gnu.org; Fri, 09 Sep 2016 12:07:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1biOKi-0002AX-3j for 24372@debbugs.gnu.org; Fri, 09 Sep 2016 12:07:19 -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.5 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:47977) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1biOKi-0002AT-0Y; Fri, 09 Sep 2016 12:07:16 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2421 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1biOKg-000755-KB; Fri, 09 Sep 2016 12:07:15 -0400 Date: Fri, 09 Sep 2016 19:07:04 +0300 Message-Id: <831t0t83br.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Fri, 09 Sep 2016 15:59:02 +0000) References: <83a8flaud3.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) 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: -6.3 (------) > From: Philipp Stephani > Date: Fri, 09 Sep 2016 15:59:02 +0000 > Cc: 24372@debbugs.gnu.org > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > From: Philipp Stephani > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > times): the cursor stays visible, as it should be. Then put the mouse > > focus on a different GTK window (not Emacs window), put the mouse focus > > back on Emacs, and move point again: the cursor is hidden, making it > > impossible to see until you stop moving. > > Does it happen even if you wait with cursor motion until after the > cursor blinks one time, i.e. if you start moving point with the cursor > already visible after Emacs gets focus? > > Yes. No matter what state the cursor is in and how often it has already blinked, it becomes invisible when > moving. So what is the importance of moving focus out of the Emacs frame and then back into it? Is the problem reproducible without that? Or are you saying that focus-out followed by focus-in event somehow changes the behavior wrt displaying the cursor? From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 16:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147343803730222 (code B ref 24372); Fri, 09 Sep 2016 16:21:02 +0000 Received: (at 24372) by debbugs.gnu.org; 9 Sep 2016 16:20:37 +0000 Received: from localhost ([127.0.0.1]:54818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOXc-0007rN-PS for submit@debbugs.gnu.org; Fri, 09 Sep 2016 12:20:37 -0400 Received: from mail-wm0-f52.google.com ([74.125.82.52]:37852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOXb-0007r3-3n for 24372@debbugs.gnu.org; Fri, 09 Sep 2016 12:20:35 -0400 Received: by mail-wm0-f52.google.com with SMTP id w12so42216910wmf.0 for <24372@debbugs.gnu.org>; Fri, 09 Sep 2016 09:20:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=2txiMIeFe9aBMpvo3/wKxUwOYcos0Knfb16Ssz5dO0U=; b=E9ZcVx4vTedWoxFy3tPBlQs9HUxKju2wLe/3O0zc8NI/Pc8pat92eDSemQs0J9SBAu ZmuQHR6XYs+nssh+4jm1DRUNvjhfs++ozY2YPHn366KBu+sD8LI1cUSVYkH72zmuw927 Xcm0iqgemKbPt3cE3C0itpzUdrWNVcHBkHgO705uqEj+m0Qc6iXXYC1Gu1IGkjyWQNHQ vt8acs43NUl5SXsYQF7uCHdjtTLXnOLjzjm9ISGTCK6haC8DsVuBWFE+I576PRugAKKj II17KiVfgPsjbrlm+tLGwFDoB6mwm8szI5pQZNzRjwPGlDiZnQE9fmUbIDVvXhEHaNNY xzWg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=2txiMIeFe9aBMpvo3/wKxUwOYcos0Knfb16Ssz5dO0U=; b=FN0R8sqh5OuclIrmGCMOLcr5vd27eimDGB8ToMxWxreYSuBV+PGf5bcoEUDDqiHMAX oEGfE9GsXrNgiuuoFCUBy7OIJrTBgay3vK7uMNnd8mGvwksJ8SMIdJ8KBeF1KDrwpN71 DQfL8k6fxkv9hSbXKiC+qgi/um1WtCqy068jh+okYfgPy/ayewwETuBpMVqKj357ZEtN L3RmK00Eq8S0FqAmk6sKRfYaJAUKqjSU6dA7h8Dir/10YrfDnBgpGS1OIf0PTVf3GSsk 4Y2AEX2unYCLfIGdCEattA59hCr3EBu2M1lj3RqbsQP91emzhwknf/d6qzH7Txs4kDJx AOag== X-Gm-Message-State: AE9vXwN2U24bXxoLWpsLtyCzjeVV45SNg9rs0Cj6uHLPnbceF/jIEJm0T4VAITXlzpagozsxW3AarqHCRTh48g== X-Received: by 10.28.153.70 with SMTP id b67mr4082388wme.84.1473438029478; Fri, 09 Sep 2016 09:20:29 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> In-Reply-To: <831t0t83br.fsf@gnu.org> From: Philipp Stephani Date: Fri, 09 Sep 2016 16:20:19 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a114b32cc588099053c15864f X-Spam-Score: 1.9 (+) 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: Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.52 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.52 listed in list.dnswl.org] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.52 listed in wl.mailspike.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 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.9 (+) 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: Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.52 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.52 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.52 listed in wl.mailspike.net] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid --001a114b32cc588099053c15864f Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > Yes. The cursor only become invisible after a focus-out/focus-in event. This isn't surprising given that blink-cursor-mode changes focus-in-hook and focus-out-hook. Probably the bug is hidden somewhere in the complex interaction between the various blink-cursor timers and hooks. --001a114b32cc588099053c15864f Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Fr., 9. Sep. 2016 um 18:07=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Fri, 09 Sep 2016 15:59:02 +0000
> Cc: 24372@debbugs.gnu.org
>
> Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:0= 3 Uhr:
>
>=C2=A0 > From: Philipp Stephani <p.stephani2@gmail.com>= ;
>=C2=A0 > Date: Mon, 05 Sep 2016 21:16:40 +0200
>=C2=A0 >
>=C2=A0 > emacs -Q -eval '(setq blink-cursor-delay 0.0)'
>=C2=A0 >
>=C2=A0 > Move point around in the scratch buffer (e.g. press C-b a c= ouple of
>=C2=A0 > times): the cursor stays visible, as it should be. Then put= the mouse
>=C2=A0 > focus on a different GTK window (not Emacs window), put the= mouse focus
>=C2=A0 > back on Emacs, and move point again: the cursor is hidden, = making it
>=C2=A0 > impossible to see until you stop moving.
>
>=C2=A0 Does it happen even if you wait with cursor motion until after t= he
>=C2=A0 cursor blinks one time, i.e. if you start moving point with the = cursor
>=C2=A0 already visible after Emacs gets focus?
>
> Yes. No matter what state the cursor is in and how often it has alread= y blinked, it becomes invisible when
> moving.

So what is the importance of moving focus out of the Emacs frame and
then back into it?=C2=A0 Is the problem reproducible without that?=C2=A0 Or= are
you saying that focus-out followed by focus-in event somehow changes
the behavior wrt displaying the cursor?

Yes. The cursor only become invisible after a focus-ou= t/focus-in event.
This isn't surprising given that blink-curs= or-mode changes focus-in-hook and focus-out-hook. Probably the bug is hidde= n somewhere in the complex interaction between the various blink-cursor tim= ers and hooks.=C2=A0
--001a114b32cc588099053c15864f-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 16:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147343858131070 (code B ref 24372); Fri, 09 Sep 2016 16:30:02 +0000 Received: (at 24372) by debbugs.gnu.org; 9 Sep 2016 16:29:41 +0000 Received: from localhost ([127.0.0.1]:54825 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOgO-000854-P2 for submit@debbugs.gnu.org; Fri, 09 Sep 2016 12:29:41 -0400 Received: from mail-wm0-f41.google.com ([74.125.82.41]:36564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biOgN-00084p-Mm for 24372@debbugs.gnu.org; Fri, 09 Sep 2016 12:29:40 -0400 Received: by mail-wm0-f41.google.com with SMTP id b187so40593246wme.1 for <24372@debbugs.gnu.org>; Fri, 09 Sep 2016 09:29:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=l3JHG//Mikf1Fm4nR4BypBYxlK9VSGdEOeOsy1vSepE=; b=gOPjC/xv886Rx9OfXfPUqlRmJP4yvDwO1ZrZvYBy6pJ6yGb5SH8pJBetiTJx3r9BYV 57JYjD65wXuTYmCEdL5/zNy7OBo1L3ULSMxtqghNhoZCa77w+faHceF9CIYiok/euQm2 tDf81zD1bLfnzcKPuwDNcQNp/0av3nvKD35/l2XvkO+d7zQsZ/MqTPqnETyRTVMX/LPk OkiHf7XOjQJyaWONOO+Qy6/43455fM6SGq3Z2bVytrupkJ+vsXcsNUvPvnZQ6jFvT1RD A2c/qiDVzo3tQhAMJMtocQbldN/oNt1vTdCk7OoOz3HjnD5SQeUO2PvcSPZWXB4Q/0u0 PdRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=l3JHG//Mikf1Fm4nR4BypBYxlK9VSGdEOeOsy1vSepE=; b=MOkKayXrZfuJUq3Biv0YT0diVNlmQb5fi0aPx4UDesAzyLsJOAHx6tAHWVb7DS6+3Y WWvBKRKfSyHRy3V02H+UBbK/H3VDGC2Yq0laS2Um4htP7dwdrwh2ZNwoXOrqMa2SXfv1 glyO7PuzLJlSa9DBPhNX53nUxx62dEUt8OvqjyjUqA6tC6V15vwetPwnY2tcGX8fGei3 FYZnlkR7FFAt86AIsywWqhDtXnaSP4dckV8rH9/vK8OR0EWU2JCNh91q8fTy48aSYjA4 dMeNKqm+9kqxCw9w2Zpx/tkzOgRZC5OQo/VuTi0X1sNmgO/zC3VHsHQ+7NiEe7oP7cTt Y7Gw== X-Gm-Message-State: AE9vXwP698F+2GhqVdnySz/gQtROvNUod5dilu7KXT9jepQ6gkUdcgeNTrjle1XJ6y8cRXaYq7EAuNOzokFlFg== X-Received: by 10.194.87.169 with SMTP id az9mr4033990wjb.81.1473438574051; Fri, 09 Sep 2016 09:29:34 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> In-Reply-To: From: Philipp Stephani Date: Fri, 09 Sep 2016 16:29:23 +0000 Message-ID: Content-Type: multipart/alternative; boundary=047d7b10c7e7ce0d08053c15a679 X-Spam-Score: 1.9 (+) 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: Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 18:20 Uhr: > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.41 listed in dnsbl.sorbs.net] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.41 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.41 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 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.9 (+) 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: Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 18:20 Uhr: > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.41 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.41 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.41 listed in wl.mailspike.net] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid --047d7b10c7e7ce0d08053c15a679 Content-Type: text/plain; charset=UTF-8 Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 18:20 Uhr: > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > A simpler recipe that doesn't need explicit focus events is emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) (blink-cursor-suspend) (blink-cursor-check))' and then start moving point. --047d7b10c7e7ce0d08053c15a679 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Fr., 9. Sep. 2016 um 18:20=C2=A0Uhr:
Eli Zaretskii &= lt;el= iz@gnu.org> schrieb am Fr., 9. Sep. 2016 um 18:07=C2=A0Uhr:
> From: Ph= ilipp Stephani <p.stephani2@gmail.com>
> Date: Fri, 09 Sep 2016 15:59:02 +0000
> Cc: 24372@debbugs.gnu.org
>
> Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:0= 3 Uhr:
>
>=C2=A0 > From: Philipp Stephani <p.stephani2@gmail.com>= ;
>=C2=A0 > Date: Mon, 05 Sep 2016 21:16:40 +0200
>=C2=A0 >
>=C2=A0 > emacs -Q -eval '(setq blink-cursor-delay 0.0)'
>=C2=A0 >
>=C2=A0 > Move point around in the scratch buffer (e.g. press C-b a c= ouple of
>=C2=A0 > times): the cursor stays visible, as it should be. Then put= the mouse
>=C2=A0 > focus on a different GTK window (not Emacs window), put the= mouse focus
>=C2=A0 > back on Emacs, and move point again: the cursor is hidden, = making it
>=C2=A0 > impossible to see until you stop moving.
>
>=C2=A0 Does it happen even if you wait with cursor motion until after t= he
>=C2=A0 cursor blinks one time, i.e. if you start moving point with the = cursor
>=C2=A0 already visible after Emacs gets focus?
>
> Yes. No matter what state the cursor is in and how often it has alread= y blinked, it becomes invisible when
> moving.

So what is the importance of moving focus out of the Emacs frame and
then back into it?=C2=A0 Is the problem reproducible without that?=C2=A0 Or= are
you saying that focus-out followed by focus-in event somehow changes
the behavior wrt displaying the cursor?

Yes. The cursor only become invisible after a focus-out/fo= cus-in event.
This isn't surprising given= that blink-cursor-mode changes focus-in-hook and focus-out-hook. Probably = the bug is hidden somewhere in the complex interaction between the various = blink-cursor timers and hooks.=C2=A0
A simpler recipe that doesn't need explicit focus events is=

emacs -Q -eval '(progn (setq blink-cursor-del= ay 0.0) (blink-cursor-suspend) (blink-cursor-check))'=C2=A0
<= br>
and then start moving point.
--047d7b10c7e7ce0d08053c15a679-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 17:19:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14734415109548 (code B ref 24372); Fri, 09 Sep 2016 17:19:01 +0000 Received: (at 24372) by debbugs.gnu.org; 9 Sep 2016 17:18:30 +0000 Received: from localhost ([127.0.0.1]:54860 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biPRe-0002Tw-3R for submit@debbugs.gnu.org; Fri, 09 Sep 2016 13:18:30 -0400 Received: from mail-wm0-f45.google.com ([74.125.82.45]:37593) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biPRd-0002Tk-27 for 24372@debbugs.gnu.org; Fri, 09 Sep 2016 13:18:29 -0400 Received: by mail-wm0-f45.google.com with SMTP id w12so44798882wmf.0 for <24372@debbugs.gnu.org>; Fri, 09 Sep 2016 10:18:29 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=kLGB2cI3fE9MVjRurFEp2pJwzTeEIQbD/5qMRR+aQ1s=; b=Fgxk231BAEyGTetw3vZ5L1TU1tDNN4yiaAP+08kDjJ5Io8wN8hG3Fp/xxNhFUwZPuk vmtilb6utJb/0vrCu+DsRrkpbQVP731jSTew/vIfcKAwVfULKK1SbW6P2yViXs2mppSE HzsMMIUnZ2l8ClHNUVnjE7r9ENirPLAWvyiMoNdyq6TLW6s+7LAZKKSKRgvjqgRuj1h4 Ac1u1IOo77Yfd+ej5Mi5vt7n6OfoYr3wrCiGjc9aASWA0NHs7ZNxBNnTpQip8yKiC1AL +c2qO/iOXDj1JDYKQwNtXYCryuK5BpiQdKeDY59KQCO+e7LLg6QZFIo+FNecfUpwjVhK 94zw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=kLGB2cI3fE9MVjRurFEp2pJwzTeEIQbD/5qMRR+aQ1s=; b=SSHDpHQ8zA+OPElYLox8McD9FxRelh+rVHj9GTU5fsGtm2v2Ee1ApqlzcqTSXp5oAm f2Pd1TEBvoUg+ZEuyLEVaIVkev8NMQ8yRdNExV1vTOsljCoGBc39MjYqDq60Pm3SCRLj lpkV5iUOJWqM6u4pLLb1v87c23DqL8Ru51TtOvThKipKoMvnK84hI3/RiunREtJdD0F1 ExT9/uHMgwuHCs17zsKCxKNSrzgmCUv+CjyZHFPqYCdALsswyLExEJ4zc6fbreTXI02w wtPXbj1hYyv584V5kASDj+3bWUwuRU2XZgK8tOX1kF6d01CyezLtiSTNtjIEnyQ1/r9u N//Q== X-Gm-Message-State: AE9vXwPVQcBCnNNh7/NhLrAjbJYq5KY5lcHFFTmtxY+Az16mqAZTDcDCRIvpVoGeRzMuSBi1zO7I3d5BVvRzsQ== X-Received: by 10.28.74.217 with SMTP id n86mr4351938wmi.84.1473441503443; Fri, 09 Sep 2016 10:18:23 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> In-Reply-To: From: Philipp Stephani Date: Fri, 09 Sep 2016 17:18:12 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a114e2e3a690aaf053c1655de X-Spam-Score: 1.9 (+) 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: Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 18:29 Uhr: > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:20 Uhr: > > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving point. > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.45 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.45 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.45 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 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.9 (+) 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: Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 18:29 Uhr: > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:20 Uhr: > > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving point. > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.45 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.45 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.45 listed in wl.mailspike.net] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid --001a114e2e3a690aaf053c1655de Content-Type: text/plain; charset=UTF-8 Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 18:29 Uhr: > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:20 Uhr: > > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving point. > OK, I guess one issue is that setting blink-cursor-delay doesn't restart blink-cursor-idle-timer. (Similarly, changing blink-cursor-interval doesn't restart blink-cursor-timer.) While obviously we can't fix that when using setq, I'd suggest adding custom setters to the variables nevertheless. The direct cause of the issue seems to be that, when blink-cursor-delay is idle, after every command blink-cursor-start is called immediately, which hides the cursor. I guess that is so that in the default case where blink-cursor-delay = blink-cursor-interval the cursor frequency is constant. However, this causes the cursor to be hidden very quickly when blink-cursor-delay < blink-cursor-interval. Maybe in that case blink-cursor-start should show instead of hide the cursor, and run-with-timer should be called with an argument of (blink-cursor-interval - blink-cursor-delay), so that the cursor is at least shown for blink-cursor-interval. WDYT? --001a114e2e3a690aaf053c1655de Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Fr., 9. Sep. 2016 um 18:29=C2=A0Uhr:
Philipp Stephan= i <p.stephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um 1= 8:20=C2=A0Uhr:
Eli Zaretskii <eliz@gnu.org= > schrieb am Fr., 9. Sep. 2016 um 18:07=C2=A0Uhr:
> From: Philipp Stephani= <p.stephani2@gmail.com>
> Date: Fri, 09 Sep 2016 15:59:02 +0000
> Cc: 24372@debbugs.gnu.org
>
> Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:0= 3 Uhr:
>
>=C2=A0 > From: Philipp Stephani <p.stephani2@gmail.com>= ;
>=C2=A0 > Date: Mon, 05 Sep 2016 21:16:40 +0200
>=C2=A0 >
>=C2=A0 > emacs -Q -eval '(setq blink-cursor-delay 0.0)'
>=C2=A0 >
>=C2=A0 > Move point around in the scratch buffer (e.g. press C-b a c= ouple of
>=C2=A0 > times): the cursor stays visible, as it should be. Then put= the mouse
>=C2=A0 > focus on a different GTK window (not Emacs window), put the= mouse focus
>=C2=A0 > back on Emacs, and move point again: the cursor is hidden, = making it
>=C2=A0 > impossible to see until you stop moving.
>
>=C2=A0 Does it happen even if you wait with cursor motion until after t= he
>=C2=A0 cursor blinks one time, i.e. if you start moving point with the = cursor
>=C2=A0 already visible after Emacs gets focus?
>
> Yes. No matter what state the cursor is in and how often it has alread= y blinked, it becomes invisible when
> moving.

So what is the importance of moving focus out of the Emacs frame and
then back into it?=C2=A0 Is the problem reproducible without that?=C2=A0 Or= are
you saying that focus-out followed by focus-in event somehow changes
the behavior wrt displaying the cursor?

Yes. The cursor only become invisible after a focus-out/fo= cus-in event.
This isn't surprising given= that blink-cursor-mode changes focus-in-hook and focus-out-hook. Probably = the bug is hidden somewhere in the complex interaction between the various = blink-cursor timers and hooks.=C2=A0

A simpler recipe that doesn't need explicit focus events is

emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) (blink-curs= or-suspend) (blink-cursor-check))'=C2=A0
=
and then start movin= g point.

OK, I guess one = issue is that setting blink-cursor-delay doesn't restart blink-cursor-i= dle-timer. (Similarly, changing blink-cursor-interval doesn't restart b= link-cursor-timer.) While obviously we can't fix that when using setq, = I'd suggest adding custom setters to the variables nevertheless.
<= div>
The direct cause of the issue seems to be that, when bli= nk-cursor-delay is idle, after every command blink-cursor-start is called i= mmediately, which hides the cursor. I guess that is so that in the default = case where blink-cursor-delay =3D blink-cursor-interval the cursor frequenc= y is constant. However, this causes the cursor to be hidden very quickly wh= en blink-cursor-delay < blink-cursor-interval. Maybe in that case blink-= cursor-start should show instead of hide the cursor, and run-with-timer sho= uld be called with an argument of (blink-cursor-interval - blink-cursor-del= ay), so that the cursor is at least shown for blink-cursor-interval. WDYT?= =C2=A0
--001a114e2e3a690aaf053c1655de-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 09 Sep 2016 19:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147344760925369 (code B ref 24372); Fri, 09 Sep 2016 19:01:02 +0000 Received: (at 24372) by debbugs.gnu.org; 9 Sep 2016 19:00:09 +0000 Received: from localhost ([127.0.0.1]:54885 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biR20-0006b7-SY for submit@debbugs.gnu.org; Fri, 09 Sep 2016 15:00:09 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:37617) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1biR1y-0006Zg-Ve for 24372@debbugs.gnu.org; Fri, 09 Sep 2016 15:00:07 -0400 Received: by mail-wm0-f48.google.com with SMTP id w12so48925370wmf.0 for <24372@debbugs.gnu.org>; Fri, 09 Sep 2016 12:00:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=jAYM+7VlqB21UIhWCE/BCsbctiaF2tV4R+5t3CnDUNU=; b=dBlhGkWzA/3gzkKLCrMHfGYoc6A5InLRO5Z8+4gXElUatIzbBxnQQjFmQQP6NxEGhf MCe1wL+UK9cUZV2MR4X+KNMHCiB3uI18TtLOWK3zSdlCMr4dHxJDbEV9vlaW2ZtqXLaY 8YXBuFC04EHOYRFfQ4mFC+YilRPAUPU2vD1FHorkwp9V6H8bRCQtSbThs/yNk5hmRvD9 9xaOUtMGLn+ynLYHWYYOGzEINVWzhZlgwvTB+oskEHQOBAoYibFatesSHM9LFnixZjVa VDvKNYqHPi9sxHNCOpun8izfEscrX96JwpCSfRDarMN/NElSx9PoxAvMQe5Io+SHaVJW CtMQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=jAYM+7VlqB21UIhWCE/BCsbctiaF2tV4R+5t3CnDUNU=; b=iFIbuqHsxY6VsTyKOMQXQbymBOhzhwZ5LsePYADx/wldT5qlj+CHKoptePKhZCuPOQ EyQVuY8cf9LLQq16KShJIxrmTyGZnweB08gIWa0iuVfShTi4oNl6JENDGWz6AQerrT9x kbml8IJWATPYr2YaGV40E77LOXKK2ECgF79YxpL6PklM1qmZTbMV3PO5I6O3/cnuJYnQ lA0BZMu0ai4GMPmf8XyfheBTl7V76jeS9Rw4un35H5FSHBHHxLWVkgwHvJLPxJxWRpAa GmxzqMMMBr23y1UFrLbGv8n6B3FkE3jKNprpxHXjDcC84ckeZf97CUQbHo7birVZt1c0 gCPw== X-Gm-Message-State: AE9vXwNOzMCg01c8EK3sP/++LKlCLkPt4hFdTpNs+BopdN8gINcQPfb8eZ+BunlDsPq+7TQ9Xe1ny3RqrtMuHQ== X-Received: by 10.28.153.70 with SMTP id b67mr4718113wme.84.1473447600992; Fri, 09 Sep 2016 12:00:00 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> In-Reply-To: From: Philipp Stephani Date: Fri, 09 Sep 2016 18:59:50 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a114b32ccda37e8053c17c064 X-Spam-Score: 1.9 (+) 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: Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 19:18 Uhr: > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:29 Uhr: > > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:20 Uhr: > > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.48 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.48 listed in list.dnswl.org] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.48 listed in wl.mailspike.net] 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 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.9 (+) 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: Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 19:18 Uhr: > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:29 Uhr: > > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:20 Uhr: > > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.48 listed in dnsbl.sorbs.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.48 listed in list.dnswl.org] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.48 listed in wl.mailspike.net] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid --001a114b32ccda37e8053c17c064 Content-Type: text/plain; charset=UTF-8 Philipp Stephani schrieb am Fr., 9. Sep. 2016 um 19:18 Uhr: > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:29 Uhr: > > Philipp Stephani schrieb am Fr., 9. Sep. 2016 um > 18:20 Uhr: > > Eli Zaretskii schrieb am Fr., 9. Sep. 2016 um 18:07 Uhr: > > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 15:59:02 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Eli Zaretskii schrieb am Di., 6. Sep. 2016 um 18:03 Uhr: > > > > > From: Philipp Stephani > > > Date: Mon, 05 Sep 2016 21:16:40 +0200 > > > > > > emacs -Q -eval '(setq blink-cursor-delay 0.0)' > > > > > > Move point around in the scratch buffer (e.g. press C-b a couple of > > > times): the cursor stays visible, as it should be. Then put the mouse > > > focus on a different GTK window (not Emacs window), put the mouse > focus > > > back on Emacs, and move point again: the cursor is hidden, making it > > > impossible to see until you stop moving. > > > > Does it happen even if you wait with cursor motion until after the > > cursor blinks one time, i.e. if you start moving point with the cursor > > already visible after Emacs gets focus? > > > > Yes. No matter what state the cursor is in and how often it has already > blinked, it becomes invisible when > > moving. > > So what is the importance of moving focus out of the Emacs frame and > then back into it? Is the problem reproducible without that? Or are > you saying that focus-out followed by focus-in event somehow changes > the behavior wrt displaying the cursor? > > > Yes. The cursor only become invisible after a focus-out/focus-in event. > This isn't surprising given that blink-cursor-mode changes focus-in-hook > and focus-out-hook. Probably the bug is hidden somewhere in the complex > interaction between the various blink-cursor timers and hooks. > > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving point. > > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart > blink-cursor-idle-timer. (Similarly, changing blink-cursor-interval doesn't > restart blink-cursor-timer.) While obviously we can't fix that when using > setq, I'd suggest adding custom setters to the variables nevertheless. > > The direct cause of the issue seems to be that, when blink-cursor-delay is > idle, after every command blink-cursor-start is called immediately, which > hides the cursor. I guess that is so that in the default case where > blink-cursor-delay = blink-cursor-interval the cursor frequency is > constant. However, this causes the cursor to be hidden very quickly when > blink-cursor-delay < blink-cursor-interval. Maybe in that case > blink-cursor-start should show instead of hide the cursor, and > run-with-timer should be called with an argument of (blink-cursor-interval > - blink-cursor-delay), so that the cursor is at least shown for > blink-cursor-interval. WDYT? > I just realized that this is equivalent to treating blink-cursor-interval as a lower bound to blink-cursor-delay. Not sure whether that's the intention of blink-cursor-delay. --001a114b32ccda37e8053c17c064 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Fr., 9. Sep. 2016 um 19:18=C2=A0Uhr:
Philipp Stephan= i <p.stephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um 1= 8:29=C2=A0Uhr:
Philipp Stephani <p.s= tephani2@gmail.com> schrieb am Fr., 9. Sep. 2016 um 18:20=C2=A0Uhr:<= br class=3D"gmail_msg">
Eli Zaretskii <eliz@gnu.org> schrieb am= Fr., 9. Sep. 2016 um 18:07=C2=A0Uhr:
> From: Philipp Stephani <p.step= hani2@gmail.com>
> Date: Fri, 09 Sep 2016 15:59:02 +0000
> Cc: 24372@debbugs.gnu.org
>
> Eli Zaretskii <eliz@gnu.org> schrieb am Di., 6. Sep. 2016 um 18:0= 3 Uhr:
>
>=C2=A0 > From: Philipp Stephani <p.stephani2@gmail.com>= ;
>=C2=A0 > Date: Mon, 05 Sep 2016 21:16:40 +0200
>=C2=A0 >
>=C2=A0 > emacs -Q -eval '(setq blink-cursor-delay 0.0)'
>=C2=A0 >
>=C2=A0 > Move point around in the scratch buffer (e.g. press C-b a c= ouple of
>=C2=A0 > times): the cursor stays visible, as it should be. Then put= the mouse
>=C2=A0 > focus on a different GTK window (not Emacs window), put the= mouse focus
>=C2=A0 > back on Emacs, and move point again: the cursor is hidden, = making it
>=C2=A0 > impossible to see until you stop moving.
>
>=C2=A0 Does it happen even if you wait with cursor motion until after t= he
>=C2=A0 cursor blinks one time, i.e. if you start moving point with the = cursor
>=C2=A0 already visible after Emacs gets focus?
>
> Yes. No matter what state the cursor is in and how often it has alread= y blinked, it becomes invisible when
> moving.

So what is the importance of moving focus out of the Emacs frame and
then back into it?=C2=A0 Is the problem reproducible without that?=C2=A0 Or= are
you saying that focus-out followed by focus-in event somehow changes
the behavior wrt displaying the cursor?

Yes. The cursor only become invisible after a focus-out/fo= cus-in event.
This isn't surprising given= that blink-cursor-mode changes focus-in-hook and focus-out-hook. Probably = the bug is hidden somewhere in the complex interaction between the various = blink-cursor timers and hooks.=C2=A0

A simpler recipe that doesn't need explicit focus events is

emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) (blink-curs= or-suspend) (blink-cursor-check))'=C2=A0
=
and then start movin= g point.

OK, I guess one is= sue is that setting blink-cursor-delay doesn't restart blink-cursor-idl= e-timer. (Similarly, changing blink-cursor-interval doesn't restart bli= nk-cursor-timer.) While obviously we can't fix that when using setq, I&= #39;d suggest adding custom setters to the variables nevertheless.

The direct cause of the issue seems to be that, when blink-cursor-delay i= s idle, after every command blink-cursor-start is called immediately, which= hides the cursor. I guess that is so that in the default case where blink-= cursor-delay =3D blink-cursor-interval the cursor frequency is constant. Ho= wever, this causes the cursor to be hidden very quickly when blink-cursor-d= elay < blink-cursor-interval. Maybe in that case blink-cursor-start shou= ld show instead of hide the cursor, and run-with-timer should be called wit= h an argument of (blink-cursor-interval - blink-cursor-delay), so that the = cursor is at least shown for blink-cursor-interval. WDYT?=C2=A0
=

I just realized that this is equival= ent to treating blink-cursor-interval as a lower bound to blink-cursor-dela= y. Not sure whether that's the intention of blink-cursor-delay.
--001a114b32ccda37e8053c17c064-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 10 Sep 2016 07:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14734921084093 (code B ref 24372); Sat, 10 Sep 2016 07:22:01 +0000 Received: (at 24372) by debbugs.gnu.org; 10 Sep 2016 07:21:48 +0000 Received: from localhost ([127.0.0.1]:55098 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bicbk-00013x-4x for submit@debbugs.gnu.org; Sat, 10 Sep 2016 03:21:48 -0400 Received: from eggs.gnu.org ([208.118.235.92]:37783) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bicbi-00013k-Nn for 24372@debbugs.gnu.org; Sat, 10 Sep 2016 03:21:47 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bicba-00079d-Du for 24372@debbugs.gnu.org; Sat, 10 Sep 2016 03:21: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=-1.3 required=5.0 tests=BAYES_40,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:56733) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bicba-00078Q-AX; Sat, 10 Sep 2016 03:21:38 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1928 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bicbW-0001jC-FG; Sat, 10 Sep 2016 03:21:35 -0400 Date: Sat, 10 Sep 2016 10:21:33 +0300 Message-Id: <83mvjg8bk2.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Fri, 09 Sep 2016 17:18:12 +0000) References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -6.3 (------) 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: -6.3 (------) > From: Philipp Stephani > Date: Fri, 09 Sep 2016 17:18:12 +0000 > Cc: 24372@debbugs.gnu.org > > A simpler recipe that doesn't need explicit focus events is > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) (blink-cursor-suspend) (blink-cursor-check))' > > and then start moving point. > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart blink-cursor-idle-timer. (Similarly, > changing blink-cursor-interval doesn't restart blink-cursor-timer.) While obviously we can't fix that when using > setq, I'd suggest adding custom setters to the variables nevertheless. > > The direct cause of the issue seems to be that, when blink-cursor-delay is idle, after every command > blink-cursor-start is called immediately, which hides the cursor. Thanks. Does the patch below fix the issue, without introducing any adverse side effects? diff --git a/lisp/frame.el b/lisp/frame.el index cfd40bf..e10f0ce 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -2068,7 +2068,10 @@ blink-cursor-start (run-with-timer blink-cursor-interval blink-cursor-interval 'blink-cursor-timer-function)) (add-hook 'pre-command-hook 'blink-cursor-end) - (internal-show-cursor nil nil))) + ;; Start by showing the cursor, so that even if they set + ;; blink-cursor-delay to zero, they still see the cursor during + ;; the execution of the Emacs commands. + (internal-show-cursor nil t))) (defun blink-cursor-timer-function () "Timer function of timer `blink-cursor-timer'." From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 09:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147358537022579 (code B ref 24372); Sun, 11 Sep 2016 09:17:02 +0000 Received: (at 24372) by debbugs.gnu.org; 11 Sep 2016 09:16:10 +0000 Received: from localhost ([127.0.0.1]:55906 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj0rx-0005s6-Ed for submit@debbugs.gnu.org; Sun, 11 Sep 2016 05:16:10 -0400 Received: from mail-wm0-f51.google.com ([74.125.82.51]:38205) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj0ru-0005rK-Ui for 24372@debbugs.gnu.org; Sun, 11 Sep 2016 05:16:07 -0400 Received: by mail-wm0-f51.google.com with SMTP id 1so98339134wmz.1 for <24372@debbugs.gnu.org>; Sun, 11 Sep 2016 02:16:06 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=o4sFmipW8mnABAuS2/n5NLE1t9i7sIIRta7ZkNj3SJE=; b=Tp45tHDmVvTEB8lT9Xrwt2jmw/Zco+7sdI3YpAbCYWwpU+B/vvxMbUb9j9Po78ERGw Ia/faguuywLXHMtEmGgfxB357DHGj0hRskkLL/45lSdaPEoPvObKmF2DOvzIVIcNC3Dy dk6H88+MzrorBbDz3rlcBaoDmdCt/OWtYh4uzZjjit3G7Pc+6vyjwAhe6NYlVHqyTTyl ZXIF9cqiFC1Am5nQbhINyINbtY/4+FmO9Xf8QtnGGD3seWCOR8la9hl0bry4W6qi06jW 8JtwjSwiP0h3Cvz8PrhnptuelMRCFFjq4ilrqY5YGXdqUbsa3XIH2QufqBiEJPjWWbRD l1+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=o4sFmipW8mnABAuS2/n5NLE1t9i7sIIRta7ZkNj3SJE=; b=RxtjiRi8jtZuOjvzIaMF5qFEPZbHih56peVxQYzr99Jz+aj0KXBjPxOTf/Dou76rBP Ro2dq5O9YthU/WSJz564Bhk90Ie3r1O99+w6t3SyP5KqeK1GjlNGhnpZk53HubkIv8ML O4vzk1p/5MlvC3cLXJm/N2w2IDLoM2iwTjKS7dBwWYwwQARVsp6nIXq8ZRaEv3A/SEdN X5bn7su6vqXZ3/4HK5vVJtDqdHlg/HSNkMlNmeNbNUz1xP8ZlLeG5XWiI4Z9MFMdwZeG brdB90tCkjQ1O67vPbmd/yHfY733BuE+rOr/Ph8Cz1oB7nNVxLMTNuDqNxapRJuMD+pe sZ/w== X-Gm-Message-State: AE9vXwPNa+T8doNaDI3Q3Je+VYMMsBMtYZ+7WiBHY16kTCk/7IRTF84cvqyZsjd59+mRFnap24jn3+BodPoJbg== X-Received: by 10.28.22.6 with SMTP id 6mr5953477wmw.55.1473585361066; Sun, 11 Sep 2016 02:16:01 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> In-Reply-To: <83mvjg8bk2.fsf@gnu.org> From: Philipp Stephani Date: Sun, 11 Sep 2016 09:15:49 +0000 Message-ID: Content-Type: multipart/mixed; boundary=001a114702a4ffa88b053c37d3bd X-Spam-Score: 1.9 (+) 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: Eli Zaretskii schrieb am Sa., 10. Sep. 2016 um 09:21 Uhr: > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 17:18:12 +0000 > > Cc: 24372@debbugs.gnu.org > > > > A simpler recipe that doesn't need explicit focus events is > > > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > > > and then start moving point. > > > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart > blink-cursor-idle-timer. (Similarly, > > changing blink-cursor-interval doesn't restart blink-cursor-timer.) > While obviously we can't fix that when using > > setq, I'd suggest adding custom setters to the variables nevertheless. > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.51 listed in list.dnswl.org] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.51 listed in wl.mailspike.net] 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.51 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid 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.9 (+) 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: Eli Zaretskii schrieb am Sa., 10. Sep. 2016 um 09:21 Uhr: > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 17:18:12 +0000 > > Cc: 24372@debbugs.gnu.org > > > > A simpler recipe that doesn't need explicit focus events is > > > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > > > and then start moving point. > > > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart > blink-cursor-idle-timer. (Similarly, > > changing blink-cursor-interval doesn't restart blink-cursor-timer.) > While obviously we can't fix that when using > > setq, I'd suggest adding custom setters to the variables nevertheless. > [...] Content analysis details: (1.9 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 2.4 RCVD_IN_SORBS_SPAM RBL: SORBS: sender is a spam source [74.125.82.51 listed in dnsbl.sorbs.net] -0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [74.125.82.51 listed in wl.mailspike.net] -0.7 RCVD_IN_DNSWL_LOW RBL: Sender listed at http://www.dnswl.org/, low trust [74.125.82.51 listed in list.dnswl.org] 0.2 FREEMAIL_ENVFROM_END_DIGIT Envelope-from freemail username ends in digit (p.stephani2[at]gmail.com) -0.0 SPF_PASS SPF: sender matches SPF record 0.0 FREEMAIL_FROM Sender email is commonly abused enduser mail provider (p.stephani2[at]gmail.com) 0.0 HTML_MESSAGE BODY: HTML included in message -0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.0 T_DKIM_INVALID DKIM-Signature header exists but is not valid --001a114702a4ffa88b053c37d3bd Content-Type: multipart/alternative; boundary=001a114702a4ffa886053c37d3bb --001a114702a4ffa886053c37d3bb Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Sa., 10. Sep. 2016 um 09:21 Uhr: > > From: Philipp Stephani > > Date: Fri, 09 Sep 2016 17:18:12 +0000 > > Cc: 24372@debbugs.gnu.org > > > > A simpler recipe that doesn't need explicit focus events is > > > > emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) > (blink-cursor-suspend) (blink-cursor-check))' > > > > and then start moving point. > > > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart > blink-cursor-idle-timer. (Similarly, > > changing blink-cursor-interval doesn't restart blink-cursor-timer.) > While obviously we can't fix that when using > > setq, I'd suggest adding custom setters to the variables nevertheless. > I've attached a patch for this. It shouldn't be controversial because it only reduces the possibility for surprises, but doesn't change any behavior. > > > > The direct cause of the issue seems to be that, when blink-cursor-delay > is idle, after every command > > blink-cursor-start is called immediately, which hides the cursor. > > Thanks. Does the patch below fix the issue, without introducing any > adverse side effects? > > It does introduce the adverse side effect that now the first blink takes one second (the sum of cursor-blink-delay and cursor-blink-interval). I've attached another patch with the change I have in mind. --001a114702a4ffa886053c37d3bb Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Sa., 10. Sep. 2016 um 09:21=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Fri, 09 Sep 2016 17:18:12 +0000
> Cc: 24372@debbugs.gnu.org
>
>=C2=A0 A simpler recipe that doesn't need explicit focus events is<= br class=3D"gmail_msg"> >
>=C2=A0 emacs -Q -eval '(progn (setq blink-cursor-delay 0.0) (blink-= cursor-suspend) (blink-cursor-check))'
>
>=C2=A0 and then start moving point.
>
> OK, I guess one issue is that setting blink-cursor-delay doesn't r= estart blink-cursor-idle-timer. (Similarly,
> changing blink-cursor-interval doesn't restart blink-cursor-timer.= ) While obviously we can't fix that when using
> setq, I'd suggest adding custom setters to the variables neverthel= ess.

I've attac= hed a patch for this. It shouldn't be controversial because it only red= uces the possibility for surprises, but doesn't change any behavior.
=C2=A0
>
> The direct cause of the issue seems to be that, when blink-cursor-dela= y is idle, after every command
> blink-cursor-start is called immediately, which hides the cursor.

Thanks.=C2=A0 Does the patch below fix the issue, without introducing any adverse side effects?


It does introduce = the adverse side effect that now the first blink takes one second (the sum = of cursor-blink-delay and cursor-blink-interval). I've attached another= patch with the change I have in mind.
--001a114702a4ffa886053c37d3bb-- --001a114702a4ffa88b053c37d3bd Content-Type: application/octet-stream; name="0001-Avoid-hiding-the-blinking-cursor-too-fast.patch" Content-Disposition: attachment; filename="0001-Avoid-hiding-the-blinking-cursor-too-fast.patch" Content-Transfer-Encoding: base64 Content-ID: <1571886fd3213c081c51> X-Attachment-Id: 1571886fd3213c081c51 RnJvbSAwOTU5MjAwMjk4MDZiMWM1OTljOTYxODgxODEwNWUyMmUyNTMyMWY1IE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh dGU6IFN1biwgMTEgU2VwIDIwMTYgMTE6MDc6MTggKzAyMDAKU3ViamVjdDogW1BBVENIXSBBdm9p ZCBoaWRpbmcgdGhlIGJsaW5raW5nIGN1cnNvciB0b28gZmFzdAoKSWYgYGJsaW5rLWN1cnNvci1k ZWxheScgaXMgc21hbGxlciB0aGFuIGBibGluay1jdXJzb3ItZGVsYXknLCB0aGUgY3Vyc29yCmlz IGhpZGRlbiB0byBxdWlja2x5IGFmdGVyIGEgY29tbWFuZDsgc2VlIEJ1ZyMyNDM3Mi4gIFRoaXMg Y2hhbmdlIHVzZXMKYGJsaW5rLWN1cnNvci1pbnRlcnZhbCcgYXMgbG93ZXIgYm91bmQgZm9yIGBi bGluay1jdXJzb3ItZGVsYXknLgoKKiBsaXNwL2ZyYW1lLmVsIChibGluay1jdXJzb3ItY2hlY2ss IGJsaW5rLWN1cnNvci1tb2RlKTogVXNlCmBibGluay1jdXJzb3ItaW50ZXJ2YWwnIGFzIGxvd2Vy IGJvdW5kIHRvIGBibGluay1jdXJzb3ItZGVsYXknLgooYmxpbmstY3Vyc29yLWRlbGF5KTogRG9j dW1lbnQgY2hhbmdlZCBiZWhhdmlvciBvZgpgYmxpbmstY3Vyc29yLWRlbGF5Jy4KLS0tCiBsaXNw L2ZyYW1lLmVsIHwgMTYgKysrKysrKysrLS0tLS0tLQogMSBmaWxlIGNoYW5nZWQsIDkgaW5zZXJ0 aW9ucygrKSwgNyBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9saXNwL2ZyYW1lLmVsIGIvbGlz cC9mcmFtZS5lbAppbmRleCBjZmQ0MGJmLi5lYmM1Y2MxIDEwMDY0NAotLS0gYS9saXNwL2ZyYW1l LmVsCisrKyBiL2xpc3AvZnJhbWUuZWwKQEAgLTIwMjcsNyArMjAyNywxMSBAQCBjdXJzb3IKICAg Omdyb3VwICdmcmFtZXMpCiAKIChkZWZjdXN0b20gYmxpbmstY3Vyc29yLWRlbGF5IDAuNQotICAi U2Vjb25kcyBvZiBpZGxlIHRpbWUgYWZ0ZXIgd2hpY2ggY3Vyc29yIHN0YXJ0cyB0byBibGluay4i CisgICJTZWNvbmRzIG9mIGlkbGUgdGltZSBhZnRlciB3aGljaCBjdXJzb3Igc3RhcnRzIHRvIGJs aW5rLgorVGhpcyBpcyB0aGUgaW50ZXJ2YWwgYmV0d2VlbiB0aGUgZW5kIG9mIGFuIHVzZXIgYWN0 aW9uIGFuZCB0aGUKK3RpbWUgd2hlbiB0aGUgY3Vyc29yIGZpcnN0IGJlY29tZXMgaW52aXNpYmxl IGR1ZSB0byBibGlua2luZy4gIElmCit0aGlzIGlzIHNob3J0ZXIgdGhhbiBgYmxpbmstY3Vyc29y LWludGVydmFsJywgdGhlIHZhbHVlIG9mCitgYmxpbmstY3Vyc29yLWludGVydmFsJyBpcyB1c2Vk IGluc3RlYWQuIgogICA6dHlwZSAnbnVtYmVyCiAgIDpncm91cCAnY3Vyc29yKQogCkBAIC0yMTE0 LDkgKzIxMTgsOCBAQCBibGluay1jdXJzb3ItY2hlY2sKIAkgICAgIChub3QgYmxpbmstY3Vyc29y LWlkbGUtdGltZXIpKQogICAgIChyZW1vdmUtaG9vayAncG9zdC1jb21tYW5kLWhvb2sgJ2JsaW5r LWN1cnNvci1jaGVjaykKICAgICAoc2V0cSBibGluay1jdXJzb3ItaWRsZS10aW1lcgotICAgICAg ICAgIChydW4td2l0aC1pZGxlLXRpbWVyIGJsaW5rLWN1cnNvci1kZWxheQotICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgIGJsaW5rLWN1cnNvci1kZWxheQotICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICdibGluay1jdXJzb3Itc3RhcnQpKSkpCisgICAgICAgICAgKGxldCAoKGRl bGF5IChtYXggYmxpbmstY3Vyc29yLWRlbGF5IGJsaW5rLWN1cnNvci1pbnRlcnZhbCkpKQorICAg ICAgICAgICAgKHJ1bi13aXRoLWlkbGUtdGltZXIgZGVsYXkgZGVsYXkgIydibGluay1jdXJzb3It c3RhcnQpKSkpKQogCiAoZGVmaW5lLW9ic29sZXRlLXZhcmlhYmxlLWFsaWFzICdibGluay1jdXJz b3IgJ2JsaW5rLWN1cnNvci1tb2RlICIyMi4xIikKIApAQCAtMjE0OCw5ICsyMTUxLDggQEAgYmxp bmstY3Vyc29yLW1vZGUKICAgICAoYWRkLWhvb2sgJ2ZvY3VzLWluLWhvb2sgIydibGluay1jdXJz b3ItY2hlY2spCiAgICAgKGFkZC1ob29rICdmb2N1cy1vdXQtaG9vayAjJ2JsaW5rLWN1cnNvci1z dXNwZW5kKQogICAgIChzZXRxIGJsaW5rLWN1cnNvci1pZGxlLXRpbWVyCi0gICAgICAgICAgKHJ1 bi13aXRoLWlkbGUtdGltZXIgYmxpbmstY3Vyc29yLWRlbGF5Ci0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgYmxpbmstY3Vyc29yLWRlbGF5Ci0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgIydibGluay1jdXJzb3Itc3RhcnQpKSkpCisgICAgICAgICAgKGxldCAoKGRlbGF5ICht YXggYmxpbmstY3Vyc29yLWRlbGF5IGJsaW5rLWN1cnNvci1pbnRlcnZhbCkpKQorICAgICAgICAg ICAgKHJ1bi13aXRoLWlkbGUtdGltZXIgZGVsYXkgZGVsYXkgIydibGluay1jdXJzb3Itc3RhcnQp KSkpKQogCiAMCiA7OyBGcmFtZSBtYXhpbWl6YXRpb24vZnVsbHNjcmVlbgotLSAKMi45LjAKCg== --001a114702a4ffa88b053c37d3bd Content-Type: application/octet-stream; name="0001-Restart-blink-cursor-timers-on-interval-changes.patch" Content-Disposition: attachment; filename="0001-Restart-blink-cursor-timers-on-interval-changes.patch" Content-Transfer-Encoding: base64 Content-ID: <1571887ef0c652a84c02> X-Attachment-Id: 1571887ef0c652a84c02 RnJvbSAwNjQ0NWIzZTZmZWU0YWIxYzY4MGFiNGQ5YWVkYjc1ZWRkZjg1MzUyIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh dGU6IFNhdCwgMTAgU2VwIDIwMTYgMTA6MTY6MzIgKzAyMDAKU3ViamVjdDogW1BBVENIXSBSZXN0 YXJ0IGJsaW5rIGN1cnNvciB0aW1lcnMgb24gaW50ZXJ2YWwgY2hhbmdlcwoKVGhpcyBwcmV2ZW50 cyBzdXJwcmlzaW5nIGJlaGF2aW9yIHdoZW4gdGltZXIgaW50ZXJ2YWwgY3VzdG9taXphdGlvbnMg YXJlCm9ubHkgYXBwbGllZCB3aGVuZXZlciB0aGUgdGltZXJzIGhhcHBlbiB0byBiZSByZXN0YXJ0 ZWQgKHNlZSBCdWcjMjQzNzIpLgoKKiBsaXNwL2ZyYW1lLmVsIChibGluay1jdXJzb3ItLXN0YXJ0 LWlkbGUtdGltZXIpCihibGluay1jdXJzb3ItLXN0YXJ0LXRpbWVyKTogTmV3IGZ1bmN0aW9ucy4K KGJsaW5rLWN1cnNvci1zdGFydCwgYmxpbmstY3Vyc29yLWNoZWNrLCBibGluay1jdXJzb3ItbW9k ZSk6IFVzZQp0aGUgbmV3IGhlbHBlciBmdW5jdGlvbnMuCihibGluay1jdXJzb3ItZGVsYXksIGJs aW5rLWN1cnNvci1pbnRlcnZhbCk6IFJlc3RhcnQgdGltZXJzIHdoZW4KdGhlIHZhbHVlIGlzIGNo YW5nZWQuCi0tLQogbGlzcC9mcmFtZS5lbCB8IDM4ICsrKysrKysrKysrKysrKysrKysrKysrKyst LS0tLS0tLS0tLS0tCiAxIGZpbGUgY2hhbmdlZCwgMjUgaW5zZXJ0aW9ucygrKSwgMTMgZGVsZXRp b25zKC0pCgpkaWZmIC0tZ2l0IGEvbGlzcC9mcmFtZS5lbCBiL2xpc3AvZnJhbWUuZWwKaW5kZXgg Y2ZkNDBiZi4uYjMyYmE3YSAxMDA2NDQKLS0tIGEvbGlzcC9mcmFtZS5lbAorKysgYi9saXNwL2Zy YW1lLmVsCkBAIC0yMDI5LDEyICsyMDI5LDE4IEBAIGN1cnNvcgogKGRlZmN1c3RvbSBibGluay1j dXJzb3ItZGVsYXkgMC41CiAgICJTZWNvbmRzIG9mIGlkbGUgdGltZSBhZnRlciB3aGljaCBjdXJz b3Igc3RhcnRzIHRvIGJsaW5rLiIKICAgOnR5cGUgJ251bWJlcgotICA6Z3JvdXAgJ2N1cnNvcikK KyAgOmdyb3VwICdjdXJzb3IKKyAgOnNldCAobGFtYmRhIChzeW1ib2wgdmFsdWUpCisgICAgICAg ICAoc2V0LWRlZmF1bHQgc3ltYm9sIHZhbHVlKQorICAgICAgICAgKHdoZW4gYmxpbmstY3Vyc29y LWlkbGUtdGltZXIgKGJsaW5rLWN1cnNvci0tc3RhcnQtaWRsZS10aW1lcikpKSkKIAogKGRlZmN1 c3RvbSBibGluay1jdXJzb3ItaW50ZXJ2YWwgMC41CiAgICJMZW5ndGggb2YgY3Vyc29yIGJsaW5r IGludGVydmFsIGluIHNlY29uZHMuIgogICA6dHlwZSAnbnVtYmVyCi0gIDpncm91cCAnY3Vyc29y KQorICA6Z3JvdXAgJ2N1cnNvcgorICA6c2V0IChsYW1iZGEgKHN5bWJvbCB2YWx1ZSkKKyAgICAg ICAgIChzZXQtZGVmYXVsdCBzeW1ib2wgdmFsdWUpCisgICAgICAgICAod2hlbiBibGluay1jdXJz b3ItdGltZXIgKGJsaW5rLWN1cnNvci0tc3RhcnQtdGltZXIpKSkpCiAKIChkZWZjdXN0b20gYmxp bmstY3Vyc29yLWJsaW5rcyAxMAogICAiSG93IG1hbnkgdGltZXMgdG8gYmxpbmsgYmVmb3JlIHVz aW5nIGEgc29saWQgY3Vyc29yIG9uIE5TLCBYLCBhbmQgTVMtV2luZG93cy4KQEAgLTIwNTUsNiAr MjA2MSwyMCBAQCBibGluay1jdXJzb3ItdGltZXIKIFRoaXMgdGltZXIgY2FsbHMgYGJsaW5rLWN1 cnNvci10aW1lci1mdW5jdGlvbicgZXZlcnkKIGBibGluay1jdXJzb3ItaW50ZXJ2YWwnIHNlY29u ZHMuIikKIAorKGRlZnVuIGJsaW5rLWN1cnNvci0tc3RhcnQtaWRsZS10aW1lciAoKQorICAiU3Rh cnQgdGhlIGBibGluay1jdXJzb3ItaWRsZS10aW1lcicuIgorICAod2hlbiBibGluay1jdXJzb3It aWRsZS10aW1lciAoY2FuY2VsLXRpbWVyIGJsaW5rLWN1cnNvci1pZGxlLXRpbWVyKSkKKyAgKHNl dHEgYmxpbmstY3Vyc29yLWlkbGUtdGltZXIKKyAgICAgICAgKHJ1bi13aXRoLWlkbGUtdGltZXIg YmxpbmstY3Vyc29yLWRlbGF5IGJsaW5rLWN1cnNvci1kZWxheQorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAjJ2JsaW5rLWN1cnNvci1zdGFydCkpKQorCisoZGVmdW4gYmxpbmstY3Vyc29y LS1zdGFydC10aW1lciAoKQorICAiU3RhcnQgdGhlIGBibGluay1jdXJzb3ItdGltZXInLiIKKyAg KHdoZW4gYmxpbmstY3Vyc29yLXRpbWVyIChjYW5jZWwtdGltZXIgYmxpbmstY3Vyc29yLXRpbWVy KSkKKyAgKHNldHEgYmxpbmstY3Vyc29yLXRpbWVyCisgICAgICAgIChydW4td2l0aC10aW1lciBi bGluay1jdXJzb3ItaW50ZXJ2YWwgYmxpbmstY3Vyc29yLWludGVydmFsCisgICAgICAgICAgICAg ICAgICAgICAgICAjJ2JsaW5rLWN1cnNvci10aW1lci1mdW5jdGlvbikpKQorCiAoZGVmdW4gYmxp bmstY3Vyc29yLXN0YXJ0ICgpCiAgICJUaW1lciBmdW5jdGlvbiBjYWxsZWQgZnJvbSB0aGUgdGlt ZXIgYGJsaW5rLWN1cnNvci1pZGxlLXRpbWVyJy4KIFRoaXMgc3RhcnRzIHRoZSB0aW1lciBgYmxp bmstY3Vyc29yLXRpbWVyJywgd2hpY2ggbWFrZXMgdGhlIGN1cnNvciBibGluawpAQCAtMjA2NCw5 ICsyMDg0LDcgQEAgYmxpbmstY3Vyc29yLXN0YXJ0CiAgICAgOzsgU2V0IHVwIHRoZSB0aW1lciBm aXJzdCwgc28gdGhhdCBpZiB0aGlzIHNpZ25hbHMgYW4gZXJyb3IsCiAgICAgOzsgYmxpbmstY3Vy c29yLWVuZCBpcyBub3QgYWRkZWQgdG8gcHJlLWNvbW1hbmQtaG9vay4KICAgICAoc2V0cSBibGlu ay1jdXJzb3ItYmxpbmtzLWRvbmUgMSkKLSAgICAoc2V0cSBibGluay1jdXJzb3ItdGltZXIKLQkg IChydW4td2l0aC10aW1lciBibGluay1jdXJzb3ItaW50ZXJ2YWwgYmxpbmstY3Vyc29yLWludGVy dmFsCi0JCQkgICdibGluay1jdXJzb3ItdGltZXItZnVuY3Rpb24pKQorICAgIChibGluay1jdXJz b3ItLXN0YXJ0LXRpbWVyKQogICAgIChhZGQtaG9vayAncHJlLWNvbW1hbmQtaG9vayAnYmxpbmst Y3Vyc29yLWVuZCkKICAgICAoaW50ZXJuYWwtc2hvdy1jdXJzb3IgbmlsIG5pbCkpKQogCkBAIC0y MTEzLDEwICsyMTMxLDcgQEAgYmxpbmstY3Vyc29yLWNoZWNrCiAgICh3aGVuIChhbmQgYmxpbmst Y3Vyc29yLW1vZGUKIAkgICAgIChub3QgYmxpbmstY3Vyc29yLWlkbGUtdGltZXIpKQogICAgIChy ZW1vdmUtaG9vayAncG9zdC1jb21tYW5kLWhvb2sgJ2JsaW5rLWN1cnNvci1jaGVjaykKLSAgICAo c2V0cSBibGluay1jdXJzb3ItaWRsZS10aW1lcgotICAgICAgICAgIChydW4td2l0aC1pZGxlLXRp bWVyIGJsaW5rLWN1cnNvci1kZWxheQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJs aW5rLWN1cnNvci1kZWxheQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICdibGluay1j dXJzb3Itc3RhcnQpKSkpCisgICAgKGJsaW5rLWN1cnNvci0tc3RhcnQtaWRsZS10aW1lcikpKQog CiAoZGVmaW5lLW9ic29sZXRlLXZhcmlhYmxlLWFsaWFzICdibGluay1jdXJzb3IgJ2JsaW5rLWN1 cnNvci1tb2RlICIyMi4xIikKIApAQCAtMjE0NywxMCArMjE2Miw3IEBAIGJsaW5rLWN1cnNvci1t b2RlCiAgICh3aGVuIGJsaW5rLWN1cnNvci1tb2RlCiAgICAgKGFkZC1ob29rICdmb2N1cy1pbi1o b29rICMnYmxpbmstY3Vyc29yLWNoZWNrKQogICAgIChhZGQtaG9vayAnZm9jdXMtb3V0LWhvb2sg IydibGluay1jdXJzb3Itc3VzcGVuZCkKLSAgICAoc2V0cSBibGluay1jdXJzb3ItaWRsZS10aW1l cgotICAgICAgICAgIChydW4td2l0aC1pZGxlLXRpbWVyIGJsaW5rLWN1cnNvci1kZWxheQotICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJsaW5rLWN1cnNvci1kZWxheQotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICMnYmxpbmstY3Vyc29yLXN0YXJ0KSkpKQorICAgIChibGlu ay1jdXJzb3ItLXN0YXJ0LWlkbGUtdGltZXIpKSkKIAogDAogOzsgRnJhbWUgbWF4aW1pemF0aW9u L2Z1bGxzY3JlZW4KLS0gCjIuOS4wCgo= --001a114702a4ffa88b053c37d3bd-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 16:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14736110329720 (code B ref 24372); Sun, 11 Sep 2016 16:24:01 +0000 Received: (at 24372) by debbugs.gnu.org; 11 Sep 2016 16:23:52 +0000 Received: from localhost ([127.0.0.1]:56592 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj7Xr-0002Wi-Ng for submit@debbugs.gnu.org; Sun, 11 Sep 2016 12:23:51 -0400 Received: from eggs.gnu.org ([208.118.235.92]:60516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj7Xq-0002WU-FU for 24372@debbugs.gnu.org; Sun, 11 Sep 2016 12:23:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bj7Xh-0001Ex-Fb for 24372@debbugs.gnu.org; Sun, 11 Sep 2016 12:23:45 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:49915) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bj7Xh-0001EZ-C8; Sun, 11 Sep 2016 12:23:41 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1242 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bj7Xf-000873-KN; Sun, 11 Sep 2016 12:23:40 -0400 Date: Sun, 11 Sep 2016 19:23:40 +0300 Message-Id: <8360q2be2b.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Sun, 11 Sep 2016 09:15:49 +0000) References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.2 (-------) 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: -7.2 (-------) > From: Philipp Stephani > Date: Sun, 11 Sep 2016 09:15:49 +0000 > Cc: 24372@debbugs.gnu.org > > > OK, I guess one issue is that setting blink-cursor-delay doesn't restart blink-cursor-idle-timer. > (Similarly, > > changing blink-cursor-interval doesn't restart blink-cursor-timer.) While obviously we can't fix that > when using > > setq, I'd suggest adding custom setters to the variables nevertheless. > > I've attached a patch for this. It shouldn't be controversial because it only reduces the possibility for surprises, > but doesn't change any behavior. Using the maximum of blink-cursor-delay and blink-cursor-interval effectively removes the user's ability of controlling the delay before the cursor starts blinking when Emacs becomes idle, doesn't it? If so, I don't think this could qualify as not changing any behavior. Plus, if the user sets the interval to a very small value, we have the same problem again. How about a variant of this below? It uses a fixed limitation from below on the delay, but only for the first blink. (The value 0.2 was found by experimentation, not sure if we need to add yet another defcustom for that.) > It does introduce the adverse side effect that now the first blink takes one second (the sum of > cursor-blink-delay and cursor-blink-interval). Right. > I've attached another patch with the change I have in mind. This has a disadvantage of creating a new timer object each time, which I think we'd like to avoid: too much consing. (Also, don't you need to set the timer variable to nil when the timer is disabled?) I'd prefer something along the lines of the first idea, the patch below or some variant of it. It is simpler. diff --git a/lisp/frame.el b/lisp/frame.el index cfd40bf..4540172 100644 --- a/lisp/frame.el +++ b/lisp/frame.el @@ -2114,7 +2114,7 @@ blink-cursor-check (not blink-cursor-idle-timer)) (remove-hook 'post-command-hook 'blink-cursor-check) (setq blink-cursor-idle-timer - (run-with-idle-timer blink-cursor-delay + (run-with-idle-timer (max 0.2 blink-cursor-delay) blink-cursor-delay 'blink-cursor-start)))) @@ -2148,7 +2148,7 @@ blink-cursor-mode (add-hook 'focus-in-hook #'blink-cursor-check) (add-hook 'focus-out-hook #'blink-cursor-suspend) (setq blink-cursor-idle-timer - (run-with-idle-timer blink-cursor-delay + (run-with-idle-timer (max 0.2 blink-cursor-delay) blink-cursor-delay #'blink-cursor-start)))) From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 17:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147361547522999 (code B ref 24372); Sun, 11 Sep 2016 17:38:02 +0000 Received: (at 24372) by debbugs.gnu.org; 11 Sep 2016 17:37:55 +0000 Received: from localhost ([127.0.0.1]:56705 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj8hX-0005ys-8C for submit@debbugs.gnu.org; Sun, 11 Sep 2016 13:37:55 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:37989) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bj8hV-0005yf-FB for 24372@debbugs.gnu.org; Sun, 11 Sep 2016 13:37:54 -0400 Received: by mail-wm0-f50.google.com with SMTP id 1so109608331wmz.1 for <24372@debbugs.gnu.org>; Sun, 11 Sep 2016 10:37:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=VR8OCZD6US0MiXV6Q2R+4F2fXTAJI912+ZxFAbvAdSI=; b=itlkWO2rq1z2jp/4QdTGJf0t49d69OiK9YV0llKSQuwGMBEb2boCkCC/1l57aqe8J1 KOlP22pVwUrlthXyuPHLN/lUCV10QMEK1uokpgPm+4HRO3bU1PGB18NQRxGEqE8K+38L PLQwcFUc9JzMAMTbdackshoG1HKWI1YPJLslUvHGYYh1lDnLhp1IZsxVxAvRXxcZ9+tL x/tzQc3kvsDBmQf/StiBZ4RusP+W0LbJyIWabaKJ0+4ZzJgLG5V4hmRwHX/t9Uf/hrKT Fk80QALEAFO2dQokE0xY3R19WbHWHhkRPD2NV73aX4F+yYJoaFtWOdgRbnX7BaKOxo+J /ZEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=VR8OCZD6US0MiXV6Q2R+4F2fXTAJI912+ZxFAbvAdSI=; b=fz1y4E47rhzAnbDHTnUiB1/uh/GZ51FOCvTE0a4CmEIIrCwiJlEt0HQkemJTkI+IsN gg5TXLLZwvPoBv+TQrgXJPTYAkJBLy9t8pvUvB859ySjGEHUvm6wU2ATO6+Y16rxKuur IwF0xBruHitGzQLR74FYD4wCy75tSwQVot3ccjeGizoiSluvXarbC8R7wtazHDAwBX2x niQbC+VraZVrZq1Iz8orsDYulM1MChCP8846MA2897X1ZXG9iH4H4zW90egho7khlufr xtd9X+AsINw/JWL9+Rn5ETeFTTDBxSiR2u3bpFxywZ+mpWepMedslC0TX7XszaoO+6Jj 1WJA== X-Gm-Message-State: AE9vXwMinW1sgae7wpm2h0pwiRMKd2jXd130Of0dYR53mdCbLqwJcT76nA8V53eURCOlMfM7tsW+tfKvJn/PLw== X-Received: by 10.28.232.71 with SMTP id f68mr7347537wmh.55.1473615467756; Sun, 11 Sep 2016 10:37:47 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> In-Reply-To: <8360q2be2b.fsf@gnu.org> From: Philipp Stephani Date: Sun, 11 Sep 2016 17:37:36 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a1146a1527dc46a053c3ed6fd X-Spam-Score: -0.5 (/) 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 (/) --001a1146a1527dc46a053c3ed6fd Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am So., 11. Sep. 2016 um 18:23 Uhr: > > From: Philipp Stephani > > Date: Sun, 11 Sep 2016 09:15:49 +0000 > > Cc: 24372@debbugs.gnu.org > > > > > OK, I guess one issue is that setting blink-cursor-delay doesn't > restart blink-cursor-idle-timer. > > (Similarly, > > > changing blink-cursor-interval doesn't restart blink-cursor-timer.) > While obviously we can't fix that > > when using > > > setq, I'd suggest adding custom setters to the variables nevertheless. > > > > I've attached a patch for this. It shouldn't be controversial because it > only reduces the possibility for surprises, > > but doesn't change any behavior. > > Using the maximum of blink-cursor-delay and blink-cursor-interval > effectively removes the user's ability of controlling the delay before > the cursor starts blinking when Emacs becomes idle, doesn't it? Yes. I tried to figure out what the intention of blink-cursor-delay was, but couldn't find anything (the commit where it was introduced doesn't provide any motivation). I don't think that blink-cursor-delay < blink-cursor-interval ever makes sense. The other way round (delay > interval) is useful if you want to keep the cursor visible for a bit longer after a command. > If > so, I don't think this could qualify as not changing any behavior. > My comment is about the other patch, the one that fixes the customization options. > Plus, if the user sets the interval to a very small value, we have the > same problem again. > True, but so far that hasn't happened. Also it seems less surprising: if you increase the frequency, the cursor blinks faster, as expected. > > How about a variant of this below? It uses a fixed limitation from > below on the delay, but only for the first blink. (The value 0.2 was > found by experimentation, not sure if we need to add yet another > defcustom for that.) > I don't think we should introduce magic numbers or further customization options. (TBH, I already doubt the usefulness of blink-cursor-delay, but that's already there.) > > > It does introduce the adverse side effect that now the first blink takes > one second (the sum of > > cursor-blink-delay and cursor-blink-interval). > > Right. > > > I've attached another patch with the change I have in mind. > > This has a disadvantage of creating a new timer object each time, > which I think we'd like to avoid: too much consing. (Also, don't you > need to set the timer variable to nil when the timer is disabled?) > I don't understand - the patch doesn't create any additional timers, it only changes the initial delay of the idle-timer. > > I'd prefer something along the lines of the first idea, the patch > below or some variant of it. It is simpler. > > diff --git a/lisp/frame.el b/lisp/frame.el > index cfd40bf..4540172 100644 > --- a/lisp/frame.el > +++ b/lisp/frame.el > @@ -2114,7 +2114,7 @@ blink-cursor-check > (not blink-cursor-idle-timer)) > (remove-hook 'post-command-hook 'blink-cursor-check) > (setq blink-cursor-idle-timer > - (run-with-idle-timer blink-cursor-delay > + (run-with-idle-timer (max 0.2 blink-cursor-delay) > blink-cursor-delay > 'blink-cursor-start)))) > > @@ -2148,7 +2148,7 @@ blink-cursor-mode > (add-hook 'focus-in-hook #'blink-cursor-check) > (add-hook 'focus-out-hook #'blink-cursor-suspend) > (setq blink-cursor-idle-timer > - (run-with-idle-timer blink-cursor-delay > + (run-with-idle-timer (max 0.2 blink-cursor-delay) > blink-cursor-delay > #'blink-cursor-start)))) > > My patch is identical, except is uses blink-cursor-interval as lower bound. --001a1146a1527dc46a053c3ed6fd Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 11. Sep. 2016 um 18:23=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 11 Sep 2016 09:15:49 +0000
> Cc: 24372@debbugs.gnu.org
>
>=C2=A0 > OK, I guess one issue is that setting blink-cursor-delay do= esn't restart blink-cursor-idle-timer.
>=C2=A0 (Similarly,
>=C2=A0 > changing blink-cursor-interval doesn't restart blink-cu= rsor-timer.) While obviously we can't fix that
>=C2=A0 when using
>=C2=A0 > setq, I'd suggest adding custom setters to the variable= s nevertheless.
>
> I've attached a patch for this. It shouldn't be controversial = because it only reduces the possibility for surprises,
> but doesn't change any behavior.

Using the maximum of blink-cursor-delay and blink-cursor-interval
effectively removes the user's ability of controlling the delay before<= br class=3D"gmail_msg"> the cursor starts blinking when Emacs becomes idle, doesn't it?

Yes. I tried to figure out what the intention of b= link-cursor-delay was, but couldn't find anything (the commit where it = was introduced doesn't provide any motivation). I don't think that = blink-cursor-delay < blink-cursor-interval ever makes sense. The other w= ay round (delay > interval) is useful if you want to keep the cursor vis= ible for a bit longer after a command.
=C2=A0
=C2=A0 If
so, I don't think this could qualify as not changing any behavior.

My comment is about the= other patch, the one that fixes the customization options.
=C2= =A0
Plus, if the user sets the interval to a very small value, we have the
same problem again.

True, but so far that hasn't happened. Also it seems less surprising: = if you increase the frequency, the cursor blinks faster, as expected.
=
=C2=A0

How about a variant of this below?=C2=A0 It uses a fixed limitation from below on the delay, but only for the first blink.=C2=A0 (The value 0.2 was<= br class=3D"gmail_msg"> found by experimentation, not sure if we need to add yet another
defcustom for that.)

I don't think we should introduce magic numbers or further customizat= ion options. (TBH, I already doubt the usefulness of blink-cursor-delay, bu= t that's already there.)
=C2=A0

> It does introduce the adverse side effect that now the first blink tak= es one second (the sum of
> cursor-blink-delay and cursor-blink-interval).

Right.

> I've attached another patch with the change I have in mind.

This has a disadvantage of creating a new timer object each time,
which I think we'd like to avoid: too much consing.=C2=A0 (Also, don= 9;t you
need to set the timer variable to nil when the timer is disabled?)

I don't understand - th= e patch doesn't create any additional timers, it only changes the initi= al delay of the idle-timer.
=C2=A0

I'd prefer something along the lines of the first idea, the patch
below or some variant of it.=C2=A0 It is simpler.

diff --git a/lisp/frame.el b/lisp/frame.el
index cfd40bf..4540172 100644
--- a/lisp/frame.el
+++ b/lisp/frame.el
@@ -2114,7 +2114,7 @@ blink-cursor-check
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(not blink-cursor-idle-time= r))
=C2=A0 =C2=A0 =C2=A0(remove-hook 'post-command-hook 'blink-cursor-c= heck)
=C2=A0 =C2=A0 =C2=A0(setq blink-cursor-idle-timer
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (run-with-idle-timer blink-cursor-delay=
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (run-with-idle-timer (max 0.2 blink-cur= sor-delay)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 blink-cursor-delay
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 'blink-cursor-start))))

@@ -2148,7 +2148,7 @@ blink-cursor-mode
=C2=A0 =C2=A0 =C2=A0(add-hook 'focus-in-hook #'blink-cursor-check)<= br class=3D"gmail_msg"> =C2=A0 =C2=A0 =C2=A0(add-hook 'focus-out-hook #'blink-cursor-suspen= d)
=C2=A0 =C2=A0 =C2=A0(setq blink-cursor-idle-timer
-=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (run-with-idle-timer blink-cursor-delay=
+=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 (run-with-idle-timer (max 0.2 blink-cur= sor-delay)
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 blink-cursor-delay
=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 #'blink-cursor-start))))


My patch is identi= cal, except is uses blink-cursor-interval as lower bound.=C2=A0
= --001a1146a1527dc46a053c3ed6fd-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 11 Sep 2016 19:20:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147362154532023 (code B ref 24372); Sun, 11 Sep 2016 19:20:01 +0000 Received: (at 24372) by debbugs.gnu.org; 11 Sep 2016 19:19:05 +0000 Received: from localhost ([127.0.0.1]:56772 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjAHQ-0008KR-Nj for submit@debbugs.gnu.org; Sun, 11 Sep 2016 15:19:04 -0400 Received: from eggs.gnu.org ([208.118.235.92]:35108) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bjAHP-0008Jx-2D for 24372@debbugs.gnu.org; Sun, 11 Sep 2016 15:19:03 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bjAHE-00074A-R3 for 24372@debbugs.gnu.org; Sun, 11 Sep 2016 15:18:57 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: X-Spam-Status: No, score=-1.4 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:51770) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bjAHE-00073v-Nz; Sun, 11 Sep 2016 15:18:52 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1358 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bjAHA-0001YY-RV; Sun, 11 Sep 2016 15:18:51 -0400 Date: Sun, 11 Sep 2016 22:18:38 +0300 Message-Id: <83twdm9re9.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Sun, 11 Sep 2016 17:37:36 +0000) References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -7.2 (-------) 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: -7.2 (-------) > From: Philipp Stephani > Date: Sun, 11 Sep 2016 17:37:36 +0000 > Cc: 24372@debbugs.gnu.org > > Using the maximum of blink-cursor-delay and blink-cursor-interval > effectively removes the user's ability of controlling the delay before > the cursor starts blinking when Emacs becomes idle, doesn't it? > > Yes. I tried to figure out what the intention of blink-cursor-delay was, but couldn't find anything (the commit > where it was introduced doesn't provide any motivation). I don't think that blink-cursor-delay < > blink-cursor-interval ever makes sense. The other way round (delay > interval) is useful if you want to keep the > cursor visible for a bit longer after a command. I don't understand the nature of your difficulty. blink-cursor-delay is obviously how soon the user want the cursor to start blinking after Emacs becomes idle. That is orthogonal to the blink interval, which is in effect once the blinking begins. > Plus, if the user sets the interval to a very small value, we have the > same problem again. > > True, but so far that hasn't happened. Also it seems less surprising: if you increase the frequency, the cursor > blinks faster, as expected. The problem is not with a faster blinking, the problem is with the cursor almost invisible. E.g., try to set blink-cursor-delay to a very small, but non-zero value with today's sources, and then repeat your recipe, with and without the focus-out/in dance. > How about a variant of this below? It uses a fixed limitation from > below on the delay, but only for the first blink. (The value 0.2 was > found by experimentation, not sure if we need to add yet another > defcustom for that.) > > I don't think we should introduce magic numbers or further customization options. It solves the problem, doesn't it? I don't mind very much if it were a defcustom, I just think no one would want to change it. > > I've attached another patch with the change I have in mind. > > This has a disadvantage of creating a new timer object each time, > which I think we'd like to avoid: too much consing. (Also, don't you > need to set the timer variable to nil when the timer is disabled?) > > I don't understand - the patch doesn't create any additional timers, it only changes the initial delay of the > idle-timer. Each time blink-cursor--start-timer or blink-cursor--start-idle-timer is called, they create a new timer, right? And your patch makes us call these functions each time blinking is started or ended, right? > My patch is identical, except is uses blink-cursor-interval as lower bound. Of course. That's why I said it's a minor variant. There's another difference, though: in my patch we only limit the first argument to run-with-timer/run-with-idle-timer, not the second. So only the first blink cycle is affected. From unknown Tue Aug 19 10:09:22 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Philipp Stephani Subject: bug#24372: closed (Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point) Message-ID: References: <83ponud721.fsf@gnu.org> X-Gnu-PR-Message: they-closed 24372 X-Gnu-PR-Package: emacs Reply-To: 24372@debbugs.gnu.org Date: Fri, 23 Sep 2016 14:29:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1474640942-1507-1" This is a multi-part message in MIME format... ------------=_1474640942-1507-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #24372: 25.1.50; After losing focus, cursor is hidden when moving point which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 24372@debbugs.gnu.org. --=20 24372: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D24372 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1474640942-1507-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 24372-done) by debbugs.gnu.org; 23 Sep 2016 14:28:28 +0000 Received: from localhost ([127.0.0.1]:33607 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnRSm-0000NR-KK for submit@debbugs.gnu.org; Fri, 23 Sep 2016 10:28:28 -0400 Received: from eggs.gnu.org ([208.118.235.92]:36602) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bnRSl-0000NF-Nf for 24372-done@debbugs.gnu.org; Fri, 23 Sep 2016 10:28:27 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bnRSd-0005i5-8U for 24372-done@debbugs.gnu.org; Fri, 23 Sep 2016 10:28:22 -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,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:48481) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bnRSd-0005hs-4o; Fri, 23 Sep 2016 10:28:19 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:3750 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bnRSZ-0008CQ-8D; Fri, 23 Sep 2016 10:28:17 -0400 Date: Fri, 23 Sep 2016 17:28:22 +0300 Message-Id: <83ponud721.fsf@gnu.org> From: Eli Zaretskii To: p.stephani2@gmail.com In-reply-to: <83twdm9re9.fsf@gnu.org> (message from Eli Zaretskii on Sun, 11 Sep 2016 22:18:38 +0300) Subject: Re: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.1 (--------) X-Debbugs-Envelope-To: 24372-done Cc: 24372-done@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: , Reply-To: Eli Zaretskii Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -8.1 (--------) > Date: Sun, 11 Sep 2016 22:18:38 +0300 > From: Eli Zaretskii > Cc: 24372@debbugs.gnu.org > > > How about a variant of this below? It uses a fixed limitation from > > below on the delay, but only for the first blink. (The value 0.2 was > > found by experimentation, not sure if we need to add yet another > > defcustom for that.) > > > > I don't think we should introduce magic numbers or further customization options. > > It solves the problem, doesn't it? I don't mind very much if it were > a defcustom, I just think no one would want to change it. > > > > I've attached another patch with the change I have in mind. > > > > This has a disadvantage of creating a new timer object each time, > > which I think we'd like to avoid: too much consing. (Also, don't you > > need to set the timer variable to nil when the timer is disabled?) > > > > I don't understand - the patch doesn't create any additional timers, it only changes the initial delay of the > > idle-timer. > > Each time blink-cursor--start-timer or blink-cursor--start-idle-timer > is called, they create a new timer, right? And your patch makes us > call these functions each time blinking is started or ended, right? > > > My patch is identical, except is uses blink-cursor-interval as lower bound. > > Of course. That's why I said it's a minor variant. > > There's another difference, though: in my patch we only limit the > first argument to run-with-timer/run-with-idle-timer, not the second. > So only the first blink cycle is affected. No further comments, so I pushed my last proposed patch to the emacs-25 branch, and I'm marking this bug done. Thanks. ------------=_1474640942-1507-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 5 Sep 2016 19:16:59 +0000 Received: from localhost ([127.0.0.1]:50636 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgzO7-0003xI-7V for submit@debbugs.gnu.org; Mon, 05 Sep 2016 15:16:59 -0400 Received: from eggs.gnu.org ([208.118.235.92]:59230) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bgzO6-0003x3-3U for submit@debbugs.gnu.org; Mon, 05 Sep 2016 15:16:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgzNz-0004CB-Qe for submit@debbugs.gnu.org; Mon, 05 Sep 2016 15:16:52 -0400 X-Spam-Checker-Version: SpamAssassin 3.3.2 (2011-06-06) on eggs.gnu.org X-Spam-Level: * X-Spam-Status: No, score=1.1 required=5.0 tests=BAYES_50, FREEMAIL_ENVFROM_END_DIGIT,FREEMAIL_FROM,T_DKIM_INVALID autolearn=disabled version=3.3.2 Received: from lists.gnu.org ([2001:4830:134:3::11]:56147) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgzNz-0004C5-Mo for submit@debbugs.gnu.org; Mon, 05 Sep 2016 15:16:51 -0400 Received: from eggs.gnu.org ([2001:4830:134:3::10]:50167) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgzNy-0005E8-7x for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 15:16:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bgzNv-0004BC-Pj for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 15:16:49 -0400 Received: from mail-wm0-x22f.google.com ([2a00:1450:400c:c09::22f]:38370) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bgzNv-0004Ap-Fu for bug-gnu-emacs@gnu.org; Mon, 05 Sep 2016 15:16:47 -0400 Received: by mail-wm0-x22f.google.com with SMTP id 1so153967696wmz.1 for ; Mon, 05 Sep 2016 12:16:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=EuryU+nikTAGqoOjQDNzwFg6cmacLXReQWpb0mRX0Fg=; b=H1z4VnJqGBh1HcKFxQOO8xQrOcXtkssH3SCCzSrhOOSUIKjZSS79cvthbX600tceSj pvHNzNeCd1K2fgGX9x7Lt1oNt6rick5BPdaVZG774zIBw9EkY8lFduhFPMhlah1rTegU NrRJ6ZTCDGKXX4yUpmjb5vgBu7cpkfuwrRFMvMmMEHPXOrzdGxSwxIKSvzn6QDXhSr+O j9eYAhYdHw0/gTUmvfQpKJiTqpuKoIle6R8R3pE1xnQhD8EjW7iN/0LWmObnUJb67a8W spTuyabpZatxQApGYzcO1j+FkgJfL2LLUwduZukZXWReIc3yQHF82ppW/GspydlFE3s0 vj6g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:from:to:subject:date:message-id:mime-version :content-transfer-encoding; bh=EuryU+nikTAGqoOjQDNzwFg6cmacLXReQWpb0mRX0Fg=; b=TzSZLPE+5Ll1It4buXUGXMge1xJdJw5xMRnV8tT08adNk+V92yMg9HF1LlLIY3/D9B 5ydPrbYqooAF0hf16FH5wbOydEpIXBHgX+eD/neSWRV9ASjpwNSiSLGiBTokrsg4VA0I yxTP6og+6W69q5NdfkhBhvh6dDBWm5roxJ83WwXYbEXe35s/XXwHca1ssPNZjUDOlW0U R2HJ/MLg+FPtMGRRs7cURecbJWeA00GzYLjn9uenJ24EbLAmlzg/dtMUKcUbVvAVRyt9 wig1bOQJl5mTszAqbxQmHBdPpbYNnY364niLlZ8DEvOWYe8AgWqJ0KHnL8yPQj6WcQ0i scPA== X-Gm-Message-State: AE9vXwOd9QuyfbJeecHxVn7MZsfaB/i52PSG4HsXFdnMhdgAOeQqe3qyGULtkQqFaMId+Q== X-Received: by 10.28.181.142 with SMTP id e136mr17739334wmf.61.1473103006304; Mon, 05 Sep 2016 12:16:46 -0700 (PDT) Received: from a.muc.corp.google.com ([2a00:79e0:15:4:c077:c733:b8e8:6e63]) by smtp.gmail.com with ESMTPSA id f187sm22359072wmf.15.2016.09.05.12.16.44 for (version=TLS1_2 cipher=AES128-SHA bits=128/128); Mon, 05 Sep 2016 12:16:44 -0700 (PDT) From: Philipp Stephani To: bug-gnu-emacs@gnu.org Subject: 25.1.50; After losing focus, cursor is hidden when moving point Date: Mon, 05 Sep 2016 21:16:40 +0200 Message-ID: MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6.x X-Received-From: 2001:4830:134:3::11 X-Spam-Score: -3.8 (---) 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: -3.8 (---) I've tested this with a GTK build on GNU/Linux; other toolkits and OSes might also be affected (but terminal mode doesn't seem to be affected). emacs -Q -eval '(setq blink-cursor-delay 0.0)' Move point around in the scratch buffer (e.g. press C-b a couple of times): the cursor stays visible, as it should be. Then put the mouse focus on a different GTK window (not Emacs window), put the mouse focus back on Emacs, and move point again: the cursor is hidden, making it impossible to see until you stop moving. In GNU Emacs 25.1.50.4 (x86_64-unknown-linux-gnu, GTK+ Version 3.10.8) of 2016-09-05 built on unknown Repository revision: 6acff25280dbb97b5e9ddfd872b33ceb36b0470a Windowing system distributor 'The X.Org Foundation', version 11.0.11501000 System Description: Ubuntu 14.04 LTS Recent messages: For information about GNU Emacs and the GNU system, type C-h C-a. Configured using: 'configure --with-modules' Configured features: XPM JPEG TIFF GIF PNG SOUND GSETTINGS NOTIFY GNUTLS FREETYPE XFT ZLIB TOOLKIT_SCROLL_BARS GTK3 X11 MODULES Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix Major mode: Lisp Interaction 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 blink-cursor-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 subr-x puny seq byte-opt gv bytecomp byte-compile cl-extra help-mode cconv cl-loaddefs pcase cl-lib dired dired-loaddefs format-spec rfc822 mml easymenu mml-sec password-cache epa derived epg epg-config gnus-util rmail rmail-loaddefs mm-decode mm-bodies mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date 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 newcomment elisp-mode lisp-mode prog-mode register page menu-bar rfn-eshadow 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 charscript 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 inotify dynamic-setting system-font-setting font-render-setting move-toolbar gtk x-toolkit x multi-tty make-network-process emacs) Memory information: ((conses 16 97852 8736) (symbols 48 20654 0) (miscs 40 325 194) (strings 32 17964 4666) (string-bytes 1 589251) (vectors 16 13794) (vector-slots 8 452872 5883) (floats 8 183 107) (intervals 56 211 0) (buffers 976 12) (heap 1024 48215 1026)) --=20 Google Germany GmbH Erika-Mann-Stra=C3=9Fe 33 80636 M=C3=BCnchen Registergericht und -nummer: Hamburg, HRB 86891 Sitz der Gesellschaft: Hamburg Gesch=C3=A4ftsf=C3=BChrer: Matthew Scott Sucherman, Paul Terence Manicle Diese E-Mail ist vertraulich. Wenn Sie nicht der richtige Adressat sind, leiten Sie diese bitte nicht weiter, informieren Sie den Absender und l=C3= =B6schen Sie die E-Mail und alle Anh=C3=A4nge. Vielen Dank. This e-mail is confidential. If you are not the right addressee please do = not forward it, please inform the sender, and please erase this e-mail including any attachments. Thanks. ------------=_1474640942-1507-1-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 25 Sep 2016 19:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14748306113357 (code B ref 24372); Sun, 25 Sep 2016 19:11:01 +0000 Received: (at 24372) by debbugs.gnu.org; 25 Sep 2016 19:10:11 +0000 Received: from localhost ([127.0.0.1]:35788 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1boEoU-0000s5-MD for submit@debbugs.gnu.org; Sun, 25 Sep 2016 15:10:11 -0400 Received: from mail-wm0-f48.google.com ([74.125.82.48]:33741) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1boEoS-0000rr-Jf for 24372@debbugs.gnu.org; Sun, 25 Sep 2016 15:10:09 -0400 Received: by mail-wm0-f48.google.com with SMTP id d66so18652663wmf.0 for <24372@debbugs.gnu.org>; Sun, 25 Sep 2016 12:10:08 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=9mpFotPO2c0RAAGax5qL/CDPqzy9+2zJTqGFJAKJUHQ=; b=X79FXJMwvg8wfAXbEP/12rRs6h4RTrT/8kBNp6n/R3uaF7n52cZNA7BobM5UPb9UWw FN/yJwZuDW90qyJs5Kc291z5l23VQKQpKxADTFwEIBqFMxy1ZbRnNum0NXRG0BcO0zaT 8F4B+mTtk5z+KiyEtQbgzpDiiEmEpdhujuuZ9ixkQl4fMQ63uzxvR5w4PW8V7/etYjZr Uj5OcMQMT89bg6XdwCMd0/iLqp7xIcJ33fnEf8ouepnocTDrLqKFiRz98+uSpU47Jmxs TmlVHivQ7PIHGI3gXZKBDtTnzbuugxlnquSCXJ2YXdIxH6fezzefZQk66GoTBEG1I0l1 KvxQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=9mpFotPO2c0RAAGax5qL/CDPqzy9+2zJTqGFJAKJUHQ=; b=RJhK7PTAU0/NUuxZjkSz0OtowiP8FtpGue0pMY1hBV3pz+Qa/3fwKRP92K27FyjmRY iz6eDROWMxyTstsmM1U9DTLgBEqmLrrGX3+8z+UqlahHjLXxGW/T6Vvd76RoBtvHsbuE /ZCI/Z0898UbGH6UU+0zkxvU0qzh/O1rWZIy/P9loybB3qMBjwJock15Mk16AIIf6KED KMPZUmPByKXJ3cUGImTWUaHAJsBXY6q3pJ4rxsE3GrS4nNyE5QLupr6z5IK9AaiWN0w2 cQTQFBaDmQwUDJdmrfggSuzBgfmmwSYb6Da+x7F/62UU5I9wP6vd2OV3sIRgZkW0O5jK ctJw== X-Gm-Message-State: AA6/9RlLPftEAg4MjsHF7L+pwO47tog5sOFkCXU+GNX2hyaHWEbJDJr3FwX8FYH75o6WSRteXO+ccQuULkvs8w== X-Received: by 10.28.72.10 with SMTP id v10mr11838590wma.52.1474830602645; Sun, 25 Sep 2016 12:10:02 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> In-Reply-To: <83twdm9re9.fsf@gnu.org> From: Philipp Stephani Date: Sun, 25 Sep 2016 19:09:52 +0000 Message-ID: Content-Type: multipart/alternative; boundary=001a114b30662cb752053d59c210 X-Spam-Score: 0.2 (/) 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 (/) --001a114b30662cb752053d59c210 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am So., 11. Sep. 2016 um 21:19 Uhr: > > From: Philipp Stephani > > Date: Sun, 11 Sep 2016 17:37:36 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Using the maximum of blink-cursor-delay and blink-cursor-interval > > effectively removes the user's ability of controlling the delay before > > the cursor starts blinking when Emacs becomes idle, doesn't it? > > > > Yes. I tried to figure out what the intention of blink-cursor-delay was, > but couldn't find anything (the commit > > where it was introduced doesn't provide any motivation). I don't think > that blink-cursor-delay < > > blink-cursor-interval ever makes sense. The other way round (delay > > interval) is useful if you want to keep the > > cursor visible for a bit longer after a command. > > I don't understand the nature of your difficulty. blink-cursor-delay > is obviously how soon the user want the cursor to start blinking after > Emacs becomes idle. That is orthogonal to the blink interval, which > is in effect once the blinking begins. > Having the cursor hidden faster than it blinks sounds weird to me, but I guess it's OK since it's easy enough to change the option, so your interpretation sounds good to me as well. > > > How about a variant of this below? It uses a fixed limitation from > > below on the delay, but only for the first blink. (The value 0.2 was > > found by experimentation, not sure if we need to add yet another > > defcustom for that.) > > > > I don't think we should introduce magic numbers or further customization > options. > > It solves the problem, doesn't it? I don't mind very much if it were > a defcustom, I just think no one would want to change it. > OK, then it would be great to document the new behavior in the documentation of `blink-cursor-delay' and also clarify what "starting to blink" means. > > > > I've attached another patch with the change I have in mind. > > > > This has a disadvantage of creating a new timer object each time, > > which I think we'd like to avoid: too much consing. (Also, don't you > > need to set the timer variable to nil when the timer is disabled?) > > > > I don't understand - the patch doesn't create any additional timers, it > only changes the initial delay of the > > idle-timer. > > Each time blink-cursor--start-timer or blink-cursor--start-idle-timer > is called, they create a new timer, right? And your patch makes us > call these functions each time blinking is started or ended, right? > No, the other patch is that it restarts the timers when the customization options are set. Otherwise the options only become effective after a focus-out/focus-in event or something similar that restarts the cursor. > > > My patch is identical, except is uses blink-cursor-interval as lower > bound. > > Of course. That's why I said it's a minor variant. > > There's another difference, though: in my patch we only limit the > first argument to run-with-timer/run-with-idle-timer, not the second. > So only the first blink cycle is affected. > Doesn't that mean that the adjusted delay is applied only after the first command, but not after subsequent commands? --001a114b30662cb752053d59c210 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 11. Sep. 2016 um 21:19=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 11 Sep 2016 17:37:36 +0000
> Cc: 24372@debbugs.gnu.org
>
>=C2=A0 Using the maximum of blink-cursor-delay and blink-cursor-interva= l
>=C2=A0 effectively removes the user's ability of controlling the de= lay before
>=C2=A0 the cursor starts blinking when Emacs becomes idle, doesn't = it?
>
> Yes. I tried to figure out what the intention of blink-cursor-delay wa= s, but couldn't find anything (the commit
> where it was introduced doesn't provide any motivation). I don'= ;t think that blink-cursor-delay <
> blink-cursor-interval ever makes sense. The other way round (delay >= ; interval) is useful if you want to keep the
> cursor visible for a bit longer after a command.

I don't understand the nature of your difficulty.=C2=A0 blink-cursor-de= lay
is obviously how soon the user want the cursor to start blinking after
Emacs becomes idle.=C2=A0 That is orthogonal to the blink interval, which is in effect once the blinking begins.
=

Having the cursor hidden faster than it blinks sounds w= eird to me, but I guess it's OK since it's easy enough to change th= e option, so your interpretation sounds good to me as well.
=C2= =A0

>=C2=A0 How about a variant of this below? It uses a fixed limitation fr= om
>=C2=A0 below on the delay, but only for the first blink. (The value 0.2= was
>=C2=A0 found by experimentation, not sure if we need to add yet another=
>=C2=A0 defcustom for that.)
>
> I don't think we should introduce magic numbers or further customi= zation options.

It solves the problem, doesn't it?=C2=A0 I don't mind very much if = it were
a defcustom, I just think no one would want to change it.

OK, then it would be great to docume= nt the new behavior in the documentation of `blink-cursor-delay' and al= so clarify what "starting to blink" means.
=C2=A0
=

>=C2=A0 > I've attached another patch with the change I have in m= ind.
>
>=C2=A0 This has a disadvantage of creating a new timer object each time= ,
>=C2=A0 which I think we'd like to avoid: too much consing. (Also, d= on't you
>=C2=A0 need to set the timer variable to nil when the timer is disabled= ?)
>
> I don't understand - the patch doesn't create any additional t= imers, it only changes the initial delay of the
> idle-timer.

Each time blink-cursor--start-timer or blink-cursor--start-idle-timer
is called, they create a new timer, right?=C2=A0 And your patch makes us call these functions each time blinking is started or ended, right?

No, the other patch is tha= t it restarts the timers when the customization options are set. Otherwise = the options only become effective after a focus-out/focus-in event or somet= hing similar that restarts the cursor.
=C2=A0

> My patch is identical, except is uses blink-cursor-interval as lower b= ound.

Of course.=C2=A0 That's why I said it's a minor variant.

There's another difference, though: in my patch we only limit the
first argument to run-with-timer/run-with-idle-timer, not the second.
So only the first blink cycle is affected.

Doesn't that mean that the adjusted delay is ap= plied only after the first command, but not after subsequent commands?=C2= =A0
--001a114b30662cb752053d59c210-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2016 08:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14753103141540 (code B ref 24372); Sat, 01 Oct 2016 08:26:01 +0000 Received: (at 24372) by debbugs.gnu.org; 1 Oct 2016 08:25:14 +0000 Received: from localhost ([127.0.0.1]:40226 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqFbe-0000Om-DV for submit@debbugs.gnu.org; Sat, 01 Oct 2016 04:25:14 -0400 Received: from eggs.gnu.org ([208.118.235.92]:40435) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqFbd-0000Ob-Qe for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 04:25:14 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqFbV-0002md-Gp for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 04:25:08 -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.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:33003) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqFbV-0002mG-Dc; Sat, 01 Oct 2016 04:25:05 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:1533 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bqFbT-0006Sd-6w; Sat, 01 Oct 2016 04:25:03 -0400 Date: Sat, 01 Oct 2016 11:25:11 +0300 Message-Id: <831t00mq6w.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Sun, 25 Sep 2016 19:09:52 +0000) References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.0 (--------) 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: -8.0 (--------) > From: Philipp Stephani > Date: Sun, 25 Sep 2016 19:09:52 +0000 > Cc: 24372@debbugs.gnu.org > > > How about a variant of this below? It uses a fixed limitation from > > below on the delay, but only for the first blink. (The value 0.2 was > > found by experimentation, not sure if we need to add yet another > > defcustom for that.) > > > > I don't think we should introduce magic numbers or further customization options. > > It solves the problem, doesn't it? I don't mind very much if it were > a defcustom, I just think no one would want to change it. > > OK, then it would be great to document the new behavior in the documentation of `blink-cursor-delay' and also > clarify what "starting to blink" means. Done. > > > I've attached another patch with the change I have in mind. > > > > This has a disadvantage of creating a new timer object each time, > > which I think we'd like to avoid: too much consing. (Also, don't you > > need to set the timer variable to nil when the timer is disabled?) > > > > I don't understand - the patch doesn't create any additional timers, it only changes the initial delay of > the > > idle-timer. > > Each time blink-cursor--start-timer or blink-cursor--start-idle-timer > is called, they create a new timer, right? And your patch makes us > call these functions each time blinking is started or ended, right? > > No, the other patch is that it restarts the timers when the customization options are set. Otherwise the options > only become effective after a focus-out/focus-in event or something similar that restarts the cursor. > > > My patch is identical, except is uses blink-cursor-interval as lower bound. > > Of course. That's why I said it's a minor variant. > > There's another difference, though: in my patch we only limit the > first argument to run-with-timer/run-with-idle-timer, not the second. > So only the first blink cycle is affected. > > Doesn't that mean that the adjusted delay is applied only after the first command, but not after subsequent > commands? No, not AFAIK. The idle time starts anew after each command. Is there anything left to do about this, or can we close this bug? Thanks. From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2016 16:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147533828426517 (code B ref 24372); Sat, 01 Oct 2016 16:12:02 +0000 Received: (at 24372) by debbugs.gnu.org; 1 Oct 2016 16:11:24 +0000 Received: from localhost ([127.0.0.1]:41295 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqMsl-0006tc-Rq for submit@debbugs.gnu.org; Sat, 01 Oct 2016 12:11:24 -0400 Received: from mail-wm0-f54.google.com ([74.125.82.54]:34082) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqMsj-0006tO-Jw for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 12:11:22 -0400 Received: by mail-wm0-f54.google.com with SMTP id 197so14763961wmk.1 for <24372@debbugs.gnu.org>; Sat, 01 Oct 2016 09:11:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=nz3TCZygJr1almkSJohJ8WAAZDR152+TKcZwDecqf/c=; b=oB5W3ay8l1f77RwracMrys6mMruKIGeYlhTp5o690fmOb4OgfjMsCdcew4XizNMf7L j4rlNHTDlT4S9Zb4Fad6mhdSd1jW77++Oz5iLavklmjFk2hP+i7iJgTzP2DAgR8m5W/V 2TulzYToYNZWVOrdB8TeuBX3aAtJKwbCccU8jOo3lb+ZnasWKIBDCvUPtZC/SM1/QEkW UlKOzfXPedBLFzEpeIDn0xYwZ+VNb+PF2JRgZOgDgB+s3Qxsd5Y3EGcu8WE34fsv/Q29 UDhbeT48KsVnTXzNphgH8G+yFK7FWmKtWS6nL67KaOc5s2CHK9/XVjZ4iHaz/Ah2rXRO F8zg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=nz3TCZygJr1almkSJohJ8WAAZDR152+TKcZwDecqf/c=; b=VQsWHosh+y3Fe9p3yMLbSWnimAVQdYp+ulJ3m9Sm3cs+fIC8lzu09TkseSkQT4TL+p ZbkI3qTctlPaYfDMpsjcaWaRSkQzuiVlJIqgCar/pNJeWtdw6bH4lWHNU35F6myFTlot fq3ldE6cgd4jZ9Oql3XZ0RMAGpsPlXNUGwy/fk2BT+/NAGBfWMdQVK1MfNOvWJAnxBIV XhJyU1ex90oAjyT1+A3mRUvxkr1RNsfKhPzSsGOr0Jf2tVF2t1vCq5BrfqvYI1lReqIw 61Jp4EWGqnp1Fn1Ac2tCtnsOTmgiZzMeBJNRjVX1M5Hzj2ImXha8GGGhfD4/W4xbsFJR 5evA== X-Gm-Message-State: AA6/9RnYcZbMo4vEvOiANX0rE1oUodEEkoKMmHCbby7dC209qwICrh8WPKciKRKiQ1f0vMLeFIEmEIoFR1Dl9A== X-Received: by 10.194.170.163 with SMTP id an3mr11274451wjc.73.1475338275955; Sat, 01 Oct 2016 09:11:15 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> <831t00mq6w.fsf@gnu.org> In-Reply-To: <831t00mq6w.fsf@gnu.org> From: Philipp Stephani Date: Sat, 01 Oct 2016 16:11:05 +0000 Message-ID: Content-Type: multipart/alternative; boundary=089e0122f07cdca867053dcff51a X-Spam-Score: 0.7 (/) 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.7 (/) --089e0122f07cdca867053dcff51a Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Sa., 1. Okt. 2016 um 10:25 Uhr: > > From: Philipp Stephani > > Date: Sun, 25 Sep 2016 19:09:52 +0000 > > Cc: 24372@debbugs.gnu.org > > > > > How about a variant of this below? It uses a fixed limitation from > > > below on the delay, but only for the first blink. (The value 0.2 was > > > found by experimentation, not sure if we need to add yet another > > > defcustom for that.) > > > > > > I don't think we should introduce magic numbers or further > customization options. > > > > It solves the problem, doesn't it? I don't mind very much if it were > > a defcustom, I just think no one would want to change it. > > > > OK, then it would be great to document the new behavior in the > documentation of `blink-cursor-delay' and also > > clarify what "starting to blink" means. > > Done. > Thanks! > > > > > I've attached another patch with the change I have in mind. > > > > > > This has a disadvantage of creating a new timer object each time, > > > which I think we'd like to avoid: too much consing. (Also, don't you > > > need to set the timer variable to nil when the timer is disabled?) > > > > > > I don't understand - the patch doesn't create any additional timers, > it only changes the initial delay of > > the > > > idle-timer. > > > > Each time blink-cursor--start-timer or blink-cursor--start-idle-timer > > is called, they create a new timer, right? And your patch makes us > > call these functions each time blinking is started or ended, right? > > > > No, the other patch is that it restarts the timers when the > customization options are set. Otherwise the options > > only become effective after a focus-out/focus-in event or something > similar that restarts the cursor. > > > > > My patch is identical, except is uses blink-cursor-interval as lower > bound. > > > > Of course. That's why I said it's a minor variant. > > > > There's another difference, though: in my patch we only limit the > > first argument to run-with-timer/run-with-idle-timer, not the second. > > So only the first blink cycle is affected. > > > > Doesn't that mean that the adjusted delay is applied only after the > first command, but not after subsequent > > commands? > > No, not AFAIK. The idle time starts anew after each command. > Indeed, the repeat argument of run-with-idle-timer is only checked for nil-ness and otherwise ignored. I'd suggest to pass something like :repeat or t to that argument so that readers are less confused. > > Is there anything left to do about this, or can we close this bug? > > The second patch (restarting the timers after the customization options changed) is still open, what about that one? --089e0122f07cdca867053dcff51a Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Sa., 1. Okt. 2016 um 10:25=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sun, 25 Sep 2016 19:09:52 +0000
> Cc: 24372@debbugs.gnu.org
>
>=C2=A0 > How about a variant of this below? It uses a fixed limitati= on from
>=C2=A0 > below on the delay, but only for the first blink. (The valu= e 0.2 was
>=C2=A0 > found by experimentation, not sure if we need to add yet an= other
>=C2=A0 > defcustom for that.)
>=C2=A0 >
>=C2=A0 > I don't think we should introduce magic numbers or furt= her customization options.
>
>=C2=A0 It solves the problem, doesn't it? I don't mind very muc= h if it were
>=C2=A0 a defcustom, I just think no one would want to change it.
>
> OK, then it would be great to document the new behavior in the documen= tation of `blink-cursor-delay' and also
> clarify what "starting to blink" means.

Done.

Thanks!
=
=C2=A0

>=C2=A0 > > I've attached another patch with the change I have= in mind.
>=C2=A0 >
>=C2=A0 > This has a disadvantage of creating a new timer object each= time,
>=C2=A0 > which I think we'd like to avoid: too much consing. (Al= so, don't you
>=C2=A0 > need to set the timer variable to nil when the timer is dis= abled?)
>=C2=A0 >
>=C2=A0 > I don't understand - the patch doesn't create any a= dditional timers, it only changes the initial delay of
>=C2=A0 the
>=C2=A0 > idle-timer.
>
>=C2=A0 Each time blink-cursor--start-timer or blink-cursor--start-idle-= timer
>=C2=A0 is called, they create a new timer, right? And your patch makes = us
>=C2=A0 call these functions each time blinking is started or ended, rig= ht?
>
> No, the other patch is that it restarts the timers when the customizat= ion options are set. Otherwise the options
> only become effective after a focus-out/focus-in event or something si= milar that restarts the cursor.
>
>=C2=A0 > My patch is identical, except is uses blink-cursor-interval= as lower bound.
>
>=C2=A0 Of course. That's why I said it's a minor variant.
>
>=C2=A0 There's another difference, though: in my patch we only limi= t the
>=C2=A0 first argument to run-with-timer/run-with-idle-timer, not the se= cond.
>=C2=A0 So only the first blink cycle is affected.
>
> Doesn't that mean that the adjusted delay is applied only after th= e first command, but not after subsequent
> commands?

No, not AFAIK.=C2=A0 The idle time starts anew after each command.

Indeed, the repeat argument= of run-with-idle-timer is only checked for nil-ness and otherwise ignored.= I'd suggest to pass something like :repeat or t to that argument so th= at readers are less confused.
=C2=A0

Is there anything left to do about this, or can we close this bug?


The second patch (= restarting the timers after the customization options changed) is still ope= n, what about that one?=C2=A0
--089e0122f07cdca867053dcff51a-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2016 17:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14753429951052 (code B ref 24372); Sat, 01 Oct 2016 17:30:02 +0000 Received: (at 24372) by debbugs.gnu.org; 1 Oct 2016 17:29:55 +0000 Received: from localhost ([127.0.0.1]:41315 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqO6k-0000Gu-Qw for submit@debbugs.gnu.org; Sat, 01 Oct 2016 13:29:54 -0400 Received: from eggs.gnu.org ([208.118.235.92]:55720) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqO6i-0000Gd-Hc for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 13:29:52 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqO6a-0008IR-3y for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 13:29:47 -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.2 required=5.0 tests=BAYES_50,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:37009) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqO6a-0008HO-0Y; Sat, 01 Oct 2016 13:29:44 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2266 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bqO6W-0006T9-6G; Sat, 01 Oct 2016 13:29:42 -0400 Date: Sat, 01 Oct 2016 20:29:35 +0300 Message-Id: <83d1jkkmf4.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Sat, 01 Oct 2016 16:11:05 +0000) References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> <831t00mq6w.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.0 (--------) 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: -8.0 (--------) > From: Philipp Stephani > Date: Sat, 01 Oct 2016 16:11:05 +0000 > Cc: 24372@debbugs.gnu.org > > Is there anything left to do about this, or can we close this bug? > > The second patch (restarting the timers after the customization options changed) is still open, what about > that one? Why is it needed? what doesn't still work right, now that I committed my changes? From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2016 18:11:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14753454424711 (code B ref 24372); Sat, 01 Oct 2016 18:11:01 +0000 Received: (at 24372) by debbugs.gnu.org; 1 Oct 2016 18:10:42 +0000 Received: from localhost ([127.0.0.1]:41328 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqOkD-0001Dv-MO for submit@debbugs.gnu.org; Sat, 01 Oct 2016 14:10:41 -0400 Received: from mail-wm0-f46.google.com ([74.125.82.46]:38385) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqOkB-0001Dh-IJ for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 14:10:41 -0400 Received: by mail-wm0-f46.google.com with SMTP id p138so79851621wmb.1 for <24372@debbugs.gnu.org>; Sat, 01 Oct 2016 11:10:39 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=EDiDQWqQF8dHQfj5c+6Fzafk60rA8zqDVBnoHtwuqug=; b=ySfAh+FSaWOfmsuMSKPtidvUSltwXzryOu4C+Q0BX2fYfrQ+zkVL9Nz3+dt1l54Asm xeVSpnxL6cvs/wKpcN7GnaeUvoKu1Q7ljuv3aGDoQYYIj3Eu9QM+0ubX50SPkq46k60R tKse6P5icmLEsrvQIIeh8C1QJOJX60nyjqj+lPgZBjZ2HTkDREpsc7GcpJqMVtB4pyYZ dVmnIj8n1hDJBlkIEj6lmqDFSZD8StWBHgV34iPwDc0SsxrDwsDn1ULYhCkP0A+nswRE +NuSe22TX0U2GV07iQuQkY4qxkZu3Uz2KLbjhLlIdJ0RozZG+gmp2YWJJBXZOYZgxIFV sJcQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=EDiDQWqQF8dHQfj5c+6Fzafk60rA8zqDVBnoHtwuqug=; b=LSDmYE8t2jp9utJrO3pp2BD0Gtr6CzX5o/ym3iUfBX1inR4PLAMprO+hhwPQe6RijT rP//UPo6BT7C64ofM0uo97dLUUTBkxyrF7vpXx7QTloC2m7osjmdqytP5Qpw74ZO7McJ QikeYS8wHTvwKFYrEpUA7cGCKaBe3PkY9hLH3PQmH0fYtl5LH2UoAVM97HMHlFH1JR3x dyTUE+ZZSWoQONVRVoOJ7v5H0WGvina6Ggz6cvxM4s+Ue9sRXzRRei17LtYas3KvLwt0 uhu6t1NE/4ljaEZkGtg9eyjzr4kAks/R/W8iqjGWjLaV9I+13+RmWB+nUtD/CTh0oQkZ DI4w== X-Gm-Message-State: AA6/9RlQNdejRuLOaCxrPavedeOabrkzEiymTdTcGF4A3ZKHLWp5MBQEsJP7MS//n+JWEKG/A8xuQooveQ2leg== X-Received: by 10.194.94.39 with SMTP id cz7mr395946wjb.141.1475345433315; Sat, 01 Oct 2016 11:10:33 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> <831t00mq6w.fsf@gnu.org> <83d1jkkmf4.fsf@gnu.org> In-Reply-To: <83d1jkkmf4.fsf@gnu.org> From: Philipp Stephani Date: Sat, 01 Oct 2016 18:10:22 +0000 Message-ID: Content-Type: multipart/alternative; boundary=047d7bb03ddc795076053dd1a013 X-Spam-Score: 0.7 (/) 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.7 (/) --047d7bb03ddc795076053dd1a013 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am Sa., 1. Okt. 2016 um 19:29 Uhr: > > From: Philipp Stephani > > Date: Sat, 01 Oct 2016 16:11:05 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Is there anything left to do about this, or can we close this bug? > > > > The second patch (restarting the timers after the customization options > changed) is still open, what about > > that one? > > Why is it needed? what doesn't still work right, now that I committed > my changes? > After customizing the variables, they don't become active immediately, only the next time the timers are restarted (e.g. after a focus-out/in event). The patches restarts the timers when setting the customization variables so that the new settings become active immediately. This is the root cause for the "After losing focus" part of the bug title. --047d7bb03ddc795076053dd1a013 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= Sa., 1. Okt. 2016 um 19:29=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 01 Oct 2016 16:11:05 +0000
> Cc: 24372@debbugs.gnu.org
>
>=C2=A0 Is there anything left to do about this, or can we close this bu= g?
>
> The second patch (restarting the timers after the customization option= s changed) is still open, what about
> that one?

Why is it needed? what doesn't still work right, now that I committed my changes?

After c= ustomizing the variables, they don't become active immediately, only th= e next time the timers are restarted (e.g. after a focus-out/in event). The= patches restarts the timers when setting the customization variables so th= at the new settings become active immediately. This is the root cause for t= he "After losing focus" part of the bug title.=C2=A0
<= /div> --047d7bb03ddc795076053dd1a013-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 01 Oct 2016 18:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.14753458085275 (code B ref 24372); Sat, 01 Oct 2016 18:17:01 +0000 Received: (at 24372) by debbugs.gnu.org; 1 Oct 2016 18:16:48 +0000 Received: from localhost ([127.0.0.1]:41333 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqOq8-0001N0-CR for submit@debbugs.gnu.org; Sat, 01 Oct 2016 14:16:48 -0400 Received: from mail-wm0-f43.google.com ([74.125.82.43]:38081) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqOq6-0001Mn-IF for 24372@debbugs.gnu.org; Sat, 01 Oct 2016 14:16:46 -0400 Received: by mail-wm0-f43.google.com with SMTP id p138so80020409wmb.1 for <24372@debbugs.gnu.org>; Sat, 01 Oct 2016 11:16:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=f4gJZSRsFW+I2a8ptfWwqJ1r3hg07U0BICuQWX3ujB8=; b=daQ+J1OPzQ+J2PK3zeIUxrU1UyrNsaQEwla4wn5AgduwJCUh8VkKgncl9E8pgcCNLl cdZsbGZPNznmp5V2h92N+aWvPswxdkV+yBgsIQpDeDmxLmLmfn3cjvOXzUH52bHgpCIF 3+yYMcUuc5vNy4VQ8yKLYr2pp1qgtz+o1WZq9LWJ2j8+57TSXpiDV8ktBHYOC6lxMAVd 1/2Swgnh6cFD2RJUhhB4+3jKgBCAxVnJWeFA7hhblzNQafZGRBXlCW0LBAHa5VHCMmrI G7vGqMnOxGMk2vdep/ar6W5cZZxakmdryZew8AxusMWj465MLqYod7QP6yls0OMsh9Ie hBrA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=f4gJZSRsFW+I2a8ptfWwqJ1r3hg07U0BICuQWX3ujB8=; b=Ko4QLoOuP6nDvyH+DpcWXY8pKJlMaq2hmq8O9RmL4/JVvTwIwbK8vXnM4kM1PVzz+s mgNKWodPeaMFictmwreXeu42xP5cXQ8IYMNr7d51VcIVCsWZUjMu1FZQIcP0MqnkHh1i WfcBsNbUSPE4jmz4gzRaeHkHeMH+Aj9Rwyc/j1kpr5p8dexO3eHKVyF0m08C7cgAb0Wd qxduU0DAxBl3IC15b4+gewbMqoIEron6WdTtDgRBbfCaPlKNUs0h/JXJo+yx3e/8HqU1 uiS5www6gkWF19pTXJCH2uIp+L2s9I+wzubH9UCGhZH5tT/opbDQYnN2Abo6IWP9HR70 m/2A== X-Gm-Message-State: AA6/9Rk+I/k/t+Td3Ym2HMWQqd4+Bc7k8DUnXpJFb/4qE4YkJhfyR+dJSb3Leu5PrYL39zwZIVg2PVe6Zl3jWg== X-Received: by 10.28.125.209 with SMTP id y200mr3424345wmc.112.1475345800948; Sat, 01 Oct 2016 11:16:40 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> <831t00mq6w.fsf@gnu.org> In-Reply-To: From: Philipp Stephani Date: Sat, 01 Oct 2016 18:16:30 +0000 Message-ID: Content-Type: multipart/mixed; boundary=001a1141e660632399053dd1b689 X-Spam-Score: 0.7 (/) 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.7 (/) --001a1141e660632399053dd1b689 Content-Type: multipart/alternative; boundary=001a1141e660632393053dd1b687 --001a1141e660632393053dd1b687 Content-Type: text/plain; charset=UTF-8 Philipp Stephani schrieb am Sa., 1. Okt. 2016 um 18:11 Uhr: > Indeed, the repeat argument of run-with-idle-timer is only checked for > nil-ness and otherwise ignored. I'd suggest to pass something like :repeat > or t to that argument so that readers are less confused. > > I've attached another patch that does this. --001a1141e660632393053dd1b687 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Philip= p Stephani <p.stephani2@gmail.c= om> schrieb am Sa., 1. Okt. 2016 um 18:11=C2=A0Uhr:
Indeed, the rep= eat argument of run-with-idle-timer is only checked for nil-ness and otherw= ise ignored. I'd suggest to pass something like :repeat or t to that ar= gument so that readers are less confused.
=C2=A0

I'= ve attached another patch that does this.=C2=A0
--001a1141e660632393053dd1b687-- --001a1141e660632399053dd1b689 Content-Type: text/plain; charset=US-ASCII; name="0001-Use-a-simple-keyword-for-a-non-nil-argument.txt" Content-Disposition: attachment; filename="0001-Use-a-simple-keyword-for-a-non-nil-argument.txt" Content-Transfer-Encoding: base64 Content-ID: <15781762241ca461d2c1> X-Attachment-Id: 15781762241ca461d2c1 RnJvbSAwOGIzODZkYjFmNDIxMmNlOTBmNzI2NDQyZmNmMzU2ODg1ZmIzMWFlIE1vbiBTZXAgMTcg MDA6MDA6MDAgMjAwMQpGcm9tOiBQaGlsaXBwIFN0ZXBoYW5pIDxwaHN0QGdvb2dsZS5jb20+CkRh dGU6IFNhdCwgMSBPY3QgMjAxNiAyMDoxMzo1MyArMDIwMApTdWJqZWN0OiBbUEFUQ0hdIFVzZSBh IHNpbXBsZSBrZXl3b3JkIGZvciBhIG5vbi1uaWwgYXJndW1lbnQKClRoZSBzZWNvbmQgYXJndW1l bnQgb2YgYHJ1bi13aXRoLWlkbGUtdGltZXInIGlzIEJvb2xlYW4sIGkuZS4gb25seSBuaWwKYW5k IG5vbi1uaWwgdmFsdWVzIGFyZSBkaXN0aW5ndWlzaGVkLiAgUGFzc2luZyBhIG51bWJlciBoZXJl IGlzCmNvbmZ1c2luZy4gIFBhc3MgYSBkZXNjcmlwdGl2ZSBzeW1ib2wgaW5zdGVhZC4KCiogbGlz cC9mcmFtZS5lbCAoYmxpbmstY3Vyc29yLW1vZGUsIGJsaW5rLWN1cnNvci1jaGVjayk6IFVzZQo6 cmVwZWF0IHN5bWJvbCBpbnN0ZWFkIG9mIG51bWJlciBmb3Igc2Vjb25kIGFyZ3VtZW50IG9mCmBy dW4td2l0aC1pZGxlLXRpbWVyJwotLS0KIGxpc3AvZnJhbWUuZWwgfCA2ICsrLS0tLQogMSBmaWxl IGNoYW5nZWQsIDIgaW5zZXJ0aW9ucygrKSwgNCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQgYS9s aXNwL2ZyYW1lLmVsIGIvbGlzcC9mcmFtZS5lbAppbmRleCBiMTM2MjFhLi5kM2I2MzUzIDEwMDY0 NAotLS0gYS9saXNwL2ZyYW1lLmVsCisrKyBiL2xpc3AvZnJhbWUuZWwKQEAgLTIxMTksOCArMjEx OSw3IEBAIGJsaW5rLWN1cnNvci1jaGVjawogICAgICAgICAgIDs7IGR1cmluZyBjb21tYW5kIGV4 ZWN1dGlvbikgaWYgdGhleSBzZXQgYmxpbmstY3Vyc29yLWRlbGF5CiAgICAgICAgICAgOzsgdG8g YSB2ZXJ5IHNtYWxsIG9yIGV2ZW4gemVybyB2YWx1ZS4KICAgICAgICAgICAocnVuLXdpdGgtaWRs ZS10aW1lciAobWF4IDAuMiBibGluay1jdXJzb3ItZGVsYXkpCi0gICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgYmxpbmstY3Vyc29yLWRlbGF5Ci0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJ2JsaW5rLWN1cnNvci1zdGFydCkpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICA6cmVwZWF0ICMnYmxpbmstY3Vyc29yLXN0YXJ0KSkpKQogCiAoZGVmaW5lLW9ic29sZXRl LXZhcmlhYmxlLWFsaWFzICdibGluay1jdXJzb3IgJ2JsaW5rLWN1cnNvci1tb2RlICIyMi4xIikK IApAQCAtMjE1Nyw4ICsyMTU2LDcgQEAgYmxpbmstY3Vyc29yLW1vZGUKICAgICAgICAgICA7OyBk dXJpbmcgY29tbWFuZCBleGVjdXRpb24pIGlmIHRoZXkgc2V0IGJsaW5rLWN1cnNvci1kZWxheQog ICAgICAgICAgIDs7IHRvIGEgdmVyeSBzbWFsbCBvciBldmVuIHplcm8gdmFsdWUuCiAgICAgICAg ICAgKHJ1bi13aXRoLWlkbGUtdGltZXIgKG1heCAwLjIgYmxpbmstY3Vyc29yLWRlbGF5KQotICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgIGJsaW5rLWN1cnNvci1kZWxheQotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICMnYmxpbmstY3Vyc29yLXN0YXJ0KSkpKQorICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIDpyZXBlYXQgIydibGluay1jdXJzb3Itc3RhcnQpKSkpCiAK IAwKIDs7IEZyYW1lIG1heGltaXphdGlvbi9mdWxsc2NyZWVuCi0tIAoyLjEwLjAKCg== --001a1141e660632399053dd1b689-- From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Oct 2016 07:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147539234513299 (code B ref 24372); Sun, 02 Oct 2016 07:13:02 +0000 Received: (at 24372) by debbugs.gnu.org; 2 Oct 2016 07:12:25 +0000 Received: from localhost ([127.0.0.1]:41482 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqawi-0003SQ-Ki for submit@debbugs.gnu.org; Sun, 02 Oct 2016 03:12:24 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44271) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqawh-0003SB-3f for 24372@debbugs.gnu.org; Sun, 02 Oct 2016 03:12:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqawY-0007nb-Tx for 24372@debbugs.gnu.org; Sun, 02 Oct 2016 03:12:18 -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,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:42870) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqawY-0007nX-R2; Sun, 02 Oct 2016 03:12:14 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2954 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bqawX-0000UG-UT; Sun, 02 Oct 2016 03:12:14 -0400 Date: Sun, 02 Oct 2016 10:12:24 +0300 Message-Id: <83y427jkbr.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Sat, 01 Oct 2016 18:10:22 +0000) References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> <831t00mq6w.fsf@gnu.org> <83d1jkkmf4.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.0 (--------) 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: -8.0 (--------) > From: Philipp Stephani > Date: Sat, 01 Oct 2016 18:10:22 +0000 > Cc: 24372@debbugs.gnu.org > > > The second patch (restarting the timers after the customization options changed) is still open, what > about > > that one? > > Why is it needed? what doesn't still work right, now that I committed > my changes? > > After customizing the variables, they don't become active immediately, only the next time the timers are > restarted (e.g. after a focus-out/in event). The patches restarts the timers when setting the customization > variables so that the new settings become active immediately. This is the root cause for the "After losing > focus" part of the bug title. I'm okay with pushing this to the master branch. Thanks. From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Oct 2016 07:15:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Philipp Stephani Cc: 24372@debbugs.gnu.org Reply-To: Eli Zaretskii Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147539246113508 (code B ref 24372); Sun, 02 Oct 2016 07:15:01 +0000 Received: (at 24372) by debbugs.gnu.org; 2 Oct 2016 07:14:21 +0000 Received: from localhost ([127.0.0.1]:41486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqayb-0003Vo-2d for submit@debbugs.gnu.org; Sun, 02 Oct 2016 03:14:21 -0400 Received: from eggs.gnu.org ([208.118.235.92]:44607) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bqaya-0003Vc-Bt for 24372@debbugs.gnu.org; Sun, 02 Oct 2016 03:14:20 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1bqayS-0000Bs-6X for 24372@debbugs.gnu.org; Sun, 02 Oct 2016 03:14:15 -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,RP_MATCHES_RCVD autolearn=disabled version=3.3.2 Received: from fencepost.gnu.org ([2001:4830:134:3::e]:43063) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1bqayS-0000BG-34; Sun, 02 Oct 2016 03:14:12 -0400 Received: from 84.94.185.246.cable.012.net.il ([84.94.185.246]:2958 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:RSA_AES_128_CBC_SHA1:128) (Exim 4.82) (envelope-from ) id 1bqayP-0000fu-LY; Sun, 02 Oct 2016 03:14:10 -0400 Date: Sun, 02 Oct 2016 10:14:18 +0300 Message-Id: <83wphrjk8l.fsf@gnu.org> From: Eli Zaretskii In-reply-to: (message from Philipp Stephani on Sat, 01 Oct 2016 18:16:30 +0000) References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> <831t00mq6w.fsf@gnu.org> X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2001:4830:134:3::e X-Spam-Score: -8.0 (--------) 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: -8.0 (--------) > From: Philipp Stephani > Date: Sat, 01 Oct 2016 18:16:30 +0000 > Cc: 24372@debbugs.gnu.org > > Indeed, the repeat argument of run-with-idle-timer is only checked for nil-ness and otherwise ignored. I'd > suggest to pass something like :repeat or t to that argument so that readers are less confused. > > I've attached another patch that does this. Thanks, please push to master. From unknown Tue Aug 19 10:09:22 2025 X-Loop: help-debbugs@gnu.org Subject: bug#24372: 25.1.50; After losing focus, cursor is hidden when moving point Resent-From: Philipp Stephani Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 02 Oct 2016 17:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 24372 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 24372@debbugs.gnu.org Received: via spool by 24372-submit@debbugs.gnu.org id=B24372.147543100622038 (code B ref 24372); Sun, 02 Oct 2016 17:57:02 +0000 Received: (at 24372) by debbugs.gnu.org; 2 Oct 2016 17:56:46 +0000 Received: from localhost ([127.0.0.1]:42194 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bql0H-0005jN-QR for submit@debbugs.gnu.org; Sun, 02 Oct 2016 13:56:46 -0400 Received: from mail-wm0-f50.google.com ([74.125.82.50]:36558) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1bql0G-0005j8-7S for 24372@debbugs.gnu.org; Sun, 02 Oct 2016 13:56:44 -0400 Received: by mail-wm0-f50.google.com with SMTP id k125so111014120wma.1 for <24372@debbugs.gnu.org>; Sun, 02 Oct 2016 10:56:44 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc; bh=oWwYXW0O5/C6DCXWX3Stn3IudiW7sUvua+fZeVJ0o3I=; b=J80y45+73QvlrSZx7VPqHonPtWX9TTsm37UQeWR5IaIrdUO92wUARt+UhSBDkGi3pU QOjabGGwhXX4cnPgWvLisuQmgrMmC9WrXKhfejHj+DO7myeEpdA5R/rZ0Z/dllIJznFE RPl5bGcY0Sojcn3rp6zKBU2aqCf9jqK32akCgH0VbBNkFjlSf71ADYUsI9M19cP6uzQJ 9lMbuiXbZFgTg+qHCaDNMVXYe5I3wwuXIxibWoZ64qkFIGNZ5LKPJYjVmnb2nmEN2vHJ 7lF2E+Fidnzfmaw4SJIyRDYHhGczk7N/ca2FkXjRoenh04KShsig/ks6U37bI3lhkfug Jc+g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc; bh=oWwYXW0O5/C6DCXWX3Stn3IudiW7sUvua+fZeVJ0o3I=; b=jI++TfDkuy/UILkfcGkRagmBBDyVMyzdKhX3GIPgJW5BYh56gGJzZU1uJ5JCLsNFVa nL77ho/ArxIVHQIpRR9Ykmuc4wLRQV6mGnUaE25b+4r4N0L1pH++sT7mSZxrw0wLQrTa iJEDZC1K2kEp8J2YyFBSAIpdgawX1SPGgCERplJZ5YgGgU0zcZETie9Jo3Her2bUR5dX fS+2IUbusplbbSVXBDGxkrSeP9nS0ZQIrRmLdA/U4HQqSmH6No/KKWrWgDpOtCZiheZX M5UmMlhA2YxiISdun0Z6ezSMOE5sdcg33kzMIO8jGdUKCOCVozC+mz/NVow/a0pW84lZ 7OBg== X-Gm-Message-State: AA6/9RlXZOODBgmUcl2prHrpDInutgj4tIU536Ko5qPk8g0Tktuq1DlfX7hZ5dC/mylMfzlqR4YL3cKFDtbwmQ== X-Received: by 10.194.149.238 with SMTP id ud14mr14090354wjb.194.1475430998389; Sun, 02 Oct 2016 10:56:38 -0700 (PDT) MIME-Version: 1.0 References: <83a8flaud3.fsf@gnu.org> <831t0t83br.fsf@gnu.org> <83mvjg8bk2.fsf@gnu.org> <8360q2be2b.fsf@gnu.org> <83twdm9re9.fsf@gnu.org> <831t00mq6w.fsf@gnu.org> <83wphrjk8l.fsf@gnu.org> In-Reply-To: <83wphrjk8l.fsf@gnu.org> From: Philipp Stephani Date: Sun, 02 Oct 2016 17:56:27 +0000 Message-ID: Content-Type: multipart/alternative; boundary=089e01228b948cbbc7053de58c64 X-Spam-Score: 0.2 (/) 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 (/) --089e01228b948cbbc7053de58c64 Content-Type: text/plain; charset=UTF-8 Eli Zaretskii schrieb am So., 2. Okt. 2016 um 09:14 Uhr: > > From: Philipp Stephani > > Date: Sat, 01 Oct 2016 18:16:30 +0000 > > Cc: 24372@debbugs.gnu.org > > > > Indeed, the repeat argument of run-with-idle-timer is only checked for > nil-ness and otherwise ignored. I'd > > suggest to pass something like :repeat or t to that argument so that > readers are less confused. > > > > I've attached another patch that does this. > > Thanks, please push to master. > Both pushed. --089e01228b948cbbc7053de58c64 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable


Eli Za= retskii <eliz@gnu.org> schrieb am= So., 2. Okt. 2016 um 09:14=C2=A0Uhr:
> From: Philipp Stephani <p.stephani2@gmail.com>
> Date: Sat, 01 Oct 2016 18:16:30 +0000
> Cc: 24372@debbugs.gnu.org
>
>=C2=A0 Indeed, the repeat argument of run-with-idle-timer is only check= ed for nil-ness and otherwise ignored. I'd
>=C2=A0 suggest to pass something like :repeat or t to that argument so = that readers are less confused.
>
> I've attached another patch that does this.

Thanks, please push to master.
Both pushed.=C2=A0
--089e01228b948cbbc7053de58c64--