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

[Alan Mackenzie]

Hello, Dmitry.

On Sun, Dec 03, 2017 at 03:52:59 +0000, Dmitry Gutov wrote:
> On 12/2/17 8:28 PM, Alan Mackenzie wrote:

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

> I've never seen a full proposal. Details matter. And it's going to have 
> to include a lot more of them.

Details do matter.  I posted a full proposal, Subject: "Syntax
ambiguities in narrowed buffers and multiple major modes: a proposed
solution." here in emacs-devel on Sat, 25 Feb 2017 13:53:56 +0000.

I've changed my mind about some of the details, partly in response to
what people said, partly because I see things now I didn't see then.

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

> Extending parse-partial-sexp to nested syntax tables can be worthwhile, 
> but that can't be it. And while we're on this subject, there are some 
> example of Ruby syntax that we'd like to see supported, where the 
> current syntax tables (and even syntax-propertize-function) don't cut it.

What is preventing a s-p-function from working satisfactorally?

> I'm not convinced "several syntax tables" would be enough, though.

OK, let's make that "many syntax tables".  :-)

> > 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 major modes will have to change to allow for this support, that's 
> for sure. You can't expect no code changes.

Maybe, maybe not.  Super-modes would definitely have to change to use
it.  Any changes in major modes should be minor.  (I don't rate
restrictions on the use of Emacs primitives to be minor.)

> > The fact we are having this conversation is a strong indication
> > that the current designs for MMM are not coherent enough.

> The current idea is "let's do the minimum coherent step forward, so that 
> somebody can continue improving things later". A step that's easy to 
> use, and also easy to undo later, if we find something else that's much 
> better.

OK.  With such a tricky subject matter, it would surprising if we
couldn't find improvements for a long time.

> Coming up with it was not easy at all, BTW.

Yes, I can see that.  Well done!

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

> It's simply description of good engineering. You can try to criticize 
> the details of syntax-propertize, but the idea of reusing common 
> solutions is more than sound.

If those common solution are adequate, yes.  But it is also critical to
have the freedom to depart from things like syntax-propertize when they
are inadequate, or too awkward.  syntax-propertize is inadequate for CC
Mode:

E.g., in C++ Mode, with

    foo (a < b, c > d);

we have a constructor foo with one parameter d, of a templated type.  The
characters "<" and ">" have syntax-table text properties giving them
paren syntaxes and making them match each other.

Now, mark the characters ", c > d" and kill them with C-w.  What we are
left with is a function call with an integer argument a < b:

    foo (a < b);

.  Something, somewhere has to remove the syntax-table property from
"<", since it is no longer a template delimiter.

The syntax-propertize mechanism won't do this, since the place to
de-propertise is before BEG.  In CC Mode, the job is done by
c-before-change-check-<>-operators.

-- 
Alan Mackenzie (Nuremberg, Germany).