Page MenuHomePhabricator

Facilitate bidirectional editing / readability via a trailing escape character (as "\") at the end of line
Closed, DeclinedPublic


Author: gangleri


List items require to write anything behind a line starting with "*", "#", ":",
etc. in one line.

This can require longer sequences / lines which render in the editor textarea
over many lines.
Beside this long lines are more difficult to handle in 'diff' and they (long
lines) can cause a 'headache' if LTR and RTL characters are mixed. requires
scrolling to edit / verify the text.

Please choose an escape character (as "\") which should be used as final
character in a line in order to facilitate editing. 'diff' should work as before
in "real" lines.

*compatibility issues*
This change should not breake existing page source. "\" is used in Unix but I
assume that there should be anly a few lines ending with Unix style url's.
Another question is if "\" should be used as well to "split" long url's or *not*.
Hope that this request would not create other "complications".

best regards reinhardt [[user:gangleri]]

Version: unspecified
Severity: enhancement



Event Timeline

bzimport raised the priority of this task from to Lowest.Nov 21 2014, 9:08 PM
bzimport set Reference to bz5121.
bzimport added a subscriber: Unknown Object (MLST).

gangleri wrote:

Changing the summary to focus on *facilitate*.




should render the same as {{template_foo|param_01=bar}}

Would str_replace( ... ) be sufficient to implement this?

[[Thai wordbreak]] on is a browser test page, demonstrating whether or
not the browser you use to display it has Thai word segmentation capabilities. In Opera
and IE, the text in the edit box breaks at word boundaries, no horizontal scrolling is
required. In Firefox, the text is unbroken, editing requires horizontal scrolling. Adding
line breaks and backslashes would defeat the purpose. The test contrived, it consists of a
Thai passage with spaces and punctuation removed. Adding line breaks and backslashes to
real Thai text is not necessary, see for example

Interaction with lists might be a better example, although note that you can use HTML-
style lists.

gangleri wrote:

The implementation of this bug will have impacts on SQL searches (most of them
not available) for user Joe.

The "standard" search for 'hello world' would not find
hello \

Would it be enought if it were only 'per edit'?
I mean you write
hello \

but it's saved as
hello world

as an 'editor trick', like the ~~~~. It would be easier to implement as it only
hacks the editor, and even that is easy as it would be an str_replace( , "\\\n",

gangleri wrote:

(In reply to comment #4)

Would it be enought if it were only 'per edit'? ...

This would not make much sense. What would you do if you / some body else is
editing the page the next time? All "the logical breakepoints" are gone and you
would not recognize the "logical syntax" (the order of the characters how they
have been typed / are stored in the database / how they are interpreted by the

If you want to experience BiDi editing please go to
[[wikt:yi:user:Gangleri/tests/bugzilla]]. Start editing sections, move the
cursor, select somthing and paste it in another position. This is an "easy" one.
Please just make previews.

[[wikt:yi:template:tsayt - divisions]] and [[wikt:yi:template:vokh - divisions]]
contain both RTL and LTR characters. To understand "logical breakepoints" edit

The scope of this request is to be able to start in a new line *also* at
positions which would break wiki syntax. One of this situations is a syntax like


and the called template is using [[{{foo}}]] .

best regards reinhardt [[user:gangleri]]

The following also seem to work:

  • this <!--

--> continues

  • this <nowiki>

</nowiki> too

Imho there is no need to add new escaping methods when these do work.

gangleri wrote:

(In reply to comment #6)

The following also seem to work:

  • this <!--

--> continues

  • this <nowiki>

</nowiki> too

Imho there is no need to add new escaping methods when these do work.

Reopening this bug. The answer three years after the report is not satisfactory. In order to understand the importence of the requirement you need to make some 20,000++ edits with mixed directionality on crapy computers (with outdated operarting systems and browsers).

Why it should not be possible to use a *whatever* unused character to provide this functionality?

The main issue are the characters with directionality neutral which might be displayed oposite to what was keyed in. Please understand that mixed script editing and correction is not the same as looking at a Linux shell ASCII text where you may identify imediately what you are loking for.

Bidirectional support in text areas is quite poor. It is mainly a problem of the operating systems. What I have asked for is a workaround (inside the text are box). Please remind that the most commonly accesible places do not have editors with enhanced BiDirectional support installed. There you may not copy text fom one application to an editor, edit it and copy it back.

Best Regards Reinhardt [[user:Gangleri]]

The trick is to use comment for this purpose as explained in comment 6. We do not want to add another buggy key in the parser.