Emacs TODO List -*-outline-*-
-Copyright (C) 2001-2011 Free Software Foundation, Inc.
+Copyright (C) 2001-2012 Free Software Foundation, Inc.
See the end of the file for license conditions.
* 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.
** Improve the "code snippets" support: consolidate skeleton.el, tempo.el,
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
** See if other files can use generated-autoload-file (see eg ps-print).
+** Write more tests. Pick a fixed bug from the database, write a test
+case to make sure it stays fixed. Or pick your favorite programming
+major-mode, and write a test for its indentation. Or a version
+control backend, and write a test for its status parser. Etc.
+See test/automated for examples.
+
* Small but important fixes needed in existing features:
** Flymake's customization mechanism needs to be both simpler (fewer
command it will use.
I suggest totally rewriting that part of Flymake, using the simplest
-mechanism that sufficies for the specific needs. That will be easy
+mechanism that suffices for the specific needs. That will be easy
for users to customize.
** Compute the list of active keymaps *after* reading the first event.
like make-backup-file-name-function for non-numeric backup files.
** `dired-mode' should specify the semantics of `buffer-modified-p' for
-dired buffers and DTRT WRT `auto-revert-mode'.
+dired buffers and DTRT WRT `auto-revert-mode'.
** Check uses of prin1 for error-handling.
http://lists.gnu.org/archive/html/emacs-devel/2008-08/msg00456.html
scroll bars are extensible.
** Provide user-friendly ways to list all available font families,
- list fonts, display a font as a sample, etc. [fx is looking at
+ list fonts, display a font as a sample, etc. [fx is looking at
multilingual font selection for the Unicode branch of Emacs.]
** Provide a convenient way to select a color with the mouse.
** Beefed-up syntax-tables.
*** recognize multi-character syntactic entities like `begin' and `end'.
-*** nested string-delimiters (for Postscript's (foo(bar)baz) strings).
+*** nested string-delimiters (for PostScript's (foo(bar)baz) strings).
*** support for infix operators (with precedence).
*** support for the $ (paired delimiter) in parse-partial-sexp.
*** support for hook-chars whose effect on the parsing-state is specified
** Highlight rectangles (`mouse-track-rectangle-p' in XEmacs). Already in CUA,
but it's a valuable feature worth making more general.
-** Provide MIME support for Rmail using the Gnus MIME library. [Maybe
- not now feasible, given Gnus maintenance decisions. fx looked at
- this and can say where some of the problems are.]
-
** Eliminate the storm of warnings concerning char/unsigned char
mismatches that we get with GCC 4.x and proprietary compilers on
various systems. They make it difficult to spot the important warnings.
** Fix anything necessary to use `long long' EMACS_INTs with GCC.
-** Split out parts of lisp.h [and generate Makefile dependencies automatically.]
-[the last bit is done, see DEPFLAGS etc in src/Makefile.in ]
+** Split out parts of lisp.h.
** Update the FAQ.
artist, ansi-color, array, battery, calculator, cdl, cmuscheme,
completion, cua, delim-col, dirtrack, double, echistory, elide-head,
easymenu, expand, flow-ctrl, format [format-alist],
- generic/generic-x [various modes], kermit, log-edit, ledit
- [obsolete?], makesum, midnight [other than in Kill Buffer node],
+ generic/generic-x [various modes], kermit, log-edit,
+ makesum, midnight [other than in Kill Buffer node],
mouse-copy [?], mouse-drag, mouse-sel, net-utils, rcompile,
snmp-mode [?], soundex [should be interactive?], strokes [start from
the web page], talk, thingatpt [interactive functions?], type-break,
- vcursor, xscheme, zone-mode [?], mlconvert [?], iso-cvt, iso-swed,
- swedish, feedmail [?], uce, bruce, gametree, meese, page-ext,
+ vcursor, xscheme, zone-mode [?], mlconvert [?], iso-cvt,
+ feedmail [?], uce, gametree, meese, page-ext,
refbib, refer, scribe, sgml-mode, spell, texinfo, underline,
- cmacexp, hideif, mantemp [obsolete?], pcomplete, assoc, xml,
+ cmacexp, hideif, mantemp [obsolete?], pcomplete, xml,
cvs-status (should be described in PCL-CVS manual); other progmodes,
probably in separate manual.
*** Bugs
+**** The event loop relies on polling and that hurts performance.
+ A better strategy is to have the select part in its own thread and let
+ the main thread communicate with that thread (see how Gdk does it for
+ inspiration). A problem is that redraw don't happen during resize,
+ because we can't break out from the NSapp loop during resize.
+ There is a special trick to detect mouse press in the lower right
+ corner and track mouse movements, but this does not work well, and is
+ not scalable to the new Lion "resize on every window edge" behavior.
+
**** (mouse-avoidance-mode 'banish) then minimize Emacs, will pop window back
up on top of all others
*** Other / Low Priority:
-**** Better recognition of unicode scripts / Greek / composition.
+**** Better recognition of Unicode scripts / Greek / composition.
**** Undo for color-drag face customization.
+** Bidirectional editing
+
+*** Support reordering structured text
+Two important use cases: (1) comments and strings in program sources,
+and (2) text with markup, like HTML or XML.
+
+One idea is to invent a special text property that would instruct the
+display engine to reorder only the parts of buffer text covered by
+that property. The display engine will then push its state onto the
+iterator stack, restrict the bidi iterator to accessing only the
+portion of buffer text covered by the property, reorder the text, then
+pop its state from stack and continue as usual. This will require
+minor changes in the bidi_it structure.
+
+This design requires Lisp-level code to put the text properties on the
+relevant parts of the buffer text. That could be done using JIT
+fontifications, or as a preliminary processing when the file is
+visited. With HTML/XML, the code that puts text properties needs to
+pay attention to the bidi directives embedded in the HTML/XML stream.
+
+*** Allow the user to control the direction of the UI
+
+**** Introduce user option to control direction of mode line.
+One 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
ImageMagick one. This is not wrong, but how should a user go about
-prefering the ImageMagick loader? The user might like zooming etc in jpegs.
+preferring the ImageMagick loader? The user might like zooming etc in jpegs.
Try (setq image-type-header-regexps nil) for a quick hack to prefer
ImageMagick over the jpg loader.
*** 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.
**** Provide an Error Summary buffer showing all the validation errors.
-**** Pop-up menu. What is useful? Tag a region (should be greyed out if
+**** Pop-up menu. What is useful? Tag a region (should be grayed out if
the region is not balanced). Suggestions based on error messages.
**** Have configurable list of namespace URIs so that we can provide
**** Better recovery from ill-formed XML declarations.
-*** Useability improvements
+*** Usability improvements
**** Should print a "Parsing..." message during long movements.
this.]
** Rewrite make-docfile to be clean and maintainable.
+ It might be better to replace it with Lisp, using the byte compiler.
+ http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg00037.html
** Add an inferior-comint-minor-mode to capture the common set of operations
offered by major modes that offer an associated inferior
button classes inherit from it. Set the default face of the "link" button
class to the standard "link" face.
+* Wishlist items:
+
+** Maybe replace etags.c with a Lisp implementation.
+http://lists.gnu.org/archive/html/emacs-devel/2012-06/msg00354.html
+
+** Maybe replace lib-src/rcs2log with a Lisp implementation.
+It wouldn't have to be a complete replacement, just enough
+for vc-rcs-update-changelog.
+
* Other known bugs:
** `make-frame' forgets unhandled parameters, at least for X11 frames.
You should have received a copy of the GNU General Public License
along with GNU Emacs. If not, see <http://www.gnu.org/licenses/>.
-