[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Selective font-locking?
From: |
Stefan Monnier |
Subject: |
Re: Selective font-locking? |
Date: |
Sun, 11 Apr 2021 17:10:38 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) |
> Python-font-lock-keywords is a variable defined in ‘python.el’.
> Its value is
> (python-font-lock-keywords-level-1 python-font-lock-keywords-level-1
> python-font-lock-keywords-level-2
> python-font-lock-keywords-maximum-decoration)
>
> Not sure why jit-lock-function would be evaluating it like an sexp.
`python-font-lock-keywords` does not hold a valid value for use on
`font-lock-keywords` but a value to be used as the first element of
`font-lock-defaults`. This "first element" is used to initialize
`font-lock-keywords` but it depends on things like the
`font-lock-maximum-decoration`.
Stefan
>> On Apr 11, 2021, at 12:31 PM, Stefan Monnier <monnier@iro.umontreal.ca>
>> wrote:
>>
>>> But then, why bother round-tripping text out to a special-use buffer anyway,
>>> vs. just letting font-lock operate in-situ in the shell buffer itself using
>>> python-mode’s fairly simple font-lock-defaults. The only thing needed to
>>> make this work is asking font-lock to ignore all the text with ‘field of
>>> ‘output?
>>
>> Maybe you can try something like the following?
>>
>> (defvar python--font-lock-keywords ...)
>> (defvar python-font-lock-keywords
>> '(python--apply-font-lock))
>> (defun python--apply-font-lock (limit)
>> (while (< (point) limit)
>> (let ((next-boundary (find-next-boundary limit)))
>> (if (we-should-skip-this-block)
>> (goto-char next-boundary)
>> (let ((font-lock-keywords python--font-lock-keywords))
>> (font-lock-ensure (point) limit))))))
>>
>>
>> -- Stefan
>>