[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [BiDi plugins] So far I talked in the air, now there is some actual , code which will , be warmed by flames!
On Thu, 21 Jan 1999, Stanislav Malyshev a.k.a Frodo wrote:
>
> > The URL is:
> > http://www.weizmann.ac.il/~xlacha1/plugins.html
[... snipped ...]
> Level 0 - handles only fixed-size fonts. Suitable for CURSES-based
> applications and applications, which run on xterm.
> The plugin receives text, transforms it and hands it back to the
> application for drawing on the screen.
The string transforming procedure (render_string()) is supposed to have
provisions for optimization of handling a string which was already
transformed, and later was modified by inserting, deleting or overwriting
few characters in the middle.
> Now, what about selection, editing, etc.?
In the plugin, there is a procedure (mouse_translation()), which receives
"visual coordinates" of the mouse (can be used for cursor management, I
hope). It computes the position in the original string corresponding to
the visual position on the string and returns it to the application. The
application can then use this position for selecting a substring (by
marking its beginning and ending).
> ... If I take pine, stuff plugin-0
> in it and start writing Hebrew what happens? Does pine consult plugin on
> every keypress?
Every keypress, which modifies the text of your message.
> ... Note also, you are speaking further on "lines", but how
> the application know what line the cursor is in?
The application is supposed to keep track of the visual cursor position.
The plugin provides (as I said above) for translation of this position
into the logical cursor position in the original text.
> ... Lines of rendering text
> may well be not the same, as lines of non-rendered one. I still cannot
> understand how application, which does not explicitly support
> bi-directional texts, could handle these problems.
Trust me, it can handle those problems. (If not, let me know and I'll
tweak the plugin interface until this miracle happens. :-) )
In summary:
1. The editing commands of the application operate only on the logical text.
2. Cursor positioning commands of the application operate only on the
visual text.
3. After each cursor movement (by command or by mouse), the application
does not compute itself the new cursor position in the logical text,
but instead asks the plugin to compute this for it.
4. After each text change, the application hands the modified text to the
plugin and tells it where the text was modified. The plugin transforms
as much text as needed to refresh the display, and not more than that.
The plugin then (in principle) informs the application which lines on
the display need to be refreshed due to the text change.
OK. Is there anything which I left out?
--- Omer
WARNING:
By sending me unsolicited commercial/political/religious/MailPush
E-mail message/s (known also as "spam"), you irrevocably agree to
pay me US$500.- (plus any legal expenses incurred by my trying to
collect the amount due) per unsolicited commercial/political/
religious/MailPush E-mail message - for the service of receiving it.