[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: |
Alan Mackenzie |
Subject: |
Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls |
Date: |
Sun, 3 Dec 2017 14:54:46 +0000 |
User-agent: |
Mutt/1.7.2 (2016-11-26) |
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).
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, (continued)
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Richard Stallman, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Alan Mackenzie, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/01
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Alan Mackenzie, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Alan Mackenzie, 2017/12/03
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/03
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls,
Alan Mackenzie <=
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/03
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Alan Mackenzie, 2017/12/03
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/03
- syntax-propertize and CC-mode (was: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls), Stefan Monnier, 2017/12/03
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/03
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Dmitry Gutov, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Stefan Monnier, 2017/12/02
- Re: [Emacs-diffs] scratch/widen-less a4ba846: Replace prog-widen with consolidating widen calls, Eli Zaretskii, 2017/12/02