diff options
| author | Eli Zaretskii | 2012-04-07 17:57:25 +0300 |
|---|---|---|
| committer | Eli Zaretskii | 2012-04-07 17:57:25 +0300 |
| commit | 9bb794c7259bbf9593ba70fdd27d5519be2978b0 (patch) | |
| tree | 43939ee16aa85e24f76ae1b591bdab78226ca36a /etc | |
| parent | 82b24fb2792e5f15cb6dfa1a74bfd0ac6a40b4de (diff) | |
| download | emacs-9bb794c7259bbf9593ba70fdd27d5519be2978b0.tar.gz emacs-9bb794c7259bbf9593ba70fdd27d5519be2978b0.zip | |
etc/TODO: Update bidi-related items.
Diffstat (limited to 'etc')
| -rw-r--r-- | etc/TODO | 28 |
1 files changed, 20 insertions, 8 deletions
| @@ -647,17 +647,29 @@ up on top of all others | |||
| 647 | 647 | ||
| 648 | ** Bidirectional editing | 648 | ** Bidirectional editing |
| 649 | 649 | ||
| 650 | *** Support reordering structured text | ||
| 651 | Two important use cases: (1) comments and strings in program sources, | ||
| 652 | and (2) text with markup, like HTML or XML. | ||
| 653 | |||
| 654 | One idea is to invent a special text property that would instruct the | ||
| 655 | display engine to reorder only the parts of buffer text covered by | ||
| 656 | that property. The display engine will then push its state onto the | ||
| 657 | iterator stack, restrict the bidi iterator to accessing only the | ||
| 658 | portion of buffer text covered by the property, reorder the text, then | ||
| 659 | pop its state from stack and continue as usual. This will require | ||
| 660 | minor changes in the bidi_it structure. | ||
| 661 | |||
| 662 | This design requires Lisp-level code to put the text properties on the | ||
| 663 | relevant parts of the buffer text. That could be done using JIT | ||
| 664 | fontifications, or as a preliminary processing when the file is | ||
| 665 | visited. With HTML/XML, the code that puts text properties needs to | ||
| 666 | pay attention to the bidi directives embedded in the HTML/XML stream. | ||
| 667 | |||
| 650 | *** Allow the user to control the direction of the UI | 668 | *** Allow the user to control the direction of the UI |
| 651 | 669 | ||
| 652 | **** Introduce user option to control direction of mode line. | 670 | **** Introduce user option to control direction of mode line. |
| 653 | This requires to figure out what to do with unibyte strings that are | 671 | One problem is the header line, which is produced by the same routines |
| 654 | used in constructing the mode line. Currently, unibyte strings are | 672 | as the mode line. While it makes sense to have the mode-line |
| 655 | not reordered by bidi.c, without which R2L mode line will not display | ||
| 656 | correctly. One possibility would be to STRING_SET_MULTIBYTE all Lisp | ||
| 657 | strings involved in the mode line, and then pass them through bidi.c. | ||
| 658 | |||
| 659 | Another problem is the header line, which is produced by the same | ||
| 660 | routines as the mode line. While it makes sense to have the mode-line | ||
| 661 | direction controlled by a single global variable, header lines are | 673 | direction controlled by a single global variable, header lines are |
| 662 | buffer-specific, so they need a separate treatment in this regard. | 674 | buffer-specific, so they need a separate treatment in this regard. |
| 663 | 675 | ||