-
Notifications
You must be signed in to change notification settings - Fork 299
Conversation
add inactive buffers to buffer manager add inactive buffer class which is distinct from buffer class add icon class for file fn for menu icons
experiment with command to delete buffer
use this as buffer source as bufbyId is inaccurate
vim/core/oni-plugin-buffers/index.js
Outdated
const bufferMenuItems = buffers.map(b => ({ | ||
label: `${active === b.filePath ? b.id + ' %': b.id}`, | ||
detail: truncateFilePath(b.filePath), | ||
icon: Oni.ui.getIconClassForFile(b.filePath), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for hooking up the file icons here!
vim/core/oni-plugin-buffers/index.js
Outdated
|
||
const deleteBuffer = menu => { | ||
if (menu.selectedItem) { | ||
//TODO: Command to execute buffer delete by Neovim |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We could add a buffer.delete
command to NeovimEditorCommands
, which has access to the neovimInstance
to execute the command directly.
vim/core/oni-plugin-buffers/index.js
Outdated
@@ -0,0 +1,80 @@ | |||
// @ts-check | |||
const path = require('path'); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for creating this as a plugin! Great exercise for our plugin API.
Change is looking great to me. Stoked to have this in - lots of time where I'd find this functionality useful. Could we add a default binding for this as Regarding this todo:
One plan I had for that was to add an optional argument to the
|
@bryphe thanks 😄 . public openFile(file: string): Promise<Oni.Buffer> {
Log.warn("Not implemented")
return Promise.resolve(null)
} So not sure how this is finally resolved to open the buffer. EDIT: Found it wasn't sure how it was hooking up to the active editor but found the function definition. Also re. where to add the buffer delete would this be to the |
Ah ya, sorry, I guess we'll have to implement this. I was thinking something like:
And if we had a second argument like
I'm starting to move some editor-specific commands from the global commands to the editor instance, to give us a better separation (and, in preparation of hosting multiple editor instances). It's in #1316 , so you can at least see how I'm starting that. If it's easier to make a global command for this PR, that's fine too. |
@bryphe Ideally I'd prefer to add the change were it'd be most useful long term although an issue I faced having just tried this out is that it doesn't actually read the non-implemented function understandably, can you point me towards how to get it to look at the correct function? I'm not clear on how it calls the function in neovim, From #1316 seems there are a few changes that will be happening do I need some of the larger changes to be incorporated for this to work or is there a smaller change I can make to get this working. its all in all a small change that can easily be copy/pasted over later either way |
Hmm, is this regarding
Ah I was just trying to give you some visibility in terms of how I pictured things changing (since right now, most commands are 'global'). But for this, feel free to create a global command or whatever is easier. As you mentioned, it's a pretty small tweak to move it around. |
add buffer delete command
@bryphe is it possible currently in Oni to create a binding that only applies when a menu is open?. I realise that I've now added several commands all of which can eat up bindings and are only valid when the menu is open |
Yep! That's the third argument to
The last argument is a We have other ones, like to only make the binding available for normal mode:
Hope that helps! And I saw you were waiting on the change for |
@bryphe thanks for explaining this PR I think is almost done although I'd like to hide the implementation details about passing in a third argument for the menu bindings from the user is it possible to create a command that has already taken care of these details for the user from the plugin makers perspective I know that there is commands file which has done that for certain command so would I need to add a command there or is there a way using the plugin API to accomplish this |
Awesome! Yes, I agree, it's simpler to just have the binding be enabled when it makes sense, and not other times. There's a couple different ways to accomplish this:
I like the explicit |
vim/core/oni-plugin-buffers/index.js
Outdated
Oni.commands.registerCommand({ | ||
command: 'bufferlist.vsplit', | ||
name: 'Vertical Split Selected Buffer', | ||
execute: () => openBuffer(menu, 'vertical'), |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is where I was mentioning you can add an enabled
filter - like - so you could bake in the filter to the command, instead of having the user needing to know to apply the filter. It definitely is more convenient to do it here, so that we always do the 'right' thing - and the user doesn't need to think hard about it.
Thanks @bryphe it's almost there just tried the filter method you recognised but ran into a type error with |
Just pulled in the new |
@bryphe all done with this now thanks for merging the Whilst trying to hook up the buffer delete command I realised that currently in order to properly respond to a buffer being deleted oni is entirely dependent on a subsequent I currently have no idea how to do this without forcing a bufEnter event which is what I do to ensure the mapping works, (or manually filtering out the deleted buffer which we discussed previously). I've left them in as I believe they can be useful hooks to have for some other EDIT: My current solution has the undesirable side-effect of if a user closes a buffer which isn't the current buffer as I force a |
Log.warn("Not implemented") | ||
return Promise.resolve(null) | ||
public async openFile(file: string, method = "edit"): Promise<Oni.Buffer> { | ||
const cmd = new Proxy( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we have this call into the activeEditor
's openFile
method, as opposed to duplicating the logic in NeovimEditor
's openFile
method? I'd like for the EditorManager
to be agnostic to Neovim
, if possible - ideally, the EditorManager
could support all sorts of IEditor
implementations - even ones that didn't depend on Neovim.
vim/core/oni-plugin-buffers/index.js
Outdated
// This line forces vim to navigate to the next buffer after deleting | ||
// NOTE: This is essential as otherwise Oni does not properly register the buffer | ||
// delete event | ||
await Oni.editors.activeEditor.neovim.command("bn") |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
If this will always need to be done along with the bufferDelete
, perhaps we should just push this inside the bufferDelete
method?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
In addition - can we check if the current buffer's id (activeEditor.activeBuffer.id
) is equal to the one we're deleting? If I understand correctly, we only need to do the bn
if the buffer is the same, so if activeEditor.activeBuffer.id === menu.selectedItem.metadata.id
.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
👍
Actually found an unusual bug, it seems that using the filterFunction messes with the meta data fields I've added to the menu Items which the plugin depends on for its functionality 🙁 , I'll look into that report back once it's sorted out |
vim/core/oni-plugin-buffers/index.js
Outdated
|
||
Oni.commands.registerCommand({ | ||
command: "bufferlist.delete", | ||
name: "Delete Selected Buffer", |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Could we add a common 'prefix' for these, like:
name: "Buffer: Delete",
detail: "Delete selected buffer",
```
Trying to organize the commands a bit 😄
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@bryphe did you intend for the commands to be in caps with the space there, I've changed the command to be buffer:action
as from looking at the commands none start with caps and none have spaces in them ❓
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, no set standard yet, but here's what I'm thinking:
- command: camel case / lowercase - ie,
workspace.openFolder
- name: noun + verb, capitalized -
Workspace: Open Folder
- detail: sentence case -
Set a folder as the current workspace
(not a great example, but hopefully that helps).
I think the commands you have look good - I was thinking for the name
/detail
fields.
Like looking at the command palette we have today:
The 'Workspace' ones look good to me, but the 'Show Errors' looks like it's just kind of floating. It'd be nice to group it with some other error/diagnostic related commands (maybe like Errors: Show
, Errors: Go to next
, Errors: Go to previous
, etc..)
Thanks for the details, @Akin909 ! I left a few comments on the PR. I'm not exactly sure how the buffer lifetime works, or why'd we see inconsistent results. The buffer navigation seems like a reasonable workaround, but I'm wondering - can we check the case where the deleted buffer is equal to the current buffer, and conditionally execute |
Tbh I'm sure there's some reasoning there somewhere or a way around this issue but from reading the vim docs and autocommand hooks I'm not clear on where is the earliest correct place to hook into following a buffer being delete aka what action is unconditionally always run following a As for the workaround I could pass in Also looking at the comments and will make those changes |
add buffer navigation following deletion rename commands
fix comment typo
All done 👍 I've changed the command names, moved the post deletion navigation to the command itself, and removed the |
Looks great, @Akin909 ! Bringing this in now. Really excited to start using this and have this part of the next release. Thanks for the contribution! |
This PR adds a open buffers menu, which fixes #1173,
Changes:
inactiveBuffer
class to ensure active and inactive buffers are passed in (bufferManager only had access to the visited buffers)Todo
Fix
openFile
typings (oni-api
)Add commands to open splits, tabs and delete buffers
Add
InactiveBuffer
toOni
api and referenceOni.InactiveBuffer
Add
metadata
field tomenuItem
to store original value of absolute file pathFix buffer population -
buffersById
inbufferManager
does not reflect buffers in vim.Truncate filenames