hkupty
commented
6 years ago When I started, I was focusing on changing the things 'under the hood' such as settings of plugins, not actual screen/buffer/window state.
But now that you mention it, I think it makes a lot of sense to provide that, though it might be too much to always add on the session (which was designed to be replayable) meaning that the data carried over might be stale when it's replayed.
I'm not sure how much implementing that would increase the API complexity.
Maybe it'd be better if you collect that when creating the function, similarly to what I do on the sample doc file.
That way the complexity is kept within the scope of the handling function and it doesn't overcomplicate intrinsics of impromptu.
Does it make sense?
KillTheMule
My use case for menus is having the user choose an entry, after which a certain file is put into the buffer (via ":read"). Now just running the command inserts into the current buffer... which is the scratch buffer! Can you add information about the buffer we're coming from or something like that? Note that this would solve my use case, but I could not use ":read" which just inserts where the cursor is. Thinking about it, most buffer modifications would involve the original buffer of course, so maybe there's a way to close the scratch buffer and run commands in the original buffer? But I'd say neovim provides enough infrastructure so you can just provide the original buffer number somewhere and the user (=impromptu user, not the final user) can deal with it.
(e) Thought about it some more, an easy solution is to just run
command("bp")before the final command, that works nicely. I'm still leaving this open, maybe you have some thoughts about this.