Commit cc7245e4 authored by Eli Zaretskii's avatar Eli Zaretskii
Browse files

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.
parent 1ace7267
......@@ -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.
......@@ -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
......@@ -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
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)
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
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
document xboolvector
......@@ -1093,7 +1093,7 @@ define xpr
# 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)
......@@ -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
......@@ -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
printf "Lisp type %d", $type
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.
......@@ -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;
if (depth > 100)
elt = build_string ("*too-deep*");
Markdown is supported
0% or .
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment