GNU bug report logs - #79058
30.1; involking signal using emacsclient takes very long time to complete ~2 seconds

Previous Next

To reply to this bug, email your comments to 79058 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: Bror Winther <bbw <at> nobad.coffee>
To: bug-gnu-emacs <at> gnu.org
Subject: 30.1; involking signal using emacsclient takes very long time to 
 complete ~2 seconds
Date: Sun, 20 Jul 2025 04:15:53 +0200

After upgrading to 30.1 I have noticed that all my external scripts take
very long to finish from time to time. In particular I noticed the line
in my window manager script `emacsclient --eval "(evil-window-up 1)`
would take a long time to finish if there is no window found. This
causes the script to be very slow. I think I have narrowed it down to
`signal`.

The time it takes to execute a simple signal seems to be very high.
 
time emacsclient --eval "(signal 'user-error (list (apply #'format-message \"%s\" '(test))))"
*ERROR*: test
emacsclient --eval   0.00s user 0.00s system 0% cpu 2.013 total

//bror

In GNU Emacs 30.1 (build 2, x86_64-apple-darwin23.1.0, NS appkit-2487.20
Version 14.1 (Build 23B74)) of 2025-06-23 built on baldr.nobad.coffee
Windowing system distributor 'Apple', version 10.3.2487
System Description:  macOS 14.1

Configured using:
'configure --disable-dependency-tracking --disable-silent-rules
--enable-locallisppath=/usr/local/share/emacs/site-lisp
--infodir=/usr/local/Cellar/emacs-plus <at> 30/30.1/share/info/emacs
--prefix=/usr/local/Cellar/emacs-plus <at> 30/30.1
--with-native-compilation=aot --with-xml2 --with-gnutls
--without-compress-install --without-dbus --without-imagemagick
--with-modules --with-rsvg --with-webp --with-xwidgets --with-ns
--disable-ns-self-contained 'CFLAGS=-O2 -DFD_SETSIZE=10000
-DDARWIN_UNLIMITED_SELECT -I/usr/local/opt/sqlite/include
-I/usr/local/opt/gcc/include -I/usr/local/opt/libgccjit/include'
'LDFLAGS=-L/usr/local/opt/sqlite/lib -L/usr/local/lib/gcc/15
-I/usr/local/opt/gcc/include -I/usr/local/opt/libgccjit/include''

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

Important settings:
  value of $LANG: en_US.UTF-8
  locale-coding-system: utf-8-unix

