I'm researching the history of extensions in text ...
# thinking-together
r
I'm researching the history of extensions in text editors (e.g., like VSCode extensions https://marketplace.visualstudio.com/). I generally consider TextMate (released 2004) as the starting point of an era of text editors built around extensions. That for example makes Sublime Text, Atom, and Visual Studio Code all "TextMate-likes" in that their built around significant amount of functionality coming from share-able extensions. (Note that I'm making a distinction between extensible text editors, à la Emacs, and text editor extensions that are easily share-able packages/plugins/bundles, etc...) Other note-able milestones in the text-editor-extension era are the introduction of Pathogen.vim for Vim in 2008 and Package.el added to Emacs 24 in 2011. Light Table and Atom, released in 2012 and 2014 respectively, are also notable as the first popular web-based text editor built around extensions. Being web-based greatly increased the ease of writing extensions that involve GUI elements. I'm curious to hear about what others consider important milestones for extensions in text editors? For example, I'd love to hear more about any prior art to TextMate? Before package managers for Vim and Emacs, how did people share syntax highlighting files? And were there examples in other text editors that went beyond syntax highlighting, e.g., did any text editors prior to 2004 have a plugin system that could do more than just add syntax highlighting, like adding commands?
e
have you seen the wikipedia article? https://en.wikipedia.org/wiki/Syntax_highlighting
r
Thanks for the links! I skimmed these and I saw some interesting info about syntax highlighting but I didn't catch much about extensions in general. Did I miss anything important about extensions?
a
Acme's UI is largely controllable via its filesystem/9P API, and any non-trivial behavior your invoke in it (formatting, building, etc) is implemented outside Acme itself using that API. Extensions are just programs in your system path that take advantage of the API. This is the best Acme intro, and this describes the extension API, and this is a random collection of extensions that I refer to occasionally. I use Acme daily and have written several extensions, so AMA.
k
Emacs before ELPA: add-ons of all kind were distributed as text files containing Lisp code. You had to copy them to a directory on Emacs’ load-path. And install dependencies manually. It took more experience and more time to install add-ons, so beginners often hesitated to start.
r
@alltom Awesome, I’ve read a bit about Acme and it sounds very interesting, love the approach of use the shell to flesh out functionality (that’s another characteristic of TextMate and to some extent, Vim), as well as the reliance on the mouse in a terminal program (I personally use Vim/Tmux, and I love using terminal mouse support with these programs). I’m curious what “system path” means in the context of Acme, is that like a directory that it looks for extensions in at startup?
a
It’s literally $path. :) When you execute text anywhere in the UI, if it’s not a built-in command, it shells out, setting environment variables in the child process containing the ID and file path of the current window. stdin and stdout are mapped to the current selection depending on context, and the window ID can be used to connect to the Acme instance for more invasive manipulation, like managing windows or listening for events.
🙏 2