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.
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.