Jake> I am about up build 21.4.14 (I now use 21.4.13) and would like to Jake> build it as optimally as psosible. What is suggested? Specifying "with-widgets=athena" and "with-dialogs=athena" resulted in removing the inclusion of Motif and produced the following: Compiling in support for the Athena widget set: - Athena headers location: X11/Xaw - Athena library to link: Xaw Using Lucid menubars. Using Lucid scrollbars. Using Athena dialog boxes. Using Athena native widgets. If I explicitly specified "lucid" for dialogues, or did not specify anything at all, it pulled in Motif. So is this the recommended way of removing Motif? Should this help? Is this a new problem with the 21.4 series? Any downside to what I am doing? Will it still pretty much look and feel the same? Yes, I am going to build and test this but I want to to be prepared for anything subtle that I might miss but will be guaranteed to be found by my manager! Thanks! -- Jake Colman -- XEmacs Tinkerer

VS> Starting in 21.4.14, --with-widgets defaults to =no on Unix. I, VS> personally, have avoided a very large batch of problems by always VS> running '--with-widgets=no' and '--with-dialogs=no' under SunOS and VS> linux. What do you miss if you specify '--with-widgets=no' and '--with-dialogs=no'? What interfaces changes will I see? -- Jake Colman -- XEmacs Tinkerer

Hmmmm. My guys like the buffer tabs although I do not. I'll build with Athena and without Motif and that should avoid the known issues. Could the slow redisplay be a result of fontification and lazy-lock? Is there a "best" way of using font-lock for optimal redisplay performance? VS> No buffer tabs (no gutter) no funky progress bar. These are both AFAIK, VS> because I don't use either dialogues or widgets :-) -- Jake Colman -- XEmacs Tinkerer

I am leaning now towards it being a problem with the latest set of packages. Since we primarily edit C++ files, I'd guess that something is wrong with the latet cc-mode. But I don't want to prejudge the situation. I am backing down to the previous sumo and, maybe, to 21.4.13 to see if things get better. If they do, I'll narrow it down some more. Jake> Could the slow redisplay be a result of fontification and Jake> lazy-lock? Is there a "best" way of using font-lock for Jake> optimal redisplay performance? SJT> I don't think so. The first pass takes a long time if you do a full SJT> fontification, but you will get the "fontifying ... syntax SJT> ... regexps" message. At other times, I think it's redisplay itself. SJT> How fast is the network connection, or is everybody running on their SJT> local box? XEmacs is known to get a lot of Expose events, why I'm not SJT> sure, but there are compression options you can enable in Xt resources SJT> that help a lot. Especially over a slow connection between XEmacs and SJT> the server, but on a sufficiently slow/loaded box, the difference can SJT> be perceptible even with a local transport for the X connection. SJT> However, this optimization, added in 21.4.12, is apparently totally SJT> broken on Motif (makes Motif updates horribly slow), and we've SJT> arranged to remove it for Motif as of 21.4.14. There is also a known SJT> horrible interaction between the basic Motif XmPrimitive widget and SJT> the progress gauge which causes indefinite hangs in progress feedback. SJT> I think this is also worked around in 21.4.14. Jake> What do you miss if you specify '--with-widgets=no' and Jake> '--with-dialogs=no'? What interfaces changes will I see? SJT> As Vin said, --with-widgets=no means the buffers tabs go way, and the SJT> progress bar. In customize screens, you'll see somewhat uglier SJT> buttons consed up from bitmap tiles instead of real widgets. SJT> With the dialogs, I'm not even sure if you lose all of them. There SJT> are a couple that have been historically been implemented as carefully SJT> configured Emacs frames (like the file selector), and these may still SJT> be available even if --with-dialogs=no. SJT> -- SJT> Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp SJT> University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN SJT> Ask not how you can "do" free software business; SJT> ask what your business can "do for" free software. -- Jake Colman -- XEmacs Tinkerer

Norbert, I could be wrong. It might be one of the other packages (e.g., something font-lock related). I'll back down to what I think worked and then go forward from there. Makes sense? NK> Jake Colman <jake.colman(a)xemacs.org&gt; writes: NK> Hello Jake. NK> Do you have to install the whole (old) SUMO? Wouldn't an older NK> version of cc-mode suffice? Have a look in the Attic. You find NK> single packages there. NK> norbert. -- Jake Colman -- XEmacs Tinkerer

Jake> I am leaning now towards it being a problem with the latest Jake> set of packages. Since we primarily edit C++ files, I'd Jake> guess that something is wrong with the latet cc-mode. Check the value of `lookup-syntax-properties'. If non-nil, try forcing to nil. If that speeds things up but breaks cc-mode, we'll need to ask Ben Wing. Stuff that uses the extent processing code is known to be slow, but it's as yet unknown whether it's the "stuff" or the extents. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Ask not how you can "do" free software business; ask what your business can "do for" free software.