emacs-devel
[Top][All Lists]
Advanced

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

Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with co


From: Stefan Monnier
Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls
Date: Fri, 01 Dec 2017 21:47:26 -0500
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/27.0.50 (gnu/linux)

>> "OK, implement it and we'll see what we can do with it", no
>> encouragement whatsoever.  There was no discussion of major topics, such
>> as the possibilities it would open up, or any plans to use it.  Mainly,
>> the talk was about minor aspects of the proposal, at one point
>> degenerating into a squabble about the use of the word "island".

Here's my opinion: experience shows that implementing MMM support is messy
for all kinds of reasons, and that the problems that show up in practice
are very varied and many of them are completely unexpected.

So any paper design such as your "islands" to me sounds like a plain and
simple pipe-dream.  Can it work in theory?  Sure, why not.  Can it work
in practice?  Probably.  Will it work without having to "pollute major
modes to adapt to that particular MMM"?  Not a chance in hell, IMO.

So overall, will it be better than the solutions we're already
familiar with?  maybe, but my money is on "probably not".

Also, I don't think major modes need more freedom in how to implement
things.  Instead, they need more help so they can just use existing
solutions rather than reinvent the wheel in their very own way.
Conventions/guidelines actually makes the life of major mode
implementers easier, rather than harder.  E.g. they can just use
`syntax-propertize` and move on.  If it's not efficient enough or if it
doesn't interact correctly with an MMM framework, it's not their problem
it's syntax-propertize's. 


        Stefan


PS: On a very related topic, I'd recommend anyone interested in such
ideas to look at the way other editors handle font-lock-style
highlighting and based on that develop a replacement for font-lock.
AFAICT, font-lock is much less powerful/flexible than some of our
competitor's frameworks, especially in terms of handling differently
different parts of the buffer.  So a "font-lock-NG" might be a good
starting point to add better support for some MMM-style features.



reply via email to

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