Hey all! For the past week or so, I’ve been working on improving the syntax highlighting of the Emacs inform7-mode written by GuiltyDolphin (it already had sufficient imenu navigation and auto-indentation as well). My goal was to provide syntax highlighting that gives better guidance as to what counts as proper Inform phraseology than what the plugin (or even the Inform 7 IDE) previously provided. I did this by highlighting recognized keywords and keyword-phrases, so that you can tell what is phrasing that Inform 7 understands, and what’s phrasing it doesn’t.
I think this is important, since Inform 7 attempts to make correct syntax look as identical to natural language as possible, but does not recognize all natural language (obviously), which means that the line between correct Inform syntax and incorrect syntax is hopelessly blurry typically, since both correct and incorrect syntax can look like gramatically correct English.
I subsequently, even after doing all that work, found that TADS 3 suited me better than Inform, so I did what any reasonable, completely sane, girl would do, and, uh… updated the tads3-mode available for Emacs too. That one still has some line indentation bugs I’m trying to chase down, but I’ve already improved the syntax highlighting a ton, and more importantly, updated the plugin so it’ll actually run without errors or crashing on modern (post v24) Emacs, since there were some breaking API changes in between.
For anyone who’s interested, here are the plugin pages (their readmes have screenshots too):
That’s great! I’m the lax custodian on TADS 3 mode. I recently tried to rewrite TADS 3 mode from scratch, but balked at how to get indentation to work cleanly and robustly (templates and interior objects are a pain).
I’ve seen the Github issues you posted and will look into them, but am also happy to take pull requests. Or even hand over the reins.
Oh hi!! Sorry about the issue spam, I’m actually making progress fixing those issues myself in preparation for a PR or something, I just needed somewhere to keep track of what I needed to do, and was hoping you might be able to help a bit.
I’d be willing to take over the project completely instead of doing a PR too, if you’d be okay with answering a few questions here and there — I’m new to both TADS and writing Emacs plugins, so there are some things I’m gonna need a bit of help with. Right now I’m just trying to get brace indentation to work.
I think the top selling points of Emacs (for me) are these:
Dynamic: Emacs is THE most dynamic development environment you will ever use. 90% of it is written in its own extension language (which is a Lisp, adding to the dynamicness), so almost the entire inner workings of the editor are easy to inspect, modify, replace, and extend, so you can change behavior of everything even down to the most basic elements. And since it’s a dynamic interpreted lisp, these changes take effect immediately. You can execute any line of Lisp code in any buffer and it’ll be run within the editor’s context, and it even has a REPL built in. (Compare this with neoVim, where you can script your editor using Lua, but it really has no access to the internals, only the few specific functions and hooks the programmers specifically made accessible from the C codebase, most plugins work by emulating keypresses instead of directly talking to the editor, and you can’t live reload).
Flexibility of an Editor, Power of an IDE: Because of this, the plugins available for Emacs are extremely powerful. You can give Emacs power equivalent to modern IDEs with (if you’re using Spacemacs or Doom Emacs) usually about a single line of configuration, and you can do this for hundreds of languages instead of a few, and it’s embedded in a whole ecosystem of packages that fit together and add far more customization and features than IDEs have. Additionally, Emacs is far faster and lighter weight than most IDEs such as Visual Studio, JetBrains, Eclipse, etc.
Mature: The community is ancient (the editor has been around in some form for fifty years) so there’s a plugin for everything, usually multiple, often well-maintained and powerful. Likewise, the actual plugin development tools built into the editor are excellent. Check out Rx Notation for an example.
Modern, Good Architecture: It’s been continually renovated, not just to add new features, but to make it have a more modern architecture. So for instance it can just-in-time compile Emacs Lisp to make plugins (and the editor itself) faster, has a highly multithreaded architecture so nothing ever blocks the editor if it’s implemented sanely, and the text display isn’t limited to just text — it can display inline images, SVG graphics, and GUI elements that are clickable, as well as multiple sizes and fonts of text right next to each other in the same buffer.
VIM: It has the best VIM emulation of any editor ever, partly because Doom Emacs and Spacemacs and the like even extend those keybindings to all of the rest of the editor and the plugins, so you can always stay on the home row. So if you like that, you get to have the full power of modern IDEs (and beyond) for many languages, while not having to sacrifice near perfect VIM keybindings.
Due to all this, Emacs tends to be a far more powerful, flexible development environment than anything else.
Sounds cool! I’m going to look into it. Maybe you’ll make a convert of me
I will say though, I rely pretty heavily on the symbol outliner/jump to symbol in the T3 ext. for VSCode… can eMacs do that or would something have to be developed for that?
Side note, not sure if you know or care, but you don’t need to preface T3 methods and properties with ‘self.(meth)’, even if you’re working in a class context. I learned programming through T3 and was mildly ticked off when learning Python and finding you had to type ‘self’ every time you turned around…
Hey, I just noticed the ELI in there… are you using my EventListItem extension?? I’m super tickled to find that it has seen the light of day! I was kind of imagining it would just sit buried in a dark repository till the end of time…
Hey, I just noticed the ELI in there… are you using my EventListItem extension??
oh my god what a coincidence! Yes I am! It’s super useful actually, I really like having it. Thank you for writing it! By the way, I found it because it’s included with adv3Lite as one of the extensions it comes with by default, so I definitely don’t think it’s been buried, it’s being regularly distributed to anyone who uses adv3Lite!
The tads3-mode plugin I’m working on actually does have something like that. I’m not sure if it’s exactly what you mean, but it provides an outline of all the object, class, function, and modify/replace declarations in your current file, and you can fuzzy search and jump to them as well. (One of the things that’s great about DOOM Emacs is that it makes even heavier use of fuzzy command palettes than even VS Code does, it’s very convenient). There are also keybindings to jump to the previous and next objects. Here’s what the outline looks like:
Sweet, I didn’t know Eric was distributing ELI with the library! I just assumed it was an optional module stuck in an archive directory. Glad to hear! My WIP relies on it heavily, because I have a game-long sidekick that provides most of the atmosphere. One other class I’ve made/used heavily is very simple but very handy, simplifies/encapsulates the use of Daemons and Fuses, particularly ones that turn off and on a lot. I was thinking of reposting it on the forum because there are a lot more active T3 users on here now (a whopping six or seven!) than when I first posted it…
Just to be clear, I functionally wrote the ELI extension, but Eric made some implementation tweaks and we collaborated to package it for adv3Lite… so it’s his extension too…
I just checked out the VSCode TADS 3 extension and just so you’re aware, tads3-mode is nowhere even remotely close. It could be, if given an equal amount of development time, but the VSCode extension uses a language server and so is going to be fundamentally, categorically better ununless I switch tads3-mode to an LSP as well. The equivalent to IDE language support I was talking about was for languages like Python, C++, Rust, etc.
Here’s a customization I make to inform7-mode, 'cause I figure one can’t afford not to see the syntactically-significant hard tab characters, the silent killers.
I’ve archived my TADS-3-Mode-for-Emacs repository and bequeathed future development to @alexispurslane. I’ll try to contribute to her efforts, but the TADS 3 mode is in her very capable hands.
You are welcome to use the LSP server in case you would like to expand your extension into an LSP client and get its features for free. My guess though is that you don’t want to depend on a server running on nodejs while running emacs. In my Imagination that just doesn’t sound like a mix Richard Stallman would think fondly of even so, it would be a cheap way to get an outliner, go-to-references etc.
Thank you, I have been considering that actually. I’m not sure yet but in the long run I do think setting up an LSP would probably be my best bet. My hangup is, first of all, how to isolate it nicely from the vscode extension (I assume that’s what you’re talking about) and second of all, a deep and abiding dislike for JavaScript and Node lol.
I could try creating server standalone binaries for different OS:es that you can dynamically download from the releases page depending on what OS the client is running on. That wouldn’t require nodejs on the user’s part. I need to investigate it further though. I’m guessing it will be plenty of binaries and not the most maintainable solution. But somehow feels better than downloading the server folder and running “npm install“ as a part of installing the extension. Even if it is just once.
even so, it would be a cheap way to get an outliner, go-to-references etc.