UI: Externalize Window Management

[bryphe]

There are several shortcomings to how Oni manages windows today.

• Convoluted code path - the overlay / overlaymanager concepts are unnecessarily complex and confusing
• Difficult to extend - it's non-trivial to add new functionality, like a git blame marker plugin, or something like markdown preview

For the overlay scenarios, it'd be really nice if each split had its own 'container' div. This really isn't possible today, as Neovim as a whole manages rendering to various splits.

I'd like to look at the possibility of 'multiplexing' Neovim instances to address these shortcomings. In effect, this would allow us to move window management to Oni, and allow us to really build on that experience - we could have first-class animations and much simpler overlay code if we manage the windows explicitly. Each 'split' would be its own Neovim process.

My original concern with this was that it would be difficult to persist settings between the splits - for example, marks, history, etc. @justinmk had a great write up on how this could work: https://www.reddit.com/r/neovim/comments/5ym9p3/future_of_ui/

[FrigoEU]

For me, this issue is super important, but also still very vague. I love Vim's editing experience but hate its extensibility story. Now most extensions that I'm interested in (and spacemacs is my biggest influencer here) are a git interface, keybinds explorer, compilation feedback, search, etc. These are all panels that are being drawn over/around the editor.

I don't know how you see this, and I don't know how I think it should be, but I think if we could present a nice API to plugins (and I think React can help here) next to the "internal" panels, it would mean the world.

[bryphe]

I love Vim's editing experience but hate its extensibility story.

I'm with you 100% here. This is exactly what motivated the creation of this project.

For me, this issue is super important, but also still very vague

Definitely! I have some ideas in my head, but haven't had much chance to experiment yet... I think it's worth calling out some of the primary goals:

• Git interface
• Git blame annotations
• Keybindings explorer
• Compilation feedback
• Search
• Live Preview (React components, HTML, Markdown)
• File Explorer
• Plugin Manager

I see three broad classifications of these:

• Floating Panels - these are independent pieces of UI that exist independently or on top of the editors. The log panel you implemented is a good example. The file explorer and git interface also potentially fit this, but would be on the side.
• Overlays - these are UI entry points that place UI on top of an editor window. We have lots of examples today - the completion, the error bubble, the quick info bubble. Other items I could see extending this would be things like git blame.
• Additional Renderer Types - preview modes would fall into these. They might be rendered completely differently from how we render the windows today, but maybe that is as simple as specifying a separate render strategy that is provided by a plugin.

Floating Panels would be completely new UI, independent of the editor. Overlays would be layers on top of the editor window - so they would augment the existing editor rendering strategy. Additional Renderer Types would competely replace the existing editor rendering strategy.

One thing that is important to me is maintaining Vim key bindings across these different windows. So I should be able to use the keys I'm comfortable with for navigating my file explorer, my git interface, my keybindings explorer, etc. One thing I'm experimenting with is supporting custom renderers for a buffer - sort of like how NERDTree renders to a scratch buffer, we'd have a scratch Neovim instance that would could be used for navigation, but I could do custom rendering for that neovim instance / window - so I could add folder and file icons without needing a font hack. This will be more realistic once the refactoring to support #201 is complete.

Sorry if this isn't very clear, just sort of thinking and brainstorming through the keyboard. 😄 But I agree with you, I think if we can have a reasonable story for all those - like exposing an API that takes a React component as you suggest, along with some of the other plugin capabilities - we could go pretty far in tackling many of these scenarios.

[FrigoEU]

To pile on the brainstorm, one thing that I was thinking is:

1. some functionality lives in editor windows/splits. One example of that is magit in spacemacs, which just always opens in a split next to the file that you're editing. If you already have a split open, it overtakes one split. I like your idea of reusing neovim for that to keep all the bindings working. A custom renderer also sounds like a good idea, maybe some kind of read-only attribute can be specified somewhere? ie; you don't want to be able to start typing in your git log overview.

2. Second is panels that "steal space" from editor windows. The new messages log is one example for that. It's nice that it shows up on the bottom, but it shouldn't render over the existing windows. Now that I think about it, this should be just a vertical split, right? Again with neovim handling key binds. One thing that I don't know how this would fit though, is when I search in spacemacs, this "vertical split" kind of thing comes up where you have at the top a search bar, and at the bottom your results. I'm unsure how this fits in the << let's "just" make new neovim instances for every window >>.

