GNU bug report logs -
#71345
Feature: unleash font-lock's secret weapon; handle Qfontified = non-nil
Previous Next
Full log
View this message in rfc822 format
>> >> Because a given buffer can have several (window-)points,
>> >> position-dependent highlighting will ideally want to be added via
>> >> (window-specific) overlays rather than text-properties.
>> >
>> > Not sure I understand how this remark is relevant to the issue
>> > discussed here, but let me just point out that when redisplay starts
>> > working on a window, it temporarily moves point to the window-point
>> > position. So position-dependent highlighting will behave in each
>> > window according to its window-point, which I think is what's expected
>> > here?
>>
>> But the highlighting is done "once and for all" (at least until the next
>> command), so if you want it to be different in different windows (to
>> reflect the different values of `point` in those windows) you'll need
>> overlays with the `window` property because the highlighting will not be
>> re-done in the middle of redisplay when we go from one window to another.
>
> In that case, we are in trouble anyway, because the "once and for all"
> highlighting could be (by sheer luck) be done by display code that
> doesn't run as part of redisplay, but as part of something else, like
> vertical-motion.
I can't see why that would be a problem.
The highlighting code run from `jit-lock` will usually not be able to
use `point` (or `window-point`) directly. Instead, that highlighter
will need to keep track of the windows' points elsewhere "manually" via
hooks like `post-command-hook` or `pre-redisplay-functions` and then
rely on that info when performing the highlighting.
Stefan
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.