One thing that bothers me about new code editors/IDEs is that their developers really don't do a good enough job researching and deriving inspiration from the editors that already exist.
For example, I have yet to find any modern editor that draws inspiration from the brilliantly designed ideas used in Plan 9's 'sam' and 'acme' editors.
For example structured regexps, 3 button mouse chording, and the 'plumb' feature thats basically a context-aware, smarter version of a unix pipe between two executables.
I mean i can go on and on but another thing that i find absolutely annoying about newer editors is that they all use Webkit as the base of their apps core foundation.
This makes it irritating to consider trying to make changes to the code that I believe would overall improve the editor and make it more useful. (at least as far as im concerned)
I can literally make a list a mile long of things I like in other editors and wish i could see condensed into one ultimate code editor to supplant all code editors that had come before.
Given the amount of time that people spend using editors, you think it would be worth some kind of wide ranging academic review article summarising the history of this area.
Typing only on the keyboard can be very nice for posture, but I feel that Vim users may think slightly differently if people invented a better keyboard with a pointer device attached.
Then you wouldn't be "taking your hands off the keyboard", you'd just be engaging in a different motion.
Thinkpad external keyboards, both USB and bluetooth - currently typing on one of the former, with one of the latter in my jacket pocket for use with my android tablet.
Can you recommend a place where I can read about these "plan9 paradigms"? I have an interest in it from a design perspective, but don't quite have time to read the source code.
Acme was different to the 'sam' editor and most other Plan 9 programs up to that point (aside from its predecessor, "help", a similar system that was replaced by acme).
Look up a YouTube of somebody using it and discussing its features. Basically you could mount computational resources like cpus/ram/network/etc from an external resource server. It also had a graphical equivalent to the Unix pipe between applications.
I feel like your point was missed in the sibling comment. An academic review of editor history would be fascinating, and if it thorough enough might even inspire editor authors to adjust their philosophy.
I guess if it was thorough enough and tried to synthesise some kind of framework for analysing these things there might even be a PhD in it for someone?
Those brilliantly designed ideas used in Plan 9's 'sam' and 'acme' editors were taken from how Mesa XDE, Mesa/Cedar and Oberon used to work across the whole OS, not just the text editor.
So a proof that even that point needs better research. :)
Since we are on a Lisp thread, same applies to those that just bother with Emacs, eventually SLIME, withouth ever spending one second with actual Common Lisp IDEs.
One of its strengths was discoverability. Jeff's son Aza iterated on a number of the ideas from the Cat with Enso and Ubiquity but those efforts were not specific to an editor.
It’s been years since I first heard of sam and acme. Perhaps I should try them. Is it possible to run them in MacOS/Linux/Windows? Or perhaps a virtual machine?
BTW, does chording work well with mice where one of the ”three” buttons is the scrool wheel?
Clickable scroll wheel works fine, it is mapped to the same button.
I can't, however, imagine left+middle chord on modern laptops, there are not that many laptops (mostly ThinkPads as far as I can tell) that have three physical mouse buttons.
That's true, but with UX, there are sometimes trade-offs to make around discoverability and productivity.
A more discoverable UI may take a greater number of steps to perform. If the application is used rarely or briefly, that's a good trade-off. But if an application will be heavily used by a user who is incentivized to learn the tool, then their total productivity matters more since it amortizes over the lifetime of their use with the tool.
Text editors definitely fall into the "heavily used" bucket, so a good user experience might mean "you gotta read the manual, but once you do you can go 10x faster".
They're basic verbs you use to interact with text; not a full command. E.g instead of executing "format document" from a menu, you select the document with the left mouse button, and then middle click on the word "format". This executes the "format" command on the selected text. Somewhat like running gg=G in vim.
There isn't much to it. Windows, for example, implements plumbing as the ability for the user to double-click, in an Explorer window, on, say, a PDF file and have it opened automatically using the default PDF viewer; the command-line equivalent is the 'start' command.
Any idea what happened to Chris Granger and the original LightTable/Eve plans? If I am not mistaken they took some VC money right? How did that work out? Would be really interested to hear their story and lessons learned.
Aside from that I was a big LightTable fan and really enjoyed its inline instarepl and other features, so it is definitely great to see that LT is not completely forgotten! Kudos!
I just watched a recording of a talk Chris gave a few months ago. It's a retrospective about building Lighttable/Aurora/Eve. If you were interested in the project(s) I suspect you'll find it interesting.
Thanks, will definitely watch!
LightTable and its instarepl definitely inspired me but as time went I somehow lost track of the project. Inspired by LightTable I even created an instarepl for java and clojure workflows in my pet project (titanoboa.io). So definitely will watch his talks as I might even face similar struggles (albeit in slightly different area/industry).
I think the Light Table guys inspired many people to work on this stuff. As an investor of LightTable/Eve mentioned in the video I was pretty inspired by these guys too. I am now working on my own Cloud editor, at yazz.com
Hi, author of the post here, LightTable is cool, right?
Yeah, I'm trying to get the inline code evaluation and instarepl features working on new updates.
I'm glad you asked it. It's in my future plan. It shouldn't be much hard. I would like to pursue it after of course getting LT stable(and maybe with some funding).
Pratik will be able to talk more definitively about this, but the LightTable project is seeking maintainers. If you'd like to help out, please consider joining Code Shelter[1], this will enable you to join LightTable (after talking with Pratik) and potentially a slew of other projects that need help[2].
Back when i learned about Lighttable years ago i found the instant preview and live editing of running code very cool!
I just realized thats basically what we already do today: i use WebStorm and my webapp hot-reloads any code i type. If i wanted i could even rewind the app state. And when i enable JS debug in IDE its like inception and matrix-view combined, but surprisingly userfriendly still.
The difference is that LightTable gives you inline previews of individual expressions, not just the final result. This is really nice to have for debugging why the final result isn't what you expected.
Maybe starting a flame war, but isn’t this exactly what GNU Emacs & SLIME and for other languages, REPL, LSP/DAP protocols for? While I appreciate his/her effort (I appreciate everything related to developer’s ergonomics), I’m not sure what differentiates lighttable. Maybe I’m missing something? Can anyone explain?
Pretty much the only advantage LT ever had over Emacs was the GUI layer unburdened by decades of development and compatibility with TTYs. In other words, the hope for LT was that it will allow a wide range of scriptable graphical effects. While never explicitly stated, if you read early posts on LT you'll see its feature list is basically 80% Emacs, 10% Smalltalk and 10% eye-candy.
Many (five?) years later, from what I gather, LT has the eye-candy - the rest is perpetually "under construction". It would be hard for it to be anything else, though, as the main developers jumped ship a few years back to work on Eve (which, as a karmic retribution for all my crushed hopes for LT, also tanked and died recently).
Emacs may be less pretty than newer editors, and lots of its APIs are decades old at this point, but it's still the only self-documenting, easily discoverable and extensible editor this side of Pharo and Squeak, which can be used in practice (due to a giant amount of plugins which bring it up to modern standards) for almost any task.
TLDR: LightTable as a powerful editor for programmers is dead - it may be still possible to revive it, but its scope would have to be massively scaled down. It's not going to compete with Emacs & co. anymore, which is a shame, because when it started it had the potential for this.
Oh, if LT is also advertised as a 'scriptable/extensible' editor that can accomplish 80% of GNU Emacs with eye-candy, that is actually a pretty good advantage...
One of the biggest complaint of GNU Emacs (at least for me) is the super bad defaults and esoteric GUI that doesn't mix with other apps because of it's tty-inspired nature...
If LT can become a GUI-first Emacs-competent editor, it will be big! :-)
The "core" - ie. Elisp code which is preloaded/included in the final 'emacs' executable (as a memory dump of interpreter state) it's less than 80kloc of Elisp. Emacs ships with ~300kloc of "standard" libraries and applications written in Elisp (keep in mind: it's 300kloc of a high-level, fairly expressive, Lispy language - so it translates into a giant pile of features). Further 400-500kloc of Elisp is from add-on packages available via a built-in package manager. Actually, there's more code available, I just counted the plugins I have installed locally.
IIRC Emacs' C code numbers ~300kloc and includes both bindings to low-level, systems and GUI functionality, some parts of standard Elisp library (writen in C for performance), as well as Elisp virtual machine, byte-compiler and so on. No JIT yet, but at least there's threading support (take that JS :P).
Starting from scratch has many advantages, but it doesn't really work with programs and systems large or complex enough. Otherwise we'd be using a fresh OS every five years instead of working on one of the 5-6 OSes which were all created 30+ years ago.
It's probably quite substantial, since it runs on several platforms, has a GUI on some, etc. Most of the C code is probably used, but the larger part of the Lisp code is modes (tools, games, apps, ...).
For example, I have yet to find any modern editor that draws inspiration from the brilliantly designed ideas used in Plan 9's 'sam' and 'acme' editors.
For example structured regexps, 3 button mouse chording, and the 'plumb' feature thats basically a context-aware, smarter version of a unix pipe between two executables.
I mean i can go on and on but another thing that i find absolutely annoying about newer editors is that they all use Webkit as the base of their apps core foundation.
This makes it irritating to consider trying to make changes to the code that I believe would overall improve the editor and make it more useful. (at least as far as im concerned)
I can literally make a list a mile long of things I like in other editors and wish i could see condensed into one ultimate code editor to supplant all code editors that had come before.