GNU bug report logs - #79612
31.0.50; call-process redisplay in GUI Emacs

Previous Next

To reply to this bug, email your comments to 79612 AT debbugs.gnu.org.

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

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

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: bug-gnu-emacs <at> gnu.org
Subject: 31.0.50; call-process redisplay in GUI Emacs
Date: Fri, 10 Oct 2025 16:50:43 +0200

Steps to reproduce:
-------------------

1) emacs -Q

2) put the following three lines in a buffer in a Lisp-ish mode (for
   example scratch buffer in Lisp Interaction mode)

   (message "Before external process")
   (call-process "/bin/sleep" nil nil t "5")
   (message "After external process")

3) M-x split-window-below

4) in the newly created window, show the messages buffer

5) switch back to the window with the three code lines

6) select a region covering the three code lines

7) M-x eval-region

8) observe what happens in the messages buffer, versus what happens in
   the minibufer

Observed behaviour:
-------------------

- the "before" message never appears in the minibuffer

- both messages appear at once in the messages buffer once the external
  process completes

- the "after" message appears in the minibuffer once the external
  process completes

Expected behaviour:
-------------------

- the "before" message should be shown in the minibuffer while the
  external process runs

Discussion:
-----------

- When applying the above steps in terminal Emacs (emacs -Q -nw) on the
  same machine, the behaviour is as expected ("before" message is shown
  in minibuffer while the external process runs).

- These observations are for the NS port on macOS. How do other ports of
  GUI Emacs behave in this experiment?

- /bin/sleep never outputs anything, hence the t value for the DISPLAY
  parameter in the call to `call-process`, combined with nil as the
  value for the DESTINATION parameter, might just as well make this a
  case of "as designed"? If it were "as designed", would there be any
  other way of getting to see the "before" message in the minibuffer
  while an external process runs, producing no output at all?


Many thanks in advance, and looking forward to your thoughts,

  --alexander


In GNU Emacs 31.0.50 (build 1, aarch64-apple-darwin25.0.0, NS
 appkit-2685.10 Version 26.0.1 (Build 25A362)) of 2025-10-06 built on
 hyperion
Repository revision: 1df9cfdb135847bc3783d627e5244327a51fc1e1
Repository branch: master
Windowing system distributor 'Apple', version 10.3.2685
System Description:  macOS 26.0.1

Configured using:
 'configure --with-wide-int --with-rsvg --with-tree-sitter'

Configured features:
ACL DBUS GLIB GNUTLS LCMS2 LIBXML2 MODULES NOTIFY KQUEUE NS PDUMPER PNG
RSVG SQLITE3 THREADS TOOLKIT_SCROLL_BARS TREE_SITTER WEBP XIM ZLIB

Important settings:
  value of $LC_CTYPE: en_GB.UTF-8
  value of $LANG: C
  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
  minibuffer-nonselected-mode: t
  minibuffer-regexp-mode: t
  line-number-mode: t
  indent-tabs-mode: t
  transient-mark-mode: t
  auto-composition-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t

Load-path shadows:
None found.

Features:
(shadow sort mail-extr emacsbug lisp-mnt message eudc cus-edit pp
cus-start cus-load icons eudc-vars wid-edit mailcap yank-media puny
dired dired-loaddefs rfc822 mml mml-sec password-cache epa derived epg
rfc6068 epg-config gnus-util text-property-search mm-decode mm-bodies
mm-encode mailabbrev gmm-utils mailheader sendmail mail-parse rfc2231
rfc2047 rfc2045 ietf-drums mm-util mail-prsvr mail-utils time-date
subr-x cl-loaddefs cl-lib rmc iso-transl tooltip cconv 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 nadvice seq simple cl-generic
indonesian philippine 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 abbrev obarray oclosure cl-preloaded button loaddefs
theme-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 dbusbind kqueue cocoa ns
lcms2 multi-tty make-network-process tty-child-frames emacs)