3. As you said, overlays. Here we just need a clear "system" (could we just do simple z-indexing?) so that the intuitive order of overlays gets respected.

Btw, these "Additional renderer types" is I think where Oni will start shining :). All the other stuff is kinda things that other editors already figured out. For example I love magit, but I kinda fear having to implement the whole thing in Oni again...

[bryphe]

Starting to look at this in the context of #442 - a few initial blockers:

• PluginManager and NeovimInstance are both associated 1-to-1 with each other. For multiplexing the Neovim instance, this will need to be decoupled. NeovimInstance isn't used too extensively in PluginManager, so it seems like it can be decoupled fairly easily.
• Some pieces of UI would be global (ie, QuickOpen), whereas other pieces would be local to a particular window (like AutoCompletion) - they would need to start to be split up.

Need to think about how to streamline some of this architecture in light of this new model.

[Bretley]

I don't know if this is at all feasible to improve rendering in the mean time, but could you glue multiple individual windows where neovim says there are splits?

[hoschi]

@extr0py I saw you completed #557 and want to ask if you had some insights which bring this task further?

I'm also really interested in that feature, because I have an advanced use case for managing splits (I call them editors) in another way it works at the moment in vim (and other apps like Atom/VsCode/...). I build a project which enables the user to not only edit files like all of us are used to, instead you can now edit nodes of the abstract syntax tree (AST). This allows you to focus on parts of different files but save a lot of screen space so you can see all nodes (arrow functions in JS atm) on the screen. It is like NrrwRgn on steroids. My project (called NFBE, still searching for a better name) syncs the code of a function editor to the file (editor) in (near) real time, so all other tools like test runners, compilers, ... can still do their jobs without knowing that the user don't edit files, instead just a small part of it.

To integrate this in a real editor I need two things:

• editors (splits atm) should not have a defined height, instead the height should be defined by the lines of the content
• call my own save logic, because a function editor doesn't write to a file with the traditional logic

Because function editors are contain less code, it makes sense to turn around the fixed height splits into auto sizing splits to see all content easily. With this new pattern of editing parts of a file it also adds other use cases to the window manager. For example now you just can say "split vertical" or "split horizontal" to use screen space for other files to edit which are related to the file you originally edit. With editable functions you now have use cases as:

• drill down into the function of this file, replacing the current file editor window to focus on something
• open this function of the file in a new window to see its content as a reference while moving around in the file it contains something
• temporary open this function in its own window to scope editor commands (e.g. search/replace) just on this part of the file and then close it and more things like this.

It also allows a new world of intelli sense. By allowing to be more "white space" by shrinking the editors and not render this white space lines (starting with a "~" in vim), one can go even further and open up related function editors automatically. Like an editable version of code completions or imported React components of the current file. This is not ready yet, but the end goal I want to achieve.

Sorry for the wall of text, here are some screenshots. Say you want to change the behaviour of how a todo gets saved in a TodoMVC app by adding an additional parameter. Viewing all files to edit would look like this, the lines in question are selected (gray/pink background):

With function editors you can focus a lot better and make space for additional code you need to open while you implementing your feature, e.g. add another test for it:

In my prototype UI it is possible to change the width of each editor and move them around in a simple two column grid. In one column the editors simply stack. Integrated in a real editor I would add more features to this.

Do you think this is possible with Oni and the work you are achieving with this task? Any feedback is appreciated ;)

[hoschi]

It is also possible to have function and file editors:

Sorry if this was not clear, you can still edit the way you are used to even with NFBE integrated.

[bryphe]

Hi @hoschi ,

Thanks for the detailed write-up and descriptions! The screenshots were really helpful in terms of visualizing the idea.

IMO I really like the experience you describe - I believe I saw something before sort of like it (I think perhaps it was LightTable). This is exactly the sort of concept that I would like to experiment with in Oni, and exploring new paradigms of editing code was really a motivating factor for creating Oni (yet-another-text-editor).

My project (called NFBE, still searching for a better name) syncs the code of a function editor to the file (editor) in (near) real time, so all other tools like test runners, compilers, ... can still do their jobs without knowing that the user don't edit files, instead just a small part of it.

