Integrate with external window manager #130
Comments
|
Thinking about it a bit more, maybe I'm not understanding you. There is this client/server rpc thing in your plans, so I expected the clients would eventually access a list of open buffers kept in the server. But there is no "hidden buffer" feature a la vim, no way to get a list of open buffers even inside the same instance, afaics. So maybe your intention is to be old school: to avoid this kind of buffer management at all, force the user to save the changes and delegate file selection to external tools (dmenu, the shell, etc.). I'm really interested in hearing about your perspective here. |
|
I agree it is a worthwhile goal to let the window manager deal with editor windows. And yes I personally don't need the "hidden buffer" feature. In principle the window manager should be able to "hide" currently unused windows (e.g. a tilling window manager could move them to different tags). But I understand some people like opening a lot of files and then switch between them using As for the client/server architecture, the main design decision is to figure out what kind of interface to expose. For example kakoune seems to be sending key strokes to the server? Depending on what you want to achieve it might be better to provide a more low level interface. At the other end of the spectrum one could just expose the text.h API meaning the server would only take care file content changes. However things like register contents, macros, key bindings etc should probably be shared too? Does this mean the complete vi logic should be server side? What kind of API would be useful for plugins etc ... |
|
Rather than a "hidden buffer" feature, there could be "recent files" list, stored as plain text to be persistent across reboots: This would make no distinction between closed files, and buffers put to the background. |
|
I implemented this "recent files" in a script, for iomenu. Here is how I maintain a list of the most recently used files: This de-duplicates the entries but without sorting it, for latest file to be kept at the end. It keeps only the 10 latests entries using tail. |
ghost
mentioned this issue
|
I want server/client more and more as I move on in my computing world. My initial thoughts here are, the server houses file changes without much more - which would mean that Vis client could be substituted with other mechanisms, should one desire such a thing. (Think, streaming to a limited client when doing presentations, collaborating with people who prefer different interfaces to editing, etc). The client would have a ctl interface to write to for redo/undo, for example and watch the underlying file for changes. |
|
...maybe on the wrong issue, whatever. This one is about buffers - my biggest actual gripe right now is that I can be editing multiple instances of the same file. (It happens!) What I'd like most of all is that the program caches changes to files until they're :w to disk, (or the program closes) and any subsequent opening or closing of files continues, sessioned and based on the file name called on opening. This, as far as I can tell is only really expressible through a client/server, or daemonized interface |
|
@halfwit you can probably implement buffer caching as a simple lua extension listening for |
|
As a radical alternative proposal to implementing some kind of client-server architecture in vis: Why even support "window management", i.e. multiple splits in a text editor in the first place? Why not recommended using one of the excellent terminal multiplexer such as dvtm or tmux where users can create multiple vis splits according to their needs. |
|
I'd say that's the final destination but you still need a client server design to support that otherwise you'd just have multiple independent instances of vis in different terminal windows, which you can already do now. |
Without having splits, a lot of functionality wouldn't be possible even with plugins. Things like diff mode, sidebars for file navigation or git log/blame, etc. Although, currently, diff mode would probably be pretty difficult to implement, and sidebars aren't really doable in a usable way, given how limiting the window system is. |
|
Is there any progress on this? I'd love to help... |
|
So let me get this straight: because vis is (not) going to have a client/server architecture sometime soon, it's impossible to use tmux panes for windows. Meanwhile, a change as simple as adding support for resizing splits is rejected, because supposedly someday there will be a client/server architecture. Which is not going to happen. Sounds like a great plan. |
No need to be sarcastic. Of course, those patches you have prepared for us would be considered. Where are they? |
|
I'm currently working on implementing a working prototype for mouse support that covers all of the usecases in #666, and, in the process, have learned a lot about how the problem of window management was approached by Acme and Sam. I would like to propose an alternative to the client/server model which, theoretically, would require less changes to the current codebase, while simultaneously being better suited to vis' role (in my eyes, at least) as an excellent embedded editor. Rather than having a "vis server" keeping track of every vis client, we ought to take a page from Acme, and have each vis process maintain a file system interface. A set of named pipes/unix sockets/watched tmp files that allow for executing commands and reliably querying the internal state. What I'm suggesting is somewhat touched upon in #535, but I think that the suggestion there (of a single endpoint for running commands and receiving outputs) isn't strong enough. Rather, I'm suggesting we attempt something resembling acme's file system interface. Sockets created on demand by and for interacting with the Lua API, FIFOs for simulating keypresses and reading debug messages, tempfiles that are synchronised with internal buffers, leveraging file locking to prevent invalid states, things like that. As an example for how this can be useful for this issue, in particular: For me, the absolute key feature for working across multiple editors is the ability to
In a server/client model, there are all sorts of questions raised as to how much of this logic should be inside the server, and how much of it is the responsibility of the window manager, and how much external user scripting is needed... And, thus, has lead to the deadlock in which no one is sure how to even start. Within a file system interface, the delineation of responsibility is clear.
As a bonus, the lack of a separate server also means that vis remains totally usable even in situations where resources are severely limited, such as in early boot or high security file editing. In my understanding, adapting a server/client model to this situation means either duplicating logic between the server and client, or compiling a special "restricted" vis that needs to be maintained separately from the "complete system" vis. Both of these options I consider inferior to simply disabling the file system API if resources are restricted. The weakness of this system is that it'll create a secondary API that's just as, if not more complex than, the Lua API. However, I believe this to still be less complex than the work needed to implement an abstract server/client model. We have a pattern of how effective file system APIs for editors tend to look like (see acme(4)), and retaining the "each vis process handles its own file" would be less disruptive to the way vis is currently used by many- as an executable binary that can be used wherever a terminal with raw input and stderr is available. Well, this ended up longer than I hoped. I'd like feedback (from the current maintainers and the userbase that cares enough to be subscribed to this issue) as to whether what I'm describing sounds plausible and desirable. In my eyes, I think this concept is more tangible and ripe for prototyping than a theoretical server/client model for which, as far as I can tell, no one has pinned down in an actionable form. |
|
Having spent a lot of time on 9, and having used a server/client editor setup like proposed for a bit, I don’t really hate the idea of serving files, but it is decidedly not a first-class operation on the *nix side of things. Using things like sockets and FIFOs is ok, to a point; but you would need a way of say, multiplexing your FIFO writes to any clients if you ever wanted to run multiple. Using real files is not a terrible way around the janky state of VFS though. Looking forward to see what you create!
… On Apr 12, 2024, at 18:23, Dther ***@***.***> wrote:
I'm currently working on implementing a working prototype for mouse support that covers all of the usecases in #666 <#666>, and, in the process, have learned a lot about how the problem of window management was approached by Acme and Sam. I would like to propose an alternative to the client/server model which, theoretically, would require less changes to the current codebase, while simultaneously being better suited to vis' role (in my eyes, at least) as an excellent embedded editor.
Rather than having a "vis server" keeping track of every vis client, we ought to take a page from Acme, and have each vis process maintain a file system interface. A set of named pipes/unix sockets/watched tmp files that allow for executing commands and reliably querying the internal state.
What I'm suggesting is somewhat touched upon in #535 <#535>, but I think that the suggestion there (of a single endpoint for running commands and receiving outputs) isn't strong enough. Rather, I'm suggesting we attempt something resembling acme's file system interface. <http://man.cat-v.org/plan_9/4/acme> Sockets created on demand for by and for interacting with the Lua API, FIFOs for simulating keypresses and reading debug messages, tempfiles that are synchronised with internal buffers, leveraging file locking to prevent invalid states, things like that.
As an example for how this can be useful for this issue, in particular: For me, the absolute key feature for working across multiple editors is the ability to yank from one file and put into another, and to be able to jump to the appropriate editor based on file. Anything else, in my opinion, is second. For this minimal proof of concept, I'd need the following capabilities:
synchronise the contents of the unnamed register across two or more vis processes
read the file path for the currently opened file, and map it to the relevant pane containing its editor
In a server/client model, there are all sorts of questions raised as to how much of this logic should be inside the server, and how much of it is the responsibility of the window manager, and how much external user scripting is needed... And, thus, has lead to the deadlock in which no one is sure how to even start.
Within a file system interface, the delineation of responsibility is clear.
Each vis process should maintain a set of tmpfiles in /tmp/vis/processid/ (or some other similarly findable directory) which are synchronised to the registers and to important variables (e.g., absolute file path), and obtains a file lock whenever events are being processed
An external process will wait until this file is unlocked (signalling that vis is not currently executing any code), and then read/write to the file as needed to synchronise each processes' internal state
As a bonus, the lack of a separate server also means that vis remains totally usable even in situations where resources are severely limited, such as in early boot or high security file editing. In my understanding, adapting a server/client model to this situation means either duplicating logic between the server and client, or compiling a special "restricted" vis that needs to be maintained separately from the "complete system" vis. Both of these options I consider inferior to simply disabling the file system API if resources are restricted.
The weakness of this system is that it'll create a secondary API that's just as, if not more complex than, the Lua API. However, I believe this to still be less complex than the work needed to implement an abstract server/client model. We have a pattern of how effective file system APIs for editors tend to look like (see acme(4)), and retaining the "each vis process handles its own file" would be less disruptive to the way vis is currently used by many- as an executable binary that can be used wherever a terminal with raw input and stderr is available.
Well, this ended up longer than I hoped. I'd like feedback (from the current maintainers and the userbase that cares enough to be subscribed to this issue) as to whether what I'm describing sounds plausible and desirable. In my eyes, I think this concept is more tangible and ripe for prototyping than a theoretical server/client model for which, as far as I can tell, no one has pinned down in an actionable form.
—
Reply to this email directly, view it on GitHub <#130 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AC2K73MUIHDEADM3PT3LYWTY5CCJJAVCNFSM4BXVPJNKU5DIOJSWCZC7NNSXTN2JONZXKZKDN5WW2ZLOOQ5TEMBVGI4DMMRZGYZA>.
You are receiving this because you were mentioned.
|
|
@dther fascinating idea! You're right about the deadlock on how to even start to tackle this issue, and your proposal sounds like a much simpler approach. In your opinion, would this approach preclude the ability to have the same file open in separate instances at the same time? One of my more frequent (Vim) use-cases is to have multiple windows on the same buffer so I can see/edit different parts of the file at the same time. Each instance would maintain its own cursor/window position, which seems straightforward, however showing the real-time, unsaved edits in each instance would be much harder. Perhaps a copy of the file could be stored in the temp directory that could be written to for any "unsaved" changes, and then watched/reloaded by other instances as changes are made, though (without testing) it feels like that might have notable performance implications, possibly in general, but certainly for large files. |
Oh, wow, this is an excellent usecase that I hadn't even considered! Taking into account @halfwit's observation that Unix, unfortunately, doesn't have a The concept is this: each vis process that wishes to allow multi-editor operations on its file has, at bare minimum, a file system API which serves up the absolute path of the file they are editing. Before opening a new file, every vis process checks its fellow peers to see if the file is already open. If it is, then it sends a signal to the vis process, indicating a request for a file synchronisation socket. From this point onwards, the first vis process to open the file becomes the ad-hoc server responsible for tracking this particular file, and any further vis processes will only connect to the ad-hoc server, with any "client" peers rejecting requests for new sockets. Should the vis peer acting as the server shut down, it will pass its ad-hoc status to the next oldest peer, and send a special signal indicating that this peer must take responsibility for tracking all further edits and opening connections, then finally gracefully exiting after informing all the younger vis peers of the change in server. As an added bonus, the client peers need not necessarily be vis editors! They could be specially designed processes that translate the state-change messages into, say, IDE autocomplete suggestion requests! If a non-vis client peer is asked to become a server, it can simply "pass it on" to the first process that is a vis editor, or, if no real editors remain, inform the ad-hoc server that it is time to close all connections and finish editing. I believe this would solve any issues with concurrent same-file management, but it comes with, of course, another set of drawbacks (which I still believe to be more acceptable than a purely theoretical server-client model, of course!)
Thanks for the words so far! I'll definitely put the file system API on my list of fun vis projects to try, once I polish off my raw mouse event patch into something I consider presentable. I'm close to my first release. Edit: I forgot |
|
Reminds me of all the papers about collaborative editing, OT/CRDT (e.g. https://arxiv.org/abs/1810.02137). And to think that vis criticizes vim for offering merely window manager / IDE functions that "don't belong in an editor"... Otherwise, kak seemed to get it just right back when I played with it. |
I don't think that's a fair assessment. Vis doesn't do away with those functions merely for "not belonging", but rather to keep the codebase hackable and with as little backwards-compatible cruft as possible. In my experience trying to add mouse support, it has executed that goal perfectly. Working with its codebase and Lua API has been an absolute dream, and for my uses it has exceeded all expectations. The current windowing capabilities are weak, but good enough that I haven't touched vim after almost a year of use. Though, admittedly, I'm more of a sysop than a programmer these days. The reason why the server/client model has been in the design philosophy for so long is because it's conducive to vis' internal data structure, which stores changes as a series of OT operations. It's practically begging to be turned into a IPC-local collaborative editor! Vis is much closer to that, structurally, than it is to an IDE. |
Perfectly commendable, but screen-estate management does seem like a core editor feature. In particular, would making the existing splits (panes) resizable reduce hack-ability? I can see how that might be the case for going from a single pane to multiple panes, but once those are in...
That's interesting. So it should also be possible to save an undo log / journal, and implement crash recovery (e.g. for power outages etc) by replaying the undo log? Also, adding distributed computing of any kind usually introduces CAP-related limitations ("can't do X because we need to sync to other clients" etc), not to mention bugs (of the hard-to-reproduce kind); would this not also be the case here? This is not to say it's not a worthwhile idea — just that it might also complicate the existing codebase and the potential to extend it (just like what you said above about other feautres). |
The current state of affairs for the tiling/terminal crew is a mess of window management layers: vim splits inside dvtm/tmux panes inside dwm/i3 clients...
From the do one thing well perspective, and for the sake of the user mental health, it would be good to strive to delegate window management to dvtm, tmux, dwm, i3, etc. as much as possible, the way kakoune is leading.
I know this is in your todo list, I just want to remark as a potential user (I long for the day you finally free me for vim/neovim! ) that I find this one of the weakest areas of vis, currently.
The text was updated successfully, but these errors were encountered: