search

rjkroege / edwood

Go version of Plan9 Acme Editor
Other
380 stars 34 forks source link

Separating window management from the editor #180

Open Superpat opened 5 years ago

Superpat commented 5 years ago

I'm planning to explore this soon, but opening the issue now in case anybody has feedback.

I'd like to separate the acme window management from the actual acme windows, so that acme frames would be created in separate x / plan9 windows. From there on anybody could use their window manager of choice, or use a window manager replicating acme's workflow.

Alongside better flexibility, I think this would also alleviate the need to have multiple namespaces each running their own acme / plumber namespaces. I'm thinking this might be easier to do in Edwood than plan9port.

rjkroege commented 5 years ago

you would want a Window object to have its own X11 window then? This doesn't seem unreasonable but I suspect that it would require some non-trivial refactoring. I would imagine that Row and Column would need change. And maybe Window would have some extra data to wrap a some kind of external window object?

Superpat commented 5 years ago

Havent delved into the code yet, but that seems about right.

Initial tests could probably ignore the row / columns and concentrate on getting Window right.

Superpat commented 5 years ago

In the same line of questioning, could there be multiple rows? embedded in a column with other columns / rows embedded in it.

rjkroege commented 5 years ago

The row, column, window tree hierarchy is a fundamental Acme/Edwood design and implementation decision. I think that it would be very difficult to alter.

mennis commented 5 years ago

One related thought is that a long time ago there was talk of splitting acme in two so that it could be used like sam. There is a piece that runs locally and a piece that runs remotely. This makes use over high latency links feel responsive but specifically I'd be thrilled if I could leave the editor running remotely and reconnect to it with my local client so that my remote session isn't lost when I get disconnected. Current tmux usage patterns seem to have a similar flavor.

rjkroege commented 5 years ago

@mennis: I think that I already use Edwood and Acme as the client app in your description. So long as the filesystem of the remote system can be mounted successfully, editing will be responsive because the entire MVC is close to the user.

I typically have used sshfs for mounting the remote system and it has worked acceptably in practice. (Some kind of 9p solution would be more satisfying I suppose. 😊) I have a shell script that sets up mounts and such so that restarting Edwood from a dump file will open all the remote and local files.

Where this falls down is however the restarting of command sessions (e.g. win, particularly if it's running on the remote system.)