Memory information:
((conses 16 65243 10688) (symbols 48 7310 0) (strings 32 17860 1794)
 (string-bytes 1 422978) (vectors 16 11512)
 (vector-slots 8 133226 7390) (floats 8 52 53) (intervals 56 380 25)
 (buffers 1064 13))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: 79612 <at> debbugs.gnu.org
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Fri, 10 Oct 2025 19:08:45 +0300

> Date: Fri, 10 Oct 2025 16:50:43 +0200
> From:  Alexander Adolf via "Bug reports for GNU Emacs,
>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
> 
> Steps to reproduce:
> -------------------
> 
> 1) emacs -Q
> 
> 2) put the following three lines in a buffer in a Lisp-ish mode (for
>    example scratch buffer in Lisp Interaction mode)
> 
>    (message "Before external process")
>    (call-process "/bin/sleep" nil nil t "5")
>    (message "After external process")
> 
> 3) M-x split-window-below
> 
> 4) in the newly created window, show the messages buffer
> 
> 5) switch back to the window with the three code lines
> 
> 6) select a region covering the three code lines
> 
> 7) M-x eval-region
> 
> 8) observe what happens in the messages buffer, versus what happens in
>    the minibufer
> 
> Observed behaviour:
> -------------------
> 
> - the "before" message never appears in the minibuffer
> 
> - both messages appear at once in the messages buffer once the external
>   process completes
> 
> - the "after" message appears in the minibuffer once the external
>   process completes
> 
> Expected behaviour:
> -------------------
> 
> - the "before" message should be shown in the minibuffer while the
>   external process runs

I see the expected behavior, here on GNU/Linux and on MS-Windows.  So
what you see might be macOS-specific (not surprising, given the hoops
through which redisplay on macOS has to jump to do its thing, fighting
against the various idiosyncrasies of macOS and Apple APIs).

> - When applying the above steps in terminal Emacs (emacs -Q -nw) on the
>   same machine, the behaviour is as expected ("before" message is shown
>   in minibuffer while the external process runs).

I see no difference between the -nw and the GUI sessions.

> - These observations are for the NS port on macOS. How do other ports of
>   GUI Emacs behave in this experiment?

See above.

> - /bin/sleep never outputs anything, hence the t value for the DISPLAY
>   parameter in the call to `call-process`, combined with nil as the
>   value for the DESTINATION parameter, might just as well make this a
>   case of "as designed"? If it were "as designed", would there be any
>   other way of getting to see the "before" message in the minibuffer
>   while an external process runs, producing no output at all?

The "before" message should appear before the process is run because
we force it to.  But don't forget that anything you see on display is
the result of redisplay, so if redisplay on macOS doesn't get a chance
to run before the process is launched, you will not see the "before"
message.

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

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79612 <at> debbugs.gnu.org
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Fri, 10 Oct 2025 22:04:34 +0200

Hello Eli,

many thanks for double-checking so quickly! Your results confirm my
suspicion that the behaviour is indeed platform-specific.

I'll meditate over the changes to src/ns* from the past few months to
see whether anything catches my eye, and could be causing this.

Coincidentally (or maybe not?) there doesn't seem to be a branch
dedicated to the NS port? In case there would be any inclination to
create such a branch, I would be all for it (for instance "feature/ns").


Many thanks and cheers,

  --alexander

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: 79612 <at> debbugs.gnu.org
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Sat, 11 Oct 2025 09:52:20 +0300

> From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
> Cc: 79612 <at> debbugs.gnu.org
> Date: Fri, 10 Oct 2025 22:04:34 +0200
> 
> Hello Eli,
> 
> many thanks for double-checking so quickly! Your results confirm my
> suspicion that the behaviour is indeed platform-specific.
> 
> I'll meditate over the changes to src/ns* from the past few months to
> see whether anything catches my eye, and could be causing this.

Thanks.

> Coincidentally (or maybe not?) there doesn't seem to be a branch
> dedicated to the NS port? In case there would be any inclination to
> create such a branch, I would be all for it (for instance "feature/ns").

NS is AFAIK supported in the mainline, so why would we need a separate
branch for it?

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

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79612 <at> debbugs.gnu.org
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Sat, 11 Oct 2025 15:54:58 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