Very cool. This sounds like a great architecture, and it is something that Oni could handle as well (it already has affordance for sending incremental updates to the language service), and the plugin infrastructure would be able to handle this as well, in the same way that it handles edits today. There would be some changes required but it is definitely possible.

It also allows a new world of intelli sense. By allowing to be more "white space" by shrinking the editors and not render this white space lines (starting with a "~" in vim), one can go even further and open up related function editors automatically

I really like this idea! One challenge I had with the Reason integration is that, the language service gives some interesting information with the function (typing), but I didn't have a place to put it - having this extra space would allow for interesting scenarios. I could also see show test case status, or as you mentioned, a live React component next to the code you are editing, to see the changes real-time.

I also like that you allow file editors to be side-by-side with the function editors. This will be important in terms of helping users branch out from their "comfort zone" into those worlds.

I'd be happy and excited to help you experiment with this idea in Oni, and I think that it is doable - the main work right now is to continue to decouple the window rendering / layout from Neovim, and encapsulate it.

There are a few workstreams I'm looking at:

• Part 1 - Markdown preview in Oni (#49) - this is the first step of the window management decoupling, which creates a non-Neovim window in the editor.
• Part 2 - File explorer experience in Oni - this will be a proof-of-concept in terms of hosting multiple neovim processes in Oni, and hosting it in a separate window.
• Part 3 - Splits with multiple neovim processes

Once Part 3 is in place, the foundation would be set for implementing this NFBE concept.

The two bullet points you call out - not having a fixed-height, and being able to hook custom save logic - are definitely doable, we just need to figure out the right design and how it fits in with the rest of the editor infrastructure.

Thanks again for sharing your idea @hoschi , I really enjoyed reading your post!

[bryphe]

@hoschi - Here's the light table video that your proposal reminded me of: Light Table - a new IDE

[hoschi]

I'm glad that you like the idea @extr0py !

I found Light Table when it was in an early stage and they said they want to do what I did, but then switched away to that "we build a new programming language to make this all happen" and so I started something that works with already used languages like JavaScript.

That said, I'm a professional JS freelancer ... but don't know much about VimL. I use Vim for years and also backed (and still supporting) NeoVim. My config is really big and I managed to move it over to use it with Oni, but I never had the need to dive into VimL. So it would be great when you focus on the NeoVim instance multiplexing thing. Even a PR with a basic version would be cool, I think this would give me enough to play with the JS part of it.

we just need to figure out the right design and how it fits in with the rest of the editor infrastructure I draw already some general architecture stuff, but going to make this more shareable.

So my next steps would be:

• share overview of architecture/integration of NFBE and Oni
• refactoring some of my current code so you (and others) get not scared away when you see it ;)
• publish current state of NFBE, I think this would help you/us more to collaborate on the design things

NFBE needs not much API surface when it comes to NeoVim instance, mainly:

• get current cursor positon
• get current buffer content
• set current buffer content

Please reach out if you need additional things from me and/or general feedback of things you have in your mind. Also in general of this window management thingy stuff of this ticket!

So, thanks again and I'm really happy that Oni makes this integration possible and that you like the idea in general :heart_eyes:

[bryphe]

I found Light Table when it was in an early stage and they said they want to do what I did, but then switched away to that "we build a new programming language to make this all happen" and so I started something that works with already used languages like JavaScript.

Yeah, that's a bummer... I was reading up on it yesterday, because I was curious what happened with it. It certainly had some ambitious ideas, and it's interesting that they decided to bail and create a new language.

I think, though, that these core ideas - REPL-based development, live evaluation of variables, breaking code into chunks besides files - are powerful and useful in existing languages. And all of them are directly applicable to anything in the JS ecosystem (JavaScript, TypeScript, Reason/BuckleScript, PureScript, ClojureScript, etc..). It's great that you're still pushing for it 😄

That said, I'm a professional JS freelancer ... but don't know much about VimL.

I'm in the same boat - I work primarily in TypeScript and have wasted a TON of time with VimL. I prefer Vim/Neovim's editing paradigm, but I'd like to edit my configuration in JavaScript (or similiar).

