emacs-devel
[Top][All Lists]
Advanced

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

Re: Problems with syntax-ppss: Was [... Apply `comment-depth' text prope


From: Alan Mackenzie
Subject: Re: Problems with syntax-ppss: Was [... Apply `comment-depth' text properties when calling `back_comment'.]
Date: Wed, 9 Mar 2016 14:19:30 +0000
User-agent: Mutt/1.5.24 (2015-08-30)

Hello, Stefan.

On Wed, Mar 09, 2016 at 08:11:33AM -0500, Stefan Monnier wrote:
> > There are several problems with syntax-ppss.  It is not a rigorously
> [...]

> Those problems are nitpicks about the current state of the implementation.

No, these problems are to do with the philosophy of syntax-ppss.  To use
it demands active maintenance of the cache from the program using it.
(forward-comment -1) should just work, regardless of the buffer
restriction, text properties, what have you.

forward-comment should not erase syntax-table text properties.  This is,
however, what syntax-ppss does.  Think about it, syntax-propertize calls
syntax-propertize-extend-region-functions, which itself is likely to
want to do (forward-comment -1).  Whoops!  forward-comment is a
primitive - it shouldn't be dependent on the correct functioning of high
level Lisp code.

> Again: it's used all over the place, and your back-comment hack won't
> replace syntax-ppss any time soon, ....

Who ever said it was meant to?  It lacks many of the capabilities of
syntax-ppss.  It is intended solely to handle comments and strings,
particularly in back_comment.

> ...., so if you have a problem with the implementation, fix it (or
> report it as a bug, at the very least) and everyone else will benefit.

Perhaps you could fix the problems I've identified here and in my last
email.  Especially the one about starting a scan inside a two character
comment marker.  And the one about it calling out to high level Lisp,
leading to the risk of infinite recursive.

You're the maintainer who's familiar with the function, not me.

> > Also the function is complicated and difficult to understand.

> So your solution is to add another parallel cache with its own quirks,
> complexity and "difficulty to understand" but which doesn't replace it,
> so we end up with both quirks and complexities at the same time?

What quirks?  What complexity?  It is so simple that it could be written
in C.  You keep casting aspersions on the new code, but haven't
criticised a single line of it.  Have you even looked at it?

If you had, you'd realise that, being custom designed for back_comment,
it's a much better fit for the requirements than syntax-ppss.

> That's called "NIH syndrome".

syntax-ppss, in its current state, is unsuitable for use in
back_comment.  My new text property cache just works, unobstrusively, in
the background.  It solves the problem (open paren in column zero) it
was intended to solve, and does so elegantly and efficiently.

>         Stefan

-- 
Alan Mackenzie (Nuremberg, Germany).



reply via email to

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