[feat] Per-filetype cell patterns

[marty-oehme]

Love the plugin you have created!

One thing that became apparent relatively quickly with my workflow (working sometimes in pure python files, often in a mix of markdown and quarto files) is that a single cell pattern is not enough for me.

I was working with a local buffer override of the cell determination logic in my configuration for a bit, but thought this might be useful for the plugin itself.

This PR does three things:

1. Adds a new configuration option called ft_cell_patterns which is a table mapping vim filetypes to cell pattern strings.
2. Adds a new buffer-local vim.b.pyrepl_cell_pattern which will be picked up by the plugin.
3. Introduces a single function which finds the correct cell pattern at any moment, giving precedence to the buffer-local variable > the ft_cell_patterns mappings > the global default. That means if nothing is changed previous user configurations work without changes.

It also adds some documentation for this logic (though I am not sure how well the explanations are written).

Let me know if this is a feature that you could see implementing into the plugin - I am also happy to change any aspects you think don't make sense or should work differently.

[dangooddd]

Thank you for PR! I love simplicity of this change. Before merging, can you clarify use case for buffer local overrides when ft_cell_pattern exists? I am just curios. Aside from this LGTM.

[marty-oehme]

I see 2 benefits behind the buffer-local vim.b.pyrepl_cell_pattern:

1. allows users to simply set the variable directly in their ~/.config/nvim/ft/markdown.lua filetype-specific settings and not have to deal with the mapping table on plugin start
2. allows simple dynamic overrides - you can script any event to trigger the override (e.g. via key mapping, or if you for whatever reason have a single file with multiple cell types) simply by changing the variable

and, selfishly, 3. because that's how I had it set up in my dotfiles as a local override before adding this feature ;-) If you think this complicates the public API too much I have no issue with taking it out, just lmk.

As an aside: I also have two other small features that I would submit separately as a PR at some point (exposing the repl state and toggling the window on/off) but would maybe raise it as an issue first so we can figure out how much you're okay with adding more stuff to the public API.

[dangooddd]

I want to keep the core of the plugin minimal. I like idea behind this PR, and users should be able to configure cell pattern per filetype. To allow even more scripting potential, maybe we can allow cell_pattern be function? This way ft_cell_pattern can be removed. I quite like this idea, for example:

{
    cell_pattern = function()
        if vim.bo.filetype == "markdown" then return "^```.*" end
        return "^# %%%%.*$"
    end,
}

Do you like that approach?

About the second part of your comment: I am fine with creating toggle command and see it usable. But while I see current plugin API stable enough, I want to keep internals away atleast from main require("pyrepl") module. User that want to know is REPL running, can use require("pyrepl.core").get_chan() directly (good idea is to document that possibility though).

[marty-oehme]

I think that's also a worthwhile alternative approach - not least since it allows the user to re-implement the extra variable I introduced relatively easily in the function itself (by just having it return vim.b.pyrepl_cell_pattern from there).

I like it, and it accomplishes the same thing without adding the extra config option! If you're fine with me taking another stab give me a day or two and I can re-implement and document the new approach.

[dangooddd]

Of course I am fine with that. Thank you!