feat: add dev log toggling

[rlch]

@rlch the reason I don't want to really entertain the idea of "toggling" the dev log is that it can be opened in any possible way that nvim allows opening a buffer so the whole idea of toggling is quite complex since you might be toggling a tab or a split or it might replace the current window, which means it's quite hard to know what is being opened or closed. I did look into this at some point last year and it proved to be quite complex to try and cover all these cases. The above command would work if you opened a split but not if you opened this buffer using a tab.

I have only accounted for the dev log buffer being opened as a split. Creating this PR as a small foundation to build off to properly implement this feature.

closes #84

[rlch]

@akinsho Thoughts on allowing the developer to specify a function which handles closing the window? Seems logical seeing as the developer already has control over how the buffer is opened.

[akinsho]

@rlch I think if a user is going to go as far as creating a custom opener or closer I'm not sure what the benefit is to having it as part of this plugin? I'm really not sold on the complexity of this whole issue, it doesn't really tie together nicely. It makes me wonder if the log buffer should be only one type of window e.g. a tab or a split and then it's more consistent but if it's as versatile as I designed it to be then I don't think this plugin needs to invent complex toggling behaviour or offer an entry point for that complexity.

coc-flutter doesn't do this as far as I recall and I think not getting into this complex buffer toggling logic business is a good idea as I can just envision endless bugs or questions about how do I toggle X or can we pass X to the toggler function and so on and so forth.

My main goal at this point with the plugin is to reduce the maintenance burden as much as possible so any feature or functionality that gets added should I think be aimed at reducing the work of maintenance or at least should definitely not add to it (by much/at all) since I find myself really pressed for time atm and get daily issues/feature requests across like 4+ plugins 😭

[rlch]

@rlch I think if a user is going to go as far as creating a custom opener or closer I'm not sure what the benefit is to having it as part of this plugin? I'm really not sold on the complexity of this whole issue, it doesn't really tie together nicely. It makes me wonder if the log buffer should be only one type of window e.g. a tab or a split and then it's more consistent but if it's as versatile as I designed it to be then I don't think this plugin needs to invent complex toggling behaviour or offer an entry point for that complexity.

coc-flutter doesn't do this as far as I recall and I think not getting into this complex buffer toggling logic business is a good idea as I can just envision endless bugs or questions about how do I toggle X or can we pass X to the toggler function and so on and so forth.

My main goal at this point with the plugin is to reduce the maintenance burden as much as possible so any feature or functionality that gets added should I think be aimed at reducing the work of maintenance or at least should definitely not add to it (by much/at all) since I find myself really pressed for time atm and get daily issues/feature requests across like 4+ plugins 😭

Yep, I completely empathize.

Is it worth closing this PR? Or do you think enforcing, for example, a VSC-style debug console (horizontal/vertical) split if a toggle option is enabled is a better idea? That way, we can have backwards compatibility with people who want their own attaching behaviour and a sane-default for people like me who want to be able to toggle.

[RobertBrunhage]

Adding an additional pain point regarding not having something like this.

When we manually close the devlog split and open it from the buffer again we lose the auto-scroll functionality. Having a way in the plugin to either toggle or just open it again, like a FlutterOpenLog (would also apply the autoscroll). This would let us not having to re-implement the auto-scroll logic in our neovim config.

To clearify this would just open the log in the current buffer and apply the auto-scroll logic already in this repo.