How familiar are people here with Acme, the “integrating development environment”? Its extension mechanisms are well thought-out and I think it’s only incidental that the lingua franca is plain text and that its affordances for inline feedback are abysmal. This is the best short video introduction, in which its extensibility features prominently: https://research.swtch.com/acme

I like the text editing consistency, but wish there were a way to do it without such heavy mouse use, ergonomically. That's what moved me towards emacs and away from IDEs.

There are definitely ways. If you feel comfortable with your hotkeys for marking text, you’re not far from a UI that can act on it.

Well, I hope their software is better than their bird catching contraptions

Acme is similar to Oberon's editor, in that you can execute text on the screen easily. In this regard MPW (Apple's original development environment) also had this ability; it was very convenient and powerful. I would say that from the demo you Acme represents the pinnacle of 3 button mouse integration; where each button is used heavily, as it presumes exactly 3 buttons. Unfortunately Apple insisted on 1 button, and MS used 2, so a 3 button mouse although in existence is hardly guaranteed, and in laptops would be DOA. Many musical instruments are basically 10 button devices, and indeed one can make beautiful music with these kinds of devices. But perhaps Jobs was correct that the single button mouse is the easiest for a beginning user.

Acme is a classic. Runs with core ideas.

@Edward de Jong / Beads Project personally not a huge fan of calling regular folks "dumb" for preferring a simple interface to a device that historically has been caught up in all sorts of elitist and hostile attitudes against users (i.e. you're not a real programmer if you use assembler! you're not a real programmer if you use a compiler! GUIs are for suckers!). There's a lot of value in learning hard to learn things, and as you brought up a good musical instrument is a prime example of that(as is reading, writing, math, and science, etc). But, life is hard, and we can't spend all of it learning all of the hard things. The onus is on the computer to prove to users that a harder interface is worth mastering. If people decide not to do that, there's nothing dumb about it. Probably just means they have a lot else going on their lives. Technologists -including myself- often decry how "diluted" computing has been between what the pioneers imagined and what the masses have adopted. Personally I wonder, especially in Apple's case, if what happened wasn't so much a "dilution" as it was a "de-elitising" - a necessary separation of computing from toxic attitudes and terms like "dumb users" for it to spread among regular folks. As a community, I'd like to think the peeps here are interested in elevating the state of computing for everyone, and describing a subset of those people, who just happen to have a lot going on in their lives besides obsessible mastering technology they have good reason to be skeptical of, in hostile terms like that, I think is counterproductive.

In Apple's case, they eventually found out that right clicking is necessary for context menus, and Apple users quite often struggle to learn how to right click via ctrl-click which is the synonym for right click. Apple has a nasty habit of going too far in simplifying things to pursue some sense of design purity. Witness the elimination of the USB A ports in the latest MacBook pro which for a 2400$ minimum laptop is ridiculous not to have a USB type A port if only for memory sticks. Three buttons is clearly hard for users to remember, but MS did very well with 2 and windows users have very few problems with it. So many products employ contextual menus now that Apple's design choice is backfiring to some extent. However, in the touch world, the right click is horrible and i built a ton of mobile products that avoided it like the plague. There is a gesture for it, but good luck getting people to remember it. Long press is also not a winner because what is long to some people is not long to another. There is a best-selling book series called "... for dummies". Evidently millions of people self-identify as such, and ignorance is a fact in some users. One of the four noble truths of Buddha is that people are born naked and ignorant and rise from that state. People write things with a grade level in mind so as to reach a wider audience, and in my packaged software products which have free telephone support, i do my utmost to make things as crystal clear as possible because i don't want to get their call. I have a large number of seniors using one of my products, and i am one of the few people making software designed for poor eyesight. I can't tell you how many products use sub 9-point type in them. I use 18 pt type whenever possible, which is very helpful in Japanese. I've built two million selling products, and i can tell you that bell curve is a killer at the low end, and i worked so hard to accommodate everyone. Seniors are the hardest because they can have poor memories, and can call you every six months with the same problem.

Modern laptops have 4 modifier keys (shift, ctrl, alt, super) which can be used to create 16 variants of a trackpad click. Every laptop trackpad has a way to register 'left' and 'right' clicks, even on a macbook, where a 2-finger click is a 'right click'. So that's 32 kinds of clicks, more than enough to support an ACME style UI.

What do you mean by graphics as first class? The ability to draw in the window? Or display image files?

Just to get back to the extension mechanisms, there's three integration points that I think work so well together: • Acme will execute any program typed and gestured in the app, setting an environment variable that contains the ID of the Acme window where it's executing. So users "install" "plugins" by typing a name into the top bar, where it stays until they delete it. • Other programs can connect to Acme via a network protocol which, among other things, lets you control any window given its ID. In particular, if you request a window's event stream, that suppresses almost all default behaviors so that you can redefine what the "execute" and "look" mouse gestures do, while other windows continue to operate normally. • The network protocol emulates a filesystem interface that for convenience is wrapped by a command-line program whose interface boils down to

9p read [path]

and

9p write [path]

. So given any interface problem, you can attack it in a variety of ways: • Make a program that the user invokes, whose input is the current selection and/or whose output overwrites the current selection. • Make a program that controls Acme from afar with the network protocol. • Combination of the first two. And it's remarkably simple. Like, here's a shell script that you can use as your $EDITOR that opens a file in a new Acme window, adding "Cancel" and "Done" commands to the UI that dictate the exit code and whether it saves:

#!/bin/bash

filename="$1"

winid=$(echo $(9p read acme/new/ctl) | cut -d ' ' -f 1)

# Open the file
echo name $filename | 9p write acme/$winid/ctl
echo get | 9p write acme/$winid/ctl

# Add commands to the tag line
echo -n Cancel Done | 9p write acme/$winid/tag

9p read acme/$winid/event 2> /dev/null | while read -r line; do
	cmd=$(echo $line | cut -d ' ' -f 5)

	if [ "$cmd" == "Cancel" ]; then
		# Mark the file clean
		echo clean | 9p write acme/$winid/ctl

		# Close the window
		echo del | 9p write acme/$winid/ctl

		exit 1
	fi

	if [ "$cmd" == "Done" ]; then
		# Write the file
		echo put | 9p write acme/$winid/ctl

		# Close the window
		echo del | 9p write acme/$winid/ctl

		exit
	fi
done

The whole thing might be complex to implement for the editor devs, but there are obvious compromises that would make it easy, and probably still be infinitely better than an API that consists entirely of command-line arguments and SIGINT. 😅 If it ever doesn't seem worth it, consider threads like this: https://twitter.com/geoffreylitt/status/1178806585289773056