emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes


From: Stefan Monnier
Subject: Re: master 7362554: Widen around c-font-lock-fontify-region. This fixes bug #38049.
Date: Thu, 14 Nov 2019 10:33:25 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>>> diff --git a/lisp/reposition.el b/lisp/reposition.el
>>> index 22f9986efb..5d9c3180ad 100644
>>> --- a/lisp/reposition.el
>>> +++ b/lisp/reposition.el
>>> @@ -174,8 +174,8 @@ reposition-window
>>>   (defun repos-count-screen-lines (start end)
>>>     (save-excursion
>>>       (save-restriction
>>> -      (narrow-to-region start end)
>>> -      (goto-char (point-min))
>>> +      (narrow-to-region (point-min) end)
>>> +      (goto-char start)
>>>         (vertical-motion (- (point-max) (point-min))))))
>> This looks like a good change in any case, tho it does beg the question:
>> why does it narrow?
>
> I think it does that simply because vertical-motion takes LINES as an
> argument, and not LIMIT. And it's easier to narrow the buffer than 
> compute the number of lines between start and end.

Ah, right, that makes total sense.  So, a big +1 on this patch from me.

>> So, your earlier patch which added a call to `font-lock-ensure` was
>> "more or less right", except that it should have used
>> `jit-lock-ensure` (currently called `jit-lock-fontify-now`)
> But wouldn't this fail to work when jit-lock is not used?

I don't think so, no: it will (should) just do nothing.
But in case it misbehaves, I'd consider it a bug in jit-lock.el.

> And we'll need a guard to make sure font-lock is used as well. (*)

Why would we need that?


        Stefan




reply via email to

[Prev in Thread] Current Thread [Next in Thread]