unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
* bug#53276: The blink-cursor-mode not work after startup on macOS
@ 2022-01-15  4:41 Eason Huang
  2022-01-15  7:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 8+ messages in thread
From: Eason Huang @ 2022-01-15  4:41 UTC (permalink / raw)
  To: 53276

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))





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#53276: The blink-cursor-mode not work after startup on macOS
  2022-01-15  4:41 bug#53276: The blink-cursor-mode not work after startup on macOS Eason Huang
@ 2022-01-15  7:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-01-15 12:34   ` Alan Third
  0 siblings, 1 reply; 8+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-15  7:04 UTC (permalink / raw)
  To: Eason Huang; +Cc: Alan Third, 53276

Eason Huang <aqua0210@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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#53276: The blink-cursor-mode not work after startup on macOS
  2022-01-15  7:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-01-15 12:34   ` Alan Third
  2022-01-15 13:05     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 8+ messages in thread
From: Alan Third @ 2022-01-15 12:34 UTC (permalink / raw)
  To: Po Lu; +Cc: Eason Huang, 53276

On Sat, Jan 15, 2022 at 03:04:35PM +0800, Po Lu wrote:
> Eason Huang <aqua0210@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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#53276: The blink-cursor-mode not work after startup on macOS
  2022-01-15 12:34   ` Alan Third
@ 2022-01-15 13:05     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-01-15 13:11       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 8+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-15 13:05 UTC (permalink / raw)
  To: Alan Third; +Cc: Eason Huang, 53276

Alan Third <alan@idiocy.org> writes:

> On Sat, Jan 15, 2022 at 03:04:35PM +0800, Po Lu wrote:
>> Eason Huang <aqua0210@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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#53276: The blink-cursor-mode not work after startup on macOS
  2022-01-15 13:05     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-01-15 13:11       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-01-21  1:19         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 8+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-15 13:11 UTC (permalink / raw)
  To: Alan Third; +Cc: Eason Huang, 53276

Po Lu <luangruo@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?





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#53276: The blink-cursor-mode not work after startup on macOS
  2022-01-15 13:11       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-01-21  1:19         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  2022-01-21 11:38           ` Eason Huang
  0 siblings, 1 reply; 8+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-21  1:19 UTC (permalink / raw)
  To: Alan Third; +Cc: Eason Huang, 53276

Po Lu <luangruo@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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#53276: The blink-cursor-mode not work after startup on macOS
  2022-01-21  1:19         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
@ 2022-01-21 11:38           ` Eason Huang
  2022-01-21 11:41             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 1 reply; 8+ messages in thread
From: Eason Huang @ 2022-01-21 11:38 UTC (permalink / raw)
  To: Po Lu; +Cc: Alan Third, 53276

Po Lu <luangruo@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





^ permalink raw reply	[flat|nested] 8+ messages in thread

* bug#53276: The blink-cursor-mode not work after startup on macOS
  2022-01-21 11:38           ` Eason Huang
@ 2022-01-21 11:41             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
  0 siblings, 0 replies; 8+ messages in thread
From: Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors @ 2022-01-21 11:41 UTC (permalink / raw)
  To: Eason Huang; +Cc: Alan Third, 53276-done

Eason Huang <aqua0210@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.





^ permalink raw reply	[flat|nested] 8+ messages in thread

end of thread, other threads:[~2022-01-21 11:41 UTC | newest]

Thread overview: 8+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2022-01-15  4:41 bug#53276: The blink-cursor-mode not work after startup on macOS Eason Huang
2022-01-15  7:04 ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-15 12:34   ` Alan Third
2022-01-15 13:05     ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-15 13:11       ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-21  1:19         ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors
2022-01-21 11:38           ` Eason Huang
2022-01-21 11:41             ` Po Lu via Bug reports for GNU Emacs, the Swiss army knife of text editors

Code repositories for project(s) associated with this inbox:

	https://git.savannah.gnu.org/cgit/emacs.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).