Re: mined-2000.5 problems

[Nadim Shaikli <shaikli at yahoo dot com>]

--- Thomas <thomas towo net> wrote:
> Sorry for the late response.
> In your release report to 'developer' on arabeyes.org,
> you mentioned 2 problems:
>
> >  + Be aware that combining characters (LAM+ALEF) as well as harakat
> >    (eg, U+FE7D) aren't accounted for properly when you enter Arabic
> >    within mined.  They are, though, displayed properly upon startup.
> 
> > Let's hope the combining characters/harakat get fixed soon (anyone
> > interested into solving this or pointing things out - its a question
> > of proper line/column count accounting) ?
> 
> According to the Unicode data, U+FE7D is ARABIC SHADDA MEDIAL FORM, 
> not harakat. I also cannot find the work harakat in the data file.

Harakat (a subset of which is sometimes called tanween) in Arabic
is used to denote the following emphasis characters (shadda, fatha,
fathatan, damma, dammatan, kasra, kasratan, sukun).

> In any case, that character appears to behave well here. I have no 
> problems entering it and get it displayed fine.

I'm not sure what you mean by "behave well" - I was noting that upon
entry (not display after a restart) an extra unnecessary space is
visually injected.  Try the following,

enter U+0645 (MEEM) then U+064E (FATHA) - the cursor now should stand
right after the U+0645 (the U+064E is a "composing" character and gets
folded into whatever proceeded it), now enter U+0646 (NOON) -- see the
extra space ?  Now save the file and exit.  Restart mined and open the
file, now note how it looks - no space which is correct.  So the initial
entry of the character was not accounted for correctly and that extra
space should not be displayed.

> By LAM+ALEF, do you mean U+06D9? The only effect I see is that mlterm 
> doesn't show any combining character on an Arabic character at all, 
> whether the combining character is also Arabic or not.

No - I mean U+FEF5 through U+FEFC.  The problem noted above with the
harakat is the same one that appears with the combined characters, there
is an extra space upon entry that should not be there.  To further see,
do the following,

enter U+0644 (LAM) followed by U+0627 (ALEF) followed by U+0631 (REH) -
note space; save and exit; restart mined and note no space (which is
correct) - so mined needs to not insert (or to better account) for that
space.

In short, combining and composing characters should not take-up any space
on the line and thus should not be accounted for by including spaces for
them (ie. don't increment the cursor forward for 'em).

> But that's a bug in mlterm, not mined (test with cat).

I beg to differ - this is very much a mined issue (vim with mlterm does
no such thing).  Using cat or less simply notes that mlterm does the
displaying correctly (which is what I'm contending all along and is
not an issue), mined simply needs to account for those combined/composing
characters upon entry that's all.

Suggestion - you might want to put the Keyboard options within the pull
down menu in alphabetical order (ie. Alt-K produces a menu - that's the
one I'm referring to).

BTW: if you have issues, please include 'developer' in your emails as it
     will reach a wider audience and might get problems resolved sooner :-)

Regards,

 - Nadim


__________________________________________________
Do you Yahoo!?
Yahoo! Mail Plus - Powerful. Affordable. Sign up now.
http://mailplus.yahoo.com