* lisp/emacs-lisp/package-vc.el (package-vc--build-documentation):
Invoke makeinfo with -I to ensure the package directory is always
consulted for @include statements. (Bug#63337)
* lisp/progmodes/vhdl-mode.el (vhdl-version): Bump to 3.38.5.
(vhdl-compiler-alist): Fix the regexps and the doc string.
Copyright-paperwork-exempt: yes
This fixes auto-filling in Texinfo buffers. It was broken by the
fix to bug#49558, which made M-q fill over-long @noindent lines by
refraining from customizing 'paragraph-separate' in Texinfo mode.
The underlying problem here is that 'auto-fill-mode' doesn't call
mode-specific filling functions, but does its job by itself, and
depends on 'forward-paragraph' to find the beginning of the
paragraph as appropriate for calculation of 'fill-prefix', and a
different value of 'paragraph-separate' broke that. As a side
effect, the change below also changes paragraph-movement commands
in Texinfo back to how they behaved prior to that bugfix, but I
don't see why the paragraph-movement behavior introduced by that
fix made more sense. Try to move through a series of
@-directives, like a paragraph preceded by several @cindex
entries, and you will see the inconsistencies. In any case, the
adverse effects of that fix on auto-filling is unacceptable.
* lisp/textmodes/texinfo.el (fill-paragraph-separate): New
variable.
(texinfo-mode): Set 'fill-paragraph-separate' to the default value
of 'paragraph-separate'. Customize 'paragraph-separate' to the
Texinfo-specific value, as it was before commit dde591571a.
(texinfo--fill-paragraph): Bind 'paragraph-separate' to the value
of 'fill-paragraph-separate', to keep 'M-q' happy.
* src/editfns.c:
(labeled_restrictions_get_bound): Return a Lisp_Object instead of
a pointer to a struct Lisp_Marker.
(unwind_reset_outermost_restriction, reset_outermost_restrictions)
(Fwiden, Fnarrow_to_region): Adapt to the new return type.
* lisp/emacs-lisp/package.el (package-menu--find-upgrades): Check if
built-in packages can be upgraded if
'package-install-upgrade-built-in' is non-nil.
This is relevant for bug #58558, although it does not fix it. Due to a wrong
ordering of with-current-buffer and a let form, the function overwrote the
global value of parse-sexp-lookup-properties and two other variables.
* lisp/progmodes/cc-defs.el (c-emacs-features): Change the nesting of
with-current-buffer and let so that the let bindings get used.
Running arbitrary ELisp code from an atimer is still dangerous,
at least because the regexp engine is not-reentrant, so let's patch up
the case we bumped into. There are probably many other such holes :-(
* src/alloc.c (garbage_collection_inhibited): Make it non-static.
* src/xdisp.c (garbage_collection_inhibited): Declare it.
(set_message, clear_message): Use it as a proxy for "we're in
a dangerous context like within `probably_quit`".
As explained in the manual (20.7.2 Fast minibuffer selection)
'fido-mode' and 'fido-vertical-mode' give priority the "flex"
completion style.
In fact, bug#62015 was recently fixed in commit because that priority
was not taking place correctly and some completions were missed.
However, an exception must be made for the 'external' completion
style.
That style, made available by the lisp/external-completion.el library,
is specifically designed to work with backends that provide only a
partial view of all completions. If we allow 'flex' to step in front
of 'external' it could mean that 'flex' matches something and
'external' isn't triggered as it probably should.
To reproduce have the rust-mode ELPA package and the rust-analyzer LSP
server handy. Then:
emacs -Q -f package-initialize main.rs
Where main.rs is this content:
fn foo1() {} fn foo2() {} fn foo3() {}
fn foobar1() {} fn foobar2() {} fn foobar3() {}
The rust-analyzer server can be quickly configured to return only 3
workspace symbols max, so evaluate:
(setq-default eglot-workspace-configuration
'(:rust-analyzer
(:workspace (:symbol (:search (:limit 3))))))
Now start M-x eglot and M-x fido-vertical-mode and type C-u M-. to
find an arbitrary symbol in this one-file project.
Type 'f'. You will see the three foo's are listed, correctly.
Now type '3'. You will only see "foo3".
But that's wrong because "foobar3" was available, if only the server
had been asked for it. This commit fixes the situation and no
completions are lost.
As an unfortunate side-effect of this commit, the fontification of
completions-common-part on the matches is lost, but that is not worse
than missing out on completions and there are better ways to recover
the fontification anyway (in external-completion.el).
See also:
https://github.com/joaotavora/eglot/discussions/1219#discussioncomment-5818336
* lisp/icomplete.el (icomplete--fido-ccd): Do not touch entries
with 'external in them.
Do not merge to master.
Backport:
(cherry picked from commit 0e8d8a7228)
* src/nsterm.m ([EmacsView initFrameFromEmacs:]): Have a second go at
creating the toolbar.
([EmacsWindow createToolbar:]): If there is already a toolbar or the
EmacsView's layer is not an EmacsLayer, then do nothing.
(cherry picked from commit 3adc1e7f37)
* lisp/net/mailcap.el (mailcap-mime-extensions,
mailcap-parse-mimetype-file, mailcap-mime-types): Don't regexp-quote
mimetypes in a context where they should be strings.
(mailcap--regexp-quote-type): Remove.
(cherry picked from commit 605414d018)
* emacs-lisp/easy-mmode.el (define-minor-mode): Ensure mode's
pretty name is not interprted as a message formatting string,
e.g., if the mode name contains a '%'. (Bug#63343)
* lisp/progmodes/csharp-mode.el (csharp-guess-basic-syntax): Check for
keywords containing 'enum' on the line before an opening bracket, and
make it behave like a class-open token.
