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: Dmitry Gutov
Subject: Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls
Date: Sun, 3 Dec 2017 03:52:59 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0

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.

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.

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

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.

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.

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

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.



reply via email to

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