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

[Dmitry Gutov <dgutov@yandex.ru>]

On 14.11.2019 16:55, Stefan Monnier wrote:
>> 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.

> Also, I think I'm beginning to understand: the issue is that
> vertical-motion uses the redisplay code, which in turn calls jit-lock
> when needed.

Exactly.

> 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? And we'll need 
a guard to make sure font-lock is used as well. (*)

> and
> could have a comment explaining that vertical-motion will trigger
> jit-lock anyway so it's better to do it once beforehand on the whole
> region, not only so it can be done outside of the narrowing but also so
> it can be done more efficiently than one jit-lock-chunk-size at a time.

That's a good explanation as well, yes.

So, if you like, I can push a patch with both of these changes. If you 
could only clarify what condition to use in (*).