Jamie Zawinski <jwz(a)jwz.org&gt; writes: When we were in japan in 1999 for m17n99 I seriously suggested using the mozilla display engine for this. I think that having the XEmacs code spit out XML describing the buffer and using CSS and/or XSLT would be pretty damn nice. Its a huge change though, and I've never been very impressed with the editing capabilities in Mozilla. Using KHTML would also mean better cross-platform support (no more 'widget foo works in X if you have motif, but but not in windows or lwlib+X' type of issues). Does KHTML have any support for editing right now? -bp -- Ceterum censeo vi esse delendam

r> that sounds like something i could actually help with :) r> we would need an xml parser for that wouldnt we ?? r> maybe we could to make a libxml module to do that Last I checked, gnus came with an native lisp XML parser; might not be what one wants for speed, though... r> wonder if we could customise XEmacs with XML then Sure, xml parse trees ought to be simple to bring back into lisp... But perhaps not necessarily simple the other way around (thinking of the quick/dirty map from xml to custom). best, -tony -- A.J. Rossini Rsrch. Asst. Prof. of Biostatistics U. of Washington Biostatistics rossini(a)u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org -------------- http://software.biostat.washington.edu/ ---------------- FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX (my tuesday/wednesday/friday locations are completely unpredictable.)

Jamie> Hey, have you guys considered ripping out XEmacs's Jamie> redisplay and just using KHTML? Yes (or Gecko or whatever the sexy redisplay du jour is). I can't do it personally, none of the people currently active have shown both ability and interest in the past. Although not currently active, Bill Perry has been known to work for money. As long as we're being serious, maybe we should see about getting some money for it? Russ Nelson has offered the services of pubsoft.org so we can make contributions tax-deductible (I'm afraid the contractor has to pay income tax, though). -- 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.

Jamie> Hey, have you guys considered ripping out XEmacs's Jamie> redisplay and just using KHTML? On second thought, following up on your own "notably, neither [this] nor [that] are on this list" logic, what problems does this solve? I can see that it would surely fix the show-stopping "infinite X protocol from an unchanged window" bug, and you're welcome to emphasize that with a "Yes, dammit!" But I can't help feeling there are more straightforward ways to address that bug, that might even get into an XEmacs you can use this year. (I will personally keep this approach in mind, though.) So, what _else_? On the other side.... I have to wonder how we go about linking markers, text properties, and extents to things KHTML knows about? Note that according to DESIGN.html the internal DOM object is not available to KHTML at all, only implicitly via the Javascript bindings. (Sorry, Bill.) We'd be committed to maintaining an interface to the---deliberately unexported, op. cit.---internals, at least, and maybe our own version of KHTML. I suspect this is going to be true of most advanced redisplays; the work there seems to be on browsers and word processors, not on powerful-editor-as-IDE. Would anybody want to program in any of the fancy word processors now available (let alone the Mozilla text widget)? Today's XEmacs redisplay is undoubtedly an overcomplexified monstrosity, but I can't help feeling that some of the complexity is a reflection of complex problems being solved. KHTML itself also surely depends on the Qt libraries. That means we cannot link on Windows at least (unless the licensing for Qt has changed since we last discussed a Qt port). Is Qt GPL-compatible on Apple platforms? Anyway, so much for portability benefits (not to mention the sure opposition of at least two of our most active coders). -- 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.

Stephen> KHTML itself also surely depends on the Qt libraries. ms> I don't think so, as Apple's version works with Cocoa through ms> a thin compatibility layer I find it hard to believe KHTML can render an HTML form (ie, a Customize buffer) without an underlying widget library that supplies buttons, check boxes, a text widget, and so on. If not Qt, it needs something, I bet. True, supporting a couple "thin compatibility layers" ourselves might very well be a win compared to lwlib + redisplay-*.c (assuming we could also find sanity in the menubar and toolbars at the same time). But then, that's what lwlib is supposed to be.... How thin would the Motif and MS Windows layers be? Do/can we abandon Xt, GTK, and maybe Motif in favor of Qt on platforms where Qt is GPL? Do we care about stuff like multiple displays that Xt/Motif supports but maybe Qt doesn't? -- 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.

