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