GNU bug report logs - #53276
The blink-cursor-mode not work after startup on macOS

Previous Next

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 53276 in the body.
You can then email your comments to 53276 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

Message #5 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Eason Huang <aqua0210 <at> foxmail.com>
To: bug-gnu-emacs <at> gnu.org
Subject: The blink-cursor-mode not work after startup on macOS
Date: Sat, 15 Jan 2022 12:41:27 +0800

Hi,

I found a problem when using Emacs 29 on macOS:

When Emacs is started at the first time, the blink-cursor-mode does
not work, and the focus needs to be switched to another
application, and then switching back again, it will work properly.

I tested with emacs -Q.
On other platforms (Linux, Windows) there is no such problem, It only
happened on macOS.



In GNU Emacs 29.0.50 (build 1, x86_64-apple-darwin19.6.0, NS appkit-1894.60 Version 10.15.7 (Build 19H1615))
of 2022-01-14 built on Mac-1642119124451.local
Repository revision: d476fd33ece51f506644cec737490eda96daf46c
Repository branch: HEAD
Windowing system distributor 'Apple', version 10.3.2113
System Description:  macOS 12.1

Configured using:
'configure --with-ns --with-modules
'--enable-locallisppath=/Library/Application
Support/Emacs/${version}/site-lisp:/Library/Application
Support/Emacs/site-lisp' --with-xwidgets --with-native-compilation
'CFLAGS=-I/usr/local/opt/gcc/include -I/usr/local/opt/libgccjit/include
-O2' 'LDFLAGS=-L/usr/local/opt/gcc/lib/gcc/11
-L/usr/local/opt/gcc/lib/gcc/11/gcc/x86_64-apple-darwin19/11
-L/usr/local/opt/libgccjit/lib/gcc/11 -I/usr/local/opt/gcc/include
-I/usr/local/opt/libgccjit/include -Wl,-headerpad_max_install_names''

Configured features:
ACL GIF GLIB GMP GNUTLS JPEG JSON LCMS2 LIBXML2 MODULES NATIVE_COMP
NOTIFY KQUEUE NS PDUMPER PNG RSVG SQLITE3 THREADS TIFF
TOOLKIT_SCROLL_BARS WEBP XIM XWIDGETS ZLIB

Important settings:
  value of $LC_CTYPE: en_US.UTF-8
  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
  eldoc-mode: t
  show-paren-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
  indent-tabs-mode: t
  transient-mark-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug message mailcap yank-media rmc puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search time-date seq gv
subr-x byte-opt bytecomp byte-compile cconv mm-decode mm-bodies
mm-encode mail-parse rfc2231 mailabbrev gmm-utils mailheader cl-loaddefs
cl-lib sendmail rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils
iso-transl tooltip eldoc paren electric uniquify ediff-hook vc-hooks
lisp-float-type elisp-mode mwheel term/ns-win ns-win ucs-normalize
mule-util term/common-win tool-bar dnd fontset image regexp-opt fringe
tabulated-list replace newcomment text-mode lisp-mode prog-mode register
page tab-bar menu-bar rfn-eshadow isearch easymenu timer select
scroll-bar mouse jit-lock font-lock syntax font-core term/tty-colors
frame minibuffer cl-generic cham georgian utf-8-lang misc-lang
vietnamese tibetan thai tai-viet lao korean japanese eucjp-ms cp51932
hebrew greek romanian slovak czech european ethiopic indian cyrillic
chinese composite emoji-zwj charscript charprop case-table epa-hook
jka-cmpr-hook help simple abbrev obarray cl-preloaded nadvice button
loaddefs faces cus-face macroexp files window text-properties overlay
sha1 md5 base64 format env code-pages mule custom widget keymap
hashtable-print-readable backquote threads xwidget-internal kqueue cocoa
ns lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 58007 8547)
(symbols 48 5602 0)
(strings 32 16385 1905)
(string-bytes 1 542461)
(vectors 16 12798)
(vector-slots 8 277048 11061)
(floats 8 21 39)
(intervals 56 338 0)
(buffers 992 11))

Message #8 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eason Huang <aqua0210 <at> foxmail.com>
Cc: Alan Third <alan <at> idiocy.org>, 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Sat, 15 Jan 2022 15:04:35 +0800

Eason Huang <aqua0210 <at> foxmail.com> writes:

> When Emacs is started at the first time, the blink-cursor-mode does
> not work, and the focus needs to be switched to another
> application, and then switching back again, it will work properly.

blink-cursor-mode will only start the idle timer that actually blinks
the cursor if at least one frame is focused, but no FOCUS_IN_EVENT is
sent until windowDidBecomeKey is called a second time, as emacs_event is
NULL when windowDidBecomeKey is first called.  This is both on GNUstep
and macOS.  (Perhaps storing the FOCUS_IN_EVENT into the keyboard buffer
would be an option.)

