That's interesting. Thank you for both the work and the observations Ricardo!
It's interesting to hear, but maybe not surprising, that LSP seems to be more oriented around a static programming mindset than a lispy REPL-oriented development environment. I guess it will be, as you say, more dedicated work to get proper Guile support into these editors aside from "just using LSP", but that wasn't obvious to me until I heard of your experiences! - Christine "Ricardo G. Herdt" <r.he...@posteo.de> writes: > Hi Christine, > > I started writing a Guile LSP server a while ago > (https://codeberg.org/rgherdt/scheme-lsp-server). Like you said it is > incomplete, but I got following features so far: > > - show signature > - show documentation > - autocompletion > - jump to definition > - show diagnostics > > There is an open issue to integrate it into Guix: > https://issues.guix.gnu.org/60286 > > I also wrote a simple client for VS Code: > https://codeberg.org/rgherdt/vscode-scheme-lsp > This extension is focused on LSP support though, sort of a proof of > concept. Syntax highlighting, REPL support etc could be integrated > with other extensions. Or someone could implement a more involved > extension to integrate these features, like what Magic Racket seems to > do. > > Honestly I have mixed feelings towards LSP. It's kind of a different > mindset compared to traditional lisp editors: you get a language > server that typically analyses the project statically, providing > information regardless of the user's interaction with the REPL. My > implementation relies, at least for Guile, on Geiser, so it works by > interaction with a running Guile instance in the background. It might > be enough for users coming from other editors, but I still prefer the > way Slime/Swank works, where the REPL is the same image that provides > information to the editor. > > Regards, > > Ricardo > > Am 27.09.2023 21:07 schrieb Christine Lemmer-Webber: >> There's a long thread on guix-devel which is related and touches on >> many >> things, but I thought I'd narrow in on this one thing. >> Has anyone had a "good" experience programming with Guile without >> using >> Emacs? If so, what was your development experience like? >> Furthermore, what's the right direction to making non-Emacs users >> have >> as nice of an experience as Emacs users do? Racket, for instance, has >> lovely support in vscode with "Magic Racket". What's the right path to >> recommend for the present, and what's the best path to improve the >> future? LSP? There are a few incomplete implementations I think but I >> haven't tried them. >> (Let's leave aside whether or not everyone should be using Emacs, or >> other approaches to make Emacs easier for newcomers. This thread is >> specifically about making Guile useful to people who already have a >> tool >> they like and present experiences.) >> - Christine
