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

[Dmitry Gutov]

On 14.11.2019 18:08, Eli Zaretskii wrote:
> > Cc: address@hidden, address@hidden, address@hidden
> > From: Dmitry Gutov <address@hidden>
> > 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?

> 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.