Re: mined - a utf-8 editor

[Thomas Wolff <mined at towo dot net>]

> You'll have to contact mlterm's list for more detail, but mlterm
> certainly does work.
Well, it didn't work when I downloaded an compiled it. But I have 
installed the latest SuSE Linux now including mlterm and it works there.

> Mined works fine under mlterm except for the curses
> menu and scroll-bar since there is bidi interaction and the curses
> ctrl characters gets mirrored when they shouldn't be if a line starts
> with an Arabic character (I'm not sure if unicode's UAX#9 talks about
> handling this complex scenario -- in reality curses should not be
> treated
> as normal characters and thus should not be under the bidi algorithm). 
> 
> You can see what I mean,
> 
>   http://www.arabeyes.org/~nadim/mined_view.jpg    (normal view)
>   http://www.arabeyes.org/~nadim/mined_curses.jpg  (curses bidi problem)
The pictures look terrible with respect to the scrollbar and menu.

> For those Bidi experts on the list -- any ideas on what's supposed to
> happen when curses is involved with regard to Bidi ?
First: mined does not use curses, so the question should rather be 
about interpretation of xterm/vt100 escape control sequences. 
And I would definitely assume that a positioning sequences should always 
be interpreted absolutely, not affected by any right-to-left state.
I consider this a design bug in mlterm. If that gets fixed, at least 
the menus should display correctly.
The scrollbar would perhaps still interfere with the terminals 
assumption about left and right borders, so until a solution is 
conceived, it might be switched off for bidi mode (option -o).


About keymaps:
Thanks for your links. I see from the pictures that arabic keymaps 
are a one-to-one keyboard translation, nothing more complex like 
Chinese multi-key character composition. That should be easy 
but I cannot derive from the images of Arabic letters (which I'm 
not familiar with) which Unicode characters they correspond to.
If you send me or point me to a mapping (key -> Unicode value), 
I'll implement that.
One problem is: How is the mapping supposed to be on non-US keyboards?
For example, on a German keyboard, letters "y" and "z" are swapped, 
and some special characters as well. Would the mapping rather apply to 
ASCII characters or to actual key positions?

> As for switching, its completely upto you how you'd like to define that.
OK, I can assign it to a function key, and perhaps to an ESC command.


> > Also, please not that the default mode of mined is a sort of 
> > "poor man's right-to-left", meaning that it produces right-to-left 
> > appearance on terminals that do not know anything about right-to-left.
> > This can only work together with internal right-to-left ordering of 
> > the text in the file (it's basically input support) which is not 
> > the preferred way of handling text files in regular right-to-left 
> > applications if I understood various comments correctly - please tell 
> > me what you think about it. Mined can be switched to work with a 
> > right-to-left terminal with the -b option. I would expect it to 
> > work with mlterm then - if only mlterm would work at all...
> 
> Mlterm takes care of this completely since it offers Bidi
> (di-directionality).  Right-to-left and Left-to-right only simply
> isn't sufficient when files containing both encodings (such as
> English and Arabic) are viewed.
As I told, mined's own right-to-left mode is of course not compatible 
with any right-to-left mode run by the terminal.
So you have to switch it off (option -b). Did you do that? 
If you didn't, how does it look if you do?


Kind regards,
Thomas