
Planned features for Emacs 24 - fogus
http://lists.gnu.org/archive/html/emacs-devel/2010-03/msg00272.html
======
jacoblyles
If Emacs comes out with a package manager, I'll take a day off to roll around
on the floor and giggle with glee.

~~~
technomancy
...?

<http://tromey.com/elpa/>

~~~
pmiller2
elpa is good, but, since it's not exactly a standard, there aren't many
packages available through it. Having a standard package manager in the emacs
distribution would go a long way toward solving this problem, since people
could be encouraged to package their .el files using it.

~~~
gchpaco
ELPA appears to be the one that they're going to merge into Emacs 24 (see
comment about Tromey et al, and know that Tromey is the main guy behind
ELPA...).

~~~
flogic
Nice so no need to worry about a fork.

------
jrockway
Lexbind and coroutines will be nice. But unfortunately, we are very close to
the point where Emacs' internal design won't work anymore. (Fortunately, most
of the important stuff in Emacs is Emacs Lisp, which is easy enough to compile
and run. The VM / C core is not very complicated.)

~~~
asolove
Can you explain? I don't know anything about why the internal design won't
work anymore.

~~~
jrockway
Important functionality cannot be modified without a full recompile, which is
always annoying. Try calling, say, font-backend functions from lisp... and
then try overriding them.

All of Emacs needs to be dynamic, not just some of it.

It would also be nice to allow other languages to target the Emacs VM without
rewriting those languages. Something like LLVM would be a good intermediate
platform; lots of compilers can generate code for it, and the various
assemblies can call each other.

Most users don't care, because they just want to write a function to replace <
and > with &lt; and &gt;... but some people writing more complex modes would
appreciate cleaner internals. Why shouldn't Emacs be as fast and accurate as
Yi, after all?

~~~
asolove
Good to know, thanks!

~~~
msg
Sorry, a stray click downvoted your comment and I cannot undo. I upvoted
another one of your comments to balance out the universe.

------
prodigal_erik
The package manager appears to be yet another single-app ghetto. From the
docs:

> Note that for some packages, package.el requires you to have an external tar
> program.

My platform _already has_ a package manager that knows whether I have tar, and
it will quietly go get that as soon as I install anything that needs it. If
package.el can't take advantage of a system that already works, it's part of
the problem rather than the solution.

~~~
kiiski
Emacs is cross-platform. It would be kinda hard for them to start using system
specific package managers (remember that windows exists too). And anyway, this
is meant for installing emacs extensions, not software for whatever system
you're using.

~~~
JulianMorrison
The proper solution would be

1\. Standardize the package format (say, a directory containing this-and-
that).

2\. Standardize where the packages go for personal and root installation.

3\. Have an emacs package manager, that deliberately does not use its own
metadata, but always uses the implied metadata of the packages in their
locations.

4\. Therefore, it doesn't matter what tool put the packages in place, so long
as they are in place.

5\. So use the built in package manager, or apt, or rpm, or whatever you
prefer.

~~~
kiiski
But how would that solve the problem of automatic cross-platform installation
of a tool required by the emacs package? As I see it, the problem is in
automating step 5. I guess you can find out the installed package manager in
linux somehow and then call it, but how are you going to do that in windows?

~~~
JulianMorrison
I think you misread what I was getting at. In this scenario Emacs doesn't call
the package manager - if emacs manages packages it does it for itself in
elisp. But it doesn't matter to emacs whether the package was installed from
an elisp program or from a .deb file, because the end result (predefined
format in predefined place) is the same regardless. So you're free to use, or
not use, the package manager of your choice. Or mix them.

------
abstractbill
_GTK widget embedding code_

Does this mean embedding GTK widgets into Emacs? Or making a new GTK widget
that _is_ an embeddable version of Emacs?

I suspect it's the former, but if every GTK-based application could embed an
Emacs editor, I think that would be pretty awesome too.

~~~
arohner
It means embedding GTK widgets into Emacs. For a while, people have been
threatening to do this. Among other things, it allows you to plug in a browser
control into emacs, which would be pretty awesome. Much better than dealing
with w3m and the like.

------
tjic
For the last few years elisp has been bugging me more and more. Basically,
ever since I saw how easy life is with Ruby, I've been annoyed at how hard it
is with elisp.

If I had six free months, I'd __love __to do yet-another-rewrite-of-Emacs,
this time in Ruby, with the obvious scripting language, and rewriting all of
the 100,000 function calls to be method calls on objects (make-buffer-local,
etc. scream out to be replaced with concepts that are less than 30 years
old...)

~~~
gnuvince
I'd rather see a clone implemented with Lua; with LuaJIT being so fast, it
could be really interesting what could be accomplished in Emacs.

------
docgnome
A canonical package manager?! Concurrency? _swoons_ It would totally rule to
be able to have a script to install all the package I use instead of having to
keep them all in repo myself. Also, not having to wait for Wanderlust to fetch
my mail would rock.

------
almost
Concurrency, package manager, GTK widget/SVG embedding? Wow! Seems like things
are really moving along with Emacs!

------
avar
As pointed out in the thread the planned features are now maintained in the
Emacs repository in etc/TODO. Here's a link to in on GitHub:
<http://github.com/emacsmirror/emacs/blob/master/etc/TODO#L15>

------
sethg
Bidi support! Yesssss!

------
cag_ii
>* Concurrency? (Scrivano et al.)

This would be nice!

~~~
ramchip
Now you have two problems.

~~~
tjic
LOL! Also, now _you_ have a royalties payment to JWZ.

------
gnuvince
About lexical binding, couldn't this potentially break many, many existing
packages? How easy would it be to fix the big ones (gnus, cc-mode, gdb, vc,
etc.)?

~~~
abrahamsen
Maybe not so hard. Variables defined by defvar will still have dynamic
binding, and the byte compiler has warned about using undefined symbols for a
decade or two.

------
warfangle
You know what would be great..? If it didn't litter squiggles all over my
directory structure. :P

~~~
theBobMcCormick
Easily fixed (I think someone else here linked to the wiki page for the
solution),but it _is_ a good example of one of the problems (IMHO) with Emacs.
It comes with shitty defaults. There's something of a chicken and egg problem
with getting started with Emacs. Emacs can rock very powerfully when properly
configured. But out of the box it sucks rocks. It's pretty hard for a beginner
to learn enough about Emacs to configure it to be worth a darn before giving
up in frustration. :-)

~~~
Naga
I'm a pretty new user to emacs, and this is something that has bugged me for a
while. It's one of those things I can't imagine why it would ever be a
default, but something I have to live with until my abilities to configure are
up to par.

~~~
jpr
It is easy to criticize something without providing an alternative.

~~~
Naga
Well now what I do is store the backups in a folder in my home directory.

