|
you write: > I have a radical idea which might not be a good one: > 1. A "Full" display of W x H characters (the Sharp display or whatever you replace it with) > 2. A "Fallback" 1 or 2 line display (2nd line reserved for editor info / UI?) i've thought about this, especially with respect to e-ink screens. some versions of the barnes & noble nook work this way: there's a small color lcd touchscreen for interactive stuff, and a large black-and-white e-paper display for bulk information display. i thought that a small reflective lcd like cheap scientific calculators use would be enough for a line or two of text, permitting rapid interaction without putting excessive demands on the e-paper's slow and power-hungry refresh but i think that sharp's memory lcds are so much better than e-paper that there's no real benefit to that approach now > A single 1-bit editable line is so hard to work with that ed[2] isn't even installed by default on many Linux distros. However, people did once got real work done with it and similar tools. it's not that command lines are hard to work with; it's that ed's user interface is designed for 110-baud teletypes, where erasing is impossible, and typing out a 10-character error message means forcing the user to wait for an entire second, so it's preferable to just say '?\r\n'. user interfaces designed for more capable hardware, such as an adm-3a connected over a 1200-baud modem, can be immensely easier to use, without abandoning the command-line paradigm. you'll note that ex(1) is installed by default on every linux distribution except alpine (which does, oddly enough, have an ed(1)), and i know a programmer who still uses it as his preferred editor, preferring it even to vi i've certainly done plenty of real work with tcsh and bash, where the primary user interface paradigm is editing a single line of text to your satisfaction, submitting it for execution, meditating on the results, and then repeating. not to mention the python repl, gdb's command line, octave, units(1), r, pari/gp, sqlite, psql, swi-prolog, guile, ngspice, etc. i like direct-manipulation interfaces a lot, but they're harder to design, and especially hard to design for complex problem-solving activities. it's just that correcting a typo a few words ago isn't really a complex problem-solving activity, so, by my lights, even a relatively dumb
direct-manipulation text editor can beat a command-line editor like ex most of the time.
especially if their bandwidth to your eyes
is measured in megabits per second rather than kilobits per second |
On my system, it seems to be set up as an alias of vim ("Entering Ex mode"). Huh. A bit more reading after that has been an interesting historical detour.
> i know a programmer who still uses it as his preferred editor, preferring it even to vi
I've never tried ed before this comment. Others might see it as strange and clearly teletype-oriented, but I think it's refreshingly explicit about every action taken. Even more than ex, it's a vim ancestor where commands and state are persistently visible instead of being hidden.
Thank you for mentioning this, but now I'm a little worried I might start wanting to use ed too.
> i've certainly done plenty of real work with tcsh and bash, where the primary user interface paradigm is editing a single line of text to your satisfaction, submitting it for execution, meditating on the results, and then repeating.
I think you've hit on something important here. Web-oriented workflows with live reload (and Flutter[1]) inherit this. I think it means the form of the REPL itself isn't what we should be focusing on, but easy iteration and maybe cached results to save power and time.
On the topic of accessibility, do you have any opinions on Hedy[2] and whether a long-lived, low-power system might have room for something like it? The site is annoyingly JS-filled, but the idea is interesting: a language where the names in the symbol table are more overtly a user-localizable value.
[1]: https://flutter.dev/
[2]: https://www.hedycode.com/