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:
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
|
difficult to fix. Bugs with severity "minor" may be simpler, but this
|
||||||
is not always true.
|
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
|
* Simple tasks
|
||||||
These don't require much Emacs knowledge and are suitable for anyone
|
These don't require much Emacs knowledge and are suitable for anyone
|
||||||
from beginners to experts.
|
from beginners to experts.
|
||||||
|
@ -151,44 +226,6 @@ https://lists.gnu.org/r/emacs-devel/2008-08/msg00456.html
|
||||||
|
|
||||||
* Important features
|
* 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"
|
** "Emacs as word processor"
|
||||||
https://lists.gnu.org/r/emacs-devel/2013-11/msg00515.html
|
https://lists.gnu.org/r/emacs-devel/2013-11/msg00515.html
|
||||||
rms writes:
|
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
|
as the old code. And once that works well, we can remove the old code
|
||||||
and old fields.
|
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)
|
** FFI (foreign function interface)
|
||||||
See eg https://lists.gnu.org/r/emacs-devel/2013-10/msg00246.html
|
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.
|
window associated with that modeline.
|
||||||
https://lists.gnu.org/r/emacs-devel/2007-09/msg02416.html
|
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
|
* Things to be done for specific packages or features
|
||||||
|
|
||||||
** NeXTstep port
|
** NeXTstep port
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue