Commit 6a19cde6 authored by Stefan Monnier's avatar Stefan Monnier

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

parent 56c6a28d
......@@ -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)))
(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))))
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 @@
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
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
** 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
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment