Movatterモバイル変換


[0]ホーム

URL:


Skip to content

Navigation Menu

Sign in
Appearance settings

Search code, repositories, users, issues, pull requests...

Provide feedback

We read every piece of feedback, and take your input very seriously.

Saved searches

Use saved searches to filter your results more quickly

Sign up
Appearance settings

Don't return invalid region from lsp-semantic-tokens--fontify.#4876

New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to ourterms of service andprivacy statement. We’ll occasionally send you account related emails.

Already on GitHub?Sign in to your account

Open
kurnevsky wants to merge1 commit intomaster
base:master
Choose a base branch
Loading
fromfix-invalid-region

Conversation

@kurnevsky
Copy link
Member

Currently it returns 0 . 0 which is outside of the buffer, (point-min) is 1. It's better to return nil instead because such invalid region might break other packages, i.e. indent-bars.

Seejdtsmith/indent-bars#117

Currently it returns 0 . 0 which is outside of the buffer, (point-min)is 1. It's better to return nil instead because such invalid regionmight break other packages, i.e. indent-bars.
@jdtsmith
Copy link

It also needs to call the downstream function no matter what. These functions should onlyexpand, not contract (or zero out) the indicated region.

@kurnevsky
Copy link
MemberAuthor

It also needs to call the downstream function no matter what. These functions should onlyexpand, not contract (or zero out) the indicated region.

But then the downstream function will colorize that region, won't it? This will result in inconsistent syntax highlighting and flickering once lsp-mode gets semantic tokens from lsp-server. We don't really want to get colors from the major mode here.

@jdtsmith
Copy link

But then the downstream function will colorize that region

Yes, but otherwise you are "hogging" jit-lock all for yourself, and other packages which need access to jit-lock updates simply won't work. The way eglot semantic and semel are solving this is to decorate text with semantic-based text-propertiesas/when available, then, in font-lock (just font-lock-keywords as Stefan is recommending) turn those into 'face. So if there is no semantic info yet available, font-lock wins, but once available, lsp wins.

Honestly, I don't think lsp should need to advisefont-lock-fontify-region-function at all; it can just use keywords. See this discussion for more:https://lists.gnu.org/archive/html/emacs-devel/2025-10/msg00024.html.

Note thatindent-barsdoes need to wrap thef-l-f-r-f, because (with scope highlighting), fontification depends onpoint, which is unusual. So rather than constantly redoing all of font-lock as you scroll point around in the buffer, we arrange to updateonly the bars (unless the rest of font-lock is actually necessary).

@sebastiansturm
Copy link
Contributor

sorry, I just read this today; sounds like I was using the wrong approach but if I can get rid of having to interfere withf-l-f-r-f I'm all for it.@jdtsmith thanks for the pointer(s), I plan to have a look at that proper approach (the one taken by eglot, semantic and semel) around Sunday

kurnevsky reacted with heart emoji

@sebastiansturm
Copy link
Contributor

@kurnevsky I pushed a commit to my fork at sebastiansturm/lsp-mode that uses font-lock-keywords. Like@jdtsmith said, this seems to be much simpler and work at least as well. But I haven't tested this much and have only read some of the docs on font-lock-keywords so when I find the time next week I should probably do some more poking around before I open a PR with this. But if you can test this and check whether it solves your current issue, that'd be much appreciated

Sign up for freeto join this conversation on GitHub. Already have an account?Sign in to comment

Reviewers

No reviews

Assignees

No one assigned

Projects

None yet

Milestone

No milestone

Development

Successfully merging this pull request may close these issues.

4 participants

@kurnevsky@jdtsmith@sebastiansturm

[8]ページ先頭

©2009-2025 Movatter.jp