I’m guessing Steve is using vim or emacs, since he’s a Linux guy. Which of these or some other editors have best support for Nyquist & the XLips dialect?
I know most editors have Lisp language support in one form or another, but some forms aren’t recognized in all, e.g. let* by Sublime or VSCode (which borrowed the dictionary from the latter.)
Also “best support” for Nyquist would mean parsing the *.lsp files for the pre-defined function like snd-whatever. Has anyone written an extension like that for any text editor? I know Nyquist has its own IDE, but I’d rather not use it just for this, especially since Audacity plugins don’t quite run in it with controls etc.
I don’t know of any editors that have built-in support specifically for XLISP or Nyquist, but there are several that support one or more types of LISP.
For Windows, my recommendation would be NotePad++ (https://notepad-plus-plus.org/) which has a generic “LISP” option. Of course it does not highlight Nyquist specific key words, but it recognizes enough LISP keywords to be useful.
It also shows matching parentheses (they turn red when you click on the one),
which as you know, is very important with XLisp.
It also has an editable keyword list, which you can tailor to your needs.
Haven’t used that feature though.
The standard one, suits me just fine.
If anybody wonders, VSCode support for Lisp using the lightweight extension (by Yasuhiro Matsumoto) called just Lisp is about par with Notepad++'s. VSCode’s is merely derived from a similar one for Sublime though, and hasn’t seen much development lately… Although they’ve just fixed the let* issue.
There are more heavyweight Lisp add-ons for VSCode, but they’d don’t add much for Nyquist development because they depend on a specific Lisp execution engine for the advanced features. And Nyquist is not among the supported ones.
I prefer Notepad++ for quick hacks because it loads instantly, but VSCode has much better git support. In the latter, you can roll back just some bits of code as you’re typing straight in the editor because it continuously diffs against the committed version and highlights on the margin the changed bits as interactive snippets that can be viewed inline as diffs, so for “minimal changes” hacking in a FOSS context an uploading to github it’s superior to N++, in my experience. A bit off topic, but here’s what I’m talking about; normal view of changes while editing in VSCode, while in a a git checked-out repo
Foldable inline diff snippet, one click away.
But neither N++ nor VSCode holds a candle to emacs for quickly customizable Lisp indentation rules. (See the bottom half of this page for what I mean by that, i.e. at least custom rules for special forms vs functions.) Emacs has had something like navigable diff snippets for decades, albeit not inline (ediff) and something like that for git with magit too, but magit is rather the “firehose git porcelain” version rather than the snazzy, streamlined approach that VSCode has to git, which for me strikes the right balance in terms of info offered without drowning you in git minutia. (You can install GitLens in VSCode if you want super-detailed git info inside VSCode.) Also emacs can’t control Adobe apps like VSCode can; Adobe pushed their CEP extension debugger onto VSCode nowadays, although that still lacks some features compared to their older ExtendScript Toolkit, which is a sort of IDE for scripting Adobe apps.
There’s one big nuisance in VSCode though, when using git, despite its other nice git features; can’t use any speller for its commit message box. Some APIs snafu because MS left spelling to 3rd parties in VSCode. Speaking of which, cSpell doesn’t have any dictionaries for Lisp, but it does fairly ok despite that. Again API fragmentation as the speller uses something completely different from the syntax highlighter.
