Before this change, when you use a tree-sitter navigation function to
move to the next beginning of a thing, it jumps over the immediate
next thing and lands you at the beginning of the next-next thing.
Eg, when point is at the "|", and we evaluate
(treesit--navigate-thing pos 1 'beg), we go from
| (thing) (thing)
to
(thing) |(thing)
But some might expect point to go to
|(thing) (thing)
instead, which makes sense. Also, that's how Emacs expect defun
navigation functions to work. The discrepancy in expectation causes
bug#61617.
In this change I made tree-sitter navigation functions to work as what
Emacs expects. And what I described for moving to the next beginning
of thing is similarly applicable to moving to the end of previous end
of thing.
* lisp/treesit.el (treesit-beginning-of-defun)
(treesit-end-of-defun): Handle the case where defun-skipper moves
point back to where we started, by adding a retry.
(treesit--navigate-thing): Add a single condition checking for
progress to the condition form responsible for checking whether to
skip the next defun. Namely (eq pos (funcall advance next)))).
* test/src/treesit-tests.el:
(treesit--ert-defun-navigation-nested-master)
(treesit--ert-defun-navigation-top-level-master): Change tests to
reflect the new expectation.
When writing c-ts-mode Theo used parent-bol which works well except
one case:
1 for (int i=0;
2 i < 5;
3 i++) {
4 func(i);
5 }
In this case, when indenting "func(i)", parent-bol returns the start
of "i++" on line 3, instead of the "correct" anchor, the start of
"for" on line 1. parent-bol would have worked if the "for (...) {"
part is in one line.
To support this case I tried numerous things and added a bunch of
stuff, culminating in c-ts-common-statement-offset. It's complicated,
requires extra setup, and slow.
Not anymore! I think the new anchor standalone-parent really captures
the logic behind how people expect indentation to work. It's simple
and fast, and requires no setup.
* doc/lispref/modes.texi (Parser-based Indentation): Update manual.
* lisp/progmodes/c-ts-mode.el:
(c-ts-mode--standalone-grandparent): New anchor.
(c-ts-mode--indent-styles): Replace c-ts-common-statement-offset with
standalone-parent.
(c-ts-base-mode): Add comment.
* lisp/treesit.el:
(treesit-simple-indent-presets): New anchor standalone-parent.
* lisp/progmodes/ruby-mode.el (ruby-smie-rules): Fix indentation of a
method call after assignment with ruby-after-operator-indent=nil
(bug#61822).
* test/lisp/progmodes/ruby-mode-resources/ruby-after-operator-indent.rb:
Add corresponding example.
* doc/lispref/loading.texi (How Programs Do Loading):
* doc/emacs/building.texi (Lisp Libraries): Some additional
details about what happens with natively-compiled files.
* lisp/progmodes/eglot.el(eglot-client-capabilities): Announce the
new capability.
(eglot-bytewise-column, eglot-move-to-bytewise-column): New functions.
(eglot--managed-mode): Set 'eglot-current-column-function' and
'eglot-move-to-bytewise-column' appropriately.
Turns out we don't need encode-coding-region after all.
* lisp/progmodes/eglot.el (eglot-move-to-lsp-abiding-column): Rewrite.
Co-authored-by: Augusto Stoffel <arstoffel@gmail.com>
* src/bidi.c (bidi_set_paragraph_end): Reset the isolate_level to
zero. Whenever stack_idx is reset to zero, the isolate_level must
also be reset, since there cannot be any isolate status outside of
embeddings. Failure to reset isolate_level will cause us infloop
when we see a PDI. Reported by Matt Beshara <m@mfa.pw>.
As requested by a discussion on emacs-devel.
* lisp/progmodes/c-ts-mode.el:
(c-ts-mode--anchor-prev-sibling): New function.
(c-ts-mode--indent-styles): Indent first child as before, indent the
rest to their previous sibling. Remove bracketless statement rules
that I forgot to remove previously.
* lisp/progmodes/c-ts-common.el:
(c-ts-common--node-is): Guard against case where the node has no field
name.
(c-ts-common-statement-offset): Do indent a level if the "if" in the
"else if" is on an independent line.
* doc/lispref/modes.texi (Faces for Font Lock):
Update the list of faces (bug#61655).
* etc/NEWS: Update the list of new faces.
* lisp/cus-theme.el (custom-theme--listed-faces): Update.
* lisp/font-lock.el (font-lock-function-call-face)
(font-lock-variable-ref-face, font-lock-property-ref-face):
New faces.
(font-lock-property-name-face):
Rename from 'font-lock-property-face'.
* lisp/progmodes/c-ts-mode.el (c-ts-mode--font-lock-settings):
Use new faces. More 'enumerator' query to 'definition' feature.
(c-ts-mode--fontify-declarator, c-ts-mode--fontify-variable):
Use new faces.
* lisp/progmodes/cmake-ts-mode.el
(cmake-ts-mode--font-lock-settings): Use new faces.
* lisp/progmodes/csharp-mode.el
(csharp-ts-mode--font-lock-settings): Use new faces.
* lisp/progmodes/go-ts-mode.el (go-ts-mode--font-lock-settings):
Use new faces.
* lisp/progmodes/java-ts-mode.el
(java-ts-mode--font-lock-settings): Use new faces.
* lisp/progmodes/js.el (js--treesit-fontify-assignment-lhs)
(js--treesit-font-lock-settings): Use new faces. Highlight
variable definitions inside array and object destructuring
patterns.
* lisp/progmodes/python.el (python--treesit-variable-p):
Exclude identifiers in parameters.
(python--treesit-settings): Use new faces. Highlight function
parameters. Move 'keyword' up to still highlight 'self' as
keyword.
* lisp/progmodes/ruby-ts-mode.el (ruby-ts--font-lock-settings):
Use new faces.
* lisp/progmodes/rust-ts-mode.el
(rust-ts-mode--font-lock-settings): Use new faces.
* lisp/progmodes/typescript-ts-mode.el
(typescript-ts-mode--font-lock-settings): Use new faces.
* lisp/textmodes/css-mode.el (css--treesit-settings):
Use font-lock-property-ref-face.
* lisp/textmodes/toml-ts-mode.el
(toml-ts-mode--font-lock-settings):
Use font-lock-property-ref-face.
* lisp/textmodes/yaml-ts-mode.el
(yaml-ts-mode--font-lock-settings): Same.
* lisp/emacs-lisp/package-vc.el (package-vc--main-file): Just use
:lisp-dir from 'package-desc-extras', not 'pkg-spec'.
This avoid appending the contents of :lisp-dir twice, in case it is
specified both in pkg-spec and pkg-desc.
One of the bugs was straightforward. The timer function of
eglot--update-hints must set the correct buffer.
The other is much more odd. When using Eglot on Emacs's own
src/coding.c, the jit-lock code starts calling its jit-functions over
and over again with the same sequence of arguments, like so:
======================================================================
1 -> (eglot--update-hints 63551 65051)
1 <- eglot--update-hints: [nil 25592 52026 4
======================================================================
1 -> (eglot--update-hints 65051 66551)
1 <- eglot--update-hints: [nil 25592 52026 4
======================================================================
1 -> (eglot--update-hints-1 63551 66551)
1 <- eglot--update-hints-1: nil
======================================================================
1 -> (eglot--update-hints 63551 65051)
1 <- eglot--update-hints: [nil 25592 52026 4
======================================================================
1 -> (eglot--update-hints 65051 66551)
1 <- eglot--update-hints: [nil 25592 52026 5
======================================================================
1 -> (eglot--update-hints-1 63551 66551)
1 <- eglot--update-hints-1: nil
This continues forever at a very fast rate and saturates the LSP
channel.
At first I thought that it was because eglot--update-hints-1 is
actually causing the buffer to be modified with overlays sometime in
the future, but it is not so! It seems that merely calling
(goto-char (eglot--lsp-position-to-point position))
(from the LSP request handler in eglot--update-hints-1) will cause
this bug.
* lisp/progmodes/eglot.el (eglot--update-hints): Fix bugs.
Reported by Chinmay Dalal <dalal.chinmay.0101@gmail.com>
* lisp/progmodes/eglot.el (eglot--update-hints-1): Fix bug when
inlay hint contains collection of labels.
* lisp/kmacro.el: Autoload `macro--string-to-vector'.
(kmacro-ring-head): Convert `last-kbd-macro' to a vector if it's a
string, since `kmacro' uses `key-parse' on it.
(kmacro-lambda-form): Remove require for 'macros
* test/lisp/kmacro-tests.el
(kmacro-tests-name-last-macro-key-parse-syntax):
Test that insertion of macros that contain strings that look
like named keys works correctly.
(Bug#61700)
This implementation is much simpler than the one based on
windows-scroll-functions. It's also supposedly safer, as long as
jit-lock guarantees refontification of affected regions.
It's not _trivially_ simple though, as simply adding
'eglot--update-hints-1' to jit-lock-functions, while possible, is
going to request inlay hints from the LSP server for many small
regions of the buffer, depending on what jit-lock thinks is best. So
we keep coalescing these into a larger region until the time is
suitable for a more bandwidth-efficient request.
To do this, we use a jit-lock implementation detail,
jit-lock-context-unfontify-pos, which is a proxy for knowing that the
jit-lock-context-timer has run. Not sure how brittle it is, but it
seems to work reasonably.
We also get rid of the previous "get hints for entire buffer"
implementation.
* doc/misc/eglot.texi (Eglot Variables): Remove mention
to deleted eglot-lazy-inlay-hints.
* lisp/progmodes/eglot.el (eglot-lazy-inlay-hints)
(eglot--inlay-hints-after-scroll)
(eglot--inlay-hints-fully)
(eglot--inlay-hints-lazily): Remove.
(eglot--update-hints): Add function.
(eglot-inlay-hints-mode): Simplify.
* doc/lispref/files.texi (Changing Files):
* lisp/files.el (file-modes-number-to-symbolic): Clarify the
confusion with "symbolic" forms of file modes. (Bug#61709)
Originally reported in
https://github.com/joaotavora/eglot/discussions/1141 by "Mintsoup".
Eglot doesn't always show the LSP :label property of a CompletionItem
in the completion candidates. That is because label is sometimes not
what should be inserted in the buffer in the end, the :insertText
property supercedes it.
But the label is usually more suitable for display nevertheless and if
the LSP CompletionItem contains either a snippet or a textEdit, it's
safe to display the label, since :exit-function will guarantee that a
suitable buffer insertion is performed.
This change reflects that awareness that when a textEdit is available,
it's acceptable to show the label.
* lisp/progmodes/eglot.el (eglot-completion-at-point): Adjust.
Inlay hints are small text annotations to specific parts of the whole
buffer, not unlike diagnostics, but designed to help readability
instead of indicating problems. For example, a C++ LSP server can
serve hints about positional parameter names in function calls and a
variable's automatically deduced type. Emacs can display these hints
in many little 0-length overlays with an 'before-string property, thus
helping the user remember those types and parameter names.
Since inlay hints are potentially a large amount of data to request
from the LSP server, the implementation strives to be as parsimonious
as possible with these requests.
So, by default, inlay hints are only requested for the visible
portions of the buffer across windows showing this buffer. This is
done by leveraging the 'window-scroll-functions' variable, making for
a reasonably complex implementation involving per-window timers. When
scrolling a window, it may take a short amount of time for inlay hints
to "pop in". The new user variable 'eglot-lazy-inlay-hints' can be
used to exert some control over this.
Specifically, if the variable's value is set to 'nil', then inlay
hints are greedily fetched for the whole buffer every time a change
occurs. This is a much simpler mode of operation which may avoid
problems, but is also likely much slower in large buffers.
Also, because the inlay feature is probably visually suprising to
some, it is turned OFF by default, which is not the usual practice of
Eglot (at least not when the necessary infrastructure is present).
This decision may be changed soon. Here's a good one-liner for
enabling it by default in every Eglot-managed buffer:
(add-hook 'eglot-managed-mode-hook #'eglot-inlay-hints-mode)
I haven't tested inlay hints extensively across many LSP servers, so I
would appreciate any testing, both for functional edge cases and
regarding performance. There are possibly more optimization
oportunities in the "lazy" mode of operation, like more aggressively
deleting buffer overlays that are not in visible parts of the buffer.
Though I ended up writing this one from scratch, I want to thank
Dimitry Bolopopsky <dimitri@belopopsky.com> and Chinmay Dala
<dalal.chinmay.0101@gmail.com> for suggestions and early patches.
* lisp/progmodes/eglot.el (eglot--lsp-interface-alist): Define
InlayHint.
(eglot-client-capabilities): Announce 'inlayHint' capability.
(eglot-ignored-server-capabilities): Add :inlayHintProvider.
(eglot--document-changed-hook): New helper hook.
(eglot--after-change): Use it.
(eglot-inlay-hint-face, eglot-type-hint-face)
(eglot-parameter-hint-face): New faces.
(eglot--update-hints-1, eglot--inlay-hints-after-scroll)
(eglot--inlay-hints-fully, eglot--inlay-hints-lazily): New helpers.
(eglot-lazy-inlay-hints): New user variable.
(eglot-inlay-hints-mode): New minor mode.
(eglot--maybe-activate-editing-mode): Try to activate
eglot-inlay-hints-mode.
(eglot--before-change): Remove overlays immediately in the
area being changed.
(eglot--managed-mode-off): Remove overlays.
* doc/misc/eglot.texi (Eglot Features): Mention inlay hints.
(Eglot Variables): Mention eglot-lazy-inlay-hints.
This allows using the hook for interacting with the LSP server using
the current buffer as the subject of that interaction ("document" in
LSP parlance).
* lisp/progmodes/eglot.el (eglot--maybe-activate-editing-mode):
Run eglot-managed-mode-hook here.
(eglot--managed-mode): Not here.
This commits reverts part of
commit e83c78b8c7
Author: João Távora <joaotavora@gmail.com>
Date: Mon Feb 20 22:43:50 2023 +0000
Eglot: respect user's Eldoc configuration by default
In that commit, I did what many longstanding issues and users were
suggesting and removed Eglot's override of two Eldoc user
configuration varibles.
I verified that Eglot's behaviour would stay mostly unaltered but my
tests were very incomplete. In short there is no way that Eglot can
work acceptably with the default setting of
'eldoc-documentation-strategy', which is
'eldoc-documentation-default'. So it must be changed, either globally
or locally in Eglot's minor mode.
This is true for any situation where both synchronous and asynchronous
documentation sources are present. In Eglot's case there are two
asynchronous sources which have more importance than the synchronous
source. So any other strategy except the
'eldoc-documentation-default' makes sense.
* lisp/progmodes/eglot.el (eglot--managed-mode): Set
eldoc-documentation-strategy to eldoc-documentation-compose.