Alan, do you have any idea as to why this is?  I'm afraid I don't really
understand the NS event loop code.

Thanks in advance.

Message #11 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Alan Third <alan <at> idiocy.org>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Eason Huang <aqua0210 <at> foxmail.com>, 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Sat, 15 Jan 2022 12:34:10 +0000

On Sat, Jan 15, 2022 at 03:04:35PM +0800, Po Lu wrote:
> Eason Huang <aqua0210 <at> foxmail.com> writes:
> 
> > When Emacs is started at the first time, the blink-cursor-mode does
> > not work, and the focus needs to be switched to another
> > application, and then switching back again, it will work properly.
> 
> blink-cursor-mode will only start the idle timer that actually blinks
> the cursor if at least one frame is focused, but no FOCUS_IN_EVENT is
> sent until windowDidBecomeKey is called a second time, as emacs_event is
> NULL when windowDidBecomeKey is first called.  This is both on GNUstep
> and macOS.  (Perhaps storing the FOCUS_IN_EVENT into the keyboard buffer
> would be an option.)
> 
> Alan, do you have any idea as to why this is?  I'm afraid I don't really
> understand the NS event loop code.

No, I don't know why it's done this way. There are a number of other
bugs that have the same root cause, where emacs_event is null because
the code is being called outside the run loop and therefore the event
never reaches Emacs.

My assumption is that there is a reason why it's done this way, but I
can't work it out.

I had a look at some of the other terms and they *kind of* work in a
similar fashion, in that there's one function that scoops up all the
events and passes them to Emacs (like ns_read_socket does) but they
differ in that the events are queued up by the system before they're
read in. So given that I wonder if the NS port is just copying that
style from other terms, but it doesn't actually work right.

