From: Eli Zaretskii Date: Sat, 18 Jun 2011 13:28:53 +0000 (+0300) Subject: Tried and abandoned idea of displaying mode line and tool/menu-bars R2L. X-Git-Tag: emacs-pretest-24.0.90~104^2~275^2~19 X-Git-Url: http://git.eshelyaron.com/gitweb/?a=commitdiff_plain;h=cc7245e4b5d277bff1cb5cf9af249955ff1f8e10;p=emacs.git Tried and abandoned idea of displaying mode line and tool/menu-bars R2L. 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. --- diff --git a/etc/TODO b/etc/TODO index 6019473b92f..303d21b053b 100644 --- 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. diff --git a/src/.gdbinit b/src/.gdbinit index 2cf5663df91..0f51a00ea76 100644 --- a/src/.gdbinit +++ b/src/.gdbinit @@ -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 diff --git a/src/ChangeLog b/src/ChangeLog index ba829af4026..b560528a1d6 100644 --- a/src/ChangeLog +++ b/src/ChangeLog @@ -1,5 +1,9 @@ 2011-06-18 Eli Zaretskii + * .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. diff --git a/src/xdisp.c b/src/xdisp.c index ea55cdcc3d2..7aafab4f32c 100644 --- a/src/xdisp.c +++ b/src/xdisp.c @@ -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*");