Jonathan> So far so good, until I decided I wanted to display Jonathan> LaTeX \frac's inline, that is, put the nominator and Jonathan> denominator above each other, and hide the LaTeX command Jonathan> from the user's view. This is exactly what David Kastrup's preview-latex is intended to do. Unfortunately, he's not an XEmacs user, so it is at present only available for GNU Emacs 21. http://preview-latex.sourceforge.net/ Jonathan> (Show the glyph as an annotation and hide the text? Jonathan> Don't think so...) Why not? It's the obvious solution, in fact it's equivalent to the one you propose in this case (since no repositioning is required), and works fine for preview-latex. (This isn't quite true, as AFAIK the glyph mechanism only supports glyphs that index into fonts for the mouse cursor glyphs. However, it should be reasonably easy to encapsulate raw "runs of runes", ie character/font aggregrates, in a glyph.) Granted, the annotation mechanism is clumsy for this purpose. So write a better one on top of the existing extents machinery. But I don't think you'll be doing anyone any favors by adding more complexity to the underlying redisplay to support this particular usage, which seems to me to be quite independent of the complex positioning issue you raise. Jonathan> where do I find documentation on the rendering Jonathan> subsystem, Wherever you put them when you write them. :-) There are some very limited docs in the Texinfo "Internals" manual, but really all there is is the source. Jonathan> and what projects are going on now? Adding support for GTK as a display platform, and improving support for native widgets, aka subwindows, in the buffer. Jonathan> It would seem to me to be the next logical step in Jonathan> xemacs - add x-offset, y-offset attributes. This is probably reasonable, since it only involves recomputing the height of the line. Computing line heights is something that is quite buggy in Mule, at least, so it might be possible to get this and fix the bugs for the same amount of effort. But note that this is not sufficient to get fractions, you also need to add horizontal kerning. Jonathan> While your at it, make it an orthogonal set of Jonathan> attributes with text alignment, text direction, bounding Jonathan> boxes, inline and floating elements, on top of the Jonathan> current font and color attributes. This probably requires a complete rewrite of redisplay. XEmacs's redisplay currently views a window as a continuous vertical scroll of text. This is done very straightforwardly by racking up runes horizontally, then packing the lines vertically. Except that it is no longer straightforward at all. Many of the features already available in XEmacs have required surgery on the redisplay engine, there is a lot of complex caching which knows a lot about the internal representation of the "view" (using your term), and it seems likely that further complexity would destabilize the whole thing. Jonathan> With extent positioning, xemacs would really rock. Um, except that "your grammaw don't dance, and your grandad don't rock'n'roll". Those powered beds get in the way. Without the complete rewrite, this would be godawful slow, and very likely immensely buggy. Jonathan> That is, allow userspace code to override the way a Jonathan> buffer or an extent is rendered? This violates the second Golden Rule of Redisplay: do not call Lisp from redisplay. That's why. Jonathan> Otherwise, I would happily participate in development of Jonathan> a new rendering framework. Well, you'll have to start by disabusing yourself of the notion that mere "rendering" is at issue. XEmacs is a text editor. The buffer is lord. XEmacs is not a web browser, to have the buffer contents constrained to satisfy the HTML DTD. The display must accurately render the buffer, it is true. However, it does this by following arbitrary editing operations and redisplaying to synchronize the view to the buffer. It cannot make assumptions about the buffer contents. It also must do these manipulations very very quickly, much more so than a mere "rendering engine", because the buffer manipulations are often under program control. There was a project proposed on the comp.emacs list to embed Gecko in GNU Emacs. If you really want a WYSIWYG display for XEmacs (a much better platform for this kind of hacking, IMO), I think that would be the way to go. Take the GTK XEmacs, and add support for Gecko as a widget to embed in the usual Emacs "frame," or perhaps an alternative to it. If you're very lucky, you may find it would be a satisfactory redisplay, but for the reasons presented above, I think it unlikely. However, it would be a worthwhile project as a foundation for Lisp- controlled previewers. All IMHO. I am not speaking as someone with either authority to approve such a project or time to help with it. -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.

Andy> I guess I don't understand what you mean here. Text glyphs Andy> are supposed to address this, although some of the sizing Andy> issues are still unresolved. Well, if you were careful to set up your text glyphs so that the "alpha" glyph was always reused when you see "\alpha" in the TeX buffer, it would be nearly the same. But AFAIK, if you (very naturally) scanned over the buffer for "\\\(alpha\|beta\|...\)", then did (make-glyph (match-string 1)), you would get a new glyph for each occurance of "\alpha". The idea here would be to make the glyph instantiator be an index into a font (normally simply a character) rather than a string. This way the glyphs for all occurances of "\alpha" would automatically be eq (in Emacs Lisp). Andy> Actually what you want to do could be acomplished using the Andy> new layout glyph support. They're unsupported as far as I can tell: no docs. Neither the Lispref (C-h i m lispref m glyphs) nor C-h v make-glyph mentions them. You want customers, you gotta market your product. :-) -- Institute of Policy and Planning Sciences http://turnbull.sk.tsukuba.ac.jp University of Tsukuba Tennodai 1-1-1 Tsukuba 305-8573 JAPAN Don't ask how you can "do" free software business; ask what your business can "do for" free software.