On 12/11/12 07:37, Mostafa Shahverdy wrote:
> Ben: I want to write some web pages with PHP, in Persian.
>
> Tony: How is it so that there can not be any kind of extension to handle
> BiDi algorithms in Vim itself(and not terminal)?
I suppose that the need has not been felt, or the programming ability
not found, or both. RTL display (pagewise) required somme additions to
Vim (Vim 6.0, I think, I'm not sure); Arabic presentation forms
(displaying correct initial / medial / final / isolate forms, with the
additional complication that laam-alif are always written together in a
single character cell, and that alif, daal, dhaal, raa, zaay and waa are
never bound to the next letter even if there is one in the same word,
forcing that next letter to take an "initial" or "isolate" shape) was
something even more difficult. Taking care of proper full-bidi
(including what to do if 'wrap' is on and line-wrapping happens in the
middle of a word with reversed directionality, and then how to handle
Unicode directional controls U+202A to U+202E, how to display HTML text
when it includes <bdo> elements, or elements with "dir=…" attributes; or
worse, how to handle HTML text with external CSS style sheets specifying
dir=… attributes; and how to move the cursor across changes of
directionality…) I don't think it would be easy.
If you think you know:
- the C language
- the Vim codebase
- the full-bidi conventions
- how they apply differently in different 'fileencoding's
all of that well enough to implement it, I suppose you can try writing
(at first) an unofficial patch (by "a patch" I mean "a set of changes,
possibly in several files, and possibly including the creation of new
source files"). If it works, then maybe Bram will decide to incorporate
it into Vim 8 or Vim 9. I have some textfiles with bidi text, but no
doubt you will be able to devise your own.
But I think doing it well would be a whole can of worms. I'm not sure it
is possible to do it correctly in all cases, including those where part
or all of the directionality is defined in a file external to the one
being edited (
e.g.in a style sheet for HTML or similar). It might
require a complete overhaul of not only "ordinary" display but also
syntax highlighting, since how to handle <span dir="rtl">…</span> in
HTML might be better defined in an HTML syntax script than in the "core"
display routines… Not to mention more complicated (recursive) embeddings
such as
<p dir="ltr">english1 <span dir="rtl">farsi2 <span dir="ltr">english3
<span dir="rtl">farsi4</span> english5</span> farsi6</span> english7</p>
(I ought to have shown it with mixed Arabic and Latin script but I'm
lazy) which will have to be displayed (if on a single screen line!) as
english1 6israf english3 4israf english5 2israf english7
(IYSWIM) because the underlying structure (English text quoting a Farsi
phrase which itself quotes an English phrase which etc.) is
<p> → → → → → → → → → → → → → → → → → → → → → → → → </p>
</span> ← ← ← ← ← ← ← ← ← ← ← ← <span>
<span> → → → → → </span>
←<span>
Then if soft-wrapping (due to narrow window width and 'wrap' on) happens
in the middle of the "farsi4" span, we get:
[english1 english3 {raf 2israf
6israf 4is] english5 english7}
where [ or ] is the start of the screen line and { or } its end. Not
obvious, is it?
Best regards,
Tony.
--
"But this has taken us far afield from interface, which is not a bad
place to be, since I particularly want to move ahead to the kludge.
Why do people have so much trouble understanding the kludge? What is a
kludge, after all, but not enough Ks, not enough ROMs, not enough RAMs,
poor quality interface and too few bytes to go around? Have I
explained yet about the bytes?"