4:15 p.m.
I use cc-mode's electric behavior, which is great, except that whenever I
type a '}' as the last character in a buffer, I get something like this:
(1) (change/warning) Error in `after-change-functions': (args-out-of-range
(foo.c 99 100))
Backtrace follows:
# bind (inhibit-quit)
put-text-property(99 100 font-lock-pending t)
# bind (old-len end beg)
ad-Orig-font-lock-after-change-function(99 100 1)
(setq ad-return-value (ad-Orig-font-lock-after-change-function beg end
old-len))
# bind (ad-return-value)
(let (ad-return-value) (when c-buffer-is-cc-mode (save-excursion (setq
end c-new-END) (setq beg c-new-BEG))) (setq ad-return-value
(ad-Orig-font-lock-after-change-function beg end old-len)) ad-return-value)
# bind (old-len end beg)
font-lock-after-change-function(99 99 1)
# (unwind-protect ...)
# bind (old-len end beg)
lazy-lock-after-change(99 99 1)
# (unwind-protect ...)
# (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=0) 0x0> ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
delete-char(-1)
byte-code("..." [start delete-char -1] 2)
# bind (c-syntactic-context c-macro-start c-fix-backslashes has-backslash
insert-backslash start col newline-arg)
c-newline-and-indent()
# bind (c-echo-syntactic-information-p newlines ln-syntax br-syntax
syntax old-blink-paren safepos literal blink-paren-function
case-fold-search arg)
c-electric-brace(nil)
# bind (command-debug-status)
call-interactively(c-electric-brace)
# (condition-case ... . error)
# (catch top-level ...)
The immediate problem is that the original font-lock-after-change-function
is called with begin and end arguments equal to 99 and 100, even though 99
is the last valid position in the buffer. We can see that the adviced
font-lock-after-change-function got called with 99 and 99, which is
correct, so the problem is that the adviced function is screwing up the end
argument somehow. The adviced function looks like this:
(defadvice font-lock-after-change-function (before get-awk-region activate)
;; Make sure that any string/regexp is completely font-locked.
(when c-buffer-is-cc-mode
(save-excursion
(ad-set-arg 1 c-new-END) ; end
(ad-set-arg 0 c-new-BEG))))) ; beg
Therefore, c-new-END is wrong. Why? The value of after-change-functions
is (lazy-lock-after-change c-after-change t) in the C buffer. There's the
problem. We need c-after-change to run first, to update the caches, then
lazy-lock-after-change can run on the updated region.
So the bug is in, I think, xemacs-packages/edit-utils/lazy-lock.el, which
does this:
(add-hook 'after-change-functions 'lazy-lock-after-change nil t)
when I think it should be doing this:
(add-hook 'after-change-functions 'lazy-lock-after-change t t)
Opinions?
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
10:32 a.m.
Hi, Jerry.
On Mon, Aug 11, 2014 at 09:15:41AM -0600, Jerry James wrote:
I use cc-mode's electric behavior, which is great, except that
whenever I
type a '}' as the last character in a buffer, I get something like this:
(1) (change/warning) Error in `after-change-functions':
(args-out-of-range
(foo.c 99 100))
Backtrace follows:
[ .... ]
Opinions?
OK, this looks like one for me. Give me some time!
Just as a matter of interest, a "CC Mode" (or similar) in the subject
line would have made it much more likely that I'd have spotted post. ;-)
--
Jerry James
http://www.jamezone.org/
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3:25 p.m.
Hi, Jerry.
On Mon, Aug 11, 2014 at 09:15:41AM -0600, Jerry James wrote:
I use cc-mode's electric behavior, which is great, except that
whenever I
type a '}' as the last character in a buffer, I get something like this:
(1) (change/warning) Error in `after-change-functions':
(args-out-of-range
(foo.c 99 100))
Backtrace follows:
# bind (inhibit-quit)
put-text-property(99 100 font-lock-pending t)
# bind (old-len end beg)
ad-Orig-font-lock-after-change-function(99 100 1)
(setq ad-return-value (ad-Orig-font-lock-after-change-function beg end
old-len))
# bind (ad-return-value)
(let (ad-return-value) (when c-buffer-is-cc-mode (save-excursion (setq
end c-new-END) (setq beg c-new-BEG))) (setq ad-return-value
(ad-Orig-font-lock-after-change-function beg end old-len)) ad-return-value)
# bind (old-len end beg)
font-lock-after-change-function(99 99 1)
# (unwind-protect ...)
# bind (old-len end beg)
lazy-lock-after-change(99 99 1)
# (unwind-protect ...)
# (catch #<INTERNAL OBJECT (XEmacs bug?) (opaque, size=0) 0x0> ...)
# (unwind-protect ...)
# (unwind-protect ...)
# (unwind-protect ...)
delete-char(-1)
byte-code("..." [start delete-char -1] 2)
# bind (c-syntactic-context c-macro-start c-fix-backslashes has-backslash
insert-backslash start col newline-arg)
c-newline-and-indent()
# bind (c-echo-syntactic-information-p newlines ln-syntax br-syntax
syntax old-blink-paren safepos literal blink-paren-function
case-fold-search arg)
c-electric-brace(nil)
# bind (command-debug-status)
call-interactively(c-electric-brace)
# (condition-case ... . error)
# (catch top-level ...)
The immediate problem is that the original
font-lock-after-change-function
is called with begin and end arguments equal to 99 and 100, even though 99
is the last valid position in the buffer. We can see that the adviced
font-lock-after-change-function got called with 99 and 99, which is
correct, ....
If you have just typed a '}', why is it correct that the BEG and END
arguments are equal? Surely they should differ by 1, or even more if
you've got auto-newline enabled for '}'.
.... so the problem is that the adviced function is screwing up the
end
argument somehow. The adviced function looks like this:
(defadvice font-lock-after-change-function (before get-awk-region
activate)
;; Make sure that any string/regexp is completely font-locked.
(when c-buffer-is-cc-mode
(save-excursion
(ad-set-arg 1 c-new-END) ; end
(ad-set-arg 0 c-new-BEG))))) ; beg
Therefore, c-new-END is wrong. Why? The value of
after-change-functions
is (lazy-lock-after-change c-after-change t) in the C buffer. There's the
problem. We need c-after-change to run first, to update the caches, then
lazy-lock-after-change can run on the updated region.
Yes.
So the bug is in, I think, xemacs-packages/edit-utils/lazy-lock.el,
which
does this:
(add-hook 'after-change-functions 'lazy-lock-after-change
nil t)
when I think it should be doing this:
(add-hook 'after-change-functions 'lazy-lock-after-change
t t)
Opinions?
I think the bug here may be rather that font-lock-mode-hook is not being
invoked when lazy-lock is active. CC Mode installs
c-after-font-lock-init on font-lock-mode-hook; that function ensures that
c-after-change comes first in after-change-functions.
I think {before,after}-change-functions belong more to the major mode
than any active minor modes; how can font-lock know whether its
a-c-function should be last?
#########################################################################
Incidentally, I've had problems setting up my XEmacs to use lazy-lock -
it's not well documented. In my init.el I've got
(require 'font-lock)
, which automatically sets font-lock-auto-fontify, and
(setq font-lock-support-mode 'lazy-lock-mode)
, which ought to cause lazy-lock to be enabled when a file is loaded into
a buffer. It doesn't - after-change-functions contains
font-lock-after-change-function, not the lazy one. What am I doing
wrong, here?
Incidentally2, when I reinitialise C Mode (with M-x c-mode), font lock
gets turned off for that buffer. I think it's XEmacs doing this, not CC
Mode. Is this intentional? It feels wrong.
--
Jerry James
http://www.jamezone.org/
--
Alan Mackenzie (Nuremberg, Germany).
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:51 a.m.
I apologize for the long delay. I came home from vacation only to get
buried under a huge pile of stuff to do. I'm finally surfacing for a
little air and bit of XEmacs fun....
And sorry for not adding "CC Mode" to the subject. I thought this was
purely a lazy-lock problem. It might turn out to be just that
yet.....
On Sun, Aug 24, 2014 at 8:25 AM, Alan Mackenzie <acm(a)muc.de> wrote:
If you have just typed a '}', why is it correct that the BEG
and END
arguments are equal? Surely they should differ by 1, or even more if
you've got auto-newline enabled for '}'.
I don't know the answer to this question. Perhaps that is not correct.
I think the bug here may be rather that font-lock-mode-hook is not
being
invoked when lazy-lock is active. CC Mode installs
c-after-font-lock-init on font-lock-mode-hook; that function ensures that
c-after-change comes first in after-change-functions.
If I add a (message) call to c-after-font-lock-init, I see it being
called when I visit a new C file. But then the functions on
after-change-functions are in the wrong order, so somehow the
lazy-lock code is running too late, I guess.
Incidentally, I've had problems setting up my XEmacs to use
lazy-lock -
it's not well documented. In my init.el I've got
(require 'font-lock)
, which automatically sets font-lock-auto-fontify, and
(setq font-lock-support-mode 'lazy-lock-mode)
, which ought to cause lazy-lock to be enabled when a file is loaded into
a buffer. It doesn't - after-change-functions contains
font-lock-after-change-function, not the lazy one. What am I doing
wrong, here?
Try removing both of those, and adding (turn-on-font-lock). That's
what I've got.
Incidentally2, when I reinitialise C Mode (with M-x c-mode), font
lock
gets turned off for that buffer. I think it's XEmacs doing this, not CC
Mode. Is this intentional? It feels wrong.
That doesn't happen for me, but then again, I've got the
(turn-on-font-lock) form in my init.el.
This patch fixes the issue for me.
diff -r e24f8c81c991 xemacs-packages/edit-utils/ChangeLog
--- a/xemacs-packages/edit-utils/ChangeLog Fri May 30 14:33:15 2014 +0200
+++ b/xemacs-packages/edit-utils/ChangeLog Tue Sep 23 21:46:59 2014 -0600
＠＠ -1,3 +1,12 ＠＠
+2014-09-23 Jerry James <james(a)xemacs.org>
+
+ * lazy-lock.el (lazy-lock-install-hooks): Append, rather than
+ prepend, lazy-lock-after-change to after-change-functions.
+ (lazy-lock-unstall): Ditto for font-lock-after-change-function.
+ * lazy-shot.el (lazy-shot-install): Ditto for
+ lazy-shot-after-change-function.
+ (lazy-shot-unstall): Ditto for font-lock-after-change-function.
+
2014-05-26 Norbert Koch <viteno(a)xemacs.org>
* Makefile (VERSION): XEmacs package 2.55 released.
diff -r e24f8c81c991 xemacs-packages/edit-utils/lazy-lock.el
--- a/xemacs-packages/edit-utils/lazy-lock.el Fri May 30 14:33:15 2014 +0200
+++ b/xemacs-packages/edit-utils/lazy-lock.el Tue Sep 23 21:46:59 2014 -0600
＠＠ -571,7 +571,7 ＠＠
;; Replace Font Lock mode hook.
(make-local-hook 'after-change-functions)
(remove-hook 'after-change-functions 'font-lock-after-change-function t)
- (add-hook 'after-change-functions 'lazy-lock-after-change nil t)
+ (add-hook 'after-change-functions 'lazy-lock-after-change t t)
;; FSF 21.2: Lots and lots of hooks here. Hooks for `outline', hooks for
;; `hideshow', hooks for redisplay-end-triggers, window-size-changed, and
＠＠ -616,7 +616,7 ＠＠
(save-restriction
(widen)
(lazy-lock-fontify-region (point-min) (point-max))))))
- (add-hook 'after-change-functions 'font-lock-after-change-function nil t))
+ (add-hook 'after-change-functions 'font-lock-after-change-function t t))
;;
;; Remove the text properties.
(lazy-lock-after-unfontify-buffer)
diff -r e24f8c81c991 xemacs-packages/edit-utils/lazy-shot.el
--- a/xemacs-packages/edit-utils/lazy-shot.el Fri May 30 14:33:15 2014 +0200
+++ b/xemacs-packages/edit-utils/lazy-shot.el Tue Sep 23 21:46:59 2014 -0600
＠＠ -298,7 +298,7 ＠＠
;; entire changed area.
(remove-hook 'after-change-functions 'font-lock-after-change-function t)
(make-local-hook 'after-change-functions)
- (add-hook 'after-change-functions 'lazy-shot-after-change-function nil t))
+ (add-hook 'after-change-functions 'lazy-shot-after-change-function t t))
;; Kludge needed untill lazy-lock-fontify-region is more intelligent
(defun lazy-shot-unstall-after-fontify ()
＠＠ -319,8 +319,7 ＠＠
(lazy-shot-fontify-region (point-min) (point-max))))
(remove-hook 'after-change-functions 'lazy-shot-after-change-function t)
(if font-lock-mode
- (add-hook 'after-change-functions 'font-lock-after-change-function
- nil t)))
+ (add-hook 'after-change-functions 'font-lock-after-change-function t t)))
(provide 'lazy-shot)
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
9:11 p.m.
On Tue, Sep 23, 2014 at 9:51 PM, Jerry James <james(a)xemacs.org> wrote:
And sorry for not adding "CC Mode" to the subject. I
thought this was
purely a lazy-lock problem. It might turn out to be just that
yet.....
Actually, this may turn out to be a purely Fedora problem. I finally
realized that the previous XEmacs package maintainer for Fedora, Ville,
created a default.el file to which he added this in 2007:
;; turn on syntax highlighting by default if lazy-lock is available
(when (fboundp 'turn-on-lazy-lock)
(require 'font-lock)
;; use lazy-lock by default if lazy-shot is not enabled
(remove-hook 'font-lock-mode-hook 'turn-on-lazy-lock)
(add-hook 'font-lock-mode-hook
(function
(lambda ()
(unless (and (boundp 'lazy-shot-mode) lazy-shot-mode)
(turn-on-lazy-lock))))
t))
So now, when cc-mode calls (make-local-hook 'font-lock-mode-hook), the hook
already has a value, which becomes its default global value. When I look
at font-lock-mode-hook in a C buffer, it has this value:
(c-after-font-lock-init t)
where the 't' indicates that the global value (which sets lazy-lock-mode)
should also be run. So here's what happens. When (run-hooks
'font-lock-mode-hook) is run, it calls c-after-font-lock-init, which
removes c-after-change from after-change-functions, then puts it back onto
after-change-functions, at the beginning. Then we run the global part of
font-lock-mode-hook, which calls (turn-on-lazy-lock), which calls
(lazy-lock-mode t), which calls (lazy-lock-install), which calls
(lazy-lock-install-hooks), which adds lazy-lock-after-change to the *front*
of after-change-functions.
Unless you apply the patch I sent in my previous message, which makes it
add lazy-lock-after-change to the *end* of after-change functions. I think
that patch is right. I'll send it to xemacs-patches momentarily.
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
1:53 a.m.
Jerry James writes:
Unless you apply the patch I sent in my previous message, which makes
it
add lazy-lock-after-change to the *end* of after-change functions. I think
that patch is right. I'll send it to xemacs-patches momentarily.
I can't say "obviously correct", but it seems very plausible to me
that changes that are basically about analysis of the buffer should
come "late" in the after-change list, since they would be incorrect if
any code makes changes. I don't see any reason why font-locking code
would make changes to the buffer (other than font-lock-specific text
properties recording the analysis), so theoretically this is the right
change.
Since it works in practice, even though it seems this is a distro-
specific issue, I say
+1
Steve
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
11:36 a.m.
New subject: [lazy-shot-mode o lock] (was: lazy-lock-after-change)
> "Jerry" == Jerry James <james(a)xemacs.org> writes:
On Tue, Sep 23, 2014 at 9:51 PM, Jerry James <james(a)xemacs.org>
wrote:
> And sorry for not adding "CC Mode" to the subject. I thought this was
> purely a lazy-lock problem. It might turn out to be just that
> yet.....
Actually, this may turn out to be a purely Fedora problem. I
finally
realized that the previous XEmacs package maintainer for Fedora, Ville,
created a default.el file to which he added this in 2007:
;; Turn on syntax highlighting by default if lazy-lock is available
(when (fboundp 'turn-on-lazy-lock)
BTW, since you are working on this: what is more recommendable to use
lazy-shot-mode or lazy-lock-mode? Which is more efficient on large
buffers.
Uwe
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
4:26 a.m.
New subject: [lazy-shot-mode o lock] (was: lazy-lock-after-change)
On Tue, Sep 30, 2014 at 4:36 AM, Uwe Brauer <oub(a)mat.ucm.es> wrote:
BTW, since you are working on this: what is more recommendable to
use
lazy-shot-mode or lazy-lock-mode? Which is more efficient on large
buffers.
I'm afraid I have no practical experience with lazy-shot-mode, which makes
this hard to answer. However, judging by the comments in the code, it is
supposed to be faster than lazy-lock-mode, but is experimental. I have
never tried it, so I can't really give you any feedback. Sorry. :-(
--
Jerry James
http://www.jamezone.org/
_______________________________________________
XEmacs-Beta mailing list
XEmacs-Beta(a)xemacs.org
http://lists.xemacs.org/mailman/listinfo/xemacs-beta
3500
days inactive
3552
days old
7 comments
4 participants
participants (4)
-
Alan Mackenzie -
Jerry James -
Stephen J. Turnbull -
Uwe Brauer