Tried and abandoned idea of displaying mode line and tool/menu-bars R2L.
authorEli Zaretskii <eliz@gnu.org>
Sat, 18 Jun 2011 13:28:53 +0000 (16:28 +0300)
committerEli Zaretskii <eliz@gnu.org>
Sat, 18 Jun 2011 13:28:53 +0000 (16:28 +0300)
Added those features to etc/TODO wishlist.
Fixed src/.gdbinit for changes in Lisp vector structures.

 src/.gdbinit (xvectype, xvector, xcompiled, xchartable, xboolvector)
 (xpr, xfont, xbacktrace): Use "header.size" when accessing vectors
 and vector-like objects.

etc/TODO
src/.gdbinit
src/ChangeLog
src/xdisp.c

index 6019473..303d21b 100644 (file)
--- a/etc/TODO
+++ b/etc/TODO
@@ -645,6 +645,37 @@ up on top of all others
 
 **** Undo for color-drag face customization.
 
+** Bidirectional editing
+
+*** Allow the user to control the direction of the UI
+
+**** Introduce user option to control direction of mode line.
+This requires to figure out what to do with unibyte strings that are
+used in constructing the mode line.  Currently, unibyte strings are
+not reordered by bidi.c, without which R2L mode line will not display
+correctly.  One possibility would be to STRING_SET_MULTIBYTE all Lisp
+strings involved in the mode line, and then pass them through bidi.c.
+
+Another problem is the header line, which is produced by the same
+routines as the mode line.  While it makes sense to have the mode-line
+direction controlled by a single global variable, header lines are
+buffer-specific, so they need a separate treatment in this regard.
+
+**** User options to control direction of menu bar and tool bar.
+For the tool bar, it's relatively easy: set it.paragraph_embedding
+in redisplay_tool_bar according to the user variable, and make
+f->desired_tool_bar_string multibyte with STRING_SET_MULTIBYTE.  Some
+minor changes will be needed to set the right_box_line_p and
+left_box_line_p flags correctly for the R2L tool bar.
+
+However, it makes no sense to display the tool bar right to left if
+the menu bar cannot be displayed in the same direction.
+
+R2L menu bar is tricky for the same reasons as the mode line.  In
+addition, toolkit builds create their menu bars in toolkit-specific
+parts of code, bypassing xdisp.c, so those parts need to be enhanced
+with toolkit-specific code to display the menu bar right to left.
+
 ** ImageMagick support
 
 *** image-type-header-regexps priorities the jpeg loader over the
@@ -669,8 +700,8 @@ view, page-flipping becomes uselessly slow.
 
 *** Integrate with image-dired.
 
-*** Integrate with docview. 
-  
+*** Integrate with docview.
+
 *** Integrate with image-mode.
 Some work has been done, e.g. M-x image-transform-fit-to-height will
 fit the image to the height of the Emacs window.
index 2cf5663..0f51a00 100644 (file)
@@ -677,7 +677,7 @@ end
 
 define xvectype
   xgetptr $
-  set $size = ((struct Lisp_Vector *) $ptr)->size
+  set $size = ((struct Lisp_Vector *) $ptr)->header.size
   output ($size & PVEC_FLAG) ? (enum pvec_type) ($size & PVEC_TYPE_MASK) : $size & ~gdb_array_mark_flag
   echo \n
 end
@@ -818,7 +818,7 @@ end
 define xvector
   xgetptr $
   print (struct Lisp_Vector *) $ptr
-  output ($->size > 50) ? 0 : ($->contents[0])@($->size & ~gdb_array_mark_flag)
+  output ($->header.size > 50) ? 0 : ($->contents[0])@($->header.size & ~gdb_array_mark_flag)
 echo \n
 end
 document xvector
@@ -853,7 +853,7 @@ end
 define xcompiled
   xgetptr $
   print (struct Lisp_Vector *) $ptr
