emacs-devel
[Top][All Lists]
Advanced

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

[SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace p


From: Stefan Monnier
Subject: [SUSPECTED SPAM] Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls
Date: Sun, 03 Dec 2017 21:24:45 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> No, it's just a small matter of adjusting CC-mode here and there.
>> But given that the only person who understands this part of CC-mode well
>> enough is Alan, it's difficult for anyone but Alan to do it (I think
>> I could do it as well, but I know that my solution wouldn't please Alan
>> because it would involve switching over to syntax-propertize, so my
>> motivation to do it is rather low).
> Maybe you understand the issue better than me. Or maybe it's the conversion
> to syntax-propertize that would do away with the extra caches that IIRC were
> giving me troubles.

Not really, no: adjusting the current code so that those caches work
right in mmm-mode can also be done and can't be terribly hard either
(e.g. flush the caches whenever the narrowing has changed, or index the
caches with the current narrowing.  Basically the same solutions we've
discussed to get syntax-ppss to coexist reliably with narrowing).
Of course, it would take you or me a lot of time trying to understand
how those things currently work, then choose a solution, then
implement it, but it's still just a small matter of adjusting CC-mode
here and there.  Nothing fundamentally hard.

>>> How do you address the issues which prog-indentation-context did
>>> (e.g., if the embedded chunk of code is incomplete, and perhaps even
>>> syntactically invalid)?
>> We can easily provide a similar functionality with Dmitry's design.
>> Dmitry hasn't bothered doing that, because so far it's never been used
>> (so it's not even clear whether it's ever needed nor whether it would
>> provide the needed info).
> To be clear, I'm not sure what you mean. But then, the problem/question
> isn't well-formulated here.

I think he was referring to the PREVIOUS-CHUNKS part of
prog-indentation-context.  The MMM framework could easily provide some
similar facility (which would take care of changing the narrowing when
needed).  But I think we had better see some concrete uses first before
deciding upon a design for that.


        Stefan



reply via email to

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