* etc/TODO: Add a few entries, remove others, expand some

1 files changed, 107 insertions, 22 deletions

diff --git a/etc/TODO b/etc/TODO
index 3fccffc5630..c38efd6aca3 100644
--- a/etc/TODO
+++ b/etc/TODO
@@ -26,12 +26,62 @@ are the ones we consider more important, but these also may be
 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.
@@ -43,10 +93,6 @@ is not always true.
 ** 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
@@ -102,8 +148,6 @@ I suggest totally rewriting that part of Flymake, using the simplest
 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?).
 
@@ -119,10 +163,6 @@ for users to customize.
   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).
 
@@ -195,14 +235,63 @@ http://lists.gnu.org/archive/html/emacs-devel/2013-11/msg00515.html
     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
@@ -1206,10 +1295,6 @@ systems for HTML/XML files automatically."
 ** 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