Hi,
Won't it be nice if at least I can make the output of any program to be
piped through bidiv (without explicitly mentioning it)? I tried
mkfifo jojo
(while true; do; bidiv jojo; done) &
exec >jojo
This works for basic output, but has (at least) the following problems:
o when there are colors, it gets confused about the width of the lines
o when I use more complicated applications like vim or lynx, nothing
works
My questions are
1. is there a more standard way to do this
2. is there a way to overcome those problems
I guess that if the answer to question 2 is yes, this might be enough
for what Beni wants.
Thanks,
Moshe
PS. What is the difference between using bidiv and fribidi?
Nadav Har'El <[EMAIL PROTECTED]> [03/03/03 21:29]:
> 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]
>
=================================================================
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]
