-- Hrvoje Niksic <hniksic(a)arsdigita.com&gt; spake thusly: Could someone detail the problem for me? I think I must have missed the discussion leading up to this.

Pardon the stream-of-consciousness post. -- Hrvoje Niksic <hniksic(a)arsdigita.com&gt; spake thusly: I haven't researched this fully, but I suspect this bug is in the way font-lock.c operates. However, in addition to porting the syntax-table code from GNU Emacs, I also ported `font-lock-fontify-syntactically-region' to use `parse-partial-sexp' instead of `syntactically-sectionize' (the font-lock.c method of syntaxification). So if I'm correct, this bug didn't exist on GNU Emacs because they don't have font-lock.c, and this bug is now fixed because we're not using it. I copied your sample code twice into an empty tcl-mode and did a `font-lock-fontify-buffer', and it fontified correctly. I also tried the following in the scratch buffer: --- (defun emacs-lisp-byte-compile () "Byte compile (the file containing the current buffer." (interactive) (if buffer-file-name ;; XEmacs change. Force buffer save first (progn (save-buffer) (byte-compile-file buffer-file-name)) (error "The buffer must be saved in a file first."))) --- And the '(' I stuck in the comment didn't seem to screw up fontification. However, indenting still seems to be somewhat hosed (`indent-sexp' works properly expect for the comment, but `indent-for-tab-command' doesn't), and fontification doesn't happen properly if a line is changed, although a fontify-buffer will fix it. So the bug appears to be half-fixed, and the main problem appears to be `beginning-of-defun', which `syntactically-sectionize' uses to set up its caches, and which is incorrectly reporting the embedded parenthesis as the start of defun. For what it's worth, `beginning-of-defun' is broken on GNU Emacs, but their fontification isn't, although indenting is broken in the same way. I suspect the reason fontification works is that they use a different method of refontifying which hides the problem. I can research this a bit further and try to fix it. I suspect that there are at least a couple solutions. One of them would be to apply custom syntax tables to all strings to mark opening parentheses as punctuation, but that seems overkill. It might also be possible to fix `beginning-of-defun' to use `parse-partial-sexp' instead of just doing a regex search. I've also been wanting to redo lazy-lock-mode to bring it more in line with GNU Emacs', which is more sophisticated and has more elegant behavior. I realize there are some issues with XEmacs not having the same hooks that GNU Emacs' lazy-lock uses, but I think those issues can be resolved. I also think that if proper behavior can be achieved, it might be worth rolling the lazy-lock functionality into font-lock-mode, as long as there's no opposition to it.

Matt> I've got a solution for this. Cool! Matt> I thought it might be better to commit this to 21.5 rather Matt> than 21.2, to give us more time to debug it. OK. Matt> Stephen, is 21.5 ready for commits? Should I apply this? Err, theoretically. Let me synch it, I'll get back to you. (^^;; -- University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Institute of Policy and Planning Sciences Tel/fax: +81 (298) 53-5091 _________________ _________________ _________________ _________________ What are those straight lines for? "XEmacs rules."

-- Matt Tucker <tuck(a)whistlingfish.net&gt; spake thusly: I've been experimenting with this patch (attached to Message-ID <30940000.983237796＠benzene>), and have discovered that it slows down beginning-of-defun considerably when used deep into a large file. This is because the new method does a `parse-partial-sexp' from the beginning of the file each time it's called. This is necessary to properly deal with syntax in a file. However, a consequence of this is a significant performance impact on such functions as `*-indent-command' and `*-indent-exp' (to name a couple). To achieve a performance boost, the `font-lock-fontify-syntactically- region' which I ported from GNU Emacs uses a marker `font-lock-cache-position' and a variable `font-lock-cache-state' to store the most recently parsed-to state of `parse-partial-sexp'. Presumably `beginning-of-defun' could benefit from a similar method. But if I'm going to do that, it occurs to me that perhaps I should just move the functionality into syntax.c and let everything that calls `parse-partial-sexp' take advantage of it. The assumption would be that calls to `parse-partial-sexp' which request scanning from the beginning of the file to a given point without stopping (ie, calls which are attempting to determine the syntax state at a given point) are more likely to be from a later point in the buffer than the last such call. So if `parse-partial-sexp' caches the state each time such a call is made, it could just pick up from that point the next time. Presumably this would also require a way to invalidate the cached state if an insertion/deletion is made to the buffer prior to the cache point (somewhere in buffer.c)? Comments? Does this seem like a worthwhile scheme? Would something else be better?