Emacs TODO List -*-outline-*-
-Copyright (C) 2001-2014 Free Software Foundation, Inc.
+Copyright (C) 2001-2015 Free Software Foundation, Inc.
See the end of the file for license conditions.
difficult to fix. Bugs with severity "minor" may be simpler, but this
is not always true.
-* Tentative plan for Emacs-24
+* Speed up Elisp execution
+** Speed up function calls
+Change src/bytecode.c so that calls from byte-code functions to byte-code
+functions don't go through Ffuncall/funcall_lambda/exec_byte_code but instead
+stay within exec_byte_code.
+
+** Add new `switch' byte-code
+This byte-code would take one argument from the stack (the object to test)
+and one argument from the constant-pool (a switch table, implemented as an
+eq-hashtable) and would jump to the "label" contained in the hashtable.
+
+Then add a `case' special-form that can be compiled to this byte-code.
+This would behave just like cl-case, but instead of expanding to cond+eq it
+would be its own special form and would be compiled specially.
+
+Then change pcase to use `case' when applicable.
+
+Then change the byte-compiler to recognize (cond ((eq x 'foo) bar) ...)
+and turn it into a `case' for more efficient execution.
+
+** Improve the byte-compiler to recognize immutable (lexical) bindings
+and get rid of them if they're used only once and/or they're bound to
+a constant expression.
+
+Such things aren't present in hand-written code, but macro expansion and
+defsubst can often end up generating things like
+(funcall (lambda (arg) (body)) actual) which then get optimized to
+(let ((arg actual)) (body)) but should additionally get optimized further
+when `actual' is a constant/copyable expression.
+
+** Add an "indirect goto" byte-code and use it for local lambda expressions.
+E.g. when you have code like
+
+ (let ((foo (lambda (x) bar)))
+ (dosomething
+ (funcall foo toto)
+ (blabla (funcall foo titi))))
+
+turn those `funcalls' into jumps and their return into indirect jumps back.
+
+** Compile efficiently local recursive functions
+
+Similar to the previous point, we should be able to handle something like
+
+ (letrec ((loop () (blabla) (if (toto) (loop))))
+ (loop))
+
+which ideally should generate the same byte-code as
+
+ (while (progn (blabla) (toto)))
+
+* Things that were planned for Emacs-24
** 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.
+ sounds good. Of course there might still be big questions around "which form
+ of concurrency" we'll want.
** better support for dynamic embedded graphics: I like this idea (my
mpc.el code could use it for the volume widget), though I wonder if the
resulting efficiency will be sufficient.
** 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
make it.
-*** multiple inheritance for keymaps (to get rid of the
- fix_submap_inheritance hack and to more cleanly express the
- relationship between minibuffer-local-*-map): I've had this locally
- for a long time, but the details of the semantics is somewhat ... delicate.
*** prog-mode could/should provide a better fill-paragraph default
that uses syntax-tables to recognize string/comment boundaries.
*** provide more completion-at-point-functions. Make existing
** Convert modes that use view-mode to be derived from special-mode instead.
-** Major modes should have a menu entry. Examples of modes that do
-not have one at the moment and probably should: text-mode, inferior-lisp-mode.
+** Major modes should have a menu entry.
** Check if all items on the mode-line have a suitable tooltip for all modes.
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.
-
** Distribute a bar cursor of width > 1 evenly between the two glyphs
on each side of the bar (what to do at the edges?).
It ought to be possible to omit text which is invisible (due to a
text-property, overlay, or selective display) from the kill-ring.
-** Change the way define-minor-mode handles autoloading.
- It should not generate :require. Or :require in defcustom
- should not be recorded in the user's custom-set-variables call.
-
** Feature to change cursor shape when Emacs is idle (for more than
a specified time).
using a heuristic of some kind?
** Define recompute-arg and recompute-arg-if for fix_command to use.
- See rms message of 11 Dec 05.
-
-** Height returned by frame-parameter ... and height given to
- make-frame does not mean the same thing. The former includes menu and
- tool bar lines, the latter don't. frame-parameter should return height
- without menu and tool bar lines.
+ See rms message of 11 Dec 05 in
+ http://lists.gnu.org/archive/html/emacs-pretest-bug/2005-12/msg00165.html,
+ and the rest of that discussion.
** In Emacs Info, examples of using Customize should be clickable
and they should create Custom buffers.
** Find a proper fix for rcirc multiline nick adding.
http://lists.gnu.org/archive/html/emacs-devel/2007-04/msg00684.html
-** Implement `network-interface-list' and `network-interface-info'
-on MS-Windows. Hint: the information is present in the Registry,
-under the keys
-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Linkage\
-and
-HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\<device>\
-where <device> is the network device found under the first key.
-
** Check for any included packages that define obsolete bug-reporting commands.
Change them to use report-emacs-bug.
*** Related functions:
processing. That is why we added text properties and variable
width fonts. However, more features are still needed to achieve this.
-** Extended text-properties (to make overlays "obsolete")
+** Extend text-properties and overlays
*** Several text-property planes
This would get us rid of font-lock-face property (and I'd be happy to
get rid of char-property-alias-alist as well) since font-lock would
simply use the `face' property in the `font-lock' plane.
-Each property would come with an Elisp merge-function. The merge
-would be performed in add-text-properties.
-*** zero-width text-properties.
+
+Basically `put-text-property' and friends would take an extra argument PLANE
+(maybe the best backward-compatible way to do that is to make it so that
+PROPERTY can be a cons cell (PLANE . PROP)). So font-lock would
+do (put-text-property start end '(font-lock . face) value).
+
+All the properties coming from the various planes would get merged via an Elisp
+function (so it can merge `face' differently than `keymap' or it could give
+different priorities to different planes (we could imagine enabling/disabling
+planes)). The merging would not happen lazily while looking up properties but
+instead it would take place eagerly in `add-text-properties'. This is based on
+the idea that it's much more frequent to lookup properties than to
+modify them. Also, when properties are looked up during redisplay, we
+generally can't run Elisp code, whereas we generally can do that when
+properties are added.
+
+*** Move overlays to intervals.c
+
+Currently overlays are implemented as (two) sorted singly linked lists (one
+for overlays_before some position and one for overlay_after that
+position, for some quirky definition of "before" and "after").
+The function `overlay-recenter' changes the position used for the split
+(and is called internally in various situations).
+
+Each overlay is itself implemented with two markers (which keep track of
+the overlay-start and overlay-end). Markers are implemented as
+a non-sorted singly linked list of markers. So every text
+insertion/deletion requires O(N) time, where N is the number of markers
+since we have to go down that list to update those markers that are
+affected by the modification.
+
+You can start in src/buffer.[ch], maybe grepping for overlays_before for
+a starting point.
+
+Text-properties, OTOH, are implemented with a (mostly) balanced binary
+tree. This is implemented in src/intervals.[ch].
+
+So we'd like to change overlays so that they don't use markers (and we
+don't keep them in two sorted singly-linked lists) any more. Instead,
+we'll store them inside the balanced binary tree used for
+text-properties. I think we can use the "augmented tree" approach
+described in https://en.wikipedia.org/wiki/Interval_tree.
+
+To ease up debugging during development, I'd guess the implementation
+would first add the new stuff, keeping the old stuff (i.e. add to
+Lisp_Overlay whichever fields are needed for the new code, while keeping
+the old ones, add needed overlay fields to the intervals tree, but keep
+the old fields, the overlays_before etc...). This way, you can add
+consistency checks that make sure the new code computes the same results
+as the old code. And once that works well, we can remove the old code
+and old fields.
+
** Having tabs above a window to switch buffers in it.
** "Perspectives" are named persistent window configurations. We have
** FFI (foreign function interface)
See eg http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00246.html
+One way of doing this is to start with fx's dynamic loading, and use it
+to implement things like auto-loaded buffer parsers and database
+access in cases which need more than Lisp.
+
** Replace unexec with a more portable form of dumping
See eg http://lists.gnu.org/archive/html/emacs-devel/2014-01/msg01034.html
+ http://lists.gnu.org/archive/html/emacs-devel/2014-06/msg00452.html
+
+One way is to provide portable undumping using mmap (per gerd design).
** Imenu could be extended into a file-structure browsing mechanism
using code like that of customize-groups.
by http://savannah.nongnu.org/projects/emacs-rtf/, which is still in
very early stages.
+ Another place to look is the Wikipedia article at
+ http://en.wikipedia.org/wiki/Rich_Text_Format
+
+ It currently points to the latest spec of RTF v1.9.1 at
+ http://www.microsoft.com/en-us/download/details.aspx?id=10725
+
** Implement primitive and higher-level functions to allow filling
properly with variable-pitch faces.
-** Implement a smoother vertical scroll facility, one that allows
- C-v to scroll through a tall image. The primitive operations
- posn-at-point and posn-at-x-y should now make it doable in elisp.
-
** Implement intelligent search/replace, going beyond query-replace
(see http://groups.csail.mit.edu/uid/projects/clustering/chi04.pdf).
Maybe making Lucid menus work like Gtk's (i.e. just force utf-8) is good
enough now that Emacs can encode most chars into utf-8.
-** Remove the limitation that window and frame widths and heights can
- be only full columns/lines.
-
** The GNUstep port needs some serious attention, ideally from someone
familiar with GNUstep and Objective C.
** Allow frames(terminals) created by emacsclient to inherit their environment
from the emacsclient process.
+
** Remove the default toggling behavior of minor modes when called from elisp
rather than interactively. This a trivial one-liner in easy-mode.el.
** Make byte-optimization warnings issue accurate line numbers.
-** A function to check for customizable options that have been
- set but not saved, and ask the user whether to save them.
- This could go in kill-emacs-query-functions, to remind people
- to save their changes. If the user says yes, show them
- in a Custom buffer using customize-customized.
-
** Record the sxhash of the default value for customized variables
and notify the user (maybe by adding a menu item or toolbar button,
as the detection can occur during autoload time) when the default
user-selected input method, with the default being the union of
latin-1-prefix and latin-1-postfix.
-** Switch the Windows port to using Unicode keyboard input (maybe).
- Based on http://msdn2.microsoft.com/en-us/library/ms633586.aspx,
- this boils down to (1) calling RegisterClassW function to register
- Emacs windows, and (2) modifying ALL system messages to use Unicode.
- In particular, WM_CHAR messages, which result from keyboard input,
- will then come in encoded in UTF-16.
-
- One advantage of switching to Unicode is to toss encoded-kbd usage,
- which will solve the problem with binding non-ASCII keys with modifiers.
-
- Problem: using this on Windows 9x/ME requires installing the
- Microsoft Layer for Unicode (MSLU), which might not implement all
- the required functionality that is available built-in on Windows XP
- and later. We should not make this change if it would pressure
- users of unauthorized copies of older versions of Windows to
- downgrade to versions that require activation.
-
** Implement a clean way to use different major modes for
different parts of a buffer. This could be useful in editing
Bison input files, for instance, or other kinds of text
multiple inheritance ? faster where-is ? no more fix_submap_inheritance ?
what else ?
-** Provide real menus on ttys. The MS-DOS implementation can serve as
- an example how to do part of this; see the XMenu* functions on msdos.c.
-
** Implement popular parts of the rest of the CL functions as compiler
macros in cl-macs. [Is this still relevant now that cl-lib exists?]
[Basic support added 2013/10:
http://lists.gnu.org/archive/html/emacs-devel/2013-10/msg00904.html ]
-** 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.
** Update the FAQ.
** Add definitions for symbol properties, for documentation purposes.
-** Add horizontal scroll bars.
+** Temporarily remove scroll bars when they are not needed, typically
+ when a buffer can be fully displayed in its window.
** Provide an optional feature which computes a scroll bar slider's
size and its position from lines instead of characters.
tree displays generally, mode-line mail indicator. [See work done
already for Emacs 23 and consult fx.]
-** Do something to make rms happy with fx's dynamic loading, and use it
- to implement things like auto-loaded buffer parsers and database
- access in cases which need more than Lisp.
-
** Extend ps-print to deal with multiple font sizes, images, and extra
encodings.
-** Provide portable undumping using mmap (per gerd design).
-
** Make byte-compile avoid binding an expanded defsubst's args
when the body only calls primitives.
Try (setq image-type-header-regexps nil) for a quick hack to prefer
ImageMagick over the jpg loader.
-*** For some reason its unbearably slow to look at a page in a large
+*** For some reason it's unbearably slow to look at a page in a large
image bundle using the :index feature. The ImageMagick "display"
command is also a bit slow, but nowhere near as slow as the Emacs
code. It seems ImageMagick tries to unpack every page when loading the
** Replace linum.el with nlinum.el
http://lists.gnu.org/archive/html/emacs-devel/2013-08/msg00379.html
-** Use pcomplete by default in shell-mode.
- This means to make it behave (by default) more like the current code.
- Use it also for read-shell-command, M-x compile, ...
-
** Merge sendmail.el and messages.el.
Probably not a complete merge, but at least arrange for messages.el to be
a derived mode of sendmail.el. Or arrange for messages.el to be split
** a two-char comment-starter whose two chars are symbol constituents will
not be noticed if it appears within a word.
-** Fix unexelf.c to handle the .data.rel and .data.rel.local
- sections made by GCC 3.4 on IRIX.
-
\f
This file is part of GNU Emacs.