emacs-devel
[Top][All Lists]
Advanced

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

Re: forward-comment and syntax-ppss (was: Preview: portable dumper)


From: Alan Mackenzie
Subject: Re: forward-comment and syntax-ppss (was: Preview: portable dumper)
Date: Tue, 6 Dec 2016 19:55:08 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Stefan.

On Sun, Dec 04, 2016 at 05:24:45PM -0500, Stefan Monnier wrote:
> >> Your patch was indeed simpler.  Indeed, it was so simple as actually not
> >> to work in general, as well as being ~2 orders of magnitude slower than
> >> the current (forward-comment -1).
> > You make it sound like it barely ever works and it's always 100
> > times slower.  I think this qualifies as "gross misrepresentation".

> As a counter-point, I've been using the patch below since this
> discussion, without noticing any adverse effects.  I don't doubt that it
> will occasionally mis-behave in cc-mode buffers, but I'm not sure it's
> an argument against this patch.

I'm not quite sure what you're saying here.  Normally, a piece of
software not working properly is an extremely strong argument against it
(though it's an equally strong argument for fixing it).

> After all, there are mostly 3 entities at play here:
> - this patch (i.e. the linkage between forward-commment and syntax-ppss).
> - syntax-ppss itself.
> - cc-mode.

> I think most of the problems that will show up with this patch ....

What, exactly, is this patch intended to do?  That's not obvious.

> .... can be attributed to the current syntax-ppss implementation (e.g.
> its inability to deal reliably with narrowing or with changes of the
> syntax-table).  Maybe those problems will best be solved not just by
> changing syntax-ppss but by providing more info to syntax-ppss (e.g.
> requiring major modes who narrow the buffer or change the syntax-table
> to indicate to syntax-ppss how to handle it (since there are various
> possible choices and syntax-ppss usually can't know which is best or
> even which is right)).

I think this would be a last resort, when nothing else can work.  The
syntactic primitives should not have high level lisp code poking about
in their innards.  When it comes to narrowing a buffer, I think that the
syntactic context of a buffer position should not depend on whether the
buffer has been narrowed.  If there are use cases this inconveniences, I
think that those use cases' use of narrowing is mistaken, and some other
tool should be used in its place.

> So I see this patch as an opportunity to improve syntax-ppss.

I don't think anybody will object to improving syntax-ppss.  But, at the
same time, calling syntax-ppss from the C syntax routines should be
avoided, as far as possible.  Such calls are likely to transform
side-effect free functions (such as forward-comment) into side-effect
encumbered functions, which is likely to make them less useful, and to
make Emacs more buggy, less flexible and more difficult to use.

And, just to emphasise, I think it's clear that syntax-ppss has no
business in forward-comment.  syntax-ppss is slow (compared to the
current implementation of forward-comment), and there's no need for it,
given the existence of the comment-cache branch.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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