> The language being integrated into Emacs makes writing Elisp programs a very fluid and intuitive experience: things like the fact that the documentation and the place where a function was defined is available at any time makes /understanding/ the system easy, and the actual documentation itself is often quite well written, and the Info manuals will most often explain everything you need to know about a package. Common Lisp+SLIME shares some of this convenience, but not to the extent that Elisp truly does.
I think that all (or a lot of?) the Emacs niceties could be grafted into a hypothetical EMACS package in Common Lisp. There’s no reason why an Emacs in Common Lisp wouldn’t still be able to jump to a definition, or to documentation, or whatever. It could still implement advice.
And the entire thing would be hackable at runtime, unlike the current Emacs situation where everything but the core runtime is hackable. And there would be packages instead of having to prefix every package’s function with the package name.
Common Lisp is definitely not perfect, but it would probably be a better base for Emacs than Elisp is. Elisp is not bad — at least it’s a Lisp, not Lua or Javascript — but it’s really not great.
> There’s no reason why an Emacs in Common Lisp wouldn’t still be able to jump to a definition, or to documentation, or whatever. It could still implement advice.
Sorry if you were confused by my wording; SLIME is able to do all of this--and I am not intending to badmouth SLIME either, it's a very great and well-featured system. However, it plays the odd role of having to bridge the gap between Emacs, and the various CL implementations it's meant to support. Things like documentation of functions really come down to the implementation you're using. The de-facto source of documentation for Common Lisp is the HyperSpec, which is a collection of HTML documents. If it doesn't already exist I would like to write a hack to make these documents render inside Emacs itself.
I think I should clarify the idea that Common Lisp itself is merely a /language/. Unless you're only writing strictly ANSI CL, real programs depend on the facilities provided by the implementation; it isn't a complete programming system until you give it an environment. SBCL+SLIME, or Allegro or LispWorks or a Lisp machine constitute full programming systems in the same way Emacs+Elisp does by itself.
>And the entire thing would be hackable at runtime, unlike the current Emacs situation where everything but the core runtime is hackable.
Ever since Elisp has begun to be compiled into native code, I've become hopeful of the idea that eventually the core components written in C will eventually be subsumed by Elisp itself. However, I am also concerned that this will also degrade the overall performance of the system; not because compiled Elisp wouldn't be performant enough but because hackers might be likely to rewrite these components in a negligent way (the same way they have written modules which are the source of many of the relevant complaints, like LSP and company-mode)--see my other comment in this thread about the internals of the Lisp machine system.
However, having said that, I think a good enough majority of the runtime is hackable that it escapes being a problem. Much of the window system, for example is exposed to Elisp: one of my projects recently has been to write a drop-in replacement for the X window context menus that spawn text frames instead.
>And there would be packages instead of having to prefix every package’s function with the package name.
Packages with namespaces are one thing that would have been nice to have, but it's lack of them is well entrenched enough at this point to remain, and it isn't really a problem once you get used to it.
I think that all (or a lot of?) the Emacs niceties could be grafted into a hypothetical EMACS package in Common Lisp. There’s no reason why an Emacs in Common Lisp wouldn’t still be able to jump to a definition, or to documentation, or whatever. It could still implement advice.
And the entire thing would be hackable at runtime, unlike the current Emacs situation where everything but the core runtime is hackable. And there would be packages instead of having to prefix every package’s function with the package name.
Common Lisp is definitely not perfect, but it would probably be a better base for Emacs than Elisp is. Elisp is not bad — at least it’s a Lisp, not Lua or Javascript — but it’s really not great.