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

[Dmitry Gutov]

On 12/3/17 2:54 PM, Alan Mackenzie wrote:

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

Thanks. I've read it, and you've seen my comments.

> > I'm not convinced "several syntax tables" would be enough, though.
>
> OK, let's make that "many syntax tables".  :-)

TBH, it's hard for me to tell with confidence either way. But here's the 
kind of syntax that Ruby allows:

a = %Q( #{ %q{abc} + %q{ "#{"abc #{ %q[ abc ] }" }" } } )

These are all nested literals (with the exception of #{}, which is 
interpolation). Thus exiting from a literal requires the knowledge of 
all openers that have been used before it, and a pre-defined set of 
syntax table (if I understood you correctly) won't do.

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

Major modes will have to work inside arbitrary restrictions one way or 
another. That's the crucial part, and it will require changes.

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

Since it's tricky, I would bet in the opposite direction. But there's no 
way to predict.

> > Coming up with it was not easy at all, BTW.
>
> Yes, I can see that.  Well done!

If you are not being sarcastic, thanks! Could you please stop opposing it?

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

Sorry, I'd rather you put it in a separate discussion. But, like Stefan 
described, this example is very much solvable with syntax-propertize 
(which I could have told you independently, too).