A13: I am officially creating The NexTcl Project (https://github.com/NexTcl-Project ). I have a dream (as Martin Luther King would say)... or rather, a goal I want to achieve: I want to improve the developer experience and the tooling around Tcl. We all know that Tcl is a simple and wonderful language, but we have to show beginners that too. You (or more likely all detractors) might argue that Tcl has gone past its prime time, but I have several contraexamples:
Why not Tcl? Objectively speaking, most if not all beginners in a programming language will gravitate towards having autocompletion, code suggestions, symbol renaming etc. All of these things usually happen because of LSP servers which makes it easy to have a single server communicating with all LSP-capable editors instead of supporting every single editor individually with various levels of support. As it stands, people gravitate, whether we like it or not, to Visual Studio Code.
As a case study, let's go to Visual Studio Code right now and see what options I, as a beginner, have for Tcl support. I go to the extensions page, write "Tcl", now let's see what the landscape is.
See the problem? As a beginner, I am really stuck with an old experience. Vim isn't better, although it has Expect and Tcl syntax highlighting OOTB. Emacs also has it (and from my experience the syntax highlighting is almost accurate, here a tree-sitter Tcl plugin). Luckily, lewis6691 is working on it: https://github.com/lewis6991/tree-sitter-tcl . The truth is that the tooling is old and antiquated. This is also a detriment to OpenACS or Fossil or SQLite users too, as well as people who use Expect.
The second thing that I feel Tcl is missing is a proper package manager and build system (okay, maybe not build, I might experiment with compiled Tcl too, but that's besides the point). I have found myself in situations where I have to dig for certain packages that people over here have created, but either nobody has bothered to put together or, worse, are dead now. It's a real shame because Tcl has a rich history and we should do our best to preserve it for future Tclers. My project is ambitious, but I feel like it's going to benefit the language in the long run. We can't go back to ActiveState and Komodo Edit, but we can dream bigger, we can envision a future where you can use the same server across all major IDEs and editors. We CAN do it!
I have learned many languages that are otherwise great, but suffer from a lack of (organized) documentation, lack of advertising or the community is just slowly letting the language die. For me, the hugest contender is Pascal and Oberon, but Tcl fits the description too. I don't want Tcl to be like this, especially when this wiki is quite active (so Tcl still has some heartbeats left).
I am going to also make a separate Mastodon account to promote all things Tcl-related and maybe make a bot that dumps topics from comp.lang.tcl. I truly believe that this language *can* gain new followers with just enough love given to it. Heck, even Perl can do it (I'm living proof!).
I think I'll coin a temporary motto: "NexTcl: Scripting Tomorrow, Today!". I'll deal with the LSP first and the necessary Visual Studio Code extension and make sure that works first and then maybe we can discuss what to do with the other rough edges of Tcl support.
What do you think? :)
NR - 2023-08-06 10:14:58
Excellent idea !!
A13: Well, I can always go with using a better or more descriptive name such as "Tcl" (although I feel that would be a plugin that only a big company like ActiveState or Xilinx would dare making... also rashwell took that name, slightly), "tcls"/"Tcl Language Server" (I have "clangd" and "Perl Navigator" as examples) or just "NexTcl" (but that would imply a different dialect/language than proper Tcl).
I considered forking rashwell's extension, but... how can I put it... the repo simply doesn't exist, it's been deleted some time between 2016 and 2023. I am not sure if this is the only remaining copy: https://github.com/bkmeneguello/tcl . I could even ask the Tcl/Tk Core Development to let me post a package on their behalf so people can see that it's The Official Package(tm), although that's not required. There is, it seems, a way to transfer ownership. I'll contact him and see if I can at least make him point to a normal repo that I can fork or something, since for all intents and purposes the package is abandoned (and this is supposed to be the first package beginners consider...). But my purpose is to make the LSP so it's general (and I'd really love if Tcl/Tk Core Development would support me). You know, I am surprised FlightAware or ActiveState or Xilinx didn't make a package for VS Code already since they're companies with more resources than I'll ever possibly have. FlightAware would be the most likely contender since they have a Tcl Bounty Program already. Oh, and while searching I discovered that people have decoupled Tcl and Expect in the VSCode sphere, so I have to win over the Expect crowd too (by which I mean only https://marketplace.visualstudio.com/items?itemName=bdavs.expect which only supports colorization and snippets, that's honestly enough for many use cases).
Update: https://marketplace.visualstudio.com/items?itemName=bitwisecook.tcl seems to be worked on even nowadays and has a pretty good codebase already and has a decent amount of downloads (46K) I can perhaps work together with bitwisecook (or even convince them to transfer the repo to my organization, but that would happen after I have a decent LSP and formatter in place). It's also the best rated extension and has a photo unlike rashwell's extension. Also unlike rashwell's extension, bitwisecook's has pretty good snippets in place, so it would be pretty bad if I reduplicated that effort.
APN I am in full agreement with the your goals - improving the tooling around Tcl, a better newbie experience, and more effort on promoting Tcl outside the core community. Those of us with that mind set are too preoccupied with the core Tcl effort and extensions with Tcl 9 coming up. Some of what the issues you brought up have been discussed cursorily at the monthly online meetup and it would be a good discussion to have at the next one if you can join in. IMO, the immediate focus should be on a real LSP as that will have a major impact in better tooling and unlike packaging will not suffer from extraneous factors. A proper implementation will have no problem relegating the stop gap solutions for VS Code today.
By the way the name NexTcl name is likely to confused with next-scripting which is a Tcl extension fairly commonly used.
A13 I agree :) I see the meetup is extremely close (in 2 days) and it's Europe's turn, so I think I'll join. As for the naming, I am sure it's going to be much more confused with Nextcloud than with next-scripting. Besides, you'd need to know Tcl already to know about NX so I don't think it's an issue (heck, *I* didn't know about NX and NSF, thank you btw).
APN You were asking for Tcl parsers for use with LSP. There are several options - see tclparser (a C extension but uses Tcl's own parsing engine), ptparser, parsetcl, A Tcl parser in Tcl and probably others. The treesitter Tcl parser you mentioned might be better suited though (assuming it works well). Also, I had started working on a "completion" package which may be useful as a starting point for completions - see https://github.com/apnadkarni/tcl-repl
A13 Those are definitely useful, thank you! I looked at the treesitter plugin and it's not that useful for me. I am not dealing with syntax highlighting per se, that problem has already been solved within the community. I think tclparser and also what XOTclIDE seems to have going on are my best bet. As for completions, your package seems interesting, I forgot that I should also parse namespaces and that's gonna be a lot of fun. :P
chrstphrchvz - 2023-08-11 22:23:28
See the Language Server Protocol wiki page for previous Tcl LSP efforts.