[oblio]

The problem with stuff like this is: sure, maybe it's amazing.

Then what do you do with it? Is the UI reproduced anywhere else? Does it have LSP/intellisense support? Can it be automated through various means, such as macros? Etc.

[floren]

Yes, there is LSP support. Yes, it can be automated. Yes, you can write programs to run in acme, just like you can in emacs.

I love using acme spread across the two big monitors on my desktop machine. I can keep so much code, so many files open and visible and easily-interacted-with. However, on my laptop, I use emacs, even though emacs' frame management NEVER does what I want (go to definition? Opens in the current frame. Ugh.)

[confd]

A Tour of Acme: http://research.swtch.com/acme

If you need to do anything aside from what this video suggests acme is capable of, do it with something else.

[crabbone]

Thanks for the link.

Some bits are nice, like, for instance, exposing editor's internal state as a filesystem to make it easy to automate by external tools. Unfortunately, like with the similar ideas (i.e. sysfs, procfs), time showed this is a bad idea. Well, it's not bad for simple things, but it hits a hard ceiling that requires completely dropping this concept in favor of something more robust.

On the count of scrolling and moving windows around... when I have to deal with new programmers, no matter what editor they use, one of the biggest productivity tips is to learn to never scroll and never move windows around, resize them etc. Doing so you learn to work hard, imprecisely, and blur your focus on inconsequential things. The way to move around structured text (eg. code) is to either move by structure, or by search, or through something like "ace jump" -- learning this habit makes you work with more precision and less distraction. Similarly, with moving windows around / changing layout. Depending on the shape of your screen there's really only ever going to be one best window layout. Usually, it's something simple, like two windows side by side, or one on top of another if you use a vertical screen etc. Trying to modify that always leads to both waste of time and loss of focus. It's best to develop the habit of bringing the desired content into the window with set dimensions than to manipulate window sizes and positions. Predictable layout also allows for easier design on ad hoc functionality that responds to events in one window in another.

Finally, some bits are trivial (at least in Emacs), all that executing commands from text extensively covered by the video is C-! or C-| in Emacs. My experience with these shows that in practice they are almost never enough, and what I need is something like Org code blocks with variables, rendering information etc. So, again, it looks nice, but falls apart once more robust functionality is desired.

Plumber is also a nice idea, and, I believe Emacs has something similar to it, the thing-at-point and some other functionality derived from it. But, I'm not sure what's the current state of this functionality.

Finally, an anecdote about clicking with mouse (an actual horror story I went through). The older Jenkins interface had "Delete Job" button right under "Run Job". It also used to be common to rely on Jenkins to store build artifacts (those were simpler times...) So, one day I was summoned to the office due to an emergency caused by a developer who wanted to run a release build, but accidentally fat-fingered into clicking the "Delete Job" button and wiped not only the job, but also the associated workspace that contained all builds so far.

Some recent versions were forever lost that day due to backups being done once every few days or so.

Anyways, the moral of the story: opening or executing files by pressing mouse button -- I would never do that. Just an all around awful idea. Very easy to do a lot of damage just by accidentally hitting your funny bone or by sneezing etc.

[0x69420]

> Unfortunately, like with the similar ideas (i.e. sysfs, procfs), time showed this is a bad idea. Well, it's not bad for simple things, but[...]

i know how this is going to sound, but if your only experience is those filesystems on the sysvs and bsds of the world, i am compelled to say "real filesystem APIs have never been tried". in plan 9 and its userspace tools, there is no, for instance, udev-style "doing a bunch of perilous reads and writes and symlinks followed by throwing your hands up in the air and ioctling a struct" suffering. acme's API is really nice, despite being one of the clunkier, more hastily-designed ones by plan 9 standards.

> one of the biggest productivity tips is to learn to never scroll and never move windows around, resize them etc.

acme does well here in my experience:

- the typical path:line[:column] address will take you where you expect with a right click in acme or a plumb from anywhere else (including, say, a click handler in your terminal emulator of choice)

- any time a new window pops up, there are sane predictable defaults as to where that window goes

- the simple shortcuts of left-clicking a window's handle to expand it a bit or right-clicking it to take up the entire column do 99% of what you ever want as far as "window management". these shortcuts also warp your cursor to so spamming a few left clicks is entirely thoughtless

point being, the times i find myself scrolling or dragging are rare.

> I believe Emacs has something similar to it, the thing-at-point

it's worth noting that there are two separate things at play here: plumber is a generic user-space message broker, and right-clicking is acme's built-in shortcut for accessing it. thing-at-point is ~equivalent to the latter; the former can even give give emacs new powers; example: https://github.com/alcah/sink.el/blob/master/sink.el

[crabbone]

> real filesystem APIs have never been tried

How would you approach following problems by representing data as filesystem?

