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
+ mpc.el code could use it for the volume widget), though I wonder if the
resulting efficiency will be sufficient.
** Spread Semantic.
** 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 does not redraw.
+ A problem is that redraw don't happen during resize,
+ because we can't break out from the NSapp loop during resize.
+ There was a special trick to detect mouse press in the lower right
+ corner and track mouse movements, but this did not work well, and was
+ 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
For use by sml-mode, python-mode, tex-mode, scheme-mode, lisp-mode,
haskell-mode, tuareg-mode, ...
-** Make SYNC_INPUT the default. [true since 2008-03-11]
- All loops using immediate_quit need to be checked to ensure that
- C-g can interrupt them, in case of an infinite loop. Once we
- switch to using SYNC_INPUT, we can remove the BLOCK_INPUTs in the
- allocation functions (allocate_string etc.) without worrying about
- data munging.
-
** Add "link" button class
Add a standard button-class named "link", and make all other link-like
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/>.
-