I mostly agree, though I find Allegro and LispWorks severely lacking in areas too. The companies themselves don't seem to care much about their IDEs. Certainly not in the way JetBrains cares about IntelliJ.
Tucked away in the McCLIM project is Clouseau, which you can quickload and use as a normal user: https://codeberg.org/McCLIM/McCLIM/src/branch/master/Apps/Cl... One small cool thing it does is if you inspect a complex number it will also draw a little x-y graph with its vector representation. (Though trying it out again just now it's overlapping with the text... maybe I should file a bug, but I've only now just learned they moved off github, and I'm not going to make a codeberg account. Friction wins this round.) It does take a while to first compile and load all the dependencies, especially 3bz, another weakness of at least our free Lisps; AFAIK there's still no equivalent of make -j for compiling systems.
I'm a happy vim user (though there is some jank with slimv, admittedly, but it's mostly prevalent around multiple thread situations) and setup the command ,ci to call my own clouseau-inspect function; it just inspects a symbol with clouseau instead of slimv's inspector. Also have a janky watch/unwatch pair of functions that just refreshes the inspector every second. (https://github.com/Jach/dots/blob/master/.sbclrc#L113 if curious, some other junk in .swank.lisp and .vimrc too, and there's https://github.com/dense-analysis/ale/issues/4061 to call sblint on your project...)
But more graphical tools like this are what I hope to one day see more of and are how the free Lisps can close the gap in this area with the commercial Lisps. I believe there's not much Allegro can do that poking around SBCL can't do, but for many things it's just nicer to have a GUI. Want to explore all the symbols and values in a package? Easy enough to script that, but not as nice as just having a table of symbols, and even nicer if you can set watches on some of them, or even set conditional breakpoints on value changes. None of the tools need to be tightly integrated with a single IDE either, because all the stuff necessary to debug Lisp is in the running Lisp itself. It's just that the GUI situation continues to suck.
LSP has gotten more popular with other languages and editors, sometimes I wonder if the acronym was made as an inside joke because it's basically how Lisp + Slime/Swank have worked...
I think the LispWorks Pro IDE is nice enough! When I am working on a smaller projects, I find that SBCL+Emacs+Slime are great, but when I am working with many files, often in different Quicklisp libraries I work on jointly, then I find the LispWorks Pro IDE works better for me.
I have been intending on trying the latest free IDE from Franz. Two days ago I was in a fun catch-up video call with Jans Aasman from Franz, but we were talking about AI more generally, not Common Lisp specifically.
I'm curious, what specifically works better about their IDE for you in the case of many files? Do they now have good global refactoring tools, like you can change a class name in library A and have it automatically be updated in library B and application C that depend on and use it? And without the actual files for such being open? Possibly not even the systems being loaded? (I'm reduced to what's essentially mass search-replace with https://github.com/mhinz/vim-grepper/ but it does the job and importantly helps update files I might not have open buffers for. Still a step down from what's available in JavaLand. I remember someone was working on a library to build some modern refactoring tools for Lisp but I don't know how far that's gotten.)
It has more to do with navigation and many tiled source code windows open. It is true that using treemacs + Emacs and opening multiple frames can get a similar experience.
Tucked away in the McCLIM project is Clouseau, which you can quickload and use as a normal user: https://codeberg.org/McCLIM/McCLIM/src/branch/master/Apps/Cl... One small cool thing it does is if you inspect a complex number it will also draw a little x-y graph with its vector representation. (Though trying it out again just now it's overlapping with the text... maybe I should file a bug, but I've only now just learned they moved off github, and I'm not going to make a codeberg account. Friction wins this round.) It does take a while to first compile and load all the dependencies, especially 3bz, another weakness of at least our free Lisps; AFAIK there's still no equivalent of make -j for compiling systems.
I'm a happy vim user (though there is some jank with slimv, admittedly, but it's mostly prevalent around multiple thread situations) and setup the command ,ci to call my own clouseau-inspect function; it just inspects a symbol with clouseau instead of slimv's inspector. Also have a janky watch/unwatch pair of functions that just refreshes the inspector every second. (https://github.com/Jach/dots/blob/master/.sbclrc#L113 if curious, some other junk in .swank.lisp and .vimrc too, and there's https://github.com/dense-analysis/ale/issues/4061 to call sblint on your project...)
But more graphical tools like this are what I hope to one day see more of and are how the free Lisps can close the gap in this area with the commercial Lisps. I believe there's not much Allegro can do that poking around SBCL can't do, but for many things it's just nicer to have a GUI. Want to explore all the symbols and values in a package? Easy enough to script that, but not as nice as just having a table of symbols, and even nicer if you can set watches on some of them, or even set conditional breakpoints on value changes. None of the tools need to be tightly integrated with a single IDE either, because all the stuff necessary to debug Lisp is in the running Lisp itself. It's just that the GUI situation continues to suck.
LSP has gotten more popular with other languages and editors, sometimes I wonder if the acronym was made as an inside joke because it's basically how Lisp + Slime/Swank have worked...