> [...]
>> Coincidentally (or maybe not?) there doesn't seem to be a branch
>> dedicated to the NS port? In case there would be any inclination to
>> create such a branch, I would be all for it (for instance "feature/ns").
>
> NS is AFAIK supported in the mainline, so why would we need a separate
> branch for it?

To make it easier to see/follow/review what was/is being done for that
platform?

Naming is important also, because it shapes expectations. In that light,
instead of "feature/android", something along the lines of
"platform/android" could be seen as more calling. Just my two cents
anyway.

New branch(es) will inevitably imply more merge commits, and higher
maintainer efforts, however. So there's probably a balance to strike
here.


Cheers,

  --alexander

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
Cc: 79612 <at> debbugs.gnu.org
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Sat, 11 Oct 2025 17:48:57 +0300

> From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
> Cc: 79612 <at> debbugs.gnu.org
> Date: Sat, 11 Oct 2025 15:54:58 +0200
> 
> Eli Zaretskii <eliz <at> gnu.org> writes:
> 
> > [...]
> >> Coincidentally (or maybe not?) there doesn't seem to be a branch
> >> dedicated to the NS port? In case there would be any inclination to
> >> create such a branch, I would be all for it (for instance "feature/ns").
> >
> > NS is AFAIK supported in the mainline, so why would we need a separate
> > branch for it?
> 
> To make it easier to see/follow/review what was/is being done for that
> platform?

That is only justified if you are working on some feature for a
long-enough time, and need to install multiple patches for that
feature which should be reviewed together.  Otherwise, looking at
separate commits should be okay.

> New branch(es) will inevitably imply more merge commits, and higher
> maintainer efforts, however. So there's probably a balance to strike
> here.

Right.

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

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79612 <at> debbugs.gnu.org
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Thu, 16 Oct 2025 15:32:25 +0200

Eli Zaretskii <eliz <at> gnu.org> writes:

>> Date: Fri, 10 Oct 2025 16:50:43 +0200
>> From:  Alexander Adolf via "Bug reports for GNU Emacs,
>>  the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org>
>>
>> Steps to reproduce:
>> -------------------
>>
>> 1) emacs -Q
>>
>> 2) put the following three lines in a buffer in a Lisp-ish mode (for
>>    example scratch buffer in Lisp Interaction mode)
>>
>>    (message "Before external process")
>>    (call-process "/bin/sleep" nil nil t "5")
>>    (message "After external process")
>>
>> 3) M-x split-window-below
>>
>> 4) in the newly created window, show the messages buffer
>>
>> 5) switch back to the window with the three code lines
>>
>> 6) select a region covering the three code lines
>>
>> 7) M-x eval-region
>>
>> 8) observe what happens in the messages buffer, versus what happens in
>>    the minibufer
>>
>> Observed behaviour:
>> -------------------
>>
>> - the "before" message never appears in the minibuffer
>>
>> - both messages appear at once in the messages buffer once the external
>>   process completes
>>
>> - the "after" message appears in the minibuffer once the external
>>   process completes
>>
>> Expected behaviour:
>> -------------------
>>
>> - the "before" message should be shown in the minibuffer while the
>>   external process runs
>
> I see the expected behavior, here on GNU/Linux and on MS-Windows.  So
> what you see might be macOS-specific (not surprising, given the hoops
> through which redisplay on macOS has to jump to do its thing, fighting
> against the various idiosyncrasies of macOS and Apple APIs).
> [...]

I have reviewed the changes to src/ns* files, but couldn't find anything
that would have seemed related to the described problem.

I have also built and tested a few commits, all the way back to May
2024, and I can still observe this behaviour. That said, it seems
unlikely that any change in Emacs is causing this.

It rather puts a new suspect on the radar: API change(s) in the
underlying OS platform.

I have upgraded to macOS 26 already. Could some good soul, whose system
is still running macOS 15 perhaps be so kind as to do the above
experiment, please?


Many thanks in advance and cheers,

  --alexander

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

