On Mon, Mar 03, 2003, Beni Cherniavsky wrote about "Re: [Which list?] Unicode, bidi, 
terminals and tables":
>   - The raw/cooked modes are not very elegant; cooked mode actually
>     belongs in user-space.  9term had an elegant idea of user-trigered

Well said, though the invention of "ptys" in modern Unix systems (and
Linux, of course) solved this many years ago. Applications like screen,
ile (that adds history-support to any text application, say, bc), akka,
use this to sit between the graphical terminal emulator and the final
application.

> * Termcap/info - I'm not sure this is needed; if a single set of
>   escapes defined once (or with revisions) will do, that's prefered
>   (but I do see the future compatibility value of such a thing).

This is probably what every person who invented a terminal thought :)
Termcap/terminfo exists because it is not true, and people still use
various terminal emulators for different reasons, each implementing
different sets of escape sequences.

> Since I want to make creating terminal applications easier, I want to
> minimize the entry cost of working with bidi properly.  So expecting
> full-screen programs to disable implicit bidi and do it all by
> themeselves is out of the question.
> 
> The best current model is that the application edits a rectangular
> matrix of chars (thinking that's a vt100) that is rendered through
> line-by-line implicit bidi.  This breaks as soon as the application
> puts texts side-by-side that are not logical continuations.  I don't
> think dialogs will survive it if they contain mixed hebrew/english
> text.  The worst scenario is a pop-up window covering some of the
> mixid text below it.  If at least the content of the pop-up window
> will be in place, that would already be a miracle -:).
>
> That's why I'm unsatisfied with this model.  The terminal has no idea
> about the nesting of 2d areas of the application, so it can't help it
> with the bidi.

One way to work around this problem is to add the bidi support into the
display library, i.e., Curses. Most cursor-addressing applications (at
least, the ones that originally came with Unix) are written using curses,
which takes care of supporting "windows" on the actual terminal window,
and in outputting the changes to the display in the most efficient (and
correct) way possible. Curses might be, conceivably, be modified to support
bidi. It already knows of seperate unrelated windows, and it can be perhaps
be modified to support unicode and bidi better (I have to admit that I
have no idea how well curses currently supports them).

> > The appropriate mailing list is, in my opinion ivrix-discuss.
> >
> Where are the 2003 archives ?_?  Is it alive?

It's alive. In a few minutes, I'll finally change the link on ivrix.org.il,
but in the meantime, here are the links to the archives:

 http://news.gmane.org/thread.php?group=gmane.linux.region.israel.ivrix.discuss
(nice interface to the last few months)

or
 http://www.math.technion.ac.il/lists/ivrix-discuss/
(the full archives, but in ugly monthly format...)

-- 
Nadav Har'El                        |       Monday, Mar 3 2003, 30 Adar I 5763
[EMAIL PROTECTED]             |-----------------------------------------
Phone: +972-53-245868, ICQ 13349191 |When you lose, don't lose the lesson.
http://nadav.harel.org.il           |

=================================================================
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]

Reply via email to