[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
bug#25672: Font-locking issues when font-lock-fontified is nil (Was: Wha
From: |
Clément Pit--Claudel |
Subject: |
bug#25672: Font-locking issues when font-lock-fontified is nil (Was: What to do when font-lock-flush + font-lock-ensure do less than font-lock-fontify-buffer? on emacs-devel) |
Date: |
Thu, 9 Feb 2017 16:22:21 -0500 |
User-agent: |
Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 |
X-Debbugs-CC: monnier@iro.umontreal.ca
Hi bug-gnu-emacs,
Sorry for the long delay in opening this. This is a follow-up to the
Emacs-devel thread "What to do when font-lock-flush + font-lock-ensure do less
than font-lock-fontify-buffer?", where Stefan asked me to open a bug report.
My original question was this:
> IIUC the proper way in Emacs 25 to signal changes that require a
> refontification to font-lock is to call font-lock-flush. This doesn't always
> do as much as font-lock-fontify-buffer does, though. In particular, when the
> font-lock-fontified variable is nil (which does happen, though I don't know
> why; I don't know what this variable is for), then calling font-lock-fontify
> buffer does refontify the whole buffer, but font-lock-flush and
> font-lock-ensure don't seem to do anything. What's the proper way to mark a
> buffer for refontification (and refontify the visible portion) immediately in
> 25?
And here's is my original test case:
(with-current-buffer (get-buffer-create "temp")
(erase-buffer)
(setq-default prettify-symbols-unprettify-at-point 'right-edge)
(emacs-lisp-mode)
(prettify-symbols-mode)
(insert "lambda\n\nlambda")
(pop-to-buffer (current-buffer)))
Moving around in this buffer unprettifies and reprettifies ‘lambda’s into
‘λ’s as the point moves in and out of them. Setting ‘font-lock-fontified’ to
nil breaks that mechanism (the ‘λ’s are unprettified but no reprettified), and
no series of ‘font-lock-flush’ and ‘font-lock-ensure’ will reprettify them.
Eli remarked the following:
> However, please explain why font-lock-ensure-function calls
> font-lock-DEFAULT-fontify-buffer. If it's supposed to be good for any mode,
> why
> does it call the default fontification?
>
> As a matter of fact, if I replace the font-lock-default-fontify-buffer
> call with a call to font-lock-fontify-buffer, the problem described by
> the OP goes away. That is why I said what I said.
And Stefan answered:
> I haven't seen the beginning of the thread, but if that fixes the
> problem, then I think it's a good change.
>
> To go back to the previous question. I guess I used
> font-lock-default-fontify-buffer because the whole point is to get rid
> of all the misuses of font-lock-fontify-buffer, but I think in this case
> it's indeed the right thing to do.
Then Stefan said:
> > Should I open a bug report about this?
> Yes. And put me in X-Debbugs-Cc.
Done :)
Thanks,
Clément.
signature.asc
Description: OpenPGP digital signature
[Prev in Thread] |
Current Thread |
[Next in Thread] |
- bug#25672: Font-locking issues when font-lock-fontified is nil (Was: What to do when font-lock-flush + font-lock-ensure do less than font-lock-fontify-buffer? on emacs-devel),
Clément Pit--Claudel <=