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

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

Re: comment-filling fixes


From: Stefan Monnier
Subject: Re: comment-filling fixes
Date: 25 Mar 2004 12:31:19 -0500
User-agent: Gnus/5.09 (Gnus v5.9.0) Emacs/21.3.50

>> 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.

Agreed: it's not necessarily obvious (hence the quotes around "easy"), but
at last the reason can be found within the current paragraph at worst and
within the current line in many/most cases.

>> 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.)

Except that font-lock give you some visual feedback so it's easier to trace
things back to the text location where the problem started.

> 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

(set (make-local-variable 'comment-use-global-state) t)

You can also set it globally to t, of course, if you want the same behavior
as the one you implemented.

> 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).

Yes, although it's currently a real mess for the uninitiated.

> 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 ...

100% agreement.  It's been on my own todo list for a long time.
But somehow it never got high up enough.  I don't think we necessarily need
to hook directly in the C code.  I think  we just need to take
font-lock-syntactic-keywords out of font-lock and provide
a (syntax-update-propeties-upto POS) which elisp can call when it
needs it.  I intended to put this facility in syntax.el.

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

I must say that I took that for granted ;-)
But thank you for saying so explicitly.


        Stefan




reply via email to

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