This is a neat idea! 😀

But I'd like to avoid a keymap DSL. And generalize it to work with snacks.terminal (or any other terminal plugins).

Naively, what about a couple more recommended keymaps, but with autocmd and buffer-local? Like:

vim.api.nvim_create_autocmd("FileType", {
  pattern = "opencode_terminal" -- already set on snacks.terminal - would have to set in Terminal provider too
  callback = function()
    vim.keymap.set({ 'n', }, '<C-u>', function() require('opencode').command 'session.half.page.up' end, { desc = 'opencode half page up', buffer = true })
    -- ...
  end
)

I'll admit it's a bit lengthy. Idk if Neovim's API provides a more concise way to set filetype-specific keymaps? We could use ftplugin but that'd require a way to config it unfortunately.

Is it possible to find what the user has already bound to Neovim's scroll functions?? Then we could bind the opencode_terminal versions to those ourselves, with no effort from the user, and guaranteed to match their expected keys.

I disagree I strongly believe that dsl is a way better to set keymaps than callbacks especially given that you already have all the commands as strings. Plugins with a lot of keymaps like https://github.com/dmtrKovalenko/fff.nvim should exclusively use this approach

I'll admit it's a bit lengthy. Idk if Neovim's API provides a more concise way to set filetype-specific keymaps? We could use ftplugin but that'd require a way to config it unfortunately.

The behavior I provided by default I am 100% should be coming by default

Is it possible to find what the user has already bound to Neovim's scroll functions?

Nothing what I know about

Plugins with a lot of keymaps like dmtrKovalenko/fff.nvim should exclusively use this approach

I guess I'm trying to avoid the level of complexity that warrants a DSL. I want this plugin to be a simple bridge between Neovim and the native opencode TUI first and foremost. I'm wary to make it hyper Neovim-y when e.g. https://github.com/sudo-tee/opencode.nvim or https://github.com/olimorris/codecompanion.nvim do that well already.

Let me think on this some more. I like the functionality you've added. Just considering how it best fits into the rest of the plugin 🙂

I wonder how many Neovim users already customize their opencode keybinds to be Neovim-like 🤔 I think the way their config-ing works, it'd be possible to inject configuration when launched by the plugin. (Similar outcome, but the keymaps would work in terminal mode, not normal mode. And still require a configuration DSL. Just thinking aloud.)

If we did introduce a keymap DSL for this feature, do you think the existing recommended keymaps (and maybe more) should also move to it, for consistency? This is my main reference for avoiding DSLs and default keymaps. But to your credit, it does say "An example for uncontroversial keymaps are buffer-local mappings for specific file types ".

I think it might make sense to not even expose those at the config level because most neovim users would expect this behavior by default, because if they have remapped the for example they will anyway map it like :map <smth> <C-u> which will keep working for this specific usecase unless nnoremap is set

If we did introduce a keymap DSL for this feature, do you think the existing recommended keymaps (and maybe more) should also move to it, for consistency

No because the DSL usually make sense only at a buffer level, for all the global keymaps I would still expect the global keymap. At least this is what I do in fff.nvim https://github.com/dmtrKovalenko/fff.nvim

I think it might make sense to not even expose those at the config level because most neovim users would expect this behavior by default, because if they have remapped the for example they will anyway map it like :map which will keep working for this specific usecase unless nnoremap is set

Oo that is a great point about the recursive maps working in our favor!

Removing the configuration aspect makes this a much easier merge for me. That's really the only bit I'm concerned with because it adds user-facing complexity.

Does that work for you?

you broke the original behavior

Sorry could you clarify? It's working for me as discussed above. But I could be misaligned on that. None of my changes were meant to change functionality.

Ah you're right, looks like setting the filetype on the built-in terminal doesn't trigger the autocmd. My bad! I must have forgot to test that one. Will look into it.

Now you broke all of my keymaps making <C-u> in every buffer to scroll opencode. Please if you want to push into my branch test your changes

shh my changes originally have been at least working

Sorry about that, I was a bit rushed irl! Should have done it on a different branch. Thanks for fixing 🙏

It's working for me now in both terminal and snacks.terminal. Let me know if I missed anything. Otherwise I think this is good to go!