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