GNU bug report logs -
#71345
Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil
Previous Next
Full log
Message #44 received at 71345 <at> debbugs.gnu.org (full text, mbox):
> From: JD Smith <jdtsmith <at> gmail.com>
> Cc: monnier <at> iro.umontreal.ca, 71345 <at> debbugs.gnu.org
> Date: Wed, 5 Jun 2024 10:02:23 -0400
>
> In general, yes. In my case having the scope be per-buffer not per window makes the most sense in
> terms of
>
> the functionality.
>
> Given the feature of redisplay I just mentioned, you will actually get
>
> a per-window functionality, at least as far as the position of point
>
> is concerned.
>
> Not in my case, since I am discriminating between point in the selected window and other windows showing the
> same buffer, such that switching windows = changing point. Since much of the work in my mode is not
> position-dependent but depends on text content, updating face is the natural thing.
Sorry, I don't think I understand you. But if the fact that redisplay
moves point to window-point doesn't bother me, we can drop this issue.
> Thinking more about what makes font-lock “special” as a jit-lock backend, it is exactly this: font-lock claims
> exclusive ownership of `face'. Solutions I can see:
>
> 1 Make font-lock a good citizen by using its own alias for face.
> 2 Give other jit-lock backends which may alter face and potentially conflict with font-lock the ability to specify
> to jit-lock “if you re-run font lock on a region, re-run me too after that.”
I don't understand. The solution to this dilemma is well known: Lisp
programs that want to control faces without turning off font-lock mode
should set font-lock-face property, instead of the face property. Why
do you need to find another solution?
This bug report was last modified 1 year and 10 days ago.
Previous Next
GNU bug tracking system
Copyright (C) 1999 Darren O. Benham,
1997,2003 nCipher Corporation Ltd,
1994-97 Ian Jackson.