Markus Kuhn wrote:
> we have to move
> away in terminal emulations from the notion of a matrix of glyph cells
> as the fundamentally underlying state, towards a notion of a list of
> lines (later even paragraphs?) of characters, each with variable width.
Or, in other words, make Emacs in "M-x shell" mode the standard prototype
of terminal interaction, instead of the VT-100. I agree 100%, this would
1) take advantage of the fact that most text displaying panels are
actually resizable windows in today's GUIs,
2) push the renderer complexity (counting cell widths, doing bidi
reordering, Arabic shaping, Hindi glyphs etc.) to the terminal.
Whether then the terminal internally has a matrix of glyph cells
(like Emacs has) or not (like a Postscript or HTML backend), is the
terminal's business.
Some terminals, like xmlterm <http://xmlterm.sourceforge.net/>, are already
one step further, by allowing inlined images. A standard describing a first
step into this direction would already be very good.
Bruno
--
Linux-UTF8: i18n of Linux on all levels
Archive: http://mail.nl.linux.org/linux-utf8/
