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

[Alan Mackenzie <acm@muc.de>]

Hello, Stefan.

On Fri, Dec 01, 2017 at 21:47:26 -0500, Stefan Monnier wrote:
> >> "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.

It would work, and work well, for the simple reason it is a coherent
proposal.

Emacs was designed with the assumption that each buffer has exactly one
major mode.  It turns out this assumption hasn't held all that well.
When that assumption does hold, the following returns a well defined and
meaningful state:

    (parse-partial-sexp 1 n)

.  I am proposing extending this property for buffers with several
modes and several syntax tables.  Nothing more, nothing less.

You're saying that providing support for multiple major modes in the
Emacs core is a pipe dream.  I put it to you you're mistaken.  ONLY by
supporting this in the Emacs core can we arrive at a coherent efficient
design.  The fact we are having this conversation is a strong indication
that the current designs for MMM are not coherent enough.

[ .... ]

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

That is immensely patronising.

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

syntax-propertize is your way of doing things, so naturally you want it
to become a "standard".  However it is not the only way of doing things,
and is suboptimal in several respects.

When designing syntax-propertize, with whom did you discuss the
technical aspects?  Certainly not with me, but this may have been before
my time in Emacs.  With Martin Stjernholm or Barry Warsaw, my
predecessors as CC Mode maintainers?  With RMS?  With anybody at all?

>         Stefan

[ .... ]

-- 
Alan Mackenzie (Nuremberg, Germany).