]> code.delx.au - gnu-emacs/blobdiff - etc/TODO
Merge from emacs-23 branch
[gnu-emacs] / etc / TODO
index 6019473b92ffb324791339ec0d5676d60f06f4db..c38b04a681db07d8632dd19045c33bd9463319e4 100644 (file)
--- a/etc/TODO
+++ b/etc/TODO
@@ -13,15 +13,10 @@ to the FSF.
 
 * Tentative plan for Emacs-24
 
-** Bidi
-** lexbind: I haven't checked the status of the code recently, so
-  I don't know how realistic it is to include it.  But it's been around
-  for a long time, and I trust Miles, so I have hope.
 ** concurrency: including it as an "experimental" compile-time option
   sounds good.  Of course there might still be big questions around
   "which form of concurrency" we'll want.
 ** Overhaul of customize: sounds wonderful.
-** some kind of color-theme: agreed.
 ** better support for dynamic embedded graphics: I like this idea (my
   mpc.el code could use it for the volume widget), tho I wonder if the
   resulting efficiency will be sufficient.
@@ -30,7 +25,6 @@ to the FSF.
   and expand.el (any other?) and then advertise/use/improve it.
 ** Improve VC: yes, there's a lot of work to be done there :-(
   And most of it could/should make it into Emacs-23.3.
-** package manager.
 
 ** Random things that cross my mind right now that I'd like to see (some of
 them from my local hacks), but it's not obvious at all whether they'll
@@ -645,6 +639,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 +694,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.