andy, puhleeeze! "turn off lazy lock" is not the solution. the solution is to fix the gutter code to avoid recalculation! it shouldn't matter what other lisp packages do. if the gutter code isn't made robust enough by release time, we'll have to disable it by default. Andy Piper wrote: -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html.

andy, did you miss this comment in lazy-lock? ;; Functions for hooks: ;; lazy-lock optimization: ;; ;; pre-idle-hook is called an awful lot -- pretty much every time the ;; mouse moves or a timeout expires, for example. On Linux (sometimes), ;; IRIX 5.x, and Solaris 2.something, it happens every 1/4 of a second ;; due to the 1/4-second timers installed to compensate for various ;; operating system deficiencies in the handling of SIGIO and SIGCHLD. ;; (Those timers cause a cycle of the event loop. They don't necessarily ;; have to, but rewriting to avoid this is fairly tricky and requires ;; having significant amounts of code called from signal handlers, which ;; (despite that fact that FSF Emacs reads its X input during a signal ;; handler ?!), is almost always a bad idea -- it's extremely easy to ;; introduce race conditions, which are very hard to track down. ;; ;; So to improve things, I added `frame-modified-tick'. This is an ;; internal counter that gets ticked any time that any internal ;; redisplay variable gets ticked. If `frame-modified-tick' is ;; the same as the last time we checked, it means that redisplay will ;; do absolutely nothing when encountering this frame, and thus we ;; can skip out immediately. This happens when the 1/4-second timer ;; fires while we're idle, or if we just move the mouse. (Moving ;; around in a buffer changes `frame-modified-tick' because the ;; internal redisplay variable "point_changed" gets ticked. We could ;; easily improve things further by adding more tick counters, mirroring ;; more closely the internal redisplay counters -- e.g. if we had ;; another counter that didn't get ticked when point moved, we could ;; tell if anything was going to happen by seeing if point is within ;; window-start and window-end, since we know that redisplay will ;; only do a window-scroll if it's not. (If window-start or window-end ;; or window-buffer or anything else changed, windows_changed or ;; some other variable will get ticked.)) ;; ;; Also, it's wise to try and avoid things that cons. Avoiding ;; `save-window-excursion', as we do, is definitely a major win ;; because that's a heavy-duty function as regards consing and such. lazy-lock checks frame-modified-tick and DOES NOTHING if it hasn't changed. so stop your god damn complaining about lazy-lock. the problem is that frame-modified-tick was getting ticked too much, because of this: else if (STRINGP (object)) { /* #### Changes to string extents can affect redisplay if they are in the modeline or in the gutters. If the extent is in some generated-modeline-string: when we change an extent in generated-modeline-string, this changes its parent, which is in `modeline-format', so we should force the modeline to be updated. But how to determine whether a string is a `generated-modeline-string'? Looping through all buffers is not very efficient. Should we add all `generated-modeline-string' strings to a hash table? Maybe efficiency is not the greatest concern here and there's no big loss in looping over the buffers. If the extent is in a gutter we mark the gutter as changed. This means (a) we can update extents in the gutters when we need it. (b) we don't have to update the gutters when only extents attached to buffers have changed. */ MARK_EXTENTS_CHANGED; gutter_extent_signal_changed_region_maybe (object, extent_endpoint_bufpos (extent, 0), extent_endpoint_bufpos (extent, 1)); } see attached change. Andy Piper wrote: -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/typing.html. ? lib-src/etags.pdb ? lib-src/hexl.pdb ? lib-src/i.pdb ? lib-src/make-docfile.pdb ? lib-src/mmencode.pdb ? lib-src/movemail.pdb ? lib-src/run.res ? lib-src/sorted-doc.pdb ? lib-src/vc50.pdb ? lib-src/wakeup.pdb ? nt/obj ? src/NEEDTODUMP ? src/runxemacs.pdb ? src/temacs.bsc ? src/temacs.map ? src/temacs.pdb ? src/xemacs.opt ? src/Xpm.dll Index: src/ChangeLog =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/ChangeLog,v retrieving revision 1.154.2.568 diff -u -r1.154.2.568 ChangeLog --- ChangeLog 2000/04/28 03:50:30 1.154.2.568 +++ ChangeLog 2000/04/28 05:23:37 ＠＠ -1,3 +1,15 ＠＠ +2000-04-27 Ben Wing <ben(a)xemacs.org&gt; + + * extents.h: extern in_modeline_generation. + + * redisplay.c (generate_formatted_string_db): set + in_modeline_generation. + + * extents.c (extent_changed_for_redisplay): don't mark redisplay + flags if in modeline generation. otherwise frame-modified-tick + is ticked far too often. + Declare in_modeline_generation. + 2000-04-26 Ben Wing <ben(a)xemacs.org&gt; * emacs.c (vars_of_emacs): document quick-build "error-checking" Index: src/extents.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/extents.c,v retrieving revision 1.27.2.21 diff -u -r1.27.2.21 extents.c --- extents.c 2000/03/04 16:53:32 1.27.2.21 +++ extents.c 2000/04/28 05:23:41 ＠＠ -465,6 +465,10 ＠＠ EXFUN (Fextent_properties, 1); EXFUN (Fset_extent_property, 3); +/* if true, we don't want to set any redisplay flags on modeline extent + changes */ +int in_modeline_generation; +  /************************************************************************/ /* Generalized gap array */ ＠＠ -1612,7 +1616,8 ＠＠ when we need it. (b) we don't have to update the gutters when only extents attached to buffers have changed. */ - MARK_EXTENTS_CHANGED; + if (!in_modeline_generation) + MARK_EXTENTS_CHANGED; gutter_extent_signal_changed_region_maybe (object, extent_endpoint_bufpos (extent, 0), extent_endpoint_bufpos (extent, 1)); Index: src/extents.h =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/extents.h,v retrieving revision 1.10.2.6 diff -u -r1.10.2.6 extents.h --- extents.h 2000/02/26 11:39:46 1.10.2.6 +++ extents.h 2000/04/28 05:23:41 ＠＠ -318,6 +318,7 ＠＠ EXFUN (Fset_extent_parent, 2); extern int inside_undo; +extern int in_modeline_generation; struct extent_fragment *extent_fragment_new (Lisp_Object buffer_or_string, struct frame *frm); Index: src/redisplay.c =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs/src/redisplay.c,v retrieving revision 1.55.2.52 diff -u -r1.55.2.52 redisplay.c --- redisplay.c 2000/04/24 12:21:26 1.55.2.52 +++ redisplay.c 2000/04/28 05:23:44 ＠＠ -3544,6 +3544,8 ＠＠ Bufbyte *strdata; struct buffer *buf = XBUFFER (WINDOW_BUFFER (w)); + in_modeline_generation = 1; + detach_all_extents (result_str); resize_string (XSTRING (result_str), -1, data.bytepos - XSTRING_LENGTH (result_str)); ＠＠ -3580,6 +3582,8 ＠＠ Dynarr_at (formatted_string_extent_end_dynarr, elt), result_str); } + + in_modeline_generation = 0; } }

Andy Piper wrote: andy, there's something you're just not getting: blaming packages because they do something that tickles a gutter bug is just not kosher. your mindset needs to shift from "other packages can't do this or that or the other thing too frequently" to "the gutter code needs to be robust enough that other packages can do what they want". everything else in xemacs works this way. if the gutter code is going to remain in xemacs, it needs to work this way too. *everyone* calls set-buffer. this is a totally standard function. -- Ben In order to save my hands, I am cutting back on my mail. I also write as succinctly as possible -- please don't be offended. If you send me mail, you _will_ get a response, but please be patient, especially for XEmacs-related mail. If you need an immediate response and it is not apparent in your message, please say so. Thanks for your understanding. See also http://www.666.com/ben/chronic-pain/

Ben> if the gutter code isn't made robust enough by release time, Ben> we'll have to disable it by default. To be very frank, I don't see any reason to trust it. I needed to add the code below to get the buffers-tab to play nicely with desktop.el. This just won't do; I pointed out the lack of proper initialization and finalization at the Lisp level for this widget months ago. Index: lisp/gutter-items.el =================================================================== RCS file: /usr/CVSroot/XEmacs/xemacs-20/lisp/Attic/gutter-items.el,v retrieving revision 1.1.2.48 diff -u -r1.1.2.48 gutter-items.el --- gutter-items.el 2000/04/28 15:17:12 1.1.2.48 +++ gutter-items.el 2000/04/30 14:27:26 ＠＠ -347,7 +347,11 ＠＠ (defun remove-buffer-from-gutter-tab () "Remove the current buffer from the tab control in the gutter area." (when (and (valid-image-instantiator-format-p 'tab-control) - (specifier-instance default-gutter-visible-p)) + (specifier-instance default-gutter-visible-p) + ;; #### evil and incorrect hack to allow XEmacs to run with + ;; the buffers-tab -- this function can be called when the + ;; buffers-tab doesn't exist (see #### comment below) + gutter-buffers-tab) (let ((inst (glyph-image-instance gutter-buffers-tab)) (buffers (buffers-tab-items t))) (unless buffers ＠＠ -357,6 +361,11 ＠＠ (set-image-instance-property inst :items buffers)))) ;; A myriad of different update hooks all doing slightly different things +;; #### bogon alert! -- these hooks should not be installed at top +;; level here as nothing guarantees that they won't be called when the +;; buffers-tab doesn't exist +;; #### ... and that implies the responsibility to unhook them when the +;; buffers-tab is destroyed (and probably if it's not visible) (add-hook 'kill-buffer-hook 'remove-buffer-from-gutter-tab) (add-hook 'create-frame-hook #'(lambda (frame) -- 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."