Re: mined-2000.5 problems

[Nadim Shaikli <shaikli at yahoo dot com>]

--- mined towo net wrote:
> > 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,
> > ...
>
> I will try your detailed examples when I'm back home as I only 
> have a working mlterm there.
> 
> > > By LAM+ALEF, do you mean U+06D9? ...
> >
> > No - I mean U+FEF5 through U+FEFC. ...
> > enter U+0644 (LAM) followed by U+0627 (ALEF) followed by U+0631 (REH) -
>
> So is there some other problem I might reproduce using U+FEF5... 
> (or are these automatically combined by mlterm as combined forms upon 
> entry of the others)?

Its the same flavor problem as was noted.  Yes, mlterm does the visual
combining, what mined needs to do is to track the previous character
as well as current character and not account for an extra cursor/column
increment iff certain combinations are present.  In pseudo code,

  if ( /* have combined -
          check various combining flavors,
           U+0644 + U+0622
           U+0644 + U+0623
           U+0644 + U+0625
           U+0644 + U+0627
        */
      ((prev_char == LAM) && (current_char == ALEF)) ||
      ...
       /* have composing -
          check various composing flavors (all tanween),
          U+064B -> U+0655
        */
      (current_char == FATHA) ||
      ...
     )
  {
	/* skip cursor/column increment */
  }
  else
  {
        /* do normal cursor increment */
  }

a similar problem was fixed in 'less' with a patch mailed to its
author (CC'ed the developer list).

> > In short, combining and composing characters should not take-up any
> > space
>
> Certainly for combining characters and this is of course implemented 
> by mined but there might be problems with the character width table.
> I will check if their is any deviating behaviour for "composing" 
> characters (yielding a "combined form", right? I have the suspicion 
> that mined and mlterm might not match in this matter.).

I can only suggest trying out mlterm and the arabic-patched vim to see
what the interaction ought to be (as vim under mlterm works quite well).

> > > 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.
>
> I'm sure I had a display problem with mlterm. This was with combining 
> characters, not with combined forms. I will send you a text file and 
> a screen shot.

OK.

> > 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).
>
> So that "Arabic" comes first ?:) Well, OK, alphabetic sounds reasonable.

Not really - you can start in reverse order (arabic last), it just looked
ad-hoc'ish to me and that's why I suggested it.

Again, please CC 'developer' in your correspondence.

 - Nadim


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