Your next steps sound great! On my end, the API surface for the cursor position & getting buffer content is already there. The setting buffer content is mostly there (via the "Format Document" command), but will need to be expanded.

The main issue will be setting up the UI to be generalized and more decoupled from the Neovim, especially in exposing the window management in such a way to not need a fixed height, navigating between windows, etc - I'll look at that on my side. This will be a natural progression from the other window management projects (file explorer, etc).

I'll keep this issue updated with the progress.

So, thanks again and I'm really happy that Oni makes this integration possible and that you like the idea in general 😍

Cheers, thanks for trying out Oni and for taking the time to share your idea!

[hoschi]

I'm sitting at the task "share overview of architecture/integration of NFBE and Oni" and found probably a problem with my current architecture and the integration into Oni. I just want to ask some (probably really dumb) questions, before I head into the wrong direction ;)

NFBE is at the moment a React+Redux app and all logic to make functions of a file editable is handled in reducer functions. As in React+Redux common, the editor dispatches an action and the state gets changed, UI changes "magically" on its own. If I saw it right you also use Redux, so this should be familiar. E.g. when the user removes a word in a function in a file, in the reducer the state of the corresponding file and function editor get just changed and all is rerendered from React as needed. Totally cool ...

But, Oni/NeoVim won't work this way right? As far what I saw in Oni and nvim, it is more of an event/method API where you can subscribe to events to get notifications e.g.

• cursor position changed
• active buffer/window changed
• buffer content changed
• buffer deleted

and call methods to make changes from outside, like

• closeBuffer(id)
• getCurrentCursorPosition()
• closeWindow()

Is this right @extr0py ? I just want to sure that I have to switch from the Redux state tree logic to something other, because this would be bigger changes and I would probably rearrange my todos a little bit.

[bryphe]

FBE is at the moment a React+Redux app and all logic to make functions of a file editable is handled in reducer functions. As in React+Redux common, the editor dispatches an action and the state gets changed, UI changes "magically" on its own. If I saw it right you also use Redux, so this should be familiar

Yes, I really like this functional approach - it feels magical and enforces a clear separation of 'state changes' vs 'UI rendering'. Oni uses React+Redux for most of the enhanced UI (autocompletion, menu, buffer scrollbar, statusbar, tabs, etc).

But, Oni/NeoVim won't work this way right? As far what I saw in Oni and nvim, it is more of an event/method API where you can subscribe to events to get notifications e.g.

That's correct. Actually, the very first prototype I did with Oni was using React+Redux to do all of the rendering. Performance was a major issue - even though React+Redux is very fast, it still ended up being a bottleneck. The rendering speed - and keyboard responsiveness - are extremely important and are really make-or-break for Oni. So I factored that out in a separate layer, that doesn't use React+Redux.

The other issue is that Neovim, right now, is really the text-editing-engine for Oni. That means, it manages things like syntax colors, highlighting, wrapping lines, etc. And the way it renders out to us is per-cell.

The way I see it, is that NFBE is really another way to manage windows/buffers (laying them out, what sections are visible, etc). I think that we could reuse the current Neovim rendering strategy, and build out these as custom editor/renderer components, if the window manager knows how to lay them out. I've been playing with a prototype of extracting out the <EditorHost /> component and making new IEditor implementations in #622.

Another option would be to plumb some more data into the redux store, but I think it might not be sufficient for this case.

I'd really like to have an architecture diagram at some point to more clearly demarcate this, but I hope that helps.

[hoschi]

Thanks for answering my questions :) I then scratch the in place refactoring and release the current version of Yode (prior known as NFBE) as next step. With the switch to an event/method API I need to change a good amount of code anyways, so this is includes the refactoring then.

I finished my overview diagram:

This shows a high level view of Oni and Yode. It shows which (big) parts need to communicate and where to group which logic. As I need to separate the current version of Yode in (NPM) packages, I added that information also.

The way I see it, is that NFBE is really another way to manage windows/buffers (laying them out, what sections are visible, etc). I think that we could reuse the current Neovim rendering strategy, and build out these as custom editor/renderer components, if the window manager knows how to lay them out.

