martanne
[Feature Request]:Resize window/split
What feature would you like to see?
So apparently there's no way to resize windows? Maybe I'm missing something, but 'size' and 'window width' appear neither in the FAQ, nor the manpage, nor :help. I believe this is a huge oversight.
https://github.com/martanne/vis/issues/1279#issuecomment-3563352153
Also, "this needs to be fixed" is not exactly the tone of voice I would expect in the volunteer-driven FLOSS project. You may get refund of all money you paid to the project.
Hey, first of all thanks for all the development efforts from everyone involved. I really enjoy the editor so far and I find it amazing how little config it needs to make it a viable alternative to my nvim setup.
I would also greatly enjoy resizable splits or tabs. I know they are listed as a non-goal because this functionality can be replicated with tmux, etc. I still want to try and make a case for a little more advanced buffer management:
I think it is totally reasonable for a modern editor to support editing multiple buffers and switching between them quickly. Vis even supports this through splits as is through splits. There are numerous advantages above using different sessions in e.g. a tmux. You can share copy registers, searches or even command history, which makes coding in multi file projects (most projects these days I guess) much more convenient. Of course the same can be achieved by some custom tmux scripting and plumbing, but if multiple users are going to use these features I don't see reimplementing a (very small) subset of tmux' features as a bad thing. There can be much better integration and it brings more possibilities for plugins. I am not sure about the implementation and maintenance overhead, but I imagine since multiple "parallel" buffers are already supported, it would mostly be about TUI code.
This really needs to be fixed.
I agree with @mcepl, this is a totally inacceptable attitute for a free open source project. (I hope) feedback here can be helpful for both maintainers and users, but this is not proper feedback. It is very unpleasant for both maintainers and fellow users and can hurt the motivation of developing and advancing projects like this badly. If you want to request features in the future, it would be helpful to use a more humble and understanding tone and state as detailed as possible what feature you would like to request and why you would see it fitting for the project.
Returning to the actual title of the issue, I don't think tabs or resizable splits go against the vision of a lean and bloat-free text editor. From my point of view this has become a basic feature for editors nowadays, especially ones targeted at "computer stuff"/coding. I think pretty much all other "modern" editors support it out of the box and I don't think it is an anti-feature as long as it does not come with a heavy maintenance burden.
Thanks for y'all's input. I did not realize that came off as insensitive, and I'll try to be better in the future.
I think it is totally reasonable for a modern editor to support editing multiple buffers and switching between them quickly.
Which is exactly that non-goal. Yes, there could be some benefit, but there are reasons why not to use (neo)vim, and why vis is still around 4% of vim’s C code base, Martanne was too optimist about Vim’s size, it is 540k LoC of C these days.
[...] features have been added without a seemingly coherent design. By now it weights in at over 300K lines of C code of varying quality. We think this is unacceptable and off by at least an order of magnitude.
I fully agree with the sentiment as stated here. However I would assume that very basic ui features like tabs/window resizing are not the reason for (n)vims feature creep and insane size. Also I want to point out that vis does already support "editing multiple files and switching between them quickly", so it does not seem to be as much of an anti-pattern as it is made out to be.
Ultimately I understand that if the cost for a feature is too big it does not make sense adding it. However I am not sure the overhead for this specific feature is actually as big as it is made out to be. I think it is clear that you have no interest in implementing the feature. So I think the question would a lean PR with this feature be accepted and how lean is lean enough for a feature like this?
EDIT: Also I am not sure where you are getting 540k from, for all I can see its between 330k and 360k depending on whether you include headers. Counting actual lines of code I think vis is more at ~10% of neovim.
EDIT2: After looking at the wiki page again I also noticed that all the non-goals from vim listed none refer to basic ui features, instead focusing more on custom interpreter, custom regex, etc.
EDIT: Also I am not sure where you are getting 540k from, for all I can see its between 330k and 360k depending on whether you include headers. Counting actual lines of code I think vis is more at ~10% of neovim.
Wrong repo. https://api.codetabs.com/v1/loc/?github=vim/vim
EDIT2: After looking at the wiki page again I also noticed that all the non-goals from vim listed none refer to basic ui features, instead focusing more on custom interpreter, custom regex, etc.
Likely referring to the first bullet point, "tabs / multiple workspaces / advanced window management". But calling resizing windows 'advanced window management' is a stretch IMO.