> > wow. the linked Acme paper by Rob Pike is one for the permanent library, > to be read and re-read. haven't watched the video yet, but now I *have* > to! Published 1994 and I feel like I'm reading something from 2014 or 2024 > (willfully stepping over some of the more obvious era-specific references). > > Surprised? I mean, it sure seems like recent generations of developers > just keep making the same old mistakes, and then ultimately reinventing the > same stuff that folks did back in the day. Not a profession that learns > from the past. >
Surprised? Well yes, as evidenced by the 'wow's, and no, as this is one more in a number of historic things still not evident in today's world. Today being a moving lens, some things in focus and most others not. I started my computing experience circa 1992. There are things from then absent now that I still miss regularly. But back to the why 'wow' here: it's some of the interaction concepts which are completely new to me. Edward said *"I may have missed something truly interesting in this video. If so, please tell me exactly what it is."* For me the video was rewarding after reading the acme paper [https://research.swtch.com/acme.pdf]. (Generally I find watching videos of other people driving a computer painful.) I think the two are best together and not in isolation. Specific things that made me sit up and pay attention: Middle click: whatever is selected are the command(s) to execute. It's akin to Leo's Ctrl-B execute script command but powered up so that it works everywhere, not just the body pane. Right click is search for 'selected text', but how the search happens is context aware. If it's a path and the file exists, open it. If selection is a filename and a line number, open to that line. If selection doesn't exist search for it generally. (Presumably across all open documents. Or something. There's more here that I didn't catch.) Acme as a file system command object: `path/to/acme` is the program. `path/to/acme/copy ...` is conceptually akin to running `acme --copy {parameters}`. I imagine clones-find-all-flattened being called like `/bin/leo/cff {search pattern}`. The caller could be just an interactive command shell prompt or a program like vscode. Output of commands/programs get their own panels in Acme automatically. (Flipping between Leo's log pane and shell console to catch messages is a constant low grade friction. Foreseeing ahead of time I need to declare print() or g.es() for process x instead of just "gimme everything that happens" is mental work I consistently fail at.) There's something about how the Undo/Redo stack is implemented that seems ingenious and stable. Admittedly this part is outside my ken; I'm a user and not much of a developer. The constrained yet flexible window layout is intriguing. It appears very easy to arrange and manipulate dynamically as one works. There are many more subtleties I can sense just beyond my grasp. There's only so far one can go in understanding without trying it, obviously. Like Leo and tree organization, external files, and clones. -matt -- You received this message because you are subscribed to the Google Groups "leo-editor" group. To unsubscribe from this group and stop receiving emails from it, send an email to [email protected]. To view this discussion on the web visit https://groups.google.com/d/msgid/leo-editor/54d785aa-ee95-4915-af59-6334684fa5e0o%40googlegroups.com.