I don't got this right probably. Yode (NFBE) benefits from another layout instead of the current used "split buffers into window, size is controlled by splits", but the user should still be able to edit other files which other file types (e.g. Markdown) in the same tab. So there shouldn't be separate tabs or something where one only contain Yode editors and the other tab contains "normal nvim" windows. Does this still fit what you wanted to say? What do you mean by "we could reuse the current Neovim rendering strategy"? Does Oni implement the logic to position/size windows or does nvim still do its split thing? Probably I didn't get what "rendering strategy" means here.

[hoschi]

I forgot the events/actions I identified from current code.

Events

• text updated
• buffer/window closed
• file opened
• buffer should be saved to disk

Actions

• set buffer "read only"
• add error UI for connected buffers (e.g. function buffer which contains to file)
• set buffer content for buffer ID
• swap window X with Y
• create buffer
• create window to show buffer

[bryphe]

Thanks for the diagram, @hoschi ! That helps a lot 😄

Yes, it sounds like YodeFileEditor and YodeFuncEditor would basically implement the IEditor API we have in Oni today: https://github.com/extr0py/oni/blob/1ca79c8f1593dd8ccd3d5e21afc1f9c51d2a1fc5/browser/src/Editor/Editor.ts

It seems like, based on the notes in the diagram, that we could reuse most of the pieces (the neovim-backing implementation), plus UI layers like autocomplete/signature help, and then have the Yode pieces on top. The file explorer PR is somewhat relevant: https://github.com/extr0py/oni/pull/622 - except instead of creating a scoped version of NeovimEditor, we'd derive or augment it to add some of the behavior for Yode.

There are a few gaps though (both for supporting this specifically, and for supporting multiplexing in general):

• The interface will be expanded with an onKeyDown handler
• For Yoni, we'd need to override the default save behavior.

Yode (NFBE) benefits from another layout instead of the current used "split buffers into window, size is controlled by splits", but the user should still be able to edit other files which other file types (e.g. Markdown) in the same tab.

The NeovimEditor actually provides the tabs right now - so that should be easy to remove (and actually is removed in the FileExplorer in the item I have above).

Yep, I think the layout is one of the most interesting pieces here. I'd like to add a windowManager concept, which can be used to create splits on the Oni side. Something like:

Oni.window.openSplit(Left | Right | Top | Bottom, editor)

Where editor is an instance of IEditor above.

It sounds like we'll need some more interesting ways to manage layout, for Yode, though, so we'll need to figure out how to expand and generalize this interface. Like I'm wondering, would it be possible to have half the screen in a traditional tab-layout and half in the Yode-style layout?

Does Oni implement the logic to position/size windows or does nvim still do its split thing? Probably I didn't get what "rendering strategy" means here.

Today, Oni relies on Neovim to manage window splits and size/position. But I want to move away from that, and have Oni manage splits and windows (with the Oni.window API above). So I think the important thing is figuring out how to extend that WindowManager API in a way that works for Yode.

And in terms of overwriting the save behavior - if we are using Neovim instances to back the YodeFunc/YodeFileEditor, we might not have to do special syncing on save - we'd have to figure out how we synchronize changes in like the YodeFuncEditor back to an open buffer. If the user is actually saving to disk, we could get the basically for-free - if we are porting the edits back to other open buffers (which seems like what we'd want), we'd just have to listen for buffer changes and broadcast them out to the inactive editors.

And the division of effort you called out looks right to me - if you implement the YodeFileEditor, YodeFuncEditor as implementations of IEditor, then we'd bring them to life in Oni via the Oni.window.open(..., new YodeFuncEditor(someContext))

We'd probably add some command in the command-palette or to a bound key to trigger this. It'd also be cool to hook up the language service, and have an option to open like all usages or all related functions.... just ideas.

I hope this helps! Thanks again for drawing up the diagram and sharing your idea.

I then scratch the in place refactoring and release the current version of Yode (prior known as NFBE) as next step.

Oh, and does this mean that you are going to have a release available? I'd love to try it if so!

[hoschi]

It seems like, based on the notes in the diagram, that we could reuse most of the pieces (the neovim-backing implementation), plus UI layers like autocomplete/signature help, and then have the Yode pieces on top.

Sounds good.

For Yoni, ...

:D

