On Mon, Mar 03, 2003, Beni Cherniavsky wrote about "[Which list?] Unicode, bidi,
terminals and tables":
> I'm looking for the Right Model of terminals that would support bidi
> well, with minimal hassles to the application. In particular, it's
> imperative that `cat foo.txt' does the right thing. I don't care much
Are you sure you know what the "right thing" for cat foo.txt to do is?
It's more complicated than it sounds, especially when you're talking about
mixed-language text (e.g., Hebrew and English). Do you want the "main
direction" to be always LTR? be figured out per-line (as, for example,
QT seems to do)? Per paragraph?
My "bidiv" program attempts to be such a "cat"-like program which works
on normal non-bidi terminals (i.e., it does the bidi itself). Its default
heuristic is to decide the direction per-paragraph, but I'm very skeptical
that a terminal emulator can use this kind of heuristics without annoying
a lot of people.
> for the existing vt100 model; I'd actually like to take the
> opportunity and throw most of its complexity out of the window but
> that's not a requirement, the bidi is.
Most of the vt100 "complexity" is used by cursor-addressed programs, like
for example vi and mutt. Some redundant looking escape sequences ("e.g.,
delete from the cursor to the end of line") are used to lower the number of
characters that need to be output to modify a screen (libraries like "curses"
specialize in using this efficiently), and was very important in the
days of slow modems (remember 110 baud? :)) - and to some degree it's still
important. I don't know why you'd want to get rid of these features,
especially as they already exist (e.g., in "xterm").
> The model I'm thinking of is based not on a visual-ordered matrix of
> characters but rather on a logical stream of text. The terminal
Yes, what you describe is a teletype (see
http://www.columbia.edu/acis/history/teletype.html) - printers used
before the advent of CRT terminals, which did not have cursor addressing.
Do you think anybody wants to return to this?
Feel like going back to "ed" for editing? :) I certainly don't.
That being said, if you believe that cursor-addressing applications are
"passe", and people only use graphical applications (openoffice, emacs,
mozilla, etc.) nowadays, and the xterm window is only used for commands
like "cd", "ls", "cat", your idea might have merit. But with you're
permission, I'll disagree.
> * They assume fixed-width display. This requires fixing to use
> wcwidth() and still is fragile. Perhaps it should be replaced by
> some convention of signalling the terminal "align this under this"
> that does not require the application to count anything at all.
Remember tab stops? This is what they were for :)
> every cell to emit the correct marks. It might be acceptable to
> expect `sdiff' to output some markers but it's unreasonable to
> expect it to check the first strong char in every line! It'd be
Maybe the conclusion is that an application which wants to diff
multi-lingual multi-directional text needs to be a little smarter then
sdiff, and it's not an issue of terminal emulator at all?
And what about diffing texts which contains left-right English, right-left
Hebrew, and top-down Japanese? It seems to me that some problems are not going
to be solved in the terminal-emulator level.
> So there is a need for extending "plain-text" unicode with some extra
> semantics that will allow me to express a table (at least sa far as
> bidi should work). I found some old discussions on the unicode
Plain text should not have tables.
Higher-level text files, like HTML, TeX or Troff sources, XML OpenOffice
files, etc., do contain tables and have their own mechanisms for specifying
the language in each column and so on.
> mailing list that lead nowhere. I don't aim at converting the whole
> world t ouse these extensions; I just want something that can be used
> at the command line in interactions between different unix utils (just
> like there is no end-of-line concensus but unix works happily with
> \n).
If you produce something that has real-world usefulness, I'll use it :)
Note that what you described does not need to be a terminal-emulator at
all! It can, and perhaps even should, be simply a pseudo-terminal layer
which processes the text and passes it to a normal, bidi-agnostic,
terminal emulator. I believe I once saw the Arabeyes project have exactly
such a system (I don't remember its name).
> I want to be able to `cat table.txt'; having to use visual apps for
> that is a no-no.
But why is "bidiv table.txt" a no-no?
If you want, you can even rename bidiv "cat" :)
> models. I'm not sure yet what's the right direction. Comments,
> ideas, request to elaborate or just redirections to the appropriate
> mailing list :-) are welcome.
The appropriate mailing list is, in my opinion ivrix-discuss.
--
Nadav Har'El | Monday, Mar 3 2003, 29 Adar I 5763
[EMAIL PROTECTED] |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |Having a smoking section in a restaurant
http://nadav.harel.org.il |is like having a peeing section in a pool
=================================================================
To unsubscribe, send mail to [EMAIL PROTECTED] with
the word "unsubscribe" in the message body, e.g., run the command
echo unsubscribe | mail [EMAIL PROTECTED]
