[qwertyuiop924]

If that's really your major issue with it...

Yes, the UI is awkward, but I've never really had any issues with it. It's functional.

Yes, Emacs isn't multithreaded. And yes, this can sometimes get annoying, although it's quite rare for me to actually have trouble with it. And slave processes, while expensive, are cheap enough.

In any case, threading support is on the todo list, so it may be done sometime this century.

[lispm]

> If that's really your major issue with it...

You seem to be misinterpreting me quite often. It's ONE issue. A development environment which is not multithreaded, is not very advanced.

> it's quite rare for me to actually have trouble with it.

No surprise: Blub paradox at work. Your tools limit your thought.

If my Lisp Machine would be single threaded, it would suck.

> Yes, the UI is awkward, but I've never really had any issues with it. It's functional.

Most Lisp-based development environment have much better UIs. For example in LispWorks or on a Lisp Machine the keychords are shorter. The Dynamic Windows UI of the Lisp Machine is still light-years ahead of anything GNU Emacs.

Here I made a demo how the documentation system works on the Symbolics. It uses Zmacs (the Emacs editor on the Lisp Machine, which Stallman used before he developed GNU Emacs) a component to write documentation records. This stuff had been developed in the mid-end 80s...

https://vimeo.com/83886950

Here Kalman Reti gives a demo of a Lisp Listener on the Symbolics and debugging mixed Lisp/C code:

https://www.youtube.com/watch?v=o4-YnLpLgtk

[qwertyuiop924]

>You seem to be misinterpreting me quite often. It's ONE issue. A development environment which is not multithreaded, is not very advanced.

Seriously, give the comma a break! It's starting to actually confuse me.

Anyways, on the subject at hand... A lot of the work Emacs does is either 1) manipulating text onscreen, where multithreading doesn't matter, or 2) communicating with subprocesses, which is usually pretty close to multithreading in any case. MT would be nice, but it's not as important as you think it is.

>No surprise: Blub paradox at work. Your tools limit your thought.

Oh, it totally sucks that there's no MP, it's just that there's usually a workaround: This is Unix, not DOS: we can spawn processes if we have to.

>Most Lisp-based development environment have much better UIs. For example in LispWorks or on a Lisp Machine the keychords are shorter.

If I want shorter keychords, then I'll bind them myself. I'm not sure if you've noticed, but the rest of us don't have Knight keyboards at our desks: We have to make do with what we've got.

>The Dynamic Windows UI of the Lisp Machine is still light-years ahead of anything GNU Emacs.

You keep saying that, and have yet to show an adequate example. This seems to show that Emacs's UI is adequate. And for editing text, the thing I use my editing environment most for, it is.

>Here I made a demo how the documentation system works on the Symbolics. It uses Zmacs (the Emacs editor on the Lisp Machine, which Stallman used before he developed GNU Emacs) a component to write documentation records. This stuff had been developed in the mid-end 80s...

It's a bit nicer than Emacs's, I'm willing to admit, but it's quite close, actually.

>Here Kalman Reti gives a demo of a Lisp Listener on the Symbolics and debugging mixed Lisp/C code:

That is actually genuinely cool, but it's not something we can have anymore: Most of us are on UNIX platforms, which don't really allow for this kind of debugging quite as well as the old Smalltalk/Lisp systems. But Emacs does have GDB integration, which is the next best thing.