We first need to register the received process ID so that
'handle_child_signal' checks it. Otherwise we might never call
'waitpid' for these processes, risking deadlock.
* src/callproc.c (call_process):
* src/process.c (create_process): Don't unblock SIGCHLD before
registering the process ID to wait for.
* src/callproc.c (emacs_spawn): Accept a signal set from the caller.
Originally reported in https://github.com/joaotavora/eglot/issues/588
by Pankaj Jangid.
* lisp/progmodes/flymake.el (flymake--mode-line-counter): Count
diagnostics by severity level, not by type.
(Version): Bump to 1.1.1
Implement a limited form of tail-call optimization for the special
case of recursive functions defined with `cl-labels`. Only self-recursion
is optimized, no attempt is made to handle more complex cases such a mutual
recursion.
The main benefit is to reduce the use of the stack, tho in my limited
tests, this can also improve performance (about half of the way to
a hand-written `while` loop).
(cl--self-tco): New function.
(cl-labels): Use it.
* lisp/subr.el (letrec): Optimize single-binding corner case.
* test/lisp/emacs-lisp/cl-macs-tests.el (cl-macs--labels): Add tests
to check that TCO is working.
* test/lisp/subr-tests.el (subr--kbd): Merge test...
(subr-test-kbd): ...with this one. Fix thinko in my previous commit.
Thanks to Mattias Engdegård <mattiase@acm.org>.
* doc/lispref/windows.texi (Buffer Display Action Functions):
Document it.
* lisp/window.el (display-buffer--action-function-custom-type): Add.
(display-buffer): Mention it.
(display-buffer-use-least-recent-window): New function (bug#45688).
* src/window.c (Fwindow_bump_use_time): New function.
* lisp/net/socks.el (socks-open-connection): Fix incomplete patch
titled "Append incremental message segments in socks-filter," which
addressed chunk ordering but neglected to zero out the work area
following successful username/password authentication (bug#45162).
* lisp/textmodes/paragraphs.el (mark-paragraph): Revert
eb090f65ce (bug#45318). This restores
the behaviour from Emacs 27 -- further work is needed on this patch.
* lisp/progmodes/project.el (project--files-in-directory):
Make sure the directory includes the trailing slash in case it's
a symlink, discussed in
https://lists.gnu.org/archive/html/emacs-devel/2021-01/msg00345.html.
* lisp/progmodes/xref.el (xref-matches-in-directory): Same.
* lisp/cedet/semantic/symref/grep.el (semantic-symref-perform-search):
Same.
* lisp/emacs-lisp/eieio-core.el (eieio-defclass-autoload): Try to make
the wording of the warning about the obsoleted variable less confusing.
* lisp/emacs-lisp/bytecomp.el (byte-compile-check-variable): Don't
warn for lexical variables (Bug#39169). Fix spurious `or'.
* test/lisp/emacs-lisp/bytecomp-tests.el
(bytecomp/warn-obsolete-variable-bound\.el): New test.
* test/lisp/emacs-lisp/bytecomp-resources/warn-obsolete-variable-bound.el:
New file.
`package-quickstart.el` files presume `package-activated-list`
is a bound variable, so make sure this is the case even when `package.el` is
not yet loaded.
It turns out there were other places that used `custom-initialize-delay`
on autoloaded variables and used various hacks to make it work with
`autoload.el`. The new code makes those hacks unneeded.
Also, there's no point trying to "optimize" those rare cases anyway,
so I simplified the `autoload.el` code for those cases.
(make-autoload): For non-trivial cases,
just include the whole `defcustom` instead of trying to mimic it.
* lisp/mail/rmail.el (rmail-spool-directory): Remove hacks.
* lisp/info.el (Info-default-directory-list): Remove `progn` hack.
* lisp/custom.el (custom-declare-variable)
(custom-handle-all-keywords): Don't use pseudo-group `nil`.
* src/nsmenu.m (ns_update_menubar): Always do a deep update for
GNUstep.
([EmacsMenu menuNeedsUpdate:]): Don't update the menu as it should
always have had a deep update.
* lisp/tab-bar.el (tab-bar--define-keys, tab-bar--load-buttons):
Move some code here from 'tab-bar-mode'.
(tab-bar-new-tab-to): Call tab-bar--load-buttons and tab-bar--define-keys.
Copyright-paperwork-exempt: yes
