Proposal for Changes to `autoload/slime.vim` about vim-slime HOT 6 OPEN

hi @jam1015

I received the notification for this (I'm here), but I don't have a lot of bandwidth at this time.

Let me come back to this soon and give it my full attention.

from vim-slime.

Hi! to answer your questions:

1. Can the environment become invalid? The environment can definitely become invalid; if all target repls are closed the environment is not valid anymore, and no possible config can be correct. Whether it can be correct again later with no intervention differs by target; with Tmux it seems possible, because the same socket/session/pane/window combo can reappear, but with Neovim terminal it is not possible, because the same jobid will never reappear.

2. Can the config become invalid? Yes; The environment becoming invalid is a sub-case of the config becoming invalid. Also the user can run :SlimeConfig again and make a typo. Or some other script can wipe buffer variables including the config. Anything can happen.

I don't understand the annotations you've made on my diagram in yellow and blue, but that's ok. I can do it your way on the left, but as I mentioned, the code is slightly less elegant.

OK so here's what I'll do, unless you explicitly object: I'll open two PRs, one with the approach on the left, and one with the approach on the right (whose code is ready to go). You can merge your preferred version, or neither. I'll hopefully get to it in the next couple of days.

from vim-slime.

Hi @jam1015

I read though all this, but it remains somewhat abstract.

Some context: back in 2007, I wrote this. I'm not even sure if that's the original code, because I remember it to be even shorter. It was so short you could paste it in your vimrc and start using it right away.

I think my original philosophy was: so little code, anybody can debug this. By extension, if you misconfigure or something goes wrong, you can fix it yourself. (in some way, that reminds me of Right to Repair)

What I would call "slime core" does very little. It generates some config and sends your text down a destination.

…

In my mind, there are 3 customization points in vim-slime:

• how to generate config: which varies for each target, but also in complexity and what reasonable defaults would look like
• how to send text to a target: obviously depends on the target, usually (and ironically) less complicated than config
• text-processing pipeline: what, if any, changes need to be made to the text before sending to the target — varies by target, REPL, and language

…

As you might have seen on the vim-slime-ext-plugins side of things, I think the solution is to allow the user to "plug" into these customization points

• a simpler core, with overridable functions
• but reasonable target-specific implementations

…

So, stepping back into your proposed changes:

• why do we need to validate config? env? (how did we get there?)
• why not let it crash? (how easy/not for the user to self-diagnose?)

I used to have a discord channel to discuss this — it might be an easier/faster medium to move this forward. Let me know.

from vim-slime.

discord: https://discord.gg/CTHR7wusVY
(we'll try this as an experiment)

from vim-slime.

Hi! Thanks for your response, especially the insight into minimalist philosophy of the plugin. Of the three points of customization, my proposed changes focus on the configuration generation step. I'd say that I'm approaching my proposed changes with 'clear user feedback' as the main goal with modularity and minimalism as complementary goals.

Concretely, with my proposed changes, for a target with the validation functions implemented, your flow chart is expanded to look like:

So to answer your two questions in reverse order:

• Why not let it crash? Because it is generally a more pleasant user experience when errors are gracefully handled and useful feedback is given to the user. You noticed that, the way it is now, when the Neovim target is misconfigured, ugly looking errors pop up. Not a nice experience. On the other hand, it could fail 'silently'. Imagine you mis-type the configuration with a tmux pane as the target. You send, and nothing appears. Some useful feedback that can be provided is whether the text is being sent off to nowhere or if it is being sent to a pane in a different tmux socket running somewhere in the background. This feedback is definitely in service of helping the user fix things when something goes wrong.

• Validating the environment and the config is the way to provide the useful feedback. In my branch (validate_config ) I implemented it as cleanly as I could, which meant making the backwards-compatible changes I in autoload/slime.vim as well as the Neovim target code. The changes allow each function in the target code to do it's job, without worrying about correctness (the config function just configures, doesn't have to worry if the config is making is valid, that gets checked by ValidConfig called elsewhere). This has the added bonus of letting users more easily make their own override functions for targets that don't have validation implemented in the target code yet.

I think these changes/the advantages will be more tangible if I open my PR and you try out the Neovim target again.

I'm happy to chat on Discord but I think these Github comments are well suited to their purpose.

from vim-slime.

Follow-up questions (based on your diagram)

is the environment valid?

does that evolve over time? can it be valid now and invalid later? (I think so, but I'd like to discuss circumstances)

is there a valid config?

same here — is that something that can be true now but false later?

…

Context:

I think we can shove most of the logic in 2 "boxes"

• "configure" : handles "prompt user", "validate config", and "notify user"
• "send to target" : does actually sending, but could sanity-check itself first — if things have changed, "panic" and re-trigger "configure"

This allows most plugins to stay as they are, while allowing for more flexibility. I tried to reconcile this using both diagrams.

from vim-slime.