Yode (NFBE) benefits from another layout instead of the current used "split buffers into window, size is controlled by splits", but the user should still be able to edit other files which other file types (e.g. Markdown) in the same tab.

The NeovimEditor actually provides the tabs right now - so that should be easy to remove ...

I looked into the changes of #622 a bit more deeper but couldn't get what you mean here. It removes the tab in the tab line, so you can't close the file editor? Yode should not change the tab behavior of Oni, I think. That was also the main thing I want to say in the comment you quoted. Yode(File|Func)Editor should be able to live in the same tab with other IEditors. At least for the start. With bigger features of Yode, like open functions under cursor or in the same line automatically to provide deeper context, this can change but it is a long way to that kind of things.

Here is the setup from last Yode screenshot in Oni:

Obviously it lacks the features wich get implemented in YodeXXEditor which is (at least) to show the function id/name and things like that, but from a layout perspective it can work. As I said, I think other layouts are more useful, I come to that later again.

One example which needs to be controlled by Oni window manager and not works with current nvim splits, is when I :split an existing buffer:

Now I can't see the whole text of id: 18 anymore, it should look like this:

The splitted clone has not the space to show id: 18 entirely. With nvim split logic you have now a scrollbar in the very last window in the right column.

With the layout used in Yode prototype you would get a global scrollbar:

Which leads to its own problems, like you now don't see the upper left window anymore when scrolled down. Which brings me to:

Like I'm wondering, would it be possible to have half the screen in a traditional tab-layout and half in the Yode-style layout?

This leaves us to a "yes" for this question. You can imagine a normal file editor on the left side and three Yode windows in the right as in the screenshot. This should work good for the case when you have just a bunch of functions you want to focus and a bigger file you wanna jump around in.

Yep, I think the layout is one of the most interesting pieces here.

Indeed :D

It sounds like we'll need some more interesting ways to manage layout, for Yode, though, so we'll need to figure out how to expand and generalize this interface.

The openSplit method and PR #637 is a good start I think. It definitively is enough to start! "swap" operation should also work with this. Another interesting approach in my opinion are layouts used in tiling window managers like Xmonad which I personaly use. I have a long journey with this kind of stuff, started using i3 and then switched to Xmonad because of layouts. By definiton, a tiling window manager uses always the whole space to fill it with windows, instead of a stacking window manager (Gnome, Windows, Mac OS). Just want to say that, because it is confusing that I'm talking about tiling window managers when the Yode prototpye UI has space which is not used by windows. Instead of normal window managers we have the case that we know how much content is in a window and can take advantage of this, instead of real window managers. So, layouts. i3 uses the same methods as nvim, forcing the user to manage the windows by splitting it on his own. Xmonad uses layouts which have logic to place windows in a certain position in size. This way the user just moves windows "up" and "down" in the stack and they get sized automagically. Here is an example of the Tall layout:

See the ascii art at dmw.vim. When you move "S1" "up" in the stack, it swaps its place with "M" so you maxed "S1" in size and made "M" as high as "SX". By the way "M" is master and "S" is slave.

Other sources:

