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