Re: Bug #22983 (syntax-ppss returns wrong result) is still open. Could we fix it before the release, please.

[Alan Mackenzie]

Hello, Dmitry.

On Sat, Jun 11, 2016 at 07:10:03PM +0300, Dmitry Gutov wrote:
> On 06/11/2016 01:07 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.

> > Is Vitalie still working on ... anything else to do with
> > Emacs)?

> Yes:

> https://github.com/emacs-ess/ESS/commits/master
> https://github.com/vspinu/polymode/commits/master

Glad to hear that!

> Adding hard-widen, however, is a low-level endeavor, and it seems nobody 
> sufficiently proficient there is in any hurry to help.

> > I can't say I feel enthusiastic about "hard-widen".  I haven't looked
> > into it that thoroughly, but it feels a bit like an ugly hack whose
> > ramifications might percolate all the way through Emacs, and that might
> > make us regret it fairly heavily in the not too distant future.

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

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.

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.

> I think hard-widen strikes a certain balance, in that is will require a
> moderate amount of changes in Emacs, and little to no changes in the
> user code, considering we've always (or at least for a long time) had
> to write it with consideration for the current narrowing.

hard-widen seems to destroy the simplicity evident in narrow-to-region
and widen.  It's an ugly hack, and I fear that if we implement it, it
will have ugly unforeseen consequences which it will then be too late to
do anything about.

Why does (presumably) a super mode want to do anything with narrowing
anyway?  Narrowing is needed by users and by major modes, and its use by
a super mode might well clash.  Is this hard-widen proposal at all
documented in any coherent fashion?

> If there's anything to complain about it, it's that it doesn't bring new 
> niceties. So: modest gains, and little amount of pain. Seems 
> conservative enough for the Emacs community.

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

> >>> Yes, I think having the binary toggle `syntax-ppss-dont-widen' purely to
> >>> direct the innards of the function is poor programming (since it
> >>> explicitly toggles a toggle inside a supposedly abstract function).

> >> Abstract?

> > Yes, abstract.  `syntax-ppss' has an specification and interface on the
> > one side, and an implementation on the other.

> Just like any other function?

No, some so-called functions, though thankfully few in Emacs, are
incoherent assemblages, with callers having to reach in and manipulate the
innards (and hence be aware of the implementation).  And so on.  Look up
terms like "coherence" and "coupling" in computer science text books.

> >>> I think an improvement would be to dispense with that toggle, and
> >>> have two distinct functions, one in place of
> >>> `syntax-ppss-dont-widen' being nil, and the other in place of
> >>> `s-p-d-w' being non-nil.  The latter function might usefully have an
> >>> extra parameter specifying the base point that parse-partial-sexp
> >>> should be calculated from.  That would leave quite a few options
> >>> open for the internal logic of the function.

> >> That wouldn't help in the multi-mode case, which is the primary use I
> >> have in mind for syntax-ppss-dont-widen.

> > Why would it not help?

> Because you (in CC Mode) will choose the more straightforward version 
> that does widen. And I, in mmm-mode, will thus have no ability to modify 
> what your code is doing by narrowing, and will send you dark thoughts 
> instead.

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.  A super mode should, should it use
widening and narrowing, do so in a manner which won't interfere with
major modes' and users' use of it.

> What's the purpose of the other function? Who's going to use it?

Maybe nobody.  ;-)  What I missed was the need to insert it far and wide
into existing code.

-- 
Alan Mackenzie (Nuremberg, Germany).