* Represent an array with a million elements.

* Represent data-structures s.a. stack, queue, list, various balanced trees.

* Represent "structs" a.k.a. custom data-types (or even distinguish between a fixed variety of built-in data-types)? Especially how would you enable user to pass structured information to filesystem?

* Allow for custom, more meaningful errors that are sensitive to context. I.e. ENOENT is an awful error if your API is trying to represent eg. an array, then ENOENT may mean "index out of bounds" or that the whole array wasn't found. Not to mention that the error doesn't carry any information necessary to understand and correct it (i.e. if it was an out-of-bounds access, then the necessary information is how long the array is and what index the program was trying to access, if it's a whole missing array, then what path to array was requested etc.)

The above is the bread and butter of any half-decent API. I don't see how you can bend filesystem in such a way that any of these requirements could be satisfied in a way that isn't painful to deal with.

> acme does well here in my experience:

This is nothing to do with acme. It's just always a bad idea to do it. Doesn't matter if you use a text editor, a PDF viewer, a word processor -- anything to do with text, no matter what it is, learn not to scroll. The only time when scrolling is useful is if you are reading text that's long and is meant to be read in order, s.a. a novel or a play. It just so happens that this is the first and most accessible way to navigate text documents that users learn, and they tend to misapply it to problems that have better solutions.

> the typical path:line[:column] address will take you where you expect

In places where this is sometimes useful most other editors offer a way of doing this (eg. in Emacs compilation buffers you need to press RET to go to the location of the error, in VSCode terminal, it's something like Ctrl+Enter... maybe? I don't use that, but saw a tooltip hovering over such info the editor opened by a coworker). I saw this functionality in various GUI terminal emulators too.

> any time a new window pops up, there are sane predictable defaults as to where that window goes

The number of times I want a new window to pop up is very limited (eg. I do expect a new window hosting Magit's command options buffer to pop up, or a completion buffer, if similarly summoned), but I never want to create new windows or move existing windows with the contents that I'm supposed to edit. In my experience, and by looking at programmers learning how to use their editor, this is a bad habit that they need to learn to avoid.

Of course people are different, and there could be unique individuals for whom the exact opposite is true, but if I wanted to give a general advice that would apply to most, I'd insist on never touching window layout after finding the optimal layout for oneself.

> the simple shortcuts of left-clicking a window's handle to expand it

I never want to do this. And if I was working in an environment where this could accidentally happen, I'd work towards removing this functionality. For instance, in Emacs it's possible to resize the window by dragging its margins with a mouse -- and this is part of the reason I always disable trackpad, if I'm working on a laptop, so that I don't accidentally mess things by doing something like that. It never comes as a desirable functionality.

[0x69420]

i wasn't talking about adding syscalls to the round trip of array access, i was talking about controlling a running system or speaking a protocol. for the canonical example, i refer you to http://man.cat-v.org/plan_9/3/ip http://man.cat-v.org/plan_9/3/tls http://man.cat-v.org/plan_9/2/dial

note the net argument to dial(2). the point isn't direct access (as evidenced by its encapsulation in a library, which is common in message-passing interfaces; same principle as erlang discouraging direct message sends to a gen_server pid); the point is namespacing, addressing, and protocol. "tls" is just another network you can dial on like "tcp", as are the contents of /net as, say, imported from another machine (you can imagine how trivial a vpn becomes).

"everything is a file" is miserable and, if you dig sufficiently deep, false, on unix because the unix concept of "file" is insufficiently general and weighed down with the baggage of teletypes and disks. not so with plan 9, nor with, if you prefer, a modern example: https://fuchsia.dev/fuchsia-src/concepts/process/namespaces

anyway i don't want to belabour that further as the real reason acme is relevant to this thread is the context of mousing around in a text editor:

> [...] It's just always a bad idea to do it. [...]

i mean that "acme does well" at avoiding the clumsy manual scrolling and windowing you advise against -- we're in near ideological agreement here.

> The number of times I want a new window to pop up is very limited

this is a matter of taste that traces back to the uproar against the demise of the “spatial finder” in the os 9 -> os x transition, but what i was getting at is that i do have a predictable, static layout; let me describe it: three columns i never resize in the form 80-80-remainder. terminal session and error buffer live in the right hand side, a given window dominates each of the 80-column columns, with perhaps a few titlebars of other files each. accordingly...

> For instance, in Emacs it's possible to resize the window by dragging its margins with a mouse

...refocusing within a column, whether indirectly by plumbed reference jump or directly by one click, doesn't register as window management to me. the dynamic is far more like selecting from a menu, or operating a library stack. the titlebars occupy insignificant real estate, and visually serve as an overview of the entire context i'm working with, which spares me significant mental bandwidth when either tabbing to and from another program, or getting out of my chair and back into it.