Revert "* etc/TODO: Rearrange to start with "Simple tasks"."
This reverts commit 879ef5b19a.
Some of these items are a priority for the project and should be
before other, less prioritized items, according to a private
discussion with project co-maintainer Eli Zaretskii <eliz@gnu.org>.
This commit is contained in:
Stefan Kangas
parent
3489471417
commit
7bc0cee115
1 changed files with 75 additions and 73 deletions
148
etc/TODO
148
etc/TODO
|
|
@ -29,6 +29,81 @@ 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.
|
||||
|
||||
* 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.
|
||||
|
||||
** Improve the byte-compiler to recognize immutable bindings
|
||||
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
|
||||
Such a byte-code can be used 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.
|
||||
|
||||
** 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.
|
||||
|
||||
** 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 :-(
|
||||
|
||||
** 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.
|
||||
|
||||
*** Prog-mode could/should provide a better fill-paragraph default
|
||||
That default should use syntax-tables to recognize string/comment
|
||||
boundaries.
|
||||
|
||||
*** Provide more completion-at-point-functions
|
||||
Make existing in-buffer completion use completion-at-point.
|
||||
|
||||
*** "Functional" function-key-map
|
||||
It would make it easy to add (and remove) mappings like
|
||||
"FOO-mouse-4 -> FOO-scroll-down", "FOO-tab -> ?\FOO-\t",
|
||||
"uppercase -> lowercase", "[fringe KEY...] -> [KEY]",
|
||||
"H-FOO -> M-FOO", "C-x C-y FOO -> H-FOO", ...
|
||||
|
||||
* Simple tasks
|
||||
These don't require much Emacs knowledge and are suitable for anyone
|
||||
from beginners to experts.
|
||||
|
|
@ -151,44 +226,6 @@ https://lists.gnu.org/r/emacs-devel/2008-08/msg00456.html
|
|||
|
||||
* Important features
|
||||
|
||||
** 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.
|
||||
|
||||
*** Improve the byte-compiler to recognize immutable bindings
|
||||
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
|
||||
Such a byte-code can be used 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)))
|
||||
|
||||
** "Emacs as word processor"
|
||||
https://lists.gnu.org/r/emacs-devel/2013-11/msg00515.html
|
||||
rms writes:
|
||||
|
|
@ -446,15 +483,6 @@ 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.
|
||||
|
||||
** 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.
|
||||
|
||||
** 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.
|
||||
|
||||
** FFI (foreign function interface)
|
||||
See eg https://lists.gnu.org/r/emacs-devel/2013-10/msg00246.html
|
||||
|
||||
|
|
@ -862,32 +890,6 @@ The idea is to add an "X" of some kind, that when clicked deletes the
|
|||
window associated with that modeline.
|
||||
https://lists.gnu.org/r/emacs-devel/2007-09/msg02416.html
|
||||
|
||||
** 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 :-(
|
||||
|
||||
** Spread Semantic
|
||||
|
||||
** Random things that crossed Stefan Monnier's mind for Emacs 24
|
||||
Stefan Monnier writes: "Some of them from my local hacks, but it's not
|
||||
obvious at all whether they'll make it."
|
||||
|
||||
*** Prog-mode could/should provide a better fill-paragraph default
|
||||
That default should use syntax-tables to recognize string/comment
|
||||
boundaries.
|
||||
|
||||
*** Provide more completion-at-point-functions
|
||||
Make existing in-buffer completion use completion-at-point.
|
||||
|
||||
*** "Functional" function-key-map
|
||||
It would make it easy to add (and remove) mappings like
|
||||
"FOO-mouse-4 -> FOO-scroll-down", "FOO-tab -> ?\FOO-\t",
|
||||
"uppercase -> lowercase", "[fringe KEY...] -> [KEY]",
|
||||
"H-FOO -> M-FOO", "C-x C-y FOO -> H-FOO", ...
|
||||
|
||||
* Things to be done for specific packages or features
|
||||
|
||||
** NeXTstep port
|
||||
|
|
|
|||
Loading…
Add table
Add a link
Reference in a new issue