[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: emacs-tree-sitter and Emacs
From: |
Stephen Leake |
Subject: |
Re: emacs-tree-sitter and Emacs |
Date: |
Fri, 03 Apr 2020 16:00:38 -0800 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/26.2 (windows-nt) |
Eli Zaretskii <address@hidden> writes:
>> From: Stephen Leake <address@hidden>
>> Date: Fri, 03 Apr 2020 09:05:34 -0800
>>
>> > Regarding the above use case, I don't think I understand what exactly
>> > did you mean. First, you cannot use set-variable to modify the value
>> > of font-lock-function-name-face, because it isn't a defcustom.
>> > Second, what exactly did you mean to set it to, to cause the effect
>> > you were talking about? IOW, can you present a complete recipe,
>> > starting from "emacs -Q", where you make such a change, and then you
>> > need to switch buffers to cause function names be displayed
>> > differently? I can tell you that if you replace "M-x set-variable"
>> > with "M-x customize-face" and change some attribute of
>> > font-lock-function-name-face, the effect on another frame is
>> > immediate, which means redisplay takes note of the change and redraws
>> > the other frame. But I'm not sure this is the same use case you had
>> > in mind.
>>
>> Ok. In this case, customize-face causes the redisplay. So your original
>> objection to the ada-mode face design, which was:
>>
>> > And they cannot pick up every relevant change; for example, what
>> > happens if some face used for font-lock is modified?
>>
>> is moot.
>
> My point was about using the modification hooks, not about triggering
> redisplay. That redisplay _is_ triggered by such changes (and by
> others), was exactly my point.
Ok.
> Namely, relying on redisplay to redraw the regions that require it,
> and as side-effect to refontify those regions, is better than using
> modification hooks to decide where to refontify.
the after-change-functions decide where to _parse_, which is not the
same as where to refontify. The results of a parse for fontify are
cached in text properties; if all the text properties in the fontify
region are current, no parse is needed. If some are not, parsing all the
changed text at least to the end of the fontify region is required, for
Ada.
For other languages where parsing smaller chunks is possible, the
same mechanism works, and the parse must include all of the changed parsible
chunks that overlap the fontify region.
--
-- Stephe
- Re: emacs-tree-sitter and Emacs, (continued)
- Re: emacs-tree-sitter and Emacs, martin rudalics, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Stephen Leake, 2020/04/02
- Re: emacs-tree-sitter and Emacs, Jorge Javier Araya Navarro, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Stephen Leake, 2020/04/03
- Re: emacs-tree-sitter and Emacs, Eli Zaretskii, 2020/04/03
- Re: emacs-tree-sitter and Emacs,
Stephen Leake <=
Re: emacs-tree-sitter and Emacs, Stefan Monnier, 2020/04/01