On 2003-03-03, Nadav Har'El wrote: > 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. > xterm's pty.c doesn't start with a "Dangerous dragons lie here" comment for nothing :-). More seriously, I always thought that a program like `screen' can't know when the final application requests cooked and when raw mode. It normally holds the real terminal always in raw mode but when the final application requests cooked mode, the same old terminal driver part implementing cooked mode kicks in (because it handles the pty) to interpret the chars `screen' sends to it according to the same old cooked mode rules... I'd be happy to be wrong here.
I'd rather have cooked/raw conrolled through escape sequences, just like anything else. Cooked mode is really a request from the application to some little man sitting in the terminal :-) to provide editing functions to it. Raw mode is a request to get of the way. Of course, we want cooked mode as the default for dumb applications, so the requests should be reversed. Perhaps this could be generalised to multiple helper processes. For example input methods... Bidi is another case of "helping" that some applications might want to override (in my text-based model, they could just use unicode's bidi-overriding seqences to control it separately for different parts of the screen). Generally, terminal modes (and the associated serial line control logic, which only sits there because once upon a time, all terminals were behind serial lines) are a very dirty business. `info libc' explains it all beautifully, yet it feel *so* uninviting to program. It's also not very robust. I had some ideas on a generic "context switching" protocol for terminal states, that would handle embedding of terminal applications and be more robust. > > * 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. > OK, probably this is one of the smarter ideas about unix terminals. > > 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). > Me neither. I know there is some "wide character" build of ncurses but AFAIK it's not the default that comes with linux. [Looking at ivrix-discuss archives, seeing a reference to ncursesw, going to install it :-]. Also the curses idea of windows is, erm, bogus (as soon as you start overlappping them), there are panels on top of it, of course, but I'm not sure that it will work correctly in the end. Also, not everybody likes to use curses' windows and pads for their layout (I'm pretty sure lynx and links don't). Most importantly, this fails my "terminal text" requirements. I want to be able to dump an html site with frames to some "terminal text" file and be able to `cat' it back to the terminal to reconstruct the results. Of course, I can record all output but I also want this text to be a minimal addition to a logical-order plain text that I can edit and grep, not visual hebrew in the optimal sequence pieces curses chose :-). > > > 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...) > Great! So, should I move the discussion there? -- Beni Cherniavsky <[EMAIL PROTECTED]> pure virtual static warp shield (TNG++, All Good Things O-=) ================================================================= 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]