ms> I didn't honestly mean to suggest this as a good idea. You've worked in redisplay recently. Doesn't _anything_ sound like a good idea? :-þ I suspect that's what Jamie meant, too. He's sounding a little frustrated ("the single biggest bug") with the suboptimization of redisplay of unchanged windows on Expose events (which you can get literally thousands of with modern window managers that allow opaque moves). ms> In particular, I doubt it would be easy to make it do TTY ms> output, multi-device display, or specifier-like customization. It's not clear to me that TTY or specifiers are actual problems, if we treat KHTML as a back-end to redisplay.c a la Bill P's suggestion. We'd have to rewrite redisplay-tty.c, I'm sure, but I doubt it would be any harder to maintain than the current version. I'm more worried about hooking up things like extents to display events, but maybe that's not so hard, either. And if KHTML actually doesn't require a toolkit, then we'd have to supply it with our own event loop anyway. On the other hand, I note that the message you cite names 6 presumably full-time developers. That's a lot of manpower compared to what we have available, so there could be a fair amount of effort hidden in the "thin compatibility layer" by XEmacs Project standards. -- 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.

ms> I didn't honestly mean to suggest this as a good idea. Stephen> You've worked in redisplay recently. Doesn't _anything_ sound Stephen> like a good idea? :-þ Stephen> I suspect that's what Jamie meant, too. He's sounding a little Stephen> frustrated ("the single biggest bug") with the suboptimization of Stephen> redisplay of unchanged windows on Expose events (which you can get Stephen> literally thousands of with modern window managers that allow opaque Stephen> moves). BTW, I doubt that KHTML would fix *that* problem. Qt applications are usually pigs when it comes to X11 network throughput, so I predict performance in that arena would actually get *worse* (if not *a lot worse*) than what we have now. -- Cheers =8-} Mike Friede, Völkerverständigung und überhaupt blabla

Stephen J. Turnbull wrote: One more thing someone else is maintaining that you don't have to? You get font, image, and plugin support for free without having to screw around with the associated libraries directly. I know little about current Gecko internals, and less about KHTML, but I would be surprised if it was a big deal to insert/delete text in an existing document -- that's what Mozilla's HTML editor does all the time, after all, and I believe you can do crap like that from JS too. It just struck me that the xemacs redisplay is very nearly as complex as a web browser's redisplay, and in essentially the same ways. And wouldn't it be nice if we had one *less* implementation of the same module. Why would it have to? Emacs redisplay doesn't know about markers, really. And it only knows about text properties to the extent (ha ha) necessary to answer the question "what visible attributes does this character have?" Last time I looked at it (which was a long time and several rewrite ago, but still) the interface between editor logic and redisplay logic was really quite small. Assuming there are the internal emacs buffers, and then there's the per-window "buffer" (that's really an HTML document) all you'd really need is insert rich-string / delete region / scroll-to-line / position-visible-p / maybe a couple others. For *redisplay* purposes, emacs is a very, very, very simple word processor. Simpler than most. Redisplay doesn't have to know there's a lispm emulator in there any more than it knows that its other back-ends do TCP and crypto. I think Emacs certainly makes fewer redisplay demands than e.g. the Mozilla HTML editor. *cough* Uh, ok. Not that I expect something like this to ever happen, but I thought I'd throw it out there just in case it made someone go "hey, neat!" and become motivated to work on that instead of continuing to commit unnatural acts with a defenseless MULE. -- Jamie Zawinski jwz(a)jwz.org http://www.jwz.org/ jwz(a)dnalounge.com http://www.dnalounge.com/

Jamie> One more thing someone else is maintaining that you don't Jamie> have to? You get font, image, and plugin support for free Jamie> without having to screw around with the associated Jamie> libraries directly. We tried that about 4 years ago with image support (using libmagick), which worked out dismally. Worth reconsidering, maybe we didn't try hard enough. Or maybe it's just that we currently need almost no maintenance on the image libs' glue, so there was little value-added to be gotten. Jamie> I think Emacs certainly makes fewer redisplay demands than Jamie> e.g. the Mozilla HTML editor. OK. I can recognize an informed opinion when I see one. I take it that Mozilla Composer performs snappily over your usual ssh tunnel via T1 link? Jamie> Not that I expect something like this to ever happen, *shrug* You never know. Worth a try. [...] Jamie> continuing to commit unnatural acts with a defenseless Jamie> MULE. Straightening out Mule a bit will make a lot of people's lives better faster than a new redisplay could be implemented. (Not to mention it's something I can do. :-) -- 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.

Jamie> s/straightening/deleting/ ! ./configure; make; make install is your friend.... -- 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.

