<div dir="ltr"><font face="arial,helvetica,sans-serif">I absolutely agree with Eli, that getting reasonable Bidi display when editing source code in Emacs is feasible, for the very reason that emacs is <b>syntax aware</b>. As long as the syntax is understood, it is possible to make sure that the various syntax elements (keywords, strings, comments) are handled in isolation from one another, and that there is no influence flowing e.g. from one embedded Hebrew string to the surrounding syntax characters.<br>
<br>Consider a text with the following syntax:<br><br> print("HELLO!"); // TELL THE USER HELLO<br><br>where small characters are LTR and capitals RTL. Without syntax awareness the charactes "!"); //" would be sandwiched between two RTL characters and be turned into RTL direction by the Bidi algorithm. But by handling strings and comments in isolation that does will not occur.<br>
<br>Thus I expect Bidi for syntaxes to influence strings and comments only and leave everything else intact. This would work for Nadav's example as well:<br><br> s/A/B/<br><br>as the syntax engine should isolate the bidi reordering of A from that of B, there is no problem. It won't be flawless though as e.g. in the following example:<br>
<br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace"> <a href="http://string.tr">string.tr</a>("abcdef",</span><br style="font-family:courier new,monospace"><span style="font-family:courier new,monospace"> "ABCDEF")</span><br>
<br>where you would like to substitute an 'a' for an 'A' and a 'b' for a 'B'. By applying reordering on "ABCDEF" you would loose the visual alignment.<br><br>Regards,<br>Dov<br>
</font><br><div class="gmail_quote">On Fri, Jun 15, 2012 at 12:32 AM, Eli Zaretskii <span dir="ltr"><<a href="mailto:eliz@gnu.org" target="_blank">eliz@gnu.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
> From: Omer Zak <<a href="mailto:w1@zak.co.il">w1@zak.co.il</a>><br>
> Date: Thu, 14 Jun 2012 23:38:16 +0300<br>
<div class="im">><br>
> First of all, it is GREAT that Emacs 24 has BiDi support.<br>
<br>
</div>Thanks.<br>
<div class="im"><br>
> Simply, have Emacs continue to support programming languages, just<br>
> without default BiDi support when editing such text.<br>
><br>
> Since it is anyway good practice to localize strings in separate *.po<br>
> files, I suggest that all of we invest our nitpicking skills in<br>
> specifying how to get Emacs to provide excellent support for BiDi<br>
> rendering of *.po files and similar ones (such as Android's<br>
> strings.xml).<br>
<br>
</div>The same infrastructure that is needed to support *.po files, is also<br>
needed to support HTML/XML markup and comments/strings in programming<br>
languages. After all, the messages in a .po file are just strings,<br>
they use string syntax. Whether to use that infrastructure once it<br>
exists is up to the maintainers of the respective modes. My job will<br>
be done when the infrastructure exists and is reasonably usable and<br>
flexible to satisfy these needs.<br>
<div class="im"><br>
> About comments, let's not bother. I don't think it'll be a good<br>
> practice to write comments in any language other than English. If<br>
> anyone wants to do so, caveat emptor.<br>
<br>
</div>I just showed you an example from Nadav's Perl script in the Hspell<br>
distribution. The comments are mostly in English, but they have<br>
embedded Hebrew words and phrases, which is understandable given the<br>
goal of that script. I don't want to dismiss this use case so easily,<br>
and don't really see a reason to do that, since comments are<br>
recognized by Emacs in any language it supports.<br>
<div class="im"><br>
> What if anyone needs to illustrate how a function handles Hebrew text<br>
> and because of this he needs to write a portion of the function's<br>
> comment in Hebrew?<br>
<br>
</div>That's what Nadav's script does.<br>
<div class="im"><br>
> Would it be reasonable to require the user to insert one of the<br>
> directionality special characters as a signal for Emacs to turn on<br>
> visual BiDi ordering mode in that comment (and turn it back off at<br>
> the comment's end as defined in that programming language)?<br>
<br>
</div>There are no directional controls that turn on reordering. There are<br>
directional controls that override the bidi properties of the<br>
characters, so you can have Hebrew characters have L2R directionality,<br>
which will effectively disable their reordering. But these controls'<br>
effect ends at the newline, by virtue of the UBA, so you would need to<br>
use a lot of them to manually enable and disable reordering in the<br>
whole buffer, part by part.<br>
<div class="im"><br>
> You ignored other places which might use Hebrew text in programming<br>
> languages:<br>
> - Perl's regular expressions (also Python).<br>
<br>
</div>These are already recognized by Emacs for fontification, so the same<br>
machinery can be used to reorder these strings (or not, as the Perl<br>
users want).<br>
<div class="im"><br>
> - Identifiers in computer languages, which allow non-ASCII characters in<br>
> identifiers.<br>
<br>
</div>Likewise: Emacs already fontifies identifiers, so they are<br>
recognizable.<br>
<div class="im"><br>
> - Strings may have various and differing formatting characters/phrases<br>
> (C, LISP and FORTRAN have their differing formatting languages).<br>
<br>
</div>And they all are already recognized by Emacs, aren't they? Otherwise<br>
you get bad fontification and bug reports.<br>
<div class="im"><br>
> - HTML/XML fragments - can be part of either strings or comments.<br>
<br>
</div>The relevant modes will have to write code to recognize them. Emacs<br>
has powerful features -- regular expressions and syntax tables -- to<br>
facilitate that.<br>
<div class="im"><br>
> - How will we let the programmer override, for one place in one file,<br>
> the automatic derivation as needed to deal with pathological cases?<br>
<br>
</div>By using the directional controls, or by inserting newlines<br>
judiciously. This should cover almost everything.<br>
<div class="im"><br>
> - How reasonable will it be to ask the programmer to insert extra<br>
> characters into the text just to get it correctly rendered?<br>
<br>
</div>I don't know, I guess it depends on the programmer.<br>
<div class="im"><br>
> Unless priorities have changed without my knowing about this, Emacs is<br>
> an editor. It is not meant to be a WYSIWYG type editor. It is not<br>
> meant to be a text viewer (such as a Web browser). It must make it easy<br>
> to edit the text, not necessarily render it in some final form.<br>
<br>
</div>Well, I guess priorities have changed, then: Emacs now has a lot of<br>
specialized modes whose goal is to display plain-text files in a lot<br>
of complex ways that border on WYSIWYG. Just to mention a few<br>
examples, take the Org mode, or the way cross-references are displayed<br>
in Info manuals, or the fancy tabulated list displays provided by<br>
tabulated-list.el (used by buffer-menu.el).<br>
<div class="im"><br>
> And when programming, there are enough cases in which it is easier to<br>
> edit BiDi text displayed in logical order (not reordered) rather than<br>
> visual order.<br>
<br>
</div>Easiness is not relevant here: the reordering engine is already coded<br>
and fully operational. If there are no strong R2L characters in a<br>
buffer, the text displays as it was in previous versions of Emacs,<br>
even though it passes through the reordering engine.<br>
<div class="HOEnZb"><div class="h5"><br>
_______________________________________________<br>
Linux-il mailing list<br>
<a href="mailto:Linux-il@cs.huji.ac.il">Linux-il@cs.huji.ac.il</a><br>
<a href="http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il" target="_blank">http://mailman.cs.huji.ac.il/mailman/listinfo/linux-il</a><br>
</div></div></blockquote></div><br><div style id="divCleekiAttrib"></div></div>