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? :)
APN 2026-03-15 tcl-lsp is a LSP server for Tcl with support for many editors (VS Code, Emacs, Jetbrains, Neovim and more)
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.
gold 3/14/2026. Added categories, so can find message in Wiki.
| Category Numerical Analysis | Category Toys | Category Calculator | Category Mathematics | Category Example | Toys and Games | Category Games | Category Application | Category GUI |
bitwisecook - 2026-04-08 13:07:31
I'm the author of https://marketplace.visualstudio.com/items?itemName=bitwisecook.tcl-lsp / https://github.com/bitwisecook/tcl-lsp
For context, I used to work at F5 Networks, and have deployed a lot of Tcl including, but not limited to, iRules.
I started this project to get some ideas out of my head, I'd made little versions of this sort of thing over time but never a full LSP and never a full multi-pass compiler. I've heavily used Claude to help build this, it's currently Python but I'm toying with both Rust and C++ ports. The core compiler, structures, and a lot of the infrastructure are written by me, reviewed by Claude. In the case of command definitions, I've written some examples then had Claude fill in the blanks from manpages / vendor's online documentation. The quality in there duly varies. The front ends (vscode and other editors) are all vibe coded, I find writing that stuff tremendously tedious myself. Having AI do the bulk boring stuff has made this whole endeavour possible.
This is more than just an LSP, it's an MCP, a Claude Skill, github copilot tooling, cli tooling, a full multi-pass optimising compiler that targets WASM, an admittedly poor Tcl VM implementation, an irule testing engine and harness. There's lots of documentation in there, again, some of it written by me, quite a bit bulked out with Claude and needing me to review it.
The compiler today is:
What I could do with is folk trying it out on their projects, raising issues for things they've found, command definitions that don't match reality, warnings/diagnostics/optimisation warnings misfiring, tooling issues. I'm trying to make this much more robust and helpful.