Major mode: C/*l

Minor modes in effect:
  sly-symbol-completion-mode: t
  evil-traces-mode: t
  eros-mode: t
  tree-sitter-hl-mode: t
  global-ts-fold-mode: t
  ts-fold-mode: t
  tree-sitter-mode: t
  +format-with-lsp-mode: t
  lsp-diagnostics-mode: t
  yas-global-mode: t
  yas-minor-mode: t
  lsp-modeline-workspace-status-mode: t
  lsp-modeline-diagnostics-mode: t
  lsp-modeline-code-actions-mode: t
  lsp-ui-mode: t
  lsp-ui-doc-mode: t
  lsp-ui-sideline-mode: t
  lsp-completion-mode: t
  lsp-managed-mode: t
  lsp-mode: t
  hl-todo-mode: t
  copilot-mode: t
  windmove-mode: t
  flycheck-popup-tip-mode: t
  flyspell-lazy-mode: t
  vi-tilde-fringe-mode: t
  display-line-numbers-mode: t
  save-place-mode: t
  global-so-long-mode: t
  diff-hl-flydiff-mode: t
  global-diff-hl-mode: t
  diff-hl-mode: t
  envrc-global-mode: t
  envrc-mode: t
  which-key-mode: t
  savehist-mode: t
  better-jumper-mode: t
  better-jumper-local-mode: t
  company-box-mode: t
  global-company-mode: t
  company-mode: t
  vertico-posframe-mode: t
  vertico-multiform-mode: t
  vertico-mode: t
  marginalia-mode: t
  evil-goggles-mode: t
  ultra-scroll-mode: t
  pixel-scroll-precision-mode: t
  evil-escape-mode: t
  evil-snipe-override-mode: t
  evil-snipe-mode: t
  evil-snipe-override-local-mode: t
  evil-snipe-local-mode: t
  org-roam-db-autosync-mode: t
  bug-reference-prog-mode: t
  global-git-commit-mode: t
  recentf-mode: t
  server-mode: t
  gcmh-mode: t
  global-hl-line-mode: t
  hl-line-mode: t
  winner-mode: t
  smartparens-global-mode: t
  smartparens-mode: t
  undo-fu-session-global-mode: t
  undo-fu-session-mode: t
  undo-fu-mode: t
  global-flycheck-mode: t
  flycheck-mode: t
  ws-butler-global-mode: t
  ws-butler-mode: t
  editorconfig-mode: t
  global-wakatime-mode: t
  wakatime-mode: t
  global-ligature-mode: t
  ligature-mode: t
  persp-mode: t
  doom-modeline-mode: t
  dtrt-indent-mode: t
  override-global-mode: t
  ue-global-mode: t
  projectile-mode: t
  solaire-global-mode: t
  global-atomic-chrome-edit-mode: t
  global-whitespace-mode: t
  whitespace-mode: t
  global-subword-mode: t
  subword-mode: t
  ns-auto-titlebar-mode: t
  +lsp-optimization-mode: t
  evil-mode: t
  evil-local-mode: t
  +popup-mode: t
  general-override-mode: t
  apheleia-global-mode: t
  apheleia-mode: t
  global-eldoc-mode: t
  eldoc-mode: t
  show-paren-mode: t
  electric-indent-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  window-divider-mode: t
  minibuffer-regexp-mode: t
  size-indication-mode: t
  column-number-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
  abbrev-mode: t

Load-path shadows:
/Users/nah/.config/emacs/.local/straight/build-30.1/buck/buck hides /Users/nah/.config/emacs/.local/straight/build-30.1/ghub/buck
/Users/nah/.config/emacs/.local/straight/build-30.1/gtea/gtea hides /Users/nah/.config/emacs/.local/straight/build-30.1/ghub/gtea
/Users/nah/.config/emacs/.local/straight/build-30.1/glab/glab hides /Users/nah/.config/emacs/.local/straight/build-30.1/ghub/glab
/Users/nah/.config/emacs/.local/straight/build-30.1/gogs/gogs hides /Users/nah/.config/emacs/.local/straight/build-30.1/ghub/gogs
/Users/nah/.config/emacs/.local/straight/build-30.1/straight/straight-x hides /Users/nah/.config/emacs/.local/straight/repos/straight.el/straight-x
/Users/nah/.config/emacs/.local/straight/build-30.1/straight/straight hides /Users/nah/.config/emacs/.local/straight/repos/straight.el/straight
/Users/nah/.config/emacs/.local/straight/build-30.1/straight/straight-ert-print-hack hides /Users/nah/.config/emacs/.local/straight/repos/straight.el/straight-ert-print-hack
/Users/nah/.config/emacs/.local/straight/build-30.1/which-key/which-key hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/which-key
/Users/nah/.config/emacs/.local/straight/build-30.1/transient/transient hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/transient
/Users/nah/.config/emacs/.local/straight/repos/straight.el/indent hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/indent
/Users/nah/.config/emacs/.local/straight/build-30.1/editorconfig/editorconfig hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/editorconfig
/Users/nah/.config/emacs/.local/straight/build-30.1/editorconfig/editorconfig-conf-mode hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/editorconfig-conf-mode
/Users/nah/.config/emacs/.local/straight/build-30.1/jsonrpc/jsonrpc hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/jsonrpc
/Users/nah/.config/emacs/.local/straight/build-30.1/editorconfig/editorconfig-core hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/editorconfig-core
/Users/nah/.config/emacs/.local/straight/build-30.1/editorconfig/editorconfig-tools hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/editorconfig-tools
/Users/nah/.config/emacs/.local/straight/build-30.1/editorconfig/editorconfig-core-handle hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/editorconfig-core-handle
/Users/nah/.config/emacs/.local/straight/build-30.1/bind-key/bind-key hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/bind-key
/Users/nah/.config/emacs/.local/straight/build-30.1/editorconfig/editorconfig-fnmatch hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/editorconfig-fnmatch
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package-jump hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package-jump
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package-ensure-system-package hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package-ensure-system-package
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package-diminish hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package-diminish
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package-delight hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package-delight
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package-lint hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package-lint
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package-core hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package-core
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package-ensure hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package-ensure
/Users/nah/.config/emacs/.local/straight/build-30.1/use-package/use-package-bind-key hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/use-package/use-package-bind-key
/Users/nah/.config/emacs/.local/straight/build-30.1/xref/xref hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/progmodes/xref
/Users/nah/.config/emacs/.local/straight/build-30.1/project/project hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/progmodes/project
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-comint hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-comint
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-exp hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-exp
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-ctags hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-ctags
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-emacs-lisp hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-emacs-lisp
/Users/nah/.config/emacs/.local/straight/build-30.1/org/oc hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/oc
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-texinfo hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-texinfo
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-irc hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-irc
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-doi hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-doi
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-refile hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-refile
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-version hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-version
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-num hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-num
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-mhe hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-mhe
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-shell hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-shell
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-attach hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-attach
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-C hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-C
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-macs hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-macs
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-entities hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-entities
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-dot hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-dot
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-sql hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-sql
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-eww hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-eww
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-datetree hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-datetree
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-macro hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-macro
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-eval hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-eval
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-haskell hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-haskell
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-org hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-org
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-rmail hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-rmail
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-awk hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-awk
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-groovy hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-groovy
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-icalendar hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-icalendar
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-octave hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-octave
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-scheme hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-scheme
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-mobile hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-mobile
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-processing hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-processing
/Users/nah/.config/emacs/.local/straight/build-30.1/org/oc-biblatex hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/oc-biblatex
/Users/nah/.config/emacs/.local/straight/build-30.1/org/oc-csl hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/oc-csl
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-colview hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-colview
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-R hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-R
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-table hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-table
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-html hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-html
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-fortran hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-fortran
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-plantuml hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-plantuml
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-docview hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-docview
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-perl hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-perl
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-sqlite hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-sqlite
/Users/nah/.config/emacs/.local/straight/build-30.1/org/oc-basic hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/oc-basic
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-sed hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-sed
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-fold-core hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-fold-core
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-ditaa hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-ditaa
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-ruby hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-ruby
/Users/nah/.config/emacs/.local/straight/build-30.1/org/oc-bibtex hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/oc-bibtex
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-habit hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-habit
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-loaddefs hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-loaddefs
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-gnus hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-gnus
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-screen hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-screen
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-mouse hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-mouse
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-css hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-css
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-inlinetask hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-inlinetask
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-lisp hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-lisp
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-eshell hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-eshell
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-pcomplete hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-pcomplete
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-lint hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-lint
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-id hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-id
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-capture hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-capture
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-sass hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-sass
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-tangle hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-tangle
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-calc hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-calc
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-java hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-java
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-compat hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-compat
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-attach-git hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-attach-git
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-beamer hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-beamer
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-protocol hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-protocol
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-element hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-element
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-lob hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-lob
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-tempo hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-tempo
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-python hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-python
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-latex hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-latex
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-w3m hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-w3m
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-agenda hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-agenda
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-persist hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-persist
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-ocaml hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-ocaml
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-ref hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-ref
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-fold hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-fold
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-julia hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-julia
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-lilypond hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-lilypond
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-table hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-table
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-clojure hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-clojure
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-indent hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-indent
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-plot hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-plot
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-latex hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-latex
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-src hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-src
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-duration hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-duration
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-makefile hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-makefile
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-info hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-info
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-clock hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-clock
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-forth hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-forth
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-odt hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-odt
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-man hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-man
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-publish hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-publish
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-archive hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-archive
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-org hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-org
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-lua hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-lua
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-keys hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-keys
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-eshell hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-eshell
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-faces hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-faces
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-man hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-man
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-list hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-list
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-md hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-md
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-goto hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-goto
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-bbdb hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-bbdb
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ol-bibtex hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ol-bibtex
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-koma-letter hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-koma-letter
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox-ascii hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox-ascii
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-matlab hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-matlab
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ox hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ox
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-timer hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-timer
/Users/nah/.config/emacs/.local/straight/build-30.1/org/oc-natbib hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/oc-natbib
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-core hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-core
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-feed hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-feed
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-gnuplot hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-gnuplot
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-js hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-js
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-element-ast hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-element-ast
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-footnote hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-footnote
/Users/nah/.config/emacs/.local/straight/build-30.1/org/ob-maxima hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/ob-maxima
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-cycle hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-cycle
/Users/nah/.config/emacs/.local/straight/build-30.1/org/org-crypt hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/org/org-crypt
/Users/nah/.config/emacs/.local/straight/build-30.1/compat/compat hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/emacs-lisp/compat
/Users/nah/.config/emacs/.local/straight/build-30.1/map/map hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/emacs-lisp/map
/Users/nah/.config/emacs/.local/straight/build-30.1/seq/seq hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/emacs-lisp/seq
/Users/nah/.config/emacs/.local/straight/build-30.1/eldoc/eldoc hides /usr/local/Cellar/emacs-plus <at> 30/30.1/share/emacs/30.1/lisp/emacs-lisp/eldoc

Features:
(shadow sort adaptive-wrap mail-extr emacsbug make-mode bat-mode
dumb-jump emacsql-sqlite-builtin macrostep-c cmacexp
evil-collection-macrostep macrostep gitignore-mode consult-xref
evil-collection-shortdoc shortdoc sly-completion sly-buttons
sly-messages sly-common hyperspec evil-traces evil-ex char-fold
elisp-def ert eros elisp-demos highlight-quoted evil-collection-helpful
helpful cc-langs trace cl-print evil-collection-edebug edebug
evil-collection-debug debug backtrace lisp-mode info-look help-fns
radix-tree evil-collection-elisp-refs elisp-refs
evil-textobj-tree-sitter evil-textobj-tree-sitter-thing-at-point
evil-textobj-tree-sitter-core tree-sitter-langs tree-sitter-langs-build
tree-sitter-hl ts-fold ts-fold-summary ts-fold-parsers ts-fold-util
tree-sitter tree-sitter-load tree-sitter-cli tsc tsc-dyn tsc-dyn-get
dired-aux tsc-obsolete conf-mode apheleia apheleia-rcs apheleia-dp
apheleia-formatters apheleia-utils apheleia-log
apheleia-formatter-context jka-compr delsel files-x consult-flycheck
evil-collection-consult consult evil-collection-flymake flymake
lsp-diagnostics doom-snippets doom-snippets-lib yasnippet elisp-mode
company-yasnippet lsp-modeline lsp-icons lsp-lens hide-mode-line lsp-ui
lsp-ui-flycheck lsp-ui-doc evil-collection-xwidget xwidget
evil-collection-image image-mode exif magit-bookmark
evil-collection-bookmark bookmark goto-addr evil-collection-lsp-ui-imenu
lsp-ui-imenu lsp-ui-peek lsp-ui-sideline lsp-ui-util
evil-collection-view view lsp-zig lsp-yang lsp-yaml lsp-xml lsp-wgsl
lsp-volar lsp-vimscript lsp-vhdl lsp-vetur lsp-html lsp-verilog lsp-vala
lsp-v lsp-typespec lsp-typeprof lsp-ttcn3 lsp-ts-query lsp-trunk
lsp-toml-tombi lsp-toml lsp-tilt lsp-tex lsp-svelte lsp-steep lsp-sqls
lsp-sql lsp-sourcekit lsp lsp-sorbet lsp-solidity lsp-solargraph
lsp-semgrep lsp-rust lsp-ruff lsp-ruby-syntax-tree lsp-ruby-lsp
lsp-rubocop lsp-roslyn lsp-roc lsp-rf lsp-remark lsp-racket lsp-r
lsp-qml lsp-python-ty lsp-pylsp lsp-pyls lsp-pwsh lsp-purescript
lsp-postgres lsp-pls lsp-php lsp-perlnavigator lsp-perl lsp-openscad
lsp-ocaml lsp-nushell lsp-nix lsp-nim lsp-nginx lsp-nextflow lsp-move
lsp-mojo lsp-mint lsp-meson lsp-mdx lsp-matlab lsp-marksman lsp-markdown
lsp-magik lsp-fennel lsp-lua lsp-lisp lsp-kubernetes-helm lsp-kotlin
lsp-json lsp-jq lsp-javascript lsp-idris lsp-haxe lsp-hack lsp-groovy
lsp-graphql lsp-golangci-lint lsp-glsl lsp-gleam lsp-gdscript lsp-fsharp
lsp-futhark lsp-fortran lsp-eslint lsp-erlang lsp-emmet lsp-elm
lsp-elixir lsp-earthly lsp-dockerfile lsp-dhall lsp-d lsp-cypher
lsp-cucumber lsp-copilot lsp-css lsp-c3 lsp-csharp lsp-crystal lsp-credo
lsp-cobol lsp-cmake lsp-clojure lsp-clangd lsp-bufls lsp-go
lsp-completion lsp-beancount lsp-bash lsp-awk lsp-autotools lsp-astro
lsp-asm lsp-ansible lsp-angular lsp-ada lsp-semantic-tokens
lsp-actionscript ccls ccls-member-hierarchy ccls-inheritance-hierarchy
ccls-call-hierarchy ccls-tree ccls-code-lens ccls-semantic-highlight
ccls-common cc-mode-expansions smartparens-c cc-mode cc-fonts cc-guess
cc-menus cc-cmds cc-styles cc-align cc-engine cc-vars cc-defs lsp-mode
lsp-protocol spinner network-stream hl-todo copilot copilot-balancer
jsonrpc gdscript-mode gdscript-ts-mode gdscript-eglot gdscript-hydra
hydra lv gdscript-godot gdscript-project gdscript-history
gdscript-comint gdscript-debug gdscript-format gdscript-comint-gdformat
gdscript-completion gdscript-fill-paragraph gdscript-imenu
gdscript-indent-and-nav gdscript-rx gdscript-utils gdscript-syntax
gdscript-keywords gdscript-docs evil-collection-eww eww url-queue mm-url
gdscript-customization vertico-directory windmove evil-collection-vc-git
vc-git auto-minor-mode flycheck-popup-tip evil-collection-popup popup
org-contacts gnus-art mm-uu mml2015 mm-view mml-smime smime dig gnus-sum
gnus-group gnus-undo gnus-start gnus-dbus dbus gnus-cloud nnimap nnmail
mail-source utf7 nnoo gnus-spec gnus-int gnus-range gnus-win
evil-collection-gnus gnus nnheader range embrace expand-region
subword-mode-expansions text-mode-expansions the-org-mode-expansions
er-basic-expansions expand-region-core expand-region-custom
flyspell-lazy flyspell ispell writegood-mode toc-org org-eldoc evil-org
vi-tilde-fringe display-line-numbers indent-bars evil-collection-custom
cus-edit cus-start cus-load org-indent oc-basic ol-bibtex bibtex
smartparens-go evil-collection-go-mode go-mode find-file ffap etags
fileloop evil-collection-xref xref saveplace evil-collection-so-long
so-long diff-hl-flydiff evil-collection-diff-hl diff-hl
evil-collection-log-view log-view evil-collection-vc-dir vc-dir ewoc vc
vc-dispatcher envrc inheritenv vertico-sort vertico-repeat
evil-collection-which-key which-key savehist better-jumper company-box
company-box-doc frame-local company-box-icons company-capf php-extras
company vertico-posframe posframe vertico-multiform
evil-collection-vertico vertico orderless marginalia evil-goggles
evil-collection-ultra-scroll ultra-scroll pixel-scroll cua-base
evil-easymotion avy evil-escape evil-snipe pulse org-agenda
evil-collection-org evil-collection-org-roam org-roam-migrate
org-roam-log org-roam-mode org-roam-capture org-roam-id org-roam-node
org-roam-db org-roam-utils org-roam-compat org-roam org-capture
org-element org-persist xdg avl-tree generator org-attach org-id
org-refile org-element-ast inline smartparens-org org ob-emacs-lisp
org-table org-loaddefs ob ob-tangle ol ob-ref ob-lob ob-table ob-exp
org-macro org-src evil-collection-sh-script sh-script smie treesit
executable org-keys oc ob-comint ob-core org-cycle org-fold ob-eval
org-pcomplete org-list org-footnote org-fold-core org-entities org-faces
org-version org-compat org-macs evil-collection-calendar cal-menu
calendar cal-loaddefs code-review code-review-actions
code-review-comment code-review-section code-review-bitbucket
code-review-faces shr pixel-fill kinsoku url-file svg xml dom emojify
evil-collection-apropos apropos evil-collection-tar-mode tar-mode
evil-collection-arc-mode arc-mode archive-mode ht code-review-gitlab
code-review-utils evil-collection-forge forge-repos forge-tablist
forge-topics forge-commands forge-semi forge-bitbucket buck forge-gogs
gogs forge-gitea gtea forge-gitlab glab forge-github forge-forgejo
forge-notify forge-revnote forge-pullreq forge-issue forge-discussion
forge-topic yaml parse-time iso8601 eieio-custom bug-reference
forge-post smartparens-markdown evil-collection-markdown-mode
markdown-mode edit-indirect color evil-collection-outline noutline
outline forge-repo forge forge-core forge-db code-review-parse-hunk
code-review-github code-review-db uuidgen calc-misc calc-ext
evil-collection-calc calc calc-loaddefs calc-macs a
code-review-interfaces deferred ghub-graphql treepy gsexp ghub url-http
url-gw nsm url-auth gnutls closql emacsql-sqlite emacsql
emacsql-compiler eieio-base magit-autoloads evil-collection-magit
magit-submodule magit-blame magit-stash magit-reflog magit-bisect
magit-push magit-pull magit-fetch magit-clone magit-remote magit-commit
magit-sequence magit-notes magit-worktree magit-tag magit-merge
magit-branch magit-reset magit-files magit-refs magit-status magit
evil-collection-magit-repos magit-repos magit-apply magit-wip magit-log
which-func magit-diff evil-collection-smerge-mode smerge-mode diff
evil-collection-diff-mode diff-mode track-changes magit-core
magit-autorevert magit-margin magit-transient git-commit
evil-collection-log-edit log-edit message sendmail yank-media puny
evil-collection-dired dired dired-loaddefs rfc822 mml mml-sec
evil-collection-epa epa epg rfc6068 epg-config gnus-util time-date
mm-decode mm-bodies mm-encode mail-parse rfc2231 rfc2047 rfc2045 mm-util
ietf-drums mail-prsvr mailabbrev mail-utils gmm-utils mailheader
pcvs-util add-log magit-process magit-mode transient pp benchmark
magit-git magit-base evil-collection-magit-section magit-section
format-spec cursor-sensor crm llama evil-collection-with-editor
with-editor shell pcomplete recentf tree-widget wid-edit server
autorevert filenotify gcmh hl-line winner smartparens-config
smartparens-text smartparens advice loadhist undo-fu-session undo-fu
evil-collection-flycheck flycheck-package package-lint
evil-collection-imenu imenu evil-collection-finder finder finder-inf
lisp-mnt evil-collection-package-menu package browse-url url url-proxy
url-privacy url-expand url-methods url-history mailcap url-handlers
flycheck find-func ws-butler editorconfig editorconfig-core
editorconfig-core-handle editorconfig-fnmatch wakatime-mode ligature
persp-mode doom-modeline doom-modeline-segments doom-modeline-env
doom-modeline-core shrink-path f s dash nerd-icons nerd-icons-faces
nerd-icons-data nerd-icons-data-mdicon nerd-icons-data-flicon
nerd-icons-data-codicon nerd-icons-data-devicon nerd-icons-data-sucicon
nerd-icons-data-wicon nerd-icons-data-faicon nerd-icons-data-powerline
nerd-icons-data-octicon nerd-icons-data-pomicon nerd-icons-data-ipsicon
compat dtrt-indent use-package-bind-key bind-key ue projectile project
evil-collection-grep grep evil-collection-compile compile
text-property-search evil-collection-comint comint ansi-osc ansi-color
evil-collection-ibuffer ibuffer-vc ibuf-ext ibuffer ibuffer-loaddefs
generic doom-themes-ext-org solaire-mode face-remap doom-one-theme
doom-themes doom-themes-base evil-collection-atomic-chrome atomic-chrome
websocket url-cookie generate-lisp-file url-domsuf url-util url-parse
auth-source eieio password-cache url-vars bindat disp-table whitespace
cap-words superword subword json map evil-collection-tabulated-list
evil-collection-tab-bar evil-collection-simple evil-collection-replace
evil-collection-process-menu evil-collection-kmacro evil-collection-info
evil-collection-indent evil-collection-help evil-collection-eldoc
evil-collection-buff-menu evil-collection annalist let-alist
smartparens-elixir ns-auto-titlebar ibuf-macs evil evil-integration
evil-maps evil-commands reveal evil-jumps evil-command-window evil-types
evil-search evil-macros evil-repeat evil-states evil-core evil-common
thingatpt rect evil-vars ring edmacro kmacro byte-opt derived
doom-editor doom-projects doom-ui doom-keybinds use-package-core general
info eieio-core comp comp-cstr cl-extra help-mode warnings icons
comp-run bytecomp byte-compile comp-common rx :system easy-mmode
doom-start doom doom-lib cl-seq cl-macs cl-loaddefs cl-lib doom-compat
gv jansson dynamic-modules pcase subr-x rmc iso-transl tooltip cconv
eldoc paren electric uniquify ediff-hook vc-hooks lisp-float-type 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 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 xwidget-internal kqueue cocoa
ns lcms2 multi-tty make-network-process native-compile emacs)

Memory information:
((conses 16 1723170 514800) (symbols 48 110486 3) (strings 32 387607 49338)
(string-bytes 1 13385179) (vectors 16 162710) (vector-slots 8 1980397 462793)
(floats 8 1687 7990) (intervals 56 39429 795) (buffers 992 58))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1;
 involking signal using emacsclient takes very long time to complete
 ~2 seconds
Date: Sun, 20 Jul 2025 15:02:42 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Sun, 20 Jul 2025 04:15:53 +0200
> 
> After upgrading to 30.1 I have noticed that all my external scripts take
> very long to finish from time to time. In particular I noticed the line
> in my window manager script `emacsclient --eval "(evil-window-up 1)`
> would take a long time to finish if there is no window found. This
> causes the script to be very slow. I think I have narrowed it down to
> `signal`.
> 
> The time it takes to execute a simple signal seems to be very high.
>  
> time emacsclient --eval "(signal 'user-error (list (apply #'format-message \"%s\" '(test))))"
> *ERROR*: test
> emacsclient --eval   0.00s user 0.00s system 0% cpu 2.013 total

This is a feature: the Emacs server waits fore 2 sec after showing an
error message, to make sure the user has time to see it:

  (defun server-return-error (proc err)
    (ignore-errors
      ;; Display the error as a message and give the user time to see
      ;; it, in case the error written by emacsclient to stderr is not
      ;; visible for some reason.
      (server--message-sit-for 2 (error-message-string err))
      (server-send-string
       proc (concat "-error " (server-quote-arg
			       (error-message-string err))))

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Sun, 20 Jul 2025 16:30:40 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Sun, 20 Jul 2025 14:58:06 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
> Oh. Okay. I understand that this is probably not the best place to discuss
> features but having such a delay configurable would be nice. I have created a
> small patch. What email should I send it to?

Post it to this very discussion thread.

Thanks.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: bbw <at> nobad.coffee
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1;
 involking signal using emacsclient takes very long time to complete
 ~2 seconds
Date: Sun, 20 Jul 2025 16:37:07 +0300

> Cc: 79058 <at> debbugs.gnu.org
> Date: Sun, 20 Jul 2025 16:30:40 +0300
> From: Eli Zaretskii <eliz <at> gnu.org>
> 
> > From: Bror Winther <bbw <at> nobad.coffee>
> > Date: Sun, 20 Jul 2025 14:58:06 +0200
> > Cc: 79058 <at> debbugs.gnu.org
> > 
> > Oh. Okay. I understand that this is probably not the best place to discuss
> > features but having such a delay configurable would be nice. I have created a
> > small patch. What email should I send it to?
> 
> Post it to this very discussion thread.

Btw, would you mind telling why it is important to have a script that
yields an error message finish quickly?  Scripts don't usually emit
errors, and when they do, the error should be clearly visible before
it disappears from sight.

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Sun, 20 Jul 2025 14:58:06 +0200

[Message part 1 (text/plain, inline)]

Oh. Okay. I understand that this is probably not the best place to discuss
features but having such a delay configurable would be nice. I have created a
small patch. What email should I send it to?

//bror

> On 20 Jul 2025, at 14.02, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee>
>> Date: Sun, 20 Jul 2025 04:15:53 +0200
>> 
>> After upgrading to 30.1 I have noticed that all my external scripts take
>> very long to finish from time to time. In particular I noticed the line
>> in my window manager script `emacsclient --eval "(evil-window-up 1)`
>> would take a long time to finish if there is no window found. This
>> causes the script to be very slow. I think I have narrowed it down to
>> `signal`.
>> 
>> The time it takes to execute a simple signal seems to be very high.
>> 
>> time emacsclient --eval "(signal 'user-error (list (apply #'format-message \"%s\" '(test))))"
>> *ERROR*: test
>> emacsclient --eval   0.00s user 0.00s system 0% cpu 2.013 total
> 
> This is a feature: the Emacs server waits fore 2 sec after showing an
> error message, to make sure the user has time to see it:
> 
>  (defun server-return-error (proc err)
>    (ignore-errors
>      ;; Display the error as a message and give the user time to see
>      ;; it, in case the error written by emacsclient to stderr is not
>      ;; visible for some reason.
>      (server--message-sit-for 2 (error-message-string err))
>      (server-send-string
>       proc (concat "-error " (server-quote-arg
> 			       (error-message-string err))))

[Message part 2 (text/html, inline)]

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Sun, 20 Jul 2025 19:20:22 +0200

[Message part 1 (text/plain, inline)]

Sure, no problem at all. I use a tiling window manager. For this I have a script
for navigating between OS windows and for consistency I use the same script to
navigate windows in Emacs. The script uses emacsclient --eval “(evil-window-up
1)” to navigate a window up, if this fails it will call the window manager
instead because it means that there is no window in that direction. Because the
wait is now 2 seconds it takes 2 seconds to shift focus out of emacs. This might
be a minor nuisance but enough to be annoying.

[0001-Make-error-display-timout-configurable.patch (application/octet-stream, attachment)]

[Message part 3 (text/plain, inline)]

//bror

> On 20 Jul 2025, at 15.37, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> Cc: 79058 <at> debbugs.gnu.org
>> Date: Sun, 20 Jul 2025 16:30:40 +0300
>> From: Eli Zaretskii <eliz <at> gnu.org>
>> 
>>> From: Bror Winther <bbw <at> nobad.coffee>
>>> Date: Sun, 20 Jul 2025 14:58:06 +0200
>>> Cc: 79058 <at> debbugs.gnu.org
>>> 
>>> Oh. Okay. I understand that this is probably not the best place to discuss
>>> features but having such a delay configurable would be nice. I have created a
>>> small patch. What email should I send it to?
>> 
>> Post it to this very discussion thread.
> 
> Btw, would you mind telling why it is important to have a script that
> yields an error message finish quickly?  Scripts don't usually emit
> errors, and when they do, the error should be clearly visible before
> it disappears from sight.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Sun, 20 Jul 2025 21:54:13 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Sun, 20 Jul 2025 19:20:22 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
> Sure, no problem at all. I use a tiling window manager. For this I have a script
> for navigating between OS windows and for consistency I use the same script to
> navigate windows in Emacs. The script uses emacsclient --eval “(evil-window-up
> 1)” to navigate a window up, if this fails it will call the window manager
> instead because it means that there is no window in that direction. Because the
> wait is now 2 seconds it takes 2 seconds to shift focus out of emacs. This might
> be a minor nuisance but enough to be annoying.

Sorry, I don't understand: the wait is only when an error message is
to be displayed.  Your description above doesn't involve any messages,
AFAIU, so how is the recipe you've shown related to your real problem?

> +(defcustom server-error-display-wait 2
> +  "Number of seconds the server waits when displaying an error."
> +  :type 'integer
> +  :version "30.1")

Thanks, but I don't see any need to make this a user option.  If some
rare Lisp program needs to control the wait time after showing an
error message, it can let-bind a simple variable.  Users have no
reason to customize this time globally.

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Sun, 20 Jul 2025 22:07:10 +0200

> On 20 Jul 2025, at 20.54, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee>
>> Date: Sun, 20 Jul 2025 19:20:22 +0200
>> Cc: 79058 <at> debbugs.gnu.org
>> 
>> Sure, no problem at all. I use a tiling window manager. For this I have a script
>> for navigating between OS windows and for consistency I use the same script to
>> navigate windows in Emacs. The script uses emacsclient --eval “(evil-window-up
>> 1)” to navigate a window up, if this fails it will call the window manager
>> instead because it means that there is no window in that direction. Because the
>> wait is now 2 seconds it takes 2 seconds to shift focus out of emacs. This might
>> be a minor nuisance but enough to be annoying.
> 
> Sorry, I don't understand: the wait is only when an error message is
> to be displayed.  Your description above doesn't involve any messages,
> AFAIU, so how is the recipe you've shown related to your real problem?

The script waits for emacsclient to finish execution, and execution is halted
for 2 seconds to wait for the error message to be displayed. This means that any
script calling an Emacs command with emacsclient that results in an error now
takes 2 seconds longer to complete than it did previously.

In my case, the script I use for OS window management calls Emacs to change
windows. If there is no window in the requested direction Emacs throws an error.
The script then tells the OS window manager to change focus instead. This now
takes 2 seconds extra.

For example, if you’re not using Evil, consider (windmove-up). Previously,
calling it with: `emacsclient --eval "(windmove-up)"` would return instantly,
even if there was no window in that direction and Emacs showed "No window up
from the selected window". This immediate return allowed my script to pass
control to the window manager. Currently, with the new 2-second delay, the
script halts for 2 seconds before passing control, only to display an error in the
minibuffer.

>> +(defcustom server-error-display-wait 2
>> +  "Number of seconds the server waits when displaying an error."
>> +  :type 'integer
>> +  :version "30.1")
> 
> Thanks, but I don't see any need to make this a user option.  If some
> rare Lisp program needs to control the wait time after showing an
> error message, it can let-bind a simple variable.  Users have no
> reason to customize this time globally.

From a user perspective, calling emacsclient --eval from a shell or script, I
would not expect it to halt execution for 2 seconds just to display an error on
the server. Especially since this also affects workflows where Emacs is run
daemonized. 

For instance:

```
emacs —daemon 
emacsclient --eval "(windmove-up)” 
```

will now take 2 seconds longer due to the display wait. Having it as a user
option would empower users to decide whether their scripts should incur this
delay or not, preserving the responsiveness of Emacs in integrated window
management or automation setups.  _(please note I know that these two commands
are a bit nonsensical given that there are no windows)_

Maybe I'm misunderstanding the intetion. From the doc string I understand that
the delay is a means to fix a bug where the error might not be written to stderr
and thus showing the message somewhere. In daemonized mode that message is not
being displayed anywhere yet the client waits for it to finish displaying.
While I understand the reasoning behind the fixed delay, I believe it would be
more user-friendly to make it configurable, since the current approach halts
execution and may not suit all use cases.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Mon, 21 Jul 2025 14:06:02 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Sun, 20 Jul 2025 22:07:10 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
> 
> 
> > On 20 Jul 2025, at 20.54, Eli Zaretskii <eliz <at> gnu.org> wrote:
> > 
> >> From: Bror Winther <bbw <at> nobad.coffee>
> >> Date: Sun, 20 Jul 2025 19:20:22 +0200
> >> Cc: 79058 <at> debbugs.gnu.org
> >> 
> >> Sure, no problem at all. I use a tiling window manager. For this I have a script
> >> for navigating between OS windows and for consistency I use the same script to
> >> navigate windows in Emacs. The script uses emacsclient --eval “(evil-window-up
> >> 1)” to navigate a window up, if this fails it will call the window manager
> >> instead because it means that there is no window in that direction. Because the
> >> wait is now 2 seconds it takes 2 seconds to shift focus out of emacs. This might
> >> be a minor nuisance but enough to be annoying.
> > 
> > Sorry, I don't understand: the wait is only when an error message is
> > to be displayed.  Your description above doesn't involve any messages,
> > AFAIU, so how is the recipe you've shown related to your real problem?
> 
> The script waits for emacsclient to finish execution, and execution is halted
> for 2 seconds to wait for the error message to be displayed. This means that any
> script calling an Emacs command with emacsclient that results in an error now
> takes 2 seconds longer to complete than it did previously.

If there's no one to see the error message, why is the error message
issued? it should be suppressed if it is not intended for human
consumption.

> In my case, the script I use for OS window management calls Emacs to change
> windows. If there is no window in the requested direction Emacs throws an error.
> The script then tells the OS window manager to change focus instead. This now
> takes 2 seconds extra.

So my suggestion for this case is to use ignore-errors around the form
which could signal an error, or some other method of suppressing the
error.

> > Thanks, but I don't see any need to make this a user option.  If some
> > rare Lisp program needs to control the wait time after showing an
> > error message, it can let-bind a simple variable.  Users have no
> > reason to customize this time globally.
> 
> From a user perspective, calling emacsclient --eval from a shell or script, I
> would not expect it to halt execution for 2 seconds just to display an error on
> the server. Especially since this also affects workflows where Emacs is run
> daemonized. 

We had exactly opposite requests, and thus introduced this feature.
So at least some users do care about error messages in client frames.
You seem to be assuming that --eval used from a script necessarily
means that errors important for the users should never happen, but
that is definitely not the case in general.  When errors do happen, it
is important to let the user see them.

> For instance:
> 
> ```
> emacs —daemon 
> emacsclient --eval "(windmove-up)” 
> ```
> 
> will now take 2 seconds longer due to the display wait.

As I said above, using

  emacsclient --eval "(ignore-errors (windmove-up))”

should solve this problem very easily.

> Having it as a user
> option would empower users to decide whether their scripts should incur this
> delay or not, preserving the responsiveness of Emacs in integrated window
> management or automation setups.  _(please note I know that these two commands
> are a bit nonsensical given that there are no windows)_

A user option has global effect, i.e. it affects all the client
connections and frames.  By contrast, ignoring errors only where the
user's scripts really don't care about the errors will allow users to
see messages that matter.

That is why I think the proper solution is to have a simple variable
that Lisp programs could bind as part of such scripts to easily
disable the wait, if using ignore-errors or similar technique is for
some reason inconvenient or inappropriate.

> Maybe I'm misunderstanding the intetion. From the doc string I understand that
> the delay is a means to fix a bug where the error might not be written to stderr
> and thus showing the message somewhere. In daemonized mode that message is not
> being displayed anywhere yet the client waits for it to finish displaying.

The intent is to stderr of emacsclient.  The server has no way of
knowing whether the emacsclient's stderr is shown anywhere.

> While I understand the reasoning behind the fixed delay, I believe it would be
> more user-friendly to make it configurable, since the current approach halts
> execution and may not suit all use cases.

I agreed to allow this to be controllable by Lisp programs.  However,
a user option is not the only method of providing such control, and in
this case I believe it is sub-optimal, for the reason I mentioned: its
effect is global.  In addition, adding another user option requires us
to document it in user-level terms, and increases the number of user
options in Emacs that is already huge.  So I prefer to have a simple
variable rather than a user option, because the problem, when it
happens, is local and ephemeral.

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Mon, 21 Jul 2025 15:22:06 +0200

[Message part 1 (text/plain, inline)]

> On 21 Jul 2025, at 13.06, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee <mailto:bbw <at> nobad.coffee>>
>> Date: Sun, 20 Jul 2025 22:07:10 +0200
>> Cc: 79058 <at> debbugs.gnu.org <mailto:79058 <at> debbugs.gnu.org>
>> 
>> 
>> 
>>> On 20 Jul 2025, at 20.54, Eli Zaretskii <eliz <at> gnu.org <mailto:eliz <at> gnu.org>> wrote:
>>> 
>>>> From: Bror Winther <bbw <at> nobad.coffee <mailto:bbw <at> nobad.coffee>>
>>>> Date: Sun, 20 Jul 2025 19:20:22 +0200
>>>> Cc: 79058 <at> debbugs.gnu.org <mailto:79058 <at> debbugs.gnu.org>
>>>> 
>>>> Sure, no problem at all. I use a tiling window manager. For this I have a script
>>>> for navigating between OS windows and for consistency I use the same script to
>>>> navigate windows in Emacs. The script uses emacsclient --eval “(evil-window-up
>>>> 1)” to navigate a window up, if this fails it will call the window manager
>>>> instead because it means that there is no window in that direction. Because the
>>>> wait is now 2 seconds it takes 2 seconds to shift focus out of emacs. This might
>>>> be a minor nuisance but enough to be annoying.
>>> 
>>> Sorry, I don't understand: the wait is only when an error message is
>>> to be displayed.  Your description above doesn't involve any messages,
>>> AFAIU, so how is the recipe you've shown related to your real problem?
>> 
>> The script waits for emacsclient to finish execution, and execution is halted
>> for 2 seconds to wait for the error message to be displayed. This means that any
>> script calling an Emacs command with emacsclient that results in an error now
>> takes 2 seconds longer to complete than it did previously.
> 
> If there's no one to see the error message, why is the error message
> issued? it should be suppressed if it is not intended for human
> consumption.

I don’t think that is a fair question as I don’t think an error is only for human consumption.
The error should not be suppressed, as it is still useful.

>> In my case, the script I use for OS window management calls Emacs to change
>> windows. If there is no window in the requested direction Emacs throws an error.
>> The script then tells the OS window manager to change focus instead. This now
>> takes 2 seconds extra.
> 
> So my suggestion for this case is to use ignore-errors around the form
> which could signal an error, or some other method of suppressing the
> error.

I currently use the exit code from emacsclient. If I where to suppress the errors
with ignore-errors, the exit code would always be 0. Of course I could create 
more logic to handle this but that seems like the wrong way to go about this.
It should be possible to fire one-liners to without having to wait for the error to
be displayed imo.

>>> Thanks, but I don't see any need to make this a user option.  If some
>>> rare Lisp program needs to control the wait time after showing an
>>> error message, it can let-bind a simple variable.  Users have no
>>> reason to customize this time globally.
>> 
>> From a user perspective, calling emacsclient --eval from a shell or script, I
>> would not expect it to halt execution for 2 seconds just to display an error on
>> the server. Especially since this also affects workflows where Emacs is run
>> daemonized. 
> 
> We had exactly opposite requests, and thus introduced this feature.
> So at least some users do care about error messages in client frames.

I would think as much. As I said I completely understand the reason behind this
and not being able to set the delay or ignore it is probably just a small oversight.

> You seem to be assuming that --eval used from a script necessarily
> means that errors important for the users should never happen, but
> that is definitely not the case in general.  When errors do happen, it
> is important to let the user see them.

That was not what I was assuming. I understand the general use case and that 
my use is a bit more infrequent. And I’m not arguing to remove the delay
if that is what came across. I tried to make the case that exclusively halting both emacs
and caller program to show an error is a surprising (and somewhat archaic,
pardon my words) choice. Surely there would be a way to have the --eval caller exit
while retaining the error.

> 
>> For instance:
>> 
>> ```
>> emacs —daemon 
>> emacsclient --eval "(windmove-up)” 
>> ```
>> 
>> will now take 2 seconds longer due to the display wait.
> 
> As I said above, using
> 
>  emacsclient --eval "(ignore-errors (windmove-up))”
> 
> should solve this problem very easily.

Yes but then I won’t know if it failed or not

> 
>> Having it as a user
>> option would empower users to decide whether their scripts should incur this
>> delay or not, preserving the responsiveness of Emacs in integrated window
>> management or automation setups.  _(please note I know that these two commands
>> are a bit nonsensical given that there are no windows)_
> 
> A user option has global effect, i.e. it affects all the client
> connections and frames.  By contrast, ignoring errors only where the
> user's scripts really don't care about the errors will allow users to
> see messages that matter.

I think being able to disable the wait globally is useful. That
was the reasoning behind it at least.

> That is why I think the proper solution is to have a simple variable
> that Lisp programs could bind as part of such scripts to easily
> disable the wait, if using ignore-errors or similar technique is for
> some reason inconvenient or inappropriate.

As I understand, this would mean that I would have to bind it every time I call --eval if I don’t
want to wait for errors? I don’t think this is ideal either.

>> Maybe I'm misunderstanding the intetion. From the doc string I understand that
>> the delay is a means to fix a bug where the error might not be written to stderr
>> and thus showing the message somewhere. In daemonized mode that message is not
>> being displayed anywhere yet the client waits for it to finish displaying.
> 
> The intent is to stderr of emacsclient.  The server has no way of
> knowing whether the emacsclient's stderr is shown anywhere.

 ;; Display the error as a message and give the user time to see
 ;; it, in case the error written by emacsclient to stderr is not
 ;; visible for some reason.

My understanding was that the error might not have been written by emacsclient to stderr and thus 
we just wait and hope the user sees it. From your comment I guess we wait for the client to show
it which makes a bit more sense. This raises another question, how does that make sense with 
--eval then? Are we waiting, in the terminal, for the user to see the output? In that case I think it is
perfectly reasonable to exit early as stderr usually gets written as well. I’m not sure I fully
understand what the issue based on this doc string.

> 
>> While I understand the reasoning behind the fixed delay, I believe it would be
>> more user-friendly to make it configurable, since the current approach halts
>> execution and may not suit all use cases.
> 
> I agreed to allow this to be controllable by Lisp programs.  However,
> a user option is not the only method of providing such control, and in
> this case I believe it is sub-optimal, for the reason I mentioned: its
> effect is global.  In addition, adding another user option requires us
> to document it in user-level terms, and increases the number of user
> options in Emacs that is already huge.  So I prefer to have a simple
> variable rather than a user option, because the problem, when it
> happens, is local and ephemeral.

That is completely fair. However it sounds like you are suggesting to include this
as an undocumented user option instead (I could be wrong). A simple variable would definitely
suffice but I don’t agree completely with the argument against making it a user option. Only 
that it would be less work, which is of course true.

Apologies if I sound argumentative or combative, that is not my intent.

//bror

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Mon, 21 Jul 2025 16:33:24 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Mon, 21 Jul 2025 15:22:06 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
>  That is why I think the proper solution is to have a simple variable
>  that Lisp programs could bind as part of such scripts to easily
>  disable the wait, if using ignore-errors or similar technique is for
>  some reason inconvenient or inappropriate.
> 
> As I understand, this would mean that I would have to bind it every time I call --eval if I don’t
> want to wait for errors? I don’t think this is ideal either.

No, you don't have to bind it.  You could also use setq to set its
value globally, just like with user option.

>  Maybe I'm misunderstanding the intetion. From the doc string I understand that
>  the delay is a means to fix a bug where the error might not be written to stderr
>  and thus showing the message somewhere. In daemonized mode that message is not
>  being displayed anywhere yet the client waits for it to finish displaying.
> 
>  The intent is to stderr of emacsclient.  The server has no way of
>  knowing whether the emacsclient's stderr is shown anywhere.
> 
>  ;; Display the error as a message and give the user time to see
>  ;; it, in case the error written by emacsclient to stderr is not
>  ;; visible for some reason.
> 
> My understanding was that the error might not have been written by emacsclient to stderr and thus 
> we just wait and hope the user sees it. From your comment I guess we wait for the client to show
> it which makes a bit more sense.

No, we wait for the _server_ to show it in the client frame.

> This raises another question, how does that make sense with 
> --eval then? Are we waiting, in the terminal, for the user to see the output? In that case I think it is
> perfectly reasonable to exit early as stderr usually gets written as well. I’m not sure I fully
> understand what the issue based on this doc string.

emacsclient will not exit until the server shuts down the connection.
Therefore, if the server waits, emacscilent also waits.

>  I agreed to allow this to be controllable by Lisp programs.  However,
>  a user option is not the only method of providing such control, and in
>  this case I believe it is sub-optimal, for the reason I mentioned: its
>  effect is global.  In addition, adding another user option requires us
>  to document it in user-level terms, and increases the number of user
>  options in Emacs that is already huge.  So I prefer to have a simple
>  variable rather than a user option, because the problem, when it
>  happens, is local and ephemeral.
> 
> That is completely fair. However it sounds like you are suggesting to include this
> as an undocumented user option instead (I could be wrong). A simple variable would definitely
> suffice but I don’t agree completely with the argument against making it a user option. Only 
> that it would be less work, which is of course true.

A variable has a doc string, so it is not undocumented.  It just isn't
a user option.

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Tue, 22 Jul 2025 14:26:12 +0200

> On 21 Jul 2025, at 15.33, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee>
>> Date: Mon, 21 Jul 2025 15:22:06 +0200
>> Cc: 79058 <at> debbugs.gnu.org
>> 
>> That is why I think the proper solution is to have a simple variable
>> that Lisp programs could bind as part of such scripts to easily
>> disable the wait, if using ignore-errors or similar technique is for
>> some reason inconvenient or inappropriate.
>> 
>> As I understand, this would mean that I would have to bind it every time I call --eval if I don’t
>> want to wait for errors? I don’t think this is ideal either.
> 
> No, you don't have to bind it.  You could also use setq to set its
> value globally, just like with user option.

Right, then I think your suggestion of not doing a user variable is very valid.

> 
>> Maybe I'm misunderstanding the intetion. From the doc string I understand that
>> the delay is a means to fix a bug where the error might not be written to stderr
>> and thus showing the message somewhere. In daemonized mode that message is not
>> being displayed anywhere yet the client waits for it to finish displaying.
>> 
>> The intent is to stderr of emacsclient.  The server has no way of
>> knowing whether the emacsclient's stderr is shown anywhere.
>> 
>> ;; Display the error as a message and give the user time to see
>> ;; it, in case the error written by emacsclient to stderr is not
>> ;; visible for some reason.
>> 
>> My understanding was that the error might not have been written by emacsclient to stderr and thus 
>> we just wait and hope the user sees it. From your comment I guess we wait for the client to show
>> it which makes a bit more sense.
> 
> No, we wait for the _server_ to show it in the client frame.

How does that work when the client frame is a tty? Not the sense of emacs in the terminal but
using --eval.
I’m asking to understand why we waiting in exactly that scenario is fitting.

> 
>> This raises another question, how does that make sense with 
>> --eval then? Are we waiting, in the terminal, for the user to see the output? In that case I think it is
>> perfectly reasonable to exit early as stderr usually gets written as well. I’m not sure I fully
>> understand what the issue based on this doc string.
> 
> emacsclient will not exit until the server shuts down the connection.
> Therefore, if the server waits, emacscilent also waits.
> 
>> I agreed to allow this to be controllable by Lisp programs.  However,
>> a user option is not the only method of providing such control, and in
>> this case I believe it is sub-optimal, for the reason I mentioned: its
>> effect is global.  In addition, adding another user option requires us
>> to document it in user-level terms, and increases the number of user
>> options in Emacs that is already huge.  So I prefer to have a simple
>> variable rather than a user option, because the problem, when it
>> happens, is local and ephemeral.
>> 
>> That is completely fair. However it sounds like you are suggesting to include this
>> as an undocumented user option instead (I could be wrong). A simple variable would definitely
>> suffice but I don’t agree completely with the argument against making it a user option. Only 
>> that it would be less work, which is of course true.
> 
> A variable has a doc string, so it is not undocumented.  It just isn't
> a user option.


Good point. The I concur, I’ll make a new patch.

//bror

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Tue, 22 Jul 2025 16:35:11 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Tue, 22 Jul 2025 14:26:12 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
> >> My understanding was that the error might not have been written by emacsclient to stderr and thus 
> >> we just wait and hope the user sees it. From your comment I guess we wait for the client to show
> >> it which makes a bit more sense.
> > 
> > No, we wait for the _server_ to show it in the client frame.
> 
> How does that work when the client frame is a tty? Not the sense of emacs in the terminal but
> using --eval.
> I’m asking to understand why we waiting in exactly that scenario is fitting.

Sorry, I don't understand the question.  Even if the client frame is a
tty, it is the Emacs server that displays there, not emacsclient.
emacsclient doesn't display anything on that frame, it just sends the
command to the server.

> > A variable has a doc string, so it is not undocumented.  It just isn't
> > a user option.
> 
> 
> Good point. The I concur, I’ll make a new patch.

Thanks.

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Tue, 22 Jul 2025 20:01:36 +0200

> On 22 Jul 2025, at 15.35, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee>
>> Date: Tue, 22 Jul 2025 14:26:12 +0200
>> Cc: 79058 <at> debbugs.gnu.org
>> 
>>>> My understanding was that the error might not have been written by emacsclient to stderr and thus 
>>>> we just wait and hope the user sees it. From your comment I guess we wait for the client to show
>>>> it which makes a bit more sense.
>>> 
>>> No, we wait for the _server_ to show it in the client frame.
>> 
>> How does that work when the client frame is a tty? Not the sense of emacs in the terminal but
>> using --eval.
>> I’m asking to understand why we waiting in exactly that scenario is fitting.
> 
> Sorry, I don't understand the question.  Even if the client frame is a
> tty, it is the Emacs server that displays there, not emacsclient.
> emacsclient doesn't display anything on that frame, it just sends the
> command to the server.

Let me see if I understand correctly and thank you for your patience with me.
I was under the impression that using --eval would not create a client frame
so your statement confuses me a bit.
I can’t wrap my head around the necessity of the wait in the case of --eval. 
When you call --eval and encounter an error there is no output in the terminal
during the wait time. So let me rephrase my question, what are we waiting for?

> 
>>> A variable has a doc string, so it is not undocumented.  It just isn't
>>> a user option.
>> 
>> 
>> Good point. The I concur, I’ll make a new patch.
> 
> Thanks.

Yeah no problem. Thank you for taking the time to help me understand

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Tue, 22 Jul 2025 20:06:15 +0200

> On 22 Jul 2025, at 20.01, Bror Winther <bbw <at> nobad.coffee> wrote:
> 
> 
> 
>> On 22 Jul 2025, at 15.35, Eli Zaretskii <eliz <at> gnu.org> wrote:
>> 
>>> From: Bror Winther <bbw <at> nobad.coffee>
>>> Date: Tue, 22 Jul 2025 14:26:12 +0200
>>> Cc: 79058 <at> debbugs.gnu.org
>>> 
>>>>> My understanding was that the error might not have been written by emacsclient to stderr and thus 
>>>>> we just wait and hope the user sees it. From your comment I guess we wait for the client to show
>>>>> it which makes a bit more sense.
>>>> 
>>>> No, we wait for the _server_ to show it in the client frame.
>>> 
>>> How does that work when the client frame is a tty? Not the sense of emacs in the terminal but
>>> using --eval.
>>> I’m asking to understand why we waiting in exactly that scenario is fitting.

Sorry I can see I used some confusing terms here. I wrote client frame in tty. I have since
found that there is no client frame and thus I understand why you didn’t understand the
question. I’m sorely concerned with using the --eval option only, not in in combination with
-c or any other option that would create a client frame. Apologies for the confusion. 

>> 
>> Sorry, I don't understand the question.  Even if the client frame is a
>> tty, it is the Emacs server that displays there, not emacsclient.
>> emacsclient doesn't display anything on that frame, it just sends the
>> command to the server.
> 
> Let me see if I understand correctly and thank you for your patience with me.
> I was under the impression that using --eval would not create a client frame
> so your statement confuses me a bit.
> I can’t wrap my head around the necessity of the wait in the case of --eval. 
> When you call --eval and encounter an error there is no output in the terminal
> during the wait time. So let me rephrase my question, what are we waiting for?
> 
>> 
>>>> A variable has a doc string, so it is not undocumented.  It just isn't
>>>> a user option.
>>> 
>>> 
>>> Good point. The I concur, I’ll make a new patch.
>> 
>> Thanks.
> 
> Yeah no problem. Thank you for taking the time to help me understand

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Wed, 23 Jul 2025 14:10:04 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Tue, 22 Jul 2025 20:01:36 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
> >> How does that work when the client frame is a tty? Not the sense of emacs in the terminal but
> >> using --eval.
> >> I’m asking to understand why we waiting in exactly that scenario is fitting.
> > 
> > Sorry, I don't understand the question.  Even if the client frame is a
> > tty, it is the Emacs server that displays there, not emacsclient.
> > emacsclient doesn't display anything on that frame, it just sends the
> > command to the server.
> 
> Let me see if I understand correctly and thank you for your patience with me.
> I was under the impression that using --eval would not create a client frame
> so your statement confuses me a bit.

No, --eval doesn't disable creation of a client frame.  Try this:

  $ emacsclient -t --eval '(message "foo")'

This creates a client frame on the current terminal, and shows the
message "foo" there.

> I can’t wrap my head around the necessity of the wait in the case of --eval. 
> When you call --eval and encounter an error there is no output in the terminal
> during the wait time. So let me rephrase my question, what are we waiting for?

The expression inside --eval could signal an error.  That error is
shown on the client frame.  If we delete the client frame immediately,
the error message will only be shown on the stderr stream of
emacsclient, and if that is not visible, the user won't have any
opportunity of seeing the message.  So we wait for the user to see the
message on the client frame before we delete it.

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Wed, 23 Jul 2025 14:17:59 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Tue, 22 Jul 2025 20:06:15 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
> Sorry I can see I used some confusing terms here. I wrote client frame in tty. I have since
> found that there is no client frame and thus I understand why you didn’t understand the
> question. I’m sorely concerned with using the --eval option only, not in in combination with
> -c or any other option that would create a client frame. Apologies for the confusion. 

OK, but then your situation is very special, whereas the wait targets
much more general use cases: it makes sure we give the user ample
opportunity to see any error messages before they disappear from the
screen.

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Thu, 24 Jul 2025 02:29:26 +0200

[Message part 1 (text/plain, inline)]

> On 23 Jul 2025, at 13.10, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee>
>> Date: Tue, 22 Jul 2025 20:01:36 +0200
>> Cc: 79058 <at> debbugs.gnu.org
>> 
>>>> How does that work when the client frame is a tty? Not the sense of emacs in the terminal but
>>>> using --eval.
>>>> I’m asking to understand why we waiting in exactly that scenario is fitting.
>>> 
>>> Sorry, I don't understand the question.  Even if the client frame is a
>>> tty, it is the Emacs server that displays there, not emacsclient.
>>> emacsclient doesn't display anything on that frame, it just sends the
>>> command to the server.
>> 
>> Let me see if I understand correctly and thank you for your patience with me.
>> I was under the impression that using --eval would not create a client frame
>> so your statement confuses me a bit.
> 
> No, --eval doesn't disable creation of a client frame.  Try this:
> 
>  $ emacsclient -t --eval '(message "foo")'
> 
> This creates a client frame on the current terminal, and shows the
> message "foo" there.

Right, sorry for the confusion with a -t og -c option that makes sense but with 
just --eval alone I don’t think the server should wait. Would you be open to a 
solution that ignores the wait if the caller client does not have a child frame. 
I have not researched if it is possible but would like to know if it is even worth
 spending time on it.

> 
>> I can’t wrap my head around the necessity of the wait in the case of --eval. 
>> When you call --eval and encounter an error there is no output in the terminal
>> during the wait time. So let me rephrase my question, what are we waiting for?
> 
> The expression inside --eval could signal an error.  That error is
> shown on the client frame.  If we delete the client frame immediately,
> the error message will only be shown on the stderr stream of
> emacsclient, and if that is not visible, the user won't have any
> opportunity of seeing the message.  So we wait for the user to see the
> message on the client frame before we delete it.

Thank you for the clarification.



> On 23 Jul 2025, at 13.17, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee <mailto:bbw <at> nobad.coffee>>
>> Date: Tue, 22 Jul 2025 20:06:15 +0200
>> Cc: 79058 <at> debbugs.gnu.org <mailto:79058 <at> debbugs.gnu.org>
>> 
>> Sorry I can see I used some confusing terms here. I wrote client frame in tty. I have since
>> found that there is no client frame and thus I understand why you didn’t understand the
>> question. I’m sorely concerned with using the --eval option only, not in in combination with
>> -c or any other option that would create a client frame. Apologies for the confusion. 
> 
> OK, but then your situation is very special, whereas the wait targets
> much more general use cases: it makes sure we give the user ample
> opportunity to see any error messages before they disappear from the
> screen.

I don’t think this case is rare. To execute emacsclient with only --eval is not a case where
the user should be given time because the consequences is that the user is now waiting
to see the error which I believe defeats the purpose of this fix. Options like --no-wait or 
--suppress-output also have not impact on the wait time. Is that a bug or intentional.

//bror

[Message part 2 (text/html, inline)]

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Thu, 24 Jul 2025 10:07:51 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Thu, 24 Jul 2025 02:29:26 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
>  No, --eval doesn't disable creation of a client frame.  Try this:
> 
>   $ emacsclient -t --eval '(message "foo")'
> 
>  This creates a client frame on the current terminal, and shows the
>  message "foo" there.
> 
> Right, sorry for the confusion with a -t og -c option that makes sense but with 
> just --eval alone I don’t think the server should wait. Would you be open to a 
> solution that ignores the wait if the caller client does not have a child frame. 
> I have not researched if it is possible but would like to know if it is even worth
>  spending time on it.

If we can reliably detect the case where the frame showing the message
will not be deleted when emacsclient disconnects, we could avoid
waiting in those cases.  But I very much doubt this is possible, let
alone simple: --eval argument and the functions it calls could, for
example, delete a frame by their own volition, or the frame could be
deleted because what emacsclient does triggers some Emacs mechanism
which deletes frames in certain cases, etc.

Since adding a variable provides a simple way of controlling this when
needed, in addition to ignoring non-essential errors we already have,
I doubt trying to do that automatically in some cases is worth your
time.

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

From: Bror Winther <bbw <at> nobad.coffee>
To: Eli Zaretskii <eliz <at> gnu.org>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Mon, 28 Jul 2025 05:07:16 +0200

> On 24 Jul 2025, at 09.07, Eli Zaretskii <eliz <at> gnu.org> wrote:
> 
>> From: Bror Winther <bbw <at> nobad.coffee>
>> Date: Thu, 24 Jul 2025 02:29:26 +0200
>> Cc: 79058 <at> debbugs.gnu.org
>> 
>> No, --eval doesn't disable creation of a client frame.  Try this:
>> 
>>  $ emacsclient -t --eval '(message "foo")'
>> 
>> This creates a client frame on the current terminal, and shows the
>> message "foo" there.
>> 
>> Right, sorry for the confusion with a -t og -c option that makes sense but with 
>> just --eval alone I don’t think the server should wait. Would you be open to a 
>> solution that ignores the wait if the caller client does not have a child frame. 
>> I have not researched if it is possible but would like to know if it is even worth
>> spending time on it.
> 
> If we can reliably detect the case where the frame showing the message
> will not be deleted when emacsclient disconnects, we could avoid
> waiting in those cases.  But I very much doubt this is possible, let
> alone simple: --eval argument and the functions it calls could, for
> example, delete a frame by their own volition, or the frame could be
> deleted because what emacsclient does triggers some Emacs mechanism
> which deletes frames in certain cases, etc.

That is a good point, possibly too many scenarios to effectively capture them 
all. No reason to make the experience inconsistent.
> 
> Since adding a variable provides a simple way of controlling this when
> needed, in addition to ignoring non-essential errors we already have,
> I doubt trying to do that automatically in some cases is worth your
> time.

I do feel that cli the option --no-wait should honor the meaning and not wait 
for errors. It smells like a bug or oversight that it doesn’t. The current behaviour 
contradicts the help text.

//bror

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

From: Eli Zaretskii <eliz <at> gnu.org>
To: Bror Winther <bbw <at> nobad.coffee>
Cc: 79058 <at> debbugs.gnu.org
Subject: Re: bug#79058: 30.1; involking signal using emacsclient takes very
 long time to complete ~2 seconds
Date: Mon, 28 Jul 2025 15:50:29 +0300

> From: Bror Winther <bbw <at> nobad.coffee>
> Date: Mon, 28 Jul 2025 05:07:16 +0200
> Cc: 79058 <at> debbugs.gnu.org
> 
> I do feel that cli the option --no-wait should honor the meaning and not wait 
> for errors. It smells like a bug or oversight that it doesn’t. The current behaviour 
> contradicts the help text.

No, that's not what --no-wait is about.  The user manual spells that
out:

  ‘-n’
  ‘--no-wait’
       Let ‘emacsclient’ exit immediately, instead of waiting until all
       server buffers are finished.  You can take as long as you like to
       edit the server buffers within Emacs, and they are _not_ killed
       when you type ‘C-x #’ in them.

So --no-wait means do not wait until the user is done editing the
server buffers and dismisses them with "C-x #".

Previous Next

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