[Top][All Lists]
[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
- comment-filling fixes, Dave Love, 2004/03/06
- Re: comment-filling fixes, Stefan Monnier, 2004/03/10
- Re: comment-filling fixes, Dave Love, 2004/03/18
- Re: comment-filling fixes, Richard Stallman, 2004/03/27
- Re: comment-filling fixes, Dave Love, 2004/03/29
- Re: comment-filling fixes, Stefan Monnier, 2004/03/29
- Re: comment-filling fixes, Richard Stallman, 2004/03/30