Extent positioning attributes / model-view separation

Hello all, first my questions in brief: 1/ is anybody working on extent positioning? 2/ is anybody working on a mechanism of separating model (the buffer) from the way it is rendered (view)? If so, can I help? If not, can I help? If it isn't a good idea, why? If it's already in xemacs, where's the documentation? Now the long version. I'm new to the xemacs mail lists, so I don't know whether this is the right place to be posting this question. I reckon that it's a better start than mailing directly to ben(a)xemacs.org :-) I have been using xemacs for years (oh, about 6 or 7), and been doing plenty of eclectic customising during that time. I have recently started serious attempts at elisp coding, and thought it was about time to try something useful. Inspired by the x-symbol package, I thought I'd (re-)write some minor-mode LaTeX enhancements, and take it from there. So far so good, until I decided I wanted to display LaTeX \frac's inline, that is, put the nominator and denominator above each other, and hide the LaTeX command from the user's view. The user should still be able to edit the nominators and denominators. Searches for \frac would still work, and the user would be able to toggle the way of rendering it. I had never looked at the internals of xemacs before, and even extents are pretty much new to me (I was vaguely aware of their existence from fontsel documentation). I had never before realised that there was no way to change the position a rune or a glyph!!! (At least that explains why xemacs still looks so spartan... no flames please) Okay, I thought, I'd better check and see how those cool super- and subscripts were done in x-symbol... What? Seperate fonts? You've got to be kidding! So then I got to thinking about composing glyphs using mule or some external package. But there are again obvious shortcomings here: how do you edit a bitmap of e.g. a fraction within xemacs? How do you keep the original LaTeX formatting in the buffer? (Show the glyph as an annotation and hide the text? Don't think so...) I've come to the conclusion that, rather than resort to a lot of hackery, one should turn to the xemacs rendering engine instead. And this is where I hit a bit of a dead end - where do I find documentation on the rendering subsystem, and what projects are going on now? Is somebody working on Extent positioning attributes? It would seem to me to be the next logical step in xemacs - add x-offset, y-offset attributes. While your at it, make it an orthogonal set of attributes with text alignment, text direction, bounding boxes, inline and floating elements, on top of the current font and color attributes. With extent positioning, xemacs would really rock. Imagine fontlock with stylesheets? WYSIWYG/WYSIWYM major modes? And as usual, all this functionality would be optional/customisable, as we are all used to from xemacs. A second, closely related ingredient I would see as a winner would be dynamic character encoding - as an example, it would be excellent to be able to tell fontlock to render '\omega' as the greek symbol whenever it's encountered. The way x-symbols has to modify the buffer and add hooks to the write-file-hook, as ingenious a workaround as it is, it brings me to tears. So what we have here is an _excellent_ model (the buffer) which is very hard to separate from it's view (no hooks for the rendering code at all). Why not add views? That is, allow userspace code to override the way a buffer or an extent is rendered? The only entities I have come accross so far which are rendered separately from the buffer are annotations and the begin and end glyphs of extents. Can't this be generalised? I'd really like to see these features in xemacs in the near future. If somebody has already done this sort of thing, 1/ were on the web do I find out about it? 2/ why is it not part of the main xemacs release? Otherwise, I would happily participate in development of a new rendering framework. I have experience in low-level x programming, Motif, Qt, GTK and AWT/Swing. Oh yeah and MFC/Win32SDK, but that was a previous life :-). C/C++, Java and Perl are my forte, Lisp novice unfortunately. I look forward to replies, please take it easy on me :-). Jonathan Ross