Reduce scope of internally-used functions

[litoj]

Hi, I recently noticed that quite a few of the plugins I use are polluting the global namespace often without the necessity to do so. I wanted to ask if all the globals like these functions could be handled in another way (standard requiring of a module or something not putting more stuff in the global namespace).

unception_edit_files
unception_escape_special_chars
unception_get_absolute_filepath
unception_handle_bufunload
unception_handle_quitpre
unception_notify_when_done_editing
unception_pipe_path_host_env_var

I know this sounds niche, and it probably is, but I like performance, and considering how often I actually open another nvim inside nvim it is certainly better to have the globals cleaner and for that moments of need use a normal module require.
I don't fully know the inner workings, so it might be unavoidable in this usecase, but I can't imagine a situation that would make it so.

[samjwill]

Hi @JosefLitos! I appreciate the suggestion!

For some background, the decision to use a handful of globally-scoped variables for configuration instead of a setup function was consciously made. Please see this blogpost for what is more or less the rationale for preferring global configuration variables to a setup function. Unfortunately, said blogpost was not written until after unception's initial release, so the guidance to wrap the configuration options in a globally-scoped table did not occur to me at the time of writing, and I followed the more traditional means of prefixing the options with the plugin name.

As you're likely aware since you did not mention the configuration-related variables specifically, since these are already used by people in their configs, changing them at this point without breaking backwards compatibility isn't really going to be a possibility, even if I wanted to go back on the decision to avoid using a setup function.

However, it is a fair point that the functions that you've pointed out that the user is not expected to interact with could likely be reduced in scope or at least wrapped together, whether via a module as suggested, or otherwise.

Regarding the comment about performance, I would be surprised to see any real performance difference even if the functions were lazy-loaded, as the overhead for simply defining the functions without invoking them should be almost nothing to my knowledge.

With that being said, I will definitely consider addressing this if I can find the time.

[litoj]

Thank you for mentioning the blogpost. It was an eye-opener to me in some ways.

My performance concers were rather of the theoretically increased time of lookup of other variables in the global namespace (obviously negligible with such low numbers like 60).