From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
To: Alexander Adolf <alexander.adolf <at> condition-alpha.com>, Eli Zaretskii
 <eliz <at> gnu.org>
Cc: 79612 <at> debbugs.gnu.org
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Fri, 17 Oct 2025 00:39:12 +0200

Alexander Adolf via "Bug reports for GNU Emacs, the Swiss army knife of
text editors" <bug-gnu-emacs <at> gnu.org> writes:

> I have upgraded to macOS 26 already. Could some good soul, whose system
> is still running macOS 15 perhaps be so kind as to do the above
> experiment, please?

Good soul, right here. :)

MacOS 15.5 (24F74), Emacs from `main' (00b92cd9329).

I see the following in the *Messages* buffer:

Before external process
After external process
You can run the command ‘eval-region’ with M-x ev-r
After external process

Reproducibility:

The experiment was repeated 3 times, with 100% reproduction.

Timeline:

1. "Before external process" in the echo area.
2. Pause.
3. "Before external process" and "After external process" in *Messages*
4. Pause.
4. "You can run the command ‘eval-region’ with M-x ev-r" in *Messages*
5. Another "After external process", in both the echo area and *Messages*

Rudy
-- 
"The introduction of suitable abstractions is our only mental aid to
organize and master complexity."
--- Edsger Wybe Dijkstra, 1930-2002

Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
http://adamkovic.org

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Rudolf Adamkovič <rudolf <at> adamkovic.org>
Cc: 79612 <at> debbugs.gnu.org, alexander.adolf <at> condition-alpha.com
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Sat, 01 Nov 2025 11:04:28 +0200

Ping!  Do we have anything else to do here, or can this bug be closed?

> From: Rudolf Adamkovič <rudolf <at> adamkovic.org>
> Cc: 79612 <at> debbugs.gnu.org
> Date: Fri, 17 Oct 2025 00:39:12 +0200
> 
> Alexander Adolf via "Bug reports for GNU Emacs, the Swiss army knife of
> text editors" <bug-gnu-emacs <at> gnu.org> writes:
> 
> > I have upgraded to macOS 26 already. Could some good soul, whose system
> > is still running macOS 15 perhaps be so kind as to do the above
> > experiment, please?
> 
> Good soul, right here. :)
> 
> MacOS 15.5 (24F74), Emacs from `main' (00b92cd9329).
> 
> I see the following in the *Messages* buffer:
> 
> Before external process
> After external process
> You can run the command ‘eval-region’ with M-x ev-r
> After external process
> 
> Reproducibility:
> 
> The experiment was repeated 3 times, with 100% reproduction.
> 
> Timeline:
> 
> 1. "Before external process" in the echo area.
> 2. Pause.
> 3. "Before external process" and "After external process" in *Messages*
> 4. Pause.
> 4. "You can run the command ‘eval-region’ with M-x ev-r" in *Messages*
> 5. Another "After external process", in both the echo area and *Messages*
> 
> Rudy
> -- 
> "The introduction of suitable abstractions is our only mental aid to
> organize and master complexity."
> --- Edsger Wybe Dijkstra, 1930-2002
> 
> Rudolf Adamkovič <rudolf <at> adamkovic.org> [he/him]
> http://adamkovic.org
> 

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

From: Alexander Adolf <alexander.adolf <at> condition-alpha.com>
To: Eli Zaretskii <eliz <at> gnu.org>, Rudolf Adamkovič
 <rudolf <at> adamkovic.org>
Cc: 79612 <at> debbugs.gnu.org
Subject: Re: bug#79612: 31.0.50; call-process redisplay in GUI Emacs
Date: Sat, 01 Nov 2025 18:00:31 +0100

Eli Zaretskii <eliz <at> gnu.org> writes:

> Ping!  Do we have anything else to do here, or can this bug be closed?
> [...]

As the most probable hypothesis remains "API change in underlying OS",
and nobody else has reported anything relating to the matter, I would
support your intent to close this bug.


Many thanks and cheers,

  --alexander

Previous Next

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