Internals *too* hidden

[ELLIOTTCABLE]

So, I want to ‘wrap’ the focus-toggling with some of my own behaviour (:set nonumber, :call NoShowMarks!, :hi NonText guifg=bg, etceteras). You have, however, localized basically everything under s: / <SID> … so I can't access any of it without hackery. Maybe open up EnterFocusMode() and ExitFocusMode?

(Alternatively, if you're feeling Real Nice, you could extend it with a callback or similar of functionality to preform post-setup; it'd be nice if I could hook in after you mksession!, so that I don't even have to manually restore the additional state I want to change; your state-restoration would squash my extra changes along with yours …)

[merlinrebrovic]

Hi Elliott. I agree with you that it's closed down and very opinionated on how it works. I wrote it to solve a specific problem 3-3.5 years ago and, as such, it works for me, not everyone else.

Unfortunately, as much as I would like to, I'm not able to work on it or improve it at this particular moment. That being said, the code is open and its license permissive, so you're more than welcome to fork it and improve it as you see fit.

This "callback or similar functionality" looks interesting. If you extend focus.vim with it in a way that's backwards compatible, I'll take a look if it can be merged back here.

Thank you for your interest in focus.vim.

[ELLIOTTCABLE]

@merlinrebrovic I'm pretty new at VimScript; but would a really simple PR that un-privatizes the two functions mentioned above (EnterFocusMode and ExitFocusMode) be accepted? (Unfortunately, I suspect a good callback-receiving API is way beyond my VimScripting ambitions)

[merlinrebrovic]

Unfortunately, making private functions public to access internals is not very clean and invalidates a lot of encapsulation in the plugin, so I would not be willing to accept a PR like that.

[ELLIOTTCABLE]

I totally understand that … but I'd really posit that the actions of ‘starting’ and ‘stopping’ aren't really internals? The vast majority of plugins that do something similar to this expose three(ish) public functions: EnableThing, DisableThing, and ToggleThing (the last mostly as a convenience) … I guess I don't quite understand how you perceive those first two as ‘internals?’ On Sat, Mar 26, 2016 at 12:08 PM Merlin Rebrović notifications@github.com wrote:

Unfortunately, making private functions public to access internals is not very clean and invalidates a lot of encapsulation in the plugin, so I would not be willing to accept a PR like that.

— You are receiving this because you authored the thread. Reply to this email directly or view it on GitHub https://github.com/merlinrebrovic/focus.vim/issues/14#issuecomment-201893618

[merlinrebrovic]

Elliot, I think we're on the same page here. I agree with you that this should be done in a way it's easy to plug in your preferences in some way, either through callback code or by passing preferences at certain points in time (eg. Pre/Post Start/Close).

Those points in time/events/hooks should be public, current settings could be defaults that can be overridden, and the engine driving everything should be private. My whole point, and if you look at the code you will probably agree, is that focus.vim is not written in a clean way that allows the behavior described above.

Exposing current private functions is OK for private copies of the plugin (eg. someone wants to hack it on their computer), but I'll accept a PR only if it significantly improves the overall usage experience and expendability.