Last modified: 2011-03-13 18:05:16 UTC
Hallo! 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. http://test.wikipedia.org/w/index.php?title=Thai_wordbreak&action=edit requires scrolling to edit / verify the text. *request* 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]]
Changing the summary to focus on *facilitate*. example: {{template_foo\ |param_01=bar\ }} should render the same as {{template_foo|param_01=bar}} Would str_replace( ... ) be sufficient to implement this?
[[Thai wordbreak]] on test.wikipedia.org 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 http://th.wikipedia.org/wiki/%E0%B8%AA%E0%B8%B7%E0%B8%9A_%E0%B8%99%E0%B8%B2%E0%B8%84%E0% B8%B0%E0%B9%80%E0%B8%AA%E0%B8%96%E0%B8%B5%E0%B8%A2%E0%B8%A3 Interaction with lists might be a better example, although note that you can use HTML- style lists.
*note* The implementation of this bug will have impacts on SQL searches (most of them not available) for user Joe. Example: The "standard" search for 'hello world' would not find hello \ world
Would it be enought if it were only 'per edit'? I mean you write hello \ world 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", "");
(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 syntax). 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 [[wikt:yi:צײַט]]. 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 |parameter1=foo |parameter2=bar 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.
(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.
