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.)

R> wonder if we could customise XEmacs with XML then I'm not sure what you mean. In --with-gtk, you have access to libglade for building dialog layouts (which would be saved as Glade XML), but nobody has tried to do anything with that that I know of. (For one thing, non-GTK XEmacs couldn't use it.) If you want a non-Lisp .xemacs/custom.el, the answer is "no, this has nothing to do with that." As Bill points out, redisplay.c would still exist; it's redisplay-{x,msw,gtk,...}.c that would go away. It would be pointless, anyway; xml is not a very good language for expressing procedural ideas. You'd have to maintain the Lisp interface for init.el. And anything that you would express in XML as "<tag>list contents</tag>" can be trivially converted to "(:tag list contents)" or ":tag (list contents)" in Lisp (up to tokenization issues, which would add points on the Lisp side since internals are Lisp). In practice, custom.el already mostly does look that way (custom-set-variables '(foo bar) '(baz (quux))) (custom-set-faces '(default ((t (:size "14" :family "LucidaTypewriter"))) t)) Granted, the form used as value for the default face is grody, but even there the actual face-relevant part is clearly tagged. So I really don't see much benefit to expressing that as <variables> <variable name="foo"> bar </variable> <variable name="baz"> (quux) </variable> </variables> <faces> <face name="default" initialize_now="yes" whatever_the_other_t_means_i_forgot="yes"> <size> 14 </size> <family> LucidaTypewriter </family> </face> </faces> -- 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> As far as I understand the redisplay engine, it works at a far ms> lower level of abstraction than KHTML, so I don't think that'd ms> be a viable fit: all the layout and stuff is pretty much ms> backend-independent; the rediplay backends just ship out the ms> bits to the display. Maybe not, but that's what Bill is proposing. (For the second time; he suggested something similar with Gecko way back when.) He's suggesting that redisplay would create something like a DOM, and KHTML, or part of it would translate from that intermediate language to wire protocol. Note that a lot of the ugliness of redisplay comes from the fact that we can (and do!) set "widget is dirty" flags from Lisp, as well as all levels of C. That is just evil. ms> Yeah, but judging from the total size of the code, I'm ms> assuming it's reasonable. Sure. But that also assumes that that our other backends will be as good a fit for a Qt-shaped socket in the side of KHTML as Cocoa is! -- 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 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> Took about 1.5 min to get the initial window to pop up, That's very slow, I don't get it. Ray> just over 3 min for the splash screen to get displayed. Ray> While I was waiting, each toolbar icon was drawn about 1 per Ray> second, and the toolbar was drawn twice. Andy must have imported that from Windows. Windows always paints the whole desktop two or three times. :-/ Ray> If I lower it behind another (mozilla) window and the raise Ray> it, each toolbar icon is drawn about 1 per second. That's bizarre. It suggests that we're not caching pixmap IDs. Once the toolbar is drawn _once_, it should get redrawn as fast as the X server can put bits on the screen. Ray> The actual *scratch* window gets drawn pretty fast. Yep. Ray> But sometimes when I do file-name completion, the toolbar is Ray> redrawn. And since it's 1 sec/icon, that's annoying. And bizarre; evidently something is deciding that the whole frame is dirty. Thanks for the careful report, I'll keep those in mind as "hot spots" for optimization. -- 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.

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.)

Stephen> I take it that Mozilla Composer performs snappily over your usual ssh Stephen> tunnel via T1 link? Ray> Don't know about Mozilla Composer, but Mozilla and Chatzilla work well Ray> enough over at 128 kbps DSL uplink that it's actually usable. Michael> Hm, for me Mozilla isn't even usable *locally* for me on a 300Mhz Michael> PII. I suppose it's possible that this doesn't get any worse when Michael> squeezed over DSL. Yeah, mozilla is way slow on my 300 MHz sparc box too. But it's better (and worse) and old Netscape 4.x. Michael> Well, I've got the toolbar switched off, and I routinely use XEmacs Michael> over a 38400bps modem line. It isn't spiffy, but it's quite Michael> bearable. Over DSL, XEmacs essentially feels almost like it's run Michael> locally for me. Not that good for me, but maybe network latency over my PPPoE connection is the issue. Ray