(I sometimes think it would be nice if we had git history for the NS
port from before it was merged in, because a lot of these design
decisions are ancient and it's unclear why they were made.)
-- 
Alan Third

Message #14 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Eason Huang <aqua0210 <at> foxmail.com>, 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Sat, 15 Jan 2022 21:05:38 +0800

Alan Third <alan <at> idiocy.org> writes:

> On Sat, Jan 15, 2022 at 03:04:35PM +0800, Po Lu wrote:
>> Eason Huang <aqua0210 <at> foxmail.com> writes:
>> 
>> > When Emacs is started at the first time, the blink-cursor-mode does
>> > not work, and the focus needs to be switched to another
>> > application, and then switching back again, it will work properly.
>> 
>> blink-cursor-mode will only start the idle timer that actually blinks
>> the cursor if at least one frame is focused, but no FOCUS_IN_EVENT is
>> sent until windowDidBecomeKey is called a second time, as emacs_event is
>> NULL when windowDidBecomeKey is first called.  This is both on GNUstep
>> and macOS.  (Perhaps storing the FOCUS_IN_EVENT into the keyboard buffer
>> would be an option.)
>> 
>> Alan, do you have any idea as to why this is?  I'm afraid I don't really
>> understand the NS event loop code.
>
> No, I don't know why it's done this way. There are a number of other
> bugs that have the same root cause, where emacs_event is null because
> the code is being called outside the run loop and therefore the event
> never reaches Emacs.

I think the right solution is to store events directly into the keyboard
buffer instead of using emacs_event, but I don't know if there's a
reason the NS port was not developed that way.

> My assumption is that there is a reason why it's done this way, but I
> can't work it out.

Basically, it fits well into the pselect-read-XPending-XNextEvent model
that most X-Windows applications are designed around.  The other ports
are then designed around this X model.

> I had a look at some of the other terms and they *kind of* work in a
> similar fashion, in that there's one function that scoops up all the
> events and passes them to Emacs (like ns_read_socket does) but they
> differ in that the events are queued up by the system before they're
> read in.

Does NS not queue unread events until they're read?  That seems like odd
design to me.

> So given that I wonder if the NS port is just copying that style from
> other terms, but it doesn't actually work right.

That style is reasonable (think of it like `read', except it reads
events from a display server connection into the keyboard buffer), but
what I don't understand here is why callback methods like
windowDidBecomeKey can't just call kbd_buffer_store_event, instead going
through all the trouble to allocate a temporary buffer and using that to
hold the events.

Thanks in advance.

> (I sometimes think it would be nice if we had git history for the NS
> port from before it was merged in, because a lot of these design
> decisions are ancient and it's unclear why they were made.)

I agree.

Message #17 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Eason Huang <aqua0210 <at> foxmail.com>, 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Sat, 15 Jan 2022 21:11:30 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> I think the right solution is to store events directly into the keyboard
> buffer instead of using emacs_event, but I don't know if there's a
> reason the NS port was not developed that way.

If you don't know the answer, I think we should install the following
version of `windowDidBecomeKey' in master and see if anyone complains:

    - (void)windowDidBecomeKey      /* for direct calls */
    {
      struct ns_display_info *dpyinfo = FRAME_DISPLAY_INFO (emacsframe);
      struct frame *old_focus = dpyinfo->ns_focus_frame;
      struct input_event event;

      EVENT_INIT (event);

      NSTRACE ("[EmacsView windowDidBecomeKey]");

      if (emacsframe != old_focus)
        dpyinfo->ns_focus_frame = emacsframe;

      ns_frame_rehighlight (emacsframe);

      event.kind = FOCUS_IN_EVENT;
      XSETFRAME (event.frame_or_window, emacsframe);
      kbd_buffer_store_event (&event);
    }

And if nobody complains in a year, convert the rest of the places where
emacs_event is used to do this as well.

WDYT?

Message #20 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Alan Third <alan <at> idiocy.org>
Cc: Eason Huang <aqua0210 <at> foxmail.com>, 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Fri, 21 Jan 2022 09:19:01 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> If you don't know the answer, I think we should install the following
> version of `windowDidBecomeKey' in master and see if anyone complains:
>
>     - (void)windowDidBecomeKey      /* for direct calls */
>     {
>       struct ns_display_info *dpyinfo = FRAME_DISPLAY_INFO (emacsframe);
>       struct frame *old_focus = dpyinfo->ns_focus_frame;
>       struct input_event event;
>
>       EVENT_INIT (event);
>
>       NSTRACE ("[EmacsView windowDidBecomeKey]");
>
>       if (emacsframe != old_focus)
>         dpyinfo->ns_focus_frame = emacsframe;
>
>       ns_frame_rehighlight (emacsframe);
>
>       event.kind = FOCUS_IN_EVENT;
>       XSETFRAME (event.frame_or_window, emacsframe);
>       kbd_buffer_store_event (&event);
>     }
>
> And if nobody complains in a year, convert the rest of the places where
> emacs_event is used to do this as well.

I pushed this to master along with another change that should hopefully
let C-g be handled much faster on the NS port.

Eason, can you let me know if the problem has been solved for you?
Thanks.

Message #23 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Eason Huang <aqua0210 <at> foxmail.com>
To: Po Lu <luangruo <at> yahoo.com>
Cc: Alan Third <alan <at> idiocy.org>, 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Fri, 21 Jan 2022 19:38:19 +0800

Po Lu <luangruo <at> yahoo.com> writes:

> I pushed this to master along with another change that should hopefully
> let C-g be handled much faster on the NS port.
>
> Eason, can you let me know if the problem has been solved for you?

Hi @Po Lu,

I upgrade my Emacs to latest commit, and it's working well now.
Thanks for your great work.

----
From Eason Huang

Message #28 received at 53276-done <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Eason Huang <aqua0210 <at> foxmail.com>
Cc: Alan Third <alan <at> idiocy.org>, 53276-done <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Fri, 21 Jan 2022 19:41:22 +0800

Eason Huang <aqua0210 <at> foxmail.com> writes:

> I upgrade my Emacs to latest commit, and it's working well now.
> Thanks for your great work.

Thanks, I'm closing this bug.

Message #31 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eason Huang <aqua0210 <at> foxmail.com>
Cc: Po Lu <luangruo <at> yahoo.com>, Alan Third <alan <at> idiocy.org>,
 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Thu, 27 Jan 2022 16:06:52 +0100

>>>>> On Fri, 21 Jan 2022 19:38:19 +0800, Eason Huang <aqua0210 <at> foxmail.com> said:

    Eason> Po Lu <luangruo <at> yahoo.com> writes:
    >> I pushed this to master along with another change that should hopefully
    >> let C-g be handled much faster on the NS port.
    >> 
    >> Eason, can you let me know if the problem has been solved for you?

    Eason> Hi @Po Lu,

    Eason> I upgrade my Emacs to latest commit, and it's working well now.
    Eason> Thanks for your great work.

Hmm, Iʼm not sure this is 100% fixed.

emacs -Q
=> unfocused emacs with hollow cursor
- click somewhere in *scratch*, cursor become solid, but doesnʼt
blink.
- After a few seconds, cursor starts blinking
- After a few seconds, cursor stops blinking, and doesnʼt start unless I
move the cursor. And then it stops again. repeat.

Robert
-- 

Message #34 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: luangruo <at> yahoo.com, aqua0210 <at> foxmail.com, alan <at> idiocy.org,
 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Thu, 27 Jan 2022 18:43:41 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Date: Thu, 27 Jan 2022 16:06:52 +0100
> Cc: Po Lu <luangruo <at> yahoo.com>, Alan Third <alan <at> idiocy.org>,
>  53276 <at> debbugs.gnu.org
> 
> - After a few seconds, cursor stops blinking, and doesnʼt start unless I
> move the cursor. And then it stops again. repeat.

This last part is normal: that's how blink-cursor-mode works by
default.

Message #37 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, aqua0210 <at> foxmail.com, alan <at> idiocy.org,
 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Thu, 27 Jan 2022 18:02:34 +0100

>>>>> On Thu, 27 Jan 2022 18:43:41 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Date: Thu, 27 Jan 2022 16:06:52 +0100
    >> Cc: Po Lu <luangruo <at> yahoo.com>, Alan Third <alan <at> idiocy.org>,
    >> 53276 <at> debbugs.gnu.org
    >> 
    >> - After a few seconds, cursor stops blinking, and doesnʼt start unless I
    >> move the cursor. And then it stops again. repeat.

    Eli> This last part is normal: that's how blink-cursor-mode works by
    Eli> default.

Ah. Can you tell I have it turned off? :-)

Robert
-- 

Message #40 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: luangruo <at> yahoo.com, aqua0210 <at> foxmail.com, alan <at> idiocy.org,
 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Thu, 27 Jan 2022 19:07:14 +0200

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: aqua0210 <at> foxmail.com,  luangruo <at> yahoo.com,  alan <at> idiocy.org,
>   53276 <at> debbugs.gnu.org
> Date: Thu, 27 Jan 2022 18:02:34 +0100
> 
> >>>>> On Thu, 27 Jan 2022 18:43:41 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> Date: Thu, 27 Jan 2022 16:06:52 +0100
>     >> Cc: Po Lu <luangruo <at> yahoo.com>, Alan Third <alan <at> idiocy.org>,
>     >> 53276 <at> debbugs.gnu.org
>     >> 
>     >> - After a few seconds, cursor stops blinking, and doesnʼt start unless I
>     >> move the cursor. And then it stops again. repeat.
> 
>     Eli> This last part is normal: that's how blink-cursor-mode works by
>     Eli> default.
> 
> Ah. Can you tell I have it turned off? :-)

You mean, how to make the cursor keep blinking forever? set
blink-cursor-blinks to zero.

Message #43 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Robert Pluim <rpluim <at> gmail.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: luangruo <at> yahoo.com, aqua0210 <at> foxmail.com, alan <at> idiocy.org,
 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Thu, 27 Jan 2022 18:15:49 +0100

>>>>> On Thu, 27 Jan 2022 19:07:14 +0200, Eli Zaretskii <eliz <at> gnu.org> said:

    >> From: Robert Pluim <rpluim <at> gmail.com>
    >> Cc: aqua0210 <at> foxmail.com,  luangruo <at> yahoo.com,  alan <at> idiocy.org,
    >> 53276 <at> debbugs.gnu.org
    >> Date: Thu, 27 Jan 2022 18:02:34 +0100
    >> 
    >> >>>>> On Thu, 27 Jan 2022 18:43:41 +0200, Eli Zaretskii <eliz <at> gnu.org> said:
    >> 
    >> >> From: Robert Pluim <rpluim <at> gmail.com>
    >> >> Date: Thu, 27 Jan 2022 16:06:52 +0100
    >> >> Cc: Po Lu <luangruo <at> yahoo.com>, Alan Third <alan <at> idiocy.org>,
    >> >> 53276 <at> debbugs.gnu.org
    >> >> 
    >> >> - After a few seconds, cursor stops blinking, and doesnʼt start unless I
    >> >> move the cursor. And then it stops again. repeat.
    >> 
    Eli> This last part is normal: that's how blink-cursor-mode works by
    Eli> default.
    >> 
    >> Ah. Can you tell I have it turned off? :-)

    Eli> You mean, how to make the cursor keep blinking forever? set
    Eli> blink-cursor-blinks to zero.

No, I meant "I have it turned off, so I had a misconception about how
it was supposed to function"

Robert
-- 

Message #46 received at 53276 <at> debbugs.gnu.org (full text, mbox):

From: Po Lu <luangruo <at> yahoo.com>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: Eason Huang <aqua0210 <at> foxmail.com>, Alan Third <alan <at> idiocy.org>,
 53276 <at> debbugs.gnu.org
Subject: Re: bug#53276: The blink-cursor-mode not work after startup on macOS
Date: Fri, 28 Jan 2022 08:38:05 +0800

Robert Pluim <rpluim <at> gmail.com> writes:

> Hmm, Iʼm not sure this is 100% fixed.

> emacs -Q
> => unfocused emacs with hollow cursor
> - click somewhere in *scratch*, cursor become solid, but doesnʼt
> blink.
> - After a few seconds, cursor starts blinking
> - After a few seconds, cursor stops blinking, and doesnʼt start unless I
> move the cursor. And then it stops again. repeat.

Isn't that how blink-cursor-mode works anyway?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.