Planned features for Emacs 24 | Hacker News Reader

Planned features for Emacs 24

lists.gnu.org

80 pointsfogus47 comments

If Emacs comes out with a package manager, I'll take a day off to roll around on the floor and giggle with glee.

Then it's about time someone will come up with Googlemacs, an installation of Chrome OS that, instead of the browser, launches Emacs as its only process...

Why wait?

http://www.informatimago.com/linux/emacs-on-user-mode-linux....

...?

http://tromey.com/elpa/

To be honest elpa isn't all that useful right now to get all your emacs plugins and I'm sure if a package manager came out that was integrated into emacs we would see a much larger use of package management in emacs.

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.

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...).

Nice so no need to worry about a fork.

Meh. It's the sort of thing lots of extensible programs -- including far simpler editors -- already do, so there's not as much humor value in it.

Not humor, just pure delight and relief.

There are two reasons I work primarily with textmate rather than emacs.

One is the triplicate evil of emacs lisp, the PITA it is to get els to work, and the inconvenience of no pkg management for the aforementioned.

The other is that the 'power' of emacs is well-hidden compared to textmate.

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.)

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

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 < and >... but some people writing more complex modes would appreciate cleaner internals. Why shouldn't Emacs be as fast and accurate as Yi, after all?

Well, from what I've skimmed in the emacs-devel list, there's some talk of putting guile in there, so that'd at least open up for scheme, and I guess javascript, or whatever it is that guile currently supports. This'd probably solve things like bignum support and so on too, I guess. I doubt we'd see this even in emacs25, though, but, still...

Good to know, thanks!

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

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.

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.

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.

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?

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.

From an Emacs package maintainers point of view, is that your platforms package manager is just another single-system ghetto. And most likely not the ghetto I live in.

What I need is a package format that only relies on software that is available to every Emacs user, no matter what set of device drivers and associated utilities they have running under their editor. So I can give a single set of instructions, I can actually test out myself.

But a standardized Emacs package format should make life easier for the people maintaining the single-system package managers, making it easier to import Emacs packages into their respective ghettos.

Sure, there's no reason not to standardize the information you give to the people who package your code for a given platform. But package.el makes it easier for users to smuggle code onto the filesystem whose version and dependencies aren't announced to the package manager and which may have never even been tested on the platform, and I regard that as a bad idea. Our sysadmins certainly don't want to go back to the world where every app had its own way of handling plugins and they had to understand all of them.

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.

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.

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...)

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.

you _do_ know you can customize emacs with ruby, right?

http://www.emacswiki.org/emacs/EmacsLispForRuby

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.

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

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

Bidi support! Yesssss!

>* Concurrency? (Scrivano et al.)

This would be nice!

Now you have two problems.

LOL! Also, now you have a royalties payment to JWZ.

Nobody said anything about threads.

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.)?

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.

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

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. :-)

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.

You should check out the emacs starter kit if you haven't already: http://github.com/technomancy/emacs-starter-kit

It is easy to criticize something without providing an alternative.

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

http://www.emacswiki.org/emacs/BackupDirectory

Put -B in your $LS_OPTIONS.

Reply on news.ycombinator.com