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: Fri, 1 Dec 2017 23:24:28 +0000
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:57.0) Gecko/20100101 Thunderbird/57.0

On 12/1/17 10:35 PM, Alan Mackenzie wrote:

A shim?  Yuck!  My idea is an MMM that doesn't require any such shims.M

Ideas have the tendency to be more ideal than their eventual implementations.

Major modes should not be "polluted" to adapt to one particular MMM.  It
solidifies that MMM, making it difficult to change to a better one.

It's not "one particular MMM". All existing MMM packages use narrowing.

And it's not just to adapt. Calling `widen' in fewer places just makes sense from engineering point of view.

You mean, it would be better to wait until this protocol is firmly
established before arguing against it?

The proposal isn't going to hurt you in any significant way. That's what I mean.

The shim doesn't help.  It's still horribly ugly.

Calling widen from dozens of functions in a package is ugly. A shim just helps you avoid rearchitecting it.

Indeed it can, and it must.  A super-mode thus may not "reserve"
narrowing for its own purposes to the exclusion of other uses.

Right.

Glad we agree upon this.  However that contradicts your proposal that
anything a beginning-of-defun-function calls can't use narrowing and
widening.

Nope.

There's your example for contention between major modes' narrowing and
MMM's narrowing.

Not sure what you mean by that. It's already apparent that some major modes will have to change to adapt to this proposal. Isn't it?

If you didn't narrow, CC Mode would behave properly.

Without narrowing it gives us wrong syntax highlighting and indentation.

So these are my takeaways:

1) The "low-level primitives" in CC Mode do not widen consistently.

They widen when they need to, which is not always.

I don't think I'd get this error if they did.

But hmm, I think this error was in fontification code, actually. mmm-mode, of course, narrows to each individual hunk before using the corresponding mode's font-lock-keywords.

2) The other errors should be solvable, but they require a separate
investigation, which nobody has found the time and energy to do so far,
over many years. So maybe it's not so necessary.

I would like AWK Mode to work inside shell-script-mode, since short AWK
scripts are so often embedded in scripts.

When we're talking about short snippets, sometimes it's easier to use e.g. js-mode instead. That's what I've been advising for C code, too.

But if complex syntax in AWK happens often, and CC Mode has good support for it, maybe supporting it is a worthy endeavor.

3) The solution to the other problems is most likely orthogonal to the
current discussion. Allowing multi-mode packages to use narrowing
certainly shouldn't hurt.

Of course not.  It's prohibiting major modes from using
narrowing/widening that is objectionable.

Sometimes code has to follow certain protocols. That's nothing new.

Investing the time and energy on an implementation was too risky.  In
practice, Stefan has veto power over what goes into the syntax area, and
I've been at the sharp end of that veto once too often (the rejection of
my "comment-cache" code which solved the problem of open parens at
column zero in comments).  In the last exchange about the "syntactic
islands" concept, Stefan showed little enthusiasm for it: there was no
"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".

No discussion, really? I've pointed out the major difficulties I could think of, which is normally the area that should get the most attention during the discussion of a technical proposal.

The fact that few people seemed interested... well, that happens. There's no use complaining that a proposal is unpopular. I've had a few over the years myself. Please feel free to push for it, of course.

But it has negative implications.  It will only work with major modes
specially adapted for it, and it imposes severe restrictions on those
major modes.  I think it needs those modes to be "polluted" with MMM
code.

We already have several major modes adhering to it, and for them the change was trivial. As far as major modes are concerned, web programming is the most important area, so CC Mode support is less urgent anyway.

If the new code you're proposing is incorporated into Emacs, it will
acquire some momentum, making it difficult to introduce a better
solution.

Like mentioned, for most major mode the changes are trivial, if at all needed.



reply via email to

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