• bluetile - starter GUI for Xmonad
• overview of basic layouts
• video how layouts behave
• full list of all layouts - look for XMonad-Layout-XXX
• real world usage of ThreeColumns
  • imo, really usefull for wide monitors (I have 34" ultra wide screen)
  • source of ThreeColumns

The last video shows the thing I found usefull for Oni. Layouts can have sub layouts. This means you can use a TwoColumn layout with traditional nvim splitting in the left pane and Yodes "makes windows as high as content and stack them" on the right columns. It also gives you more options, here are some thoughts:

• "full" layout modifier to maximize one window but you can still cycle all other ones
• "magnifier" for slave windows allows them to grow and float above other windows, when they have focus
• "tall layout" as used in dwm.vim, which I use with Oni right now ... because manual splitting sucks :D
• column layouts, two for normal sized screens, three for bigger ones
• "accordion" is usefull to cycle through your windows in one tab to search a window you not know by name
• "limit windows" limits the amount of slaves, all other should be shown only as one line split which is really usefull for nvim splits as the when you have more than three slaves their height is so low that you can hardly see anything
• "no borders" would remove the split (used for dragging) "line" which is useless when you have a number row in each window, imho

Using this layout (commbinations) has also the advantage that a plugin (like Yode) can add its own logic for window management easily.

And in terms of overwriting the save behavior - if we are using Neovim instances to back the YodeFunc/YodeFileEditor, we might not have to do special syncing on save

I don't get this. A YodeFuncEditor can't be saved, because is is an buffer without a file association (in nvim lingo). So you would get the error "no file name" if you hit :w in that window. That was the purpose to get a "on save" hook to say "do :w in file XX buffer because it contains the content of this buffer" when the user does :w in a func editor.

if we are porting the edits back to other open buffers (which seems like what we'd want), we'd just have to listen for buffer changes and broadcast them out to the inactive editors

Yode puts all changes to func editos into the corresponding file editors all ~500ms at the moment. This is not only important for saving to disk, it is also nice to see your changes in a function editor happen in the file editor it belongs to when it is visible. For performance reasons I put probably some logic into that case so it is only done when the file editor is visible. If file editor is not visible, just put it right before a save to disk op.

It'd also be cool to hook up the language service, and have an option to open like all usages or all related functions.... just ideas.

Yeah thats also some great things which are then possible with Yode. Or a tree view which lays functions of the current file in a tree and you can jump/open them easily. So many ideas :D

Oh, and does this mean that you are going to have a release available? I'd love to try it if so!

Jupp :) I hope I can finish the publish this week, at least next week. I think it really helps to understand the use cane, when you can play with the prototype UI.

PS Writing these "wall of texts" feels like being penpals :D

[hoschi]

@extr0py I released Yode, check it out \o/ https://github.com/hoschi/yode

[bryphe]

Wow, congrats @hoschi ! I just played with it briefly today, it looks really cool.

I like the polish you have in terms of the Open File / Open Function experience. The idea of editing based on AST nodes is very powerful (and fits in well to the Vim philosophy). I think it could be really cool to use in addition to what the language server gives us - for example, we could open all usages of functions in Yode function editors, or open a corresponding test in an editor.

It's neat that you used AST Explorer and Recast - I've been meaning to try those out.

It's cool to see ideas that can change the way we use screenspace, because as you mentioned in the README, I'm sure we haven't maxed out with the tabs/splits layouts.

Was cool to see Oni in the roadmap too, thanks! 👍 🎉 Excited to work more with you on this!

[hoschi]

Thanks for the nice words :heart:

It's neat that you used AST Explorer and Recast - I've been meaning to try those out.

AST Explorer is a life saver with this things!

It's cool to see ideas that can change the way we use screenspace, because as you mentioned in the README, I'm sure we haven't maxed out with the tabs/splits layouts.

Or reusing all the additional space we have in our pockets like tablets and phones to "flip" some text there and ... these things are bugging me for a long time and Yode is one way to deal with it :smile:

Excited to work more with you on this!

me too :100:

[hoschi]

@extr0py Do you saw https://github.com/neovim/neovim/pull/6619 ? Seems to me as controllable windows but without the need of multiplexing when done with one instance per window. An dedicated instance might be still needed for some special cases, like the file manager thingy you work on, but not for the "normal" stuff. I don't know if this helps you or is easier as the implementation you thought about, just wanted to share it ;)

[bryphe]

@hoschi Unfortunately I don't think that will help so much, since if I understand correctly, it is essentially rendering using the same strategy as before (just adding a way to do that in the terminal). Basically like a floating split 😄 It could be interesting for implementing yode directly in the TUI, though! And it does open up interesting possibilities for other TUI enhancements (easier to build custom menus and things).

The PR I've been watching that externalizes windows is here neovim/neovim#5686 - and that could potentially get us pretty far without multiplexing!

[hoschi]

Ok. Thanks for the clarification :bowing_man:

[hoschi]

I finished the API refactoring and added documentation how to integrate Yode in an existing editor https://github.com/hoschi/yode/blob/master/docs/integration.md The Yode demo app is a reference implementation for this part of the bigger picture above:

I also published it to NPM so you can test it https://www.npmjs.com/package/yode

From my side Yode is ready to test it in a real editor. I still can do stuff without a integration, like

• better naming for function node (generated id at the moment)
• get object functions to work are my next biggest issues, I think. But these don't change the API, because it is internal "stuff". I'm also going to add more issues at github to make this process more transparent.

@bryphe I don't know what all happened at Oni in the mean time ... you're commiting speed is HUGE. As a user of Oni this is really cool :+1: But I have no idea how far the stuff grown in part of plugin management, IEditor, key bindings, ... and if the plan discussed above (months ago ... 999+ commits ago) still holds :grinning: I think for a first version, living in a PR not merged in the near future, could definitively be done without full fledged window management and such. E.g. opening a function buffer in a new split would be a good first start in my opinion. Would love to hear your thoughts :wink:

Also ... should we open a new issue? This one grown very big :grin:

[bryphe]

I also published it to NPM so you can test it https://www.npmjs.com/package/yode

Nice! Congrats on publishing it 😄

On the Oni side, I've been working mostly on language stuff (both language server support, and IME). But ya lots of commits, I've been fortunate to be able to work on Oni full-time for the next few months 😄

The editor stuff + keybindings hasn't really changed too much, besides adding a few new API methods and keybindings.

It's actually great timing, as I'm going to start working a bit on some new IEditor implementations - a file explorer window, and a markdown previewer. So I think those will be good test cases - and maybe we can implement Yode in parallel as an IEditor?

I think for a first version, living in a PR not merged in the near future, could definitively be done without full fledged window management and such. E.g. opening a function buffer in a new split would be a good first start in my opinion. Would love to hear your thoughts 😉

This seems pretty doable! I think I'll loop you in as I start some of these other IEditor strategies, and we can see how we can hook up Yode in the process.

Also ... should we open a new issue? This one grown very big 😁

Sure, that would be great. Perhaps we could have one tracking Oni + Yode integration? It'll be an excellent test of Oni's extensibility. I'm excited about it because I think the next step for Oni is to demonstrate ambitious new editing paradigms to make you more productive - and Yode definitely fits in there.

One idea I had was to integrate Yode with the Find-all-references functionality, such that when execute Find-all-references, it pops open Yode splits for each of the functions that contain a reference.

[hoschi]

I've been fortunate to be able to work on Oni full-time for the next few months

Nice!! :100:

Sure, that would be great. Perhaps we could have one tracking Oni + Yode integration?

I created #894 and add my answers/questions there

[CrossR]

I think this is the right place to stick this, but maybe its worth a separate ticket so it can be more easily found / commented on.

Now we have externalised Tabs, It'd be nice to start getting the more "common" tab management bits commented on, so in the future it can be added, since I've seen some of the make new Window stuff is being added etc.

Of the top of my head, this includes :

• Rearranging them.
• Removing a tab to spawn a new instance.
• Bringing a tab back in and combining the Oni instances.

All of them end up being pretty complicated I think, so I wanted to start some conversation around them.

Rearranging Vim tabs is easy, there is tabmove. Drag, send the command for the new index, done, I think? However, when that then becomes buffers, I think it becomes a lot more awkward. I don't know an equivalent command for buffers, but that could be that I haven't used it. And if we don't update the index, then commands like next buffer could move from Oni tab 1 to Oni tab 7, as they were index 0 and 1.

Removing a tab to spawn a new instance comes with issues like if the buffer is modified, plus contextual info like line number and cursor location, how do they get over to the new instance of Oni?

Bringing a tab back has all the same issues, but instead applied to loading into an existing Oni instance instead of a new one.

Honestly, the second two are a lot less important for me, I mainly do that in editors where the split support isn't that good, which isn't the case in Vim. The first can be awkward, since I'll start going down the rabbit hole of where does the function go, and end up 10 files in, and then want to move Oni buffer tab 10 back to Oni buffer tab 2 so I can swap between them more easily.

Luckily, that case is also solved by the style of editor it looks like @hoschi is working on, where instead of 10 whole files, I'd have the few relevant bits all next to each other!

Still, I think the moving is stuff people expect, so it should probably be thought about, to determine if its needed and how it could be added.

[badosu]

@bryphe Does the recent window management system and neovim multiplexing address this issue?

[hoschi]

@bryphe Am I right that these neovim PRs would enable this feature?

• per window grids
• externalize windows - neovim PR
• externalize windows - local PR