-  output ($->contents[0])@($->size & 0xff)
+  output ($->contents[0])@($->header.size & 0xff)
 end
 document xcompiled
 Print $ as a compiled function pointer.
@@ -903,7 +903,7 @@ define xchartable
   print (struct Lisp_Char_Table *) $ptr
   printf "Purpose: "
   xprintsym $->purpose
-  printf "  %d extra slots", ($->size & 0x1ff) - 68
+  printf "  %d extra slots", ($->header.size & 0x1ff) - 68
   echo \n
 end
 document xchartable
@@ -927,7 +927,7 @@ end
 define xboolvector
   xgetptr $
   print (struct Lisp_Bool_Vector *) $ptr
-  output ($->size > 256) ? 0 : ($->data[0])@((($->size & ~gdb_array_mark_flag) + 7)/ 8)
+  output ($->header.size > 256) ? 0 : ($->data[0])@((($->header.size & ~gdb_array_mark_flag) + 7)/ 8)
   echo \n
 end
 document xboolvector
@@ -1093,7 +1093,7 @@ define xpr
 #    end
   end
   if $type == Lisp_Vectorlike
-    set $size = ((struct Lisp_Vector *) $ptr)->size
+    set $size = ((struct Lisp_Vector *) $ptr)->header.size
     if ($size & PVEC_FLAG)
       set $vec = (enum pvec_type) ($size & PVEC_TYPE_MASK)
       if $vec == PVEC_NORMAL_VECTOR
@@ -1202,7 +1202,7 @@ end
 
 define xfont
   xgetptr $
-  set $size = (((struct Lisp_Vector *) $ptr)->size & 0x1FF)
+  set $size = (((struct Lisp_Vector *) $ptr)->header.size & 0x1FF)
   if $size == FONT_SPEC_MAX
     print (struct font_spec *) $ptr
   else
@@ -1229,7 +1229,7 @@ define xbacktrace
       printf "0x%x ", $ptr
       if $type == Lisp_Vectorlike
        xgetptr (*$bt->function)
-        set $size = ((struct Lisp_Vector *) $ptr)->size
+        set $size = ((struct Lisp_Vector *) $ptr)->header.size
         output ($size & PVEC_FLAG) ? (enum pvec_type) ($size & PVEC_TYPE_MASK) : $size & ~gdb_array_mark_flag
       else
         printf "Lisp type %d", $type
index ba829af..b560528 100644 (file)
@@ -1,5 +1,9 @@
 2011-06-18  Eli Zaretskii  <eliz@gnu.org>
 
+       * .gdbinit (xvectype, xvector, xcompiled, xchartable, xboolvector)
+       (xpr, xfont, xbacktrace): Use "header.size" when accessing vectors
+       and vector-like objects.
+
        * xdisp.c (face_before_or_after_it_pos): Support bidi iteration.
        (next_element_from_c_string): Handle the case of the first string
        character that is not the first one in the visual order.
index ea55cdc..7aafab4 100644 (file)
@@ -18833,7 +18833,11 @@ display_mode_line (struct window *w, enum face_id face_id, Lisp_Object format)
     /* Force the mode-line to be displayed in the default face.  */
     it.base_face_id = it.face_id = DEFAULT_FACE_ID;
 
-  /* FIXME: This should take its value from a user option.  */
+  /* FIXME: This should be controlled by a user option.  But
+     supporting such an option is not trivial, since the mode line is
+     made up of many separate strings, most of which are normally
+     unibyte, and unibyte strings currently don't get reordered for
+     display.  */
   it.paragraph_embedding = L2R;
 
   record_unwind_protect (unwind_format_mode_line,
@@ -18941,8 +18945,6 @@ display_mode_element (struct it *it, int depth, int field_width, int precision,
   int n = 0, field, prec;
   int literal = 0;
 
-  it->paragraph_embedding = L2R;
-
  tail_recurse:
   if (depth > 100)
     elt = build_string ("*too-deep*");