[taeric]

I have to confess that the more I learn about emacs, the more I am curious about just what is new in the world of editors/ides. I mean, I understand that the thread model in emacs is supposed to be lacking, but it really seems that the only difference between emacs and so many of the "modern" alternatives, is that emacs is written in elisp, the others are not. Am I missing something more fundamental?

[agumonkey]

The fluidity of lisp based software is something very rare. Trying to extend Eclipse is a huge pain: need to create a plugin project, learn the overwhelming api, all this to get a Hello World menu entry. Extending emacs is two LoC and one shortcut away. Except for the visual side of things, emacs will ingest any feature ever produced by any new editor on the block. I felt it when I watched a 2 hour long video about sublime or textmate and how it was revolutionary whereas there was nothing remotely new in it (except on the pre-integration).

ps: Personally I'd love to see a rewrite of emacs main packages, it's not lispy/functional enough for my tastes. Something in the lines of alan kay minimalism (see VPRI, Ometa)

[sparkie]

> ps: Personally I'd love to see a rewrite of emacs main packages, it's not lispy/functional enough for my tastes.

There's a project underway to create a Guile base for emacs, which will include an elisp interpreter for compatibility. Scheme is more lispy than lisp, and lexical scoping is an obvious win. Hopefully this project will be a huge cleanup and simplify things.

There's also a Guile project called Emacsy, which is an attempt to create an embeddable library for the kind of core, non text-editing functionality emacs has, to be used in other apps (eg, minibuffers, keybindings, runtime configuration etc).

[agumonkey]

I know these. While they're still working on it, since emacs24 elisp with lexical scoping, and some 'stdlib' like dash could help simplify things. People were also discussing writing some non-toy-project lazy stream library that could be very helpfull to process buffers in a functional manner.

Have you used emacsy yourself ? I like this project a lot, and wanna extend many programs with it but I'm not versed into this kind of C programming.

[pjmlp]

That is more to do with Eclipse's design than the language being used.

Eclipse suffers from the typical Enterprise Architecture design.

[agumonkey]

Isn't it a side effect of java compilation ? it's a lot less easy to install functions at runtime than in lisps (or other languages alike)

[pjmlp]

Not really.

[xaritas]

This is a great talk by Stuart Halloway on what sets emacs apart from typical editors/IDEs. It's 25 minutes and well worth the time.

http://vimeo.com/1013263

[taeric]

Thanks for the link. Is indeed a nice video. Amusingly touches on the "pretty" aspect mentioned side thread.

[tl]

I'd not sure that the thread model is that much worse than other text editors. It's just that its customizability makes the deficiency more apparent.

However, Emacs has 3 fundamental weaknesses versus modern alternatives:

1) Out of box, it doesn't do a whole lot unless you need to edit plain text or elisp. This has improved in recent years. It needs to improve a lot more.

2) Emacs is not "pretty". Specifically, even "native" ports never look quite right and there's a limit to what you can fix (it's a surprisingly high limit, but still). Since the value of the first run experience is underestimated by people who have been using emacs for years, this is not improving.

3) Emacs cannot be ported effectively to "limited" platforms that don't respect the GPL or allow downloaded code in applications cough iOS cough. This might be the final nail in its coffin in a decade or so, as more platforms take this stance for protectionist reasons (everyone wants 30% rent and malware/piracy/whatever will be cited as justification).

[seanmcdirmid]

> (everyone wants 30% rent and malware/piracy/whatever will be cited as justification).

Emacs is a platform in itself. I don't think anyone has figured out how to create sub-gardens inside walled gardens yet, and what that even means to the curated vetted app experience. Taken to an extreme, obviously, even postscript viewers and other non-trivial viewers aren't allowed either (since they have to "interpret" documents).

[taeric]

The pretty angle is interesting. I personally like the look of just having a text editor with virtually no chrome. I'm curious what it would take to get emacs "prett," and if it would be worth attempting. More, which would be more work, taking emacs and making it pretty, or extending a brand new editor to be as capable as emacs?

[aerique]

After having used Emacs for quite some time I really cannot care less how it looks. It grows on you.

However, I can understand what it must look like to new users compared to f.e. Sublime Text or Visual Studio. Emacs isn't particularly inviting compared to them.

[taeric]

Do you think a simple layer of chrome on top of emacs would suffice for most folks, though?

And, I find calling Visual Studio inviting scary. There is so much going on there that it really jars my senses. I guess if I'm wanting to "explore" with the mouse it is good. But if I'm wanting to type in something, not so much.

Of course, maybe that is really all of this call for "visual" programming really missing a boat. In that most folks that pine for this visual nirvana simply refuse to try out visual studio. :)