Ray> XEmacs over the same link is a non-starter. An exposure Ray> event (?) Can you be more specific about exactly what you do, and is this 21.5? If it's just _one_ exposure event (eg, cover the frame partially with another window, then close or iconify the covering window), do you see this? (I don't think so, in 21.4, I'll check tonight.) If you are moving a window, even if it's not opaque, _across_ an XEmacs frame you are potentially generating an exposure event for every horizontal or vertical single-pixel movement. (Why we can't handle that gracefully I dunno and it's shameful, but if a single exposure event is causing multiple redraws of the toolbar that's downright _disgusting_.) Ray> causes xemacs to spend about 15 sec redisplaying Ray> the toolbar over and over and over again. Ray> But Lucid emacs with scrollbars and menu worked well enough Ray> over a 9600 bps line way back when. (Thanks Jamie!) I suspect 19.first-version-with-toolbar of XEmacs is OK, too. XEmacs in an X frame is still (subjectively, YMMV) no slower than a TTY frame over the same line for buffer updates as long as there are no exposure events (the last time I tried that with GNU Emacs 21 it was not true). But the widget code seems to have been written under the assumption that redisplay is cheap. :-( -- 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.

Ray> XEmacs over the same link is a non-starter. An exposure Ray> event (?) Stephen> Can you be more specific about exactly what you do, and is this 21.5? Stephen> If it's just _one_ exposure event (eg, cover the frame partially with Stephen> another window, then close or iconify the covering window), do you see Stephen> this? (I don't think so, in 21.4, I'll check tonight.) The last time I tried this was several months ago. Ok, I started it up over a 128kbps DSL line. This is 21.5.9 on a Linux box. Took about 1.5 min to get the initial window to pop up, just over 3 min for the splash screen to get displayed. While I was waiting, each toolbar icon was drawn about 1 per second, and the toolbar was drawn twice. If I lower it behind another (mozilla) window and the raise it, each toolbar icon is drawn about 1 per second. The actual *scratch* window gets drawn pretty fast. Hmm, it seems to be faster than it used to be. I did switch DSL carriers just recently, so perhaps that was the primary cause. Loading and fontifying emacs.c is reasonably fast, even with the progress bar enabled. But sometimes when I do file-name completion, the toolbar is redrawn. And since it's 1 sec/icon, that's annoying. So, I take back what I said. If I turn off the toolbar, it's pretty good and quite usable. My original slowness must have been from my network route. Me culpa, Ray

Just as a side note -- I usually read mail from my home network (even from work), hence login through the "slow" side of my DSL line. It's been awfully slow (painful, evil, just bad) running XEmacs in X rather than in a terminal. Thanks to the suggestion of turning off toolbars, it actually is useable! (XEmacs 21.4.12, debian/unstable). At least for gnus mail reading (even with picons turned on). best, -tony Ray> XEmacs over the same link is a non-starter. An exposure Ray> event (?) SJT> Can you be more specific about exactly what you do, and is this 21.5? SJT> If it's just _one_ exposure event (eg, cover the frame partially with SJT> another window, then close or iconify the covering window), do you see SJT> this? (I don't think so, in 21.4, I'll check tonight.) SJT> If you are moving a window, even if it's not opaque, _across_ an SJT> XEmacs frame you are potentially generating an exposure event for SJT> every horizontal or vertical single-pixel movement. (Why we can't SJT> handle that gracefully I dunno and it's shameful, but if a single SJT> exposure event is causing multiple redraws of the toolbar that's SJT> downright _disgusting_.) Ray> causes xemacs to spend about 15 sec redisplaying Ray> the toolbar over and over and over again. Ray> But Lucid emacs with scrollbars and menu worked well enough Ray> over a 9600 bps line way back when. (Thanks Jamie!) SJT> I suspect 19.first-version-with-toolbar of XEmacs is OK, too. SJT> XEmacs in an X frame is still (subjectively, YMMV) no slower than a SJT> TTY frame over the same line for buffer updates as long as there are SJT> no exposure events (the last time I tried that with GNU Emacs 21 it SJT> was not true). But the widget code seems to have been written under SJT> the assumption that redisplay is cheap. :-( 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. -- A.J. Rossini Rsrch. Asst. Prof. of Biostatistics U. of Washington Biostatistics rossini(a)u.washington.edu FHCRC/SCHARP/HIV Vaccine Trials Net rossini(a)scharp.org -------------- http://software.biostat.washington.edu/ ---------------- FHCRC: M: 206-667-7025 (fax=4812)|Voicemail is pretty sketchy/use Email UW: Th: 206-543-1044 (fax=3286)|Change last 4 digits of phone to FAX (my tuesday/wednesday/friday locations are completely unpredictable.)

Ray> Took about 1.5 min to get the initial window to pop up, Stephen> That's very slow, I don't get it. I'm pretty sure I've reported this before quite a while ago, but I guess everyone was busy with other stuff. :-) Stephen> Thanks for the careful report, I'll keep those in mind as "hot spots" Stephen> for optimization. That would be cool. In the meantime, turning the toolbar off makes xemacs pretty usable. Fortunately, the menubar works quite nicely. If I turn off the scrollbar and the progress thingie, xemacs will be down-right nice. :-) Ray