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

[Eli Zaretskii <eliz@gnu.org>]

> Cc: monnier@iro.umontreal.ca, acm@muc.de, emacs-devel@gnu.org
> From: Dmitry Gutov <dgutov@yandex.ru>
> Date: Thu, 14 Nov 2019 23:07:53 +0200
> 
> On 14.11.2019 18:08, Eli Zaretskii wrote:
> >> Cc: monnier@iro.umontreal.ca, acm@muc.de, emacs-devel@gnu.org
> >> From: Dmitry Gutov <dgutov@yandex.ru>
> >> Date: Thu, 14 Nov 2019 16:50:14 +0200
> >>
> >> On 14.11.2019 16:48, Eli Zaretskii wrote:
> >>>>> The reality could be different,
> >>>>> and I'd like us to support those different conditions.  It doesn't
> >>>>> sound like it's much harder.
> >>>> There are options, sure. But I think all of them will require explicit
> >>>> support from major modes.
> >>> I don't think so.  All we need to make sure is that the narrowing
> >>> doesn't conceal portions of the embedded fragment.
> >>
> >> I would very much like to read your idea in more detail.
> > 
> > I'm not sure what else is there to say.  Really.  Can you ask specific
> > questions?
> 
> Question one is: do you still stand by that earlier assessment?

Which one?

> > My point was that Alan wanted not to start fontification from a random
> > place determined by blindly narrowing to some arbitrary chunk.  But in
> > mmm-mode the code fragment is present in the narrowed portion in its
> > entirety, so it doesn't sound like we have a real problem here.
> 
> It's what I was hoping would work, but apparently font-lock rules are 
> inevitably called from different narrowings (at least in some, edge-case 
> scenarios). So to be ironclad, CC Mode has to call 'widen' its some of 
> its font-lock-keywords matchers.
> 
> But that breaks the narrowing applied by mmm-mode in its aggregated 
> fontification function.

Maybe we need to revisit the prog-widen idea.