emacs-pretest-bug
[Top][All Lists]
Advanced

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

Re: comment-filling fixes


From: Dave Love
Subject: Re: comment-filling fixes
Date: Thu, 25 Mar 2004 15:35:09 +0000
User-agent: Gnus/5.1002 (Gnus v5.10.2) Emacs/21.2 (gnu/linux)

Stefan Monnier <address@hidden> writes:

> Actually, another reason is the difference in failure mode:  when
> the non-syntax-ppss code fails, it's generally "easy" for the user
> to see why

Actually, it wasn't at all easy for me to see why.  I hard a hard job
reproducing it, and then it took me non-trivial debugging.

> OTOH, if you use syntax-ppss, when it works it's great, but
> when it doesn't the reason for it might be very much non-obvious and it
> might impact the user on all subsequent lines.

(Like font-lock.)

I eventually went and checked an update and I don't see any news on
this sort of stuff, and I don't know what I should actually do for my
Python, Haskell, noweb & el modes, for instance.  They demand
syntactic fontification and set `parse-sexp-lookup-properties'
appropriately, so I expect functions which depend on the syntactic
context to work reliably.  It would be useful for mode authors to have
guidance on how to deal with things like this (if the facilities are
ever released).

It seems to me a major failing that I have to rely on font-lock (and
thus on redisplay being done).  Is there a good reason why the lazy
text properties mechanism can't be tarted up (e.g. not just triggered
by `buffer-substring') and used to ensure syntax properties are
up-to-date for modes that need it?  I don't know why something about
this never went into TODO, though TODO mainly seems to be a list of
things for people to avoid ...

I'm grateful for the improvements that have been made in syntactic
stuff since 21.3, of course.




reply via email to

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