[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could w

From: Dmitry Gutov
Subject: Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.
Date: Sun, 12 Jun 2016 01:52:42 +0300
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:45.0) Gecko/20100101 Thunderbird/45.2

On 06/11/2016 10:50 PM, Alan Mackenzie wrote:

I'm still not even clear which branch 25.2 will come from, and that's an
important concern.

My guess is it'll will come from the master branch.  Otherwise, there'll
be too much work in cherry picking commits back to the emacs-25 branch.
That's just a guess, though.

That sounds like we shouldn't commmit any significant changes to master, doesn't it?

Hadn't you yourself proposed a far more invasive solution, not too long

Intrusive it is, but an ugly hack it certainly isn't.  It's aim is to
bring Emacs to the state it would have been in if it had been designed
for multiple major modes per buffer right from the start.  As such it
will be free from ugly workarounds.

An ugly workaround is in the eye of a beholder. And it also depends on the context.

I believe hard-widen can be made to work well, and not too hard to reason about. Although only time could tell.

The main problem with it is the amount of work to implement it is huge.
So much so, that I might well never finish it myself.  There was not a
great deal of enthusiasm expressed for it all these weeks ago, apart from
from Eli and yourself, and even then, Eli was unhappy about a fairly
important part of it.

Yes, the idea was big/complex, and the design is unprecedented among text editors, AFAIK. These two characteristics, taken together, make it it very risky, at least.

hard-widen seems to destroy the simplicity evident in narrow-to-region
and widen.

What simplicity? narrow-to-region seemingly can't decide whether it's a command for users to invoke, or it's something for Lisp code to use. We end up treating both cases the same, and that causes a lot of problems. hard-widen would differentiate those.

Why does (presumably) a super mode want to do anything with narrowing

How else would you apply each major mode's fontifications only within its subregions?

See https://github.com/purcell/mmm-mode/blob/c9a857a638701482931ffaaee262b61ce53489f3/mmm-region.el#L789-L816

Narrowing is needed by users and by major modes, and its use by
a super mode might well clash.

super modes are currently implemented as minor modes. major modes shouldn't override the choices made by minor modes, if at all possible.

Is this hard-widen proposal at all
documented in any coherent fashion?

These have been several discussions.

I'm not convinced.  But then, I don't know how the proposal will work in
any great detail.

I've linked to the patch and the previous discussion not too long ago.

That paragraph worries me greatly.  OF COURSE CC Mode uses
narrow-to-region and widen freely, there being code which can scarcely
work without it.  I and other major mode maintainers will expect to
continue to be able to do so.

The main thing CC Mode would have to worry about from then on, is that it won't always be able to goto-char to positions beyond the hard narrowing, even if they exist in the buffer (and are pointed to by some buffer-local data structure maintained by CC Mode's parser).

There may be some alternative approaches to this, but a super mode has to be able to *somehow* limit CC Mode's activity if we want to be able to use it for syntax highlighting and indentation inside e.g. Noweb's code chunks.

reply via email to

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