* bug#10183: small bidi problems in the org mode and in the mini buffer @ 2011-12-01 17:30 nabil-82 2011-12-01 19:14 ` Eli Zaretskii 2011-12-02 10:42 ` Eli Zaretskii 0 siblings, 2 replies; 9+ messages in thread From: nabil-82 @ 2011-12-01 17:30 UTC (permalink / raw) To: 10183 2 problems in the org mode: -- 1 - By an RTL-Text the three points of a folded heading appear on the right of the heading (before the star(s)!) - not as expected on the right (at end of the heading) . 2 - When a folded LTR-heading is followed by a RTL-headline. The first one appears on right side (not on the left side) if it is folded. But after typing TAB (to unfold it) it jumps to the left side (the correct side). -- These two problems I didn't have by the older version 24.0.90.. The third problem is an old one: -- 3 - In an "RTL-buffer": When I'm searching MY_RTL_TEXT I get in the minibuffer: I-search [MY_RTL_TEXT :[ XX Not: I-search [XX] : MY_RTL_TEXT (XX is the symbol of the rtl-language as example ع for arabic) It's a bit confusing when you have to make replacements. -- View this message in context: http://old.nabble.com/small-bidi-problems-in-the-org-mode-and-in-the-mini-buffer-tp32897118p32897118.html Sent from the Emacs - Bugs mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10183: small bidi problems in the org mode and in the mini buffer 2011-12-01 17:30 bug#10183: small bidi problems in the org mode and in the mini buffer nabil-82 @ 2011-12-01 19:14 ` Eli Zaretskii 2011-12-01 19:25 ` Eli Zaretskii 2011-12-02 10:42 ` Eli Zaretskii 1 sibling, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2011-12-01 19:14 UTC (permalink / raw) To: nabil-82; +Cc: 10183 > Date: Thu, 1 Dec 2011 09:30:18 -0800 (PST) > From: nabil-82 <sjanjal@web.de> > > 1 - By an RTL-Text the three points of a folded heading appear on the right > of the heading (before the star(s)!) - not as expected on the right (at end > of the heading) . I seem to be unable to reproduce this. Please show an example of an Org file where this happens. > 2 - When a folded LTR-heading is followed by a RTL-headline. The first one > appears on right side (not on the left side) if it is folded. But after > typing TAB (to unfold it) it jumps to the left side (the correct side). Again, I seem to be unable to reproduce. Please show an example file. > 3 - In an "RTL-buffer": When I'm searching MY_RTL_TEXT I get in the > minibuffer: > > I-search [MY_RTL_TEXT :[ XX > > Not: > I-search [XX] : MY_RTL_TEXT > (XX is the symbol of the rtl-language as example ع for arabic) I don't understand: the stock I-search invoked by C-s does not show the search string in brackets. Did you use some optional feature? If so, please show how to reproduce this starting with "emacs -Q". ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10183: small bidi problems in the org mode and in the mini buffer 2011-12-01 19:14 ` Eli Zaretskii @ 2011-12-01 19:25 ` Eli Zaretskii 2011-12-01 22:13 ` nabil-82 2011-12-02 6:27 ` nabil-82 0 siblings, 2 replies; 9+ messages in thread From: Eli Zaretskii @ 2011-12-01 19:25 UTC (permalink / raw) To: sjanjal; +Cc: 10183 > Date: Thu, 01 Dec 2011 21:14:59 +0200 > From: Eli Zaretskii <eliz@gnu.org> > Cc: 10183@debbugs.gnu.org > > > Date: Thu, 1 Dec 2011 09:30:18 -0800 (PST) > > From: nabil-82 <sjanjal@web.de> > > > > 1 - By an RTL-Text the three points of a folded heading appear on the right > > of the heading (before the star(s)!) - not as expected on the right (at end > > of the heading) . > > I seem to be unable to reproduce this. Please show an example of an > Org file where this happens. > > > 2 - When a folded LTR-heading is followed by a RTL-headline. The first one > > appears on right side (not on the left side) if it is folded. But after > > typing TAB (to unfold it) it jumps to the left side (the correct side). > > Again, I seem to be unable to reproduce. Please show an example file. One more question: are you using the version of Org Mode that comes with Emacs? Or are you using some other version installed separately? ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10183: small bidi problems in the org mode and in the mini buffer 2011-12-01 19:25 ` Eli Zaretskii @ 2011-12-01 22:13 ` nabil-82 2011-12-03 8:12 ` Eli Zaretskii 2011-12-02 6:27 ` nabil-82 1 sibling, 1 reply; 9+ messages in thread From: nabil-82 @ 2011-12-01 22:13 UTC (permalink / raw) To: 10183 | The org Problems | -------------------- (I'm using here the "hebrew" input method for rtl-text) Let's take o1.org, in the ("SHOW ALL")- form --- o1.org --- * א א e * e --- o1.org --- (the logical order is: * - space - Alef - newline - Alef - newline - newline - * - space - e - newline - e - newline ) So, everything is fine. But if both items are folded: a) I see this by starting with "emacs": --- o1.org --- א *... * e... --- o1.org --- So, we have problems: The first heading is not on the right and the three points are not on the left. By typing TAB in the first heading it jumps to correct side (the right side and the points disappear). I expect this - and I get it by 24.0.90: --- o1.org --- ...א * * e... --- o1.org --- - I've just tested it with emacs -Q: org doesn't know there at all that the line in arabic or hebrew starts from right. It writes the words correctly but doesn't realize that it is an rtl-paragraph. So, I see this by starting with "emacs -Q" --- o1.org --- * א... * e... --- o1.org --- |the search problem | --------------------- Let's say we have the file h.txt with just one hebrew or arabic character. --- h.txt --- א --- h.txt --- If you type C-s you will get in the minibuffer --- minibuffer --- I-search [Ayin]: --- minibuffer --- If you type there Alef you will get --- minibuffer --- I-search [Alef :[Ayin --- minibuffer --- and not --- minibuffer --- I-search [Ayin]: Alef --- minibuffer --- I hope the problems are so clear? -- View this message in context: http://old.nabble.com/small-bidi-problems-in-the-org-mode-and-in-the-mini-buffer-tp32897118p32898740.html Sent from the Emacs - Bugs mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10183: small bidi problems in the org mode and in the mini buffer 2011-12-01 22:13 ` nabil-82 @ 2011-12-03 8:12 ` Eli Zaretskii 2011-12-04 8:35 ` nabil-82 0 siblings, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2011-12-03 8:12 UTC (permalink / raw) To: nabil-82; +Cc: 10183-done > Date: Thu, 1 Dec 2011 14:13:52 -0800 (PST) > From: nabil-82 <sjanjal@web.de> > > Let's take o1.org, in the ("SHOW ALL")- form > --- o1.org --- > * א > א > > e * > e > --- o1.org --- > > (the logical order is: > * - space - Alef - newline - > Alef - newline - > newline - > * - space - e - newline - > e - newline ) > > So, everything is fine. But if both items are folded: > > a) I see this by starting with "emacs": > --- o1.org --- > א *... > * e... > --- o1.org --- > So, we have problems: > The first heading is not on the right and the three points are not on the > left. By typing TAB in the first heading it jumps to correct side (the right > side and the points disappear). This bug should be fixed in revision 106587 on the trunk. The patch appears near the end of this message. This completes the solution of the problems described in the original report, so I'm closing the bug. In the future, please file separate bug reports about unrelated problems. > I expect this - and I get it by 24.0.90: > > --- o1.org --- > ...א * > * e... > --- o1.org --- I introduced a display optimization between 24.0.90 and 24.0.91, which made Org Mode much faster, but it also introduced this bug, now fixed. > - I've just tested it with emacs -Q: > org doesn't know there at all that the line in arabic or hebrew starts from > right. It writes the words correctly but doesn't realize that it is an > rtl-paragraph. By default, Org Mode forces left-to-right paragraph direction. (I guess you have bidi-paragraph-direction reset to nil somewhere.) This is done on purpose: Org buffers can look and behave in confusing ways when the paragraph direction of the heading lines is sometimes LTR and sometimes RTL. Some of the more advanced Org features may not live happily with this. So I recommend sticking to the default LTR paragraph direction in Org buffers. === modified file 'src/ChangeLog' --- src/ChangeLog 2011-12-02 10:19:49 +0000 +++ src/ChangeLog 2011-12-03 07:59:23 +0000 @@ -1,3 +1,9 @@ +2011-12-03 Eli Zaretskii <eliz@gnu.org> + + * xdisp.c (handle_invisible_prop): If the invisible text ends just + before a newline, prepare the bidi iterator for consuming the + newline, and keep the current paragraph direction. (Bug#10183) + 2011-12-02 Juri Linkov <juri@jurta.org> * search.c (Fword_search_regexp): New Lisp function created from === modified file 'src/xdisp.c' --- src/xdisp.c 2011-11-27 04:43:11 +0000 +++ src/xdisp.c 2011-12-03 07:59:23 +0000 @@ -4093,26 +4093,37 @@ handle_invisible_prop (struct it *it) if (it->bidi_p && newpos < ZV) { EMACS_INT bpos = CHAR_TO_BYTE (newpos); - - if (FETCH_BYTE (bpos) == '\n' - || (newpos > BEGV && FETCH_BYTE (bpos - 1) == '\n')) + int on_newline = FETCH_BYTE (bpos) == '\n'; + int after_newline = + newpos <= BEGV || FETCH_BYTE (bpos - 1) == '\n'; + + /* If the invisible text ends on a newline or on a + character after a newline, we can avoid the costly, + character by character, bidi iteration to NEWPOS, and + instead simply reseat the iterator there. That's + because all bidi reordering information is tossed at + the newline. This is a big win for modes that hide + complete lines, like Outline, Org, etc. */ + if (on_newline || after_newline) { - /* If the invisible text ends on a newline or the - character after a newline, we can avoid the - costly, character by character, bidi iteration to - newpos, and instead simply reseat the iterator - there. That's because all bidi reordering - information is tossed at the newline. This is a - big win for modes that hide complete lines, like - Outline, Org, etc. (Implementation note: the - call to reseat_1 is necessary, because it signals - to the bidi iterator that it needs to reinit its - internal information when the next element for - display is requested. */ struct text_pos tpos; + bidi_dir_t pdir = it->bidi_it.paragraph_dir; SET_TEXT_POS (tpos, newpos, bpos); reseat_1 (it, tpos, 0); + /* If we reseat on a newline, we need to prep the + bidi iterator for advancing to the next character + after the newline, keeping the current paragraph + direction (so that PRODUCE_GLYPHS does TRT wrt + prepending/appending glyphs to a glyph row). */ + if (on_newline) + { + it->bidi_it.first_elt = 0; + it->bidi_it.paragraph_dir = pdir; + it->bidi_it.ch = '\n'; + it->bidi_it.nchars = 1; + it->bidi_it.ch_len = 1; + } } else /* Must use the slow method. */ { @@ -4121,11 +4132,11 @@ handle_invisible_prop (struct it *it) non-base embedding level. Therefore, we need to skip invisible text using the bidi iterator, starting at IT's current position, until we find - ourselves outside the invisible text. Skipping - invisible text _after_ bidi iteration avoids - affecting the visual order of the displayed text - when invisible properties are added or - removed. */ + ourselves outside of the invisible text. + Skipping invisible text _after_ bidi iteration + avoids affecting the visual order of the + displayed text when invisible properties are + added or removed. */ if (it->bidi_it.first_elt && it->bidi_it.charpos < ZV) { /* If we were `reseat'ed to a new paragraph, ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10183: small bidi problems in the org mode and in the mini buffer 2011-12-03 8:12 ` Eli Zaretskii @ 2011-12-04 8:35 ` nabil-82 0 siblings, 0 replies; 9+ messages in thread From: nabil-82 @ 2011-12-04 8:35 UTC (permalink / raw) To: 10183 Thanks! It has worked. -- View this message in context: http://old.nabble.com/small-bidi-problems-in-the-org-mode-and-in-the-mini-buffer-tp32897118p32911148.html Sent from the Emacs - Bugs mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10183: small bidi problems in the org mode and in the mini buffer 2011-12-01 19:25 ` Eli Zaretskii 2011-12-01 22:13 ` nabil-82 @ 2011-12-02 6:27 ` nabil-82 1 sibling, 0 replies; 9+ messages in thread From: nabil-82 @ 2011-12-02 6:27 UTC (permalink / raw) To: 10183 Eli Zaretskii wrote: > >> Date: Thu, 01 Dec 2011 21:14:59 +0200 >> From: Eli Zaretskii <eliz@gnu.org> >> Cc: 10183@debbugs.gnu.org >> >> > Date: Thu, 1 Dec 2011 09:30:18 -0800 (PST) >> > From: nabil-82 <sjanjal@web.de> >> > >> > 1 - By an RTL-Text the three points of a folded heading appear on the >> right >> > of the heading (before the star(s)!) - not as expected on the right (at >> end >> > of the heading) . >> >> I seem to be unable to reproduce this. Please show an example of an >> Org file where this happens. >> >> > 2 - When a folded LTR-heading is followed by a RTL-headline. The first >> one >> > appears on right side (not on the left side) if it is folded. But after >> > typing TAB (to unfold it) it jumps to the left side (the correct side). >> >> Again, I seem to be unable to reproduce. Please show an example file. > > One more question: are you using the version of Org Mode that comes > with Emacs? Or are you using some other version installed separately? > > > > > I've forgotten: The Problems of my last long email ( Dec 01, 2011; 11:13pm with the files o1.org and k.txt) were produced with the version that comes with emacs. -- View this message in context: http://old.nabble.com/small-bidi-problems-in-the-org-mode-and-in-the-mini-buffer-tp32897118p32900561.html Sent from the Emacs - Bugs mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10183: small bidi problems in the org mode and in the mini buffer 2011-12-01 17:30 bug#10183: small bidi problems in the org mode and in the mini buffer nabil-82 2011-12-01 19:14 ` Eli Zaretskii @ 2011-12-02 10:42 ` Eli Zaretskii 2011-12-02 18:19 ` nabil-82 1 sibling, 1 reply; 9+ messages in thread From: Eli Zaretskii @ 2011-12-02 10:42 UTC (permalink / raw) To: nabil-82; +Cc: 10183 > Date: Thu, 1 Dec 2011 09:30:18 -0800 (PST) > From: nabil-82 <sjanjal@web.de> > > -- > 3 - In an "RTL-buffer": When I'm searching MY_RTL_TEXT I get in the > minibuffer: > > I-search [MY_RTL_TEXT :[ XX > > Not: > I-search [XX] : MY_RTL_TEXT > (XX is the symbol of the rtl-language as example ع for arabic) > It's a bit confusing when you have to make replacements. I understand that "[XX]" is the mnemonic of the current input method. If so, this problem is fixed in revision 106577 on the trunk. The patch is below (note that isearch.el is preloaded into Emacs, so you will have to rebuild it for this fix to take effect). Thanks. === modified file 'lisp/ChangeLog' --- lisp/ChangeLog 2011-12-02 10:19:49 +0000 +++ lisp/ChangeLog 2011-12-02 10:35:17 +0000 @@ -1,3 +1,8 @@ +2011-12-02 Eli Zaretskii <eliz@gnu.org> + + * isearch.el (isearch-message-prefix): Run the input method part + of the prompt through bidi-string-mark-left-to-right. (Bug#10183) + 2011-12-02 Juri Linkov <juri@jurta.org> * isearch.el (isearch-occur): Use `word-search-regexp' for === modified file 'lisp/isearch.el' --- lisp/isearch.el 2011-12-02 10:19:49 +0000 +++ lisp/isearch.el 2011-12-02 10:37:53 +0000 @@ -2225,7 +2225,11 @@ If there is no completion possible, say (if nonincremental "search" "I-search") (if isearch-forward "" " backward") (if current-input-method - (concat " [" current-input-method-title "]: ") + ;; Input methods for RTL languages use RTL + ;; characters for their title, and that messes + ;; up the display of search text after the prompt. + (bidi-string-mark-left-to-right + (concat " [" current-input-method-title "]: ")) ": ") ))) (propertize (concat (upcase (substring m 0 1)) (substring m 1)) ^ permalink raw reply [flat|nested] 9+ messages in thread
* bug#10183: small bidi problems in the org mode and in the mini buffer 2011-12-02 10:42 ` Eli Zaretskii @ 2011-12-02 18:19 ` nabil-82 0 siblings, 0 replies; 9+ messages in thread From: nabil-82 @ 2011-12-02 18:19 UTC (permalink / raw) To: 10183 Eli Zaretskii wrote: > > I understand that "[XX]" is the mnemonic of the current input method. > > If so, this problem is fixed in revision 106577 on the trunk. The > patch is below (note that isearch.el is preloaded into Emacs, so you > will have to rebuild it for this fix to take effect). > > Thanks. > > > === modified file 'lisp/ChangeLog' > --- lisp/ChangeLog 2011-12-02 10:19:49 +0000 > +++ lisp/ChangeLog 2011-12-02 10:35:17 +0000 > @@ -1,3 +1,8 @@ > +2011-12-02 Eli Zaretskii <eliz@gnu.org> > + > + * isearch.el (isearch-message-prefix): Run the input method part > + of the prompt through bidi-string-mark-left-to-right. (Bug#10183) > + > 2011-12-02 Juri Linkov <juri@jurta.org> > > * isearch.el (isearch-occur): Use `word-search-regexp' for > > === modified file 'lisp/isearch.el' > --- lisp/isearch.el 2011-12-02 10:19:49 +0000 > +++ lisp/isearch.el 2011-12-02 10:37:53 +0000 > @@ -2225,7 +2225,11 @@ If there is no completion possible, say > (if nonincremental "search" "I-search") > (if isearch-forward "" " backward") > (if current-input-method > - (concat " [" current-input-method-title "]: ") > + ;; Input methods for RTL languages use RTL > + ;; characters for their title, and that messes > + ;; up the display of search text after the prompt. > + (bidi-string-mark-left-to-right > + (concat " [" current-input-method-title "]: ")) > ": ") > ))) > (propertize (concat (upcase (substring m 0 1)) (substring m 1)) > > > > > > > Thanks. This problem is solved. -- View this message in context: http://old.nabble.com/small-bidi-problems-in-the-org-mode-and-in-the-mini-buffer-tp32897118p32904166.html Sent from the Emacs - Bugs mailing list archive at Nabble.com. ^ permalink raw reply [flat|nested] 9+ messages in thread
end of thread, other threads:[~2011-12-04 8:35 UTC | newest] Thread overview: 9+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2011-12-01 17:30 bug#10183: small bidi problems in the org mode and in the mini buffer nabil-82 2011-12-01 19:14 ` Eli Zaretskii 2011-12-01 19:25 ` Eli Zaretskii 2011-12-01 22:13 ` nabil-82 2011-12-03 8:12 ` Eli Zaretskii 2011-12-04 8:35 ` nabil-82 2011-12-02 6:27 ` nabil-82 2011-12-02 10:42 ` Eli Zaretskii 2011-12-02 18:19 ` nabil-82
Code repositories for project(s) associated with this public inbox https://git.savannah.gnu.org/cgit/emacs.git This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).