8 ms·

Planned features for Emacs 24

80 points by fogus 17y ago

jrockway 17y ago
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 17y ago
  Can you explain? I don't know anything about why the internal design won't work anymore.
  - jrockway 17y ago
    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?
    - asolove 17y ago
      Good to know, thanks!
      - msg 17y ago
        Sorry, a stray click downvoted your comment and I cannot undo. I upvoted another one of your comments to balance out the universe.
    - modokode 17y ago
      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...
sethg 17y ago
Bidi support! Yesssss!
abstractbill 17y ago
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 17y ago
  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.
cag_ii 17y ago
>* Concurrency? (Scrivano et al.) This would be nice!
- ramchip 17y ago
  Now you have two problems.
  - jrockway 17y ago
    Nobody said anything about threads.
  - tjic 17y ago
    LOL! Also, now you have a royalties payment to JWZ.
warfangle 17y ago
You know what would be great..? If it didn't litter squiggles all over my directory structure. :P
- shimon 17y ago
  Put -B in your $LS_OPTIONS.
- dryicerx 17y ago
  http://www.emacswiki.org/emacs/BackupDirectory http://www.emacswiki.org/emacs/BackupDirectory
- theBobMcCormick 17y ago
  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 17y ago
    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.
    - avar 17y ago
      You should check out the emacs starter kit if you haven't already: http://github.com/technomancy/emacs-starter-kit http://github.com/technomancy/emacs-starter-kit
    - jpr 17y ago
      It is easy to criticize something without providing an alternative.
jacoblyles 17y ago
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 17y ago
  ...? http://tromey.com/elpa/ http://tromey.com/elpa/
  - pmiller2 17y ago
    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 17y ago
      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 17y ago
        Nice so no need to worry about a fork.
  - bugs 17y ago
    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.
- ubernostrum 17y ago
  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.
docgnome 17y ago
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.
- deleted 17y ago
  [deleted]
prodigal_erik 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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 17y ago
        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.
almost 17y ago
Concurrency, package manager, GTK widget/SVG embedding? Wow! Seems like things are really moving along with Emacs!
tjic 17y ago
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...)
- zenspider 17y ago
  you _do_ know you can customize emacs with ruby, right? http://www.emacswiki.org/emacs/EmacsLispForRuby http://www.emacswiki.org/emacs/EmacsLispForRuby
- gnuvince 17y ago
  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.
gnuvince 17y ago
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 17y ago
  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.
avar 17y ago
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 http://github.com/emacsmirror/emacs/blob/master/etc/TODO#L15

80 points by fogus 17y ago

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 17y ago
Can you explain? I don't know anything about why the internal design won't work anymore.
- jrockway 17y ago
  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?
  - asolove 17y ago
    Good to know, thanks!
    - msg 17y ago
      Sorry, a stray click downvoted your comment and I cannot undo. I upvoted another one of your comments to balance out the universe.
  - modokode 17y ago
    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...

sethg 17y ago

Bidi support! Yesssss!

abstractbill 17y ago

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 17y ago
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.

cag_ii 17y ago

>* Concurrency? (Scrivano et al.) This would be nice!

ramchip 17y ago
Now you have two problems.
- jrockway 17y ago
  Nobody said anything about threads.
- tjic 17y ago
  LOL! Also, now you have a royalties payment to JWZ.

warfangle 17y ago

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

shimon 17y ago
Put -B in your $LS_OPTIONS.
dryicerx 17y ago
http://www.emacswiki.org/emacs/BackupDirectory http://www.emacswiki.org/emacs/BackupDirectory
theBobMcCormick 17y ago
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 17y ago
  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.
  - avar 17y ago
    You should check out the emacs starter kit if you haven't already: http://github.com/technomancy/emacs-starter-kit http://github.com/technomancy/emacs-starter-kit
  - jpr 17y ago
    It is easy to criticize something without providing an alternative.

jacoblyles 17y ago

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 17y ago
...? http://tromey.com/elpa/ http://tromey.com/elpa/
- pmiller2 17y ago
  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 17y ago
    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 17y ago
      Nice so no need to worry about a fork.
- bugs 17y ago
  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.
ubernostrum 17y ago
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.

docgnome 17y ago

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.

deleted 17y ago
[deleted]

prodigal_erik 17y ago

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 17y ago
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 17y ago
  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 17y ago
    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 17y ago
      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.

almost 17y ago

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

tjic 17y ago

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

zenspider 17y ago
you _do_ know you can customize emacs with ruby, right? http://www.emacswiki.org/emacs/EmacsLispForRuby http://www.emacswiki.org/emacs/EmacsLispForRuby
gnuvince 17y ago
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.

gnuvince 17y ago

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 17y ago
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.

avar 17y ago

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 http://github.com/emacsmirror/emacs/blob/master/etc/TODO#L15