4 ms·

No. They are not the same and shouldn't be. Rather they should communicate with each other. That is vim shouldn't have its own window functionality but instead

No. They are not the same and shouldn't be. Rather they should communicate with each other. That is vim shouldn't have its own window functionality but instead detect that it runs within a terminal multiplexer and instruct it to create a new window. When I find the time I will try to experiment with this design in vis. https://github.com/martanne/vis https://github.com/martanne/vis As for the copy mode, in my opinion the multiplexer should use the editor as a filter (which requires that the editor uses stderr for its regular output). The whole scroll back buffer is piped to the editor and whatever the editor writes to stdout is kept around in a copy buffer. That is the way it is implemented in the latest dvtm releases. http://www.brain-dump.org/projects/dvtm/ http://www.brain-dump.org/projects/dvtm/

alandarev 12y ago
Reusing one's functionality is amazing, but not always the best solution. The example you gave is exactly this: imagine if your web-browser would create new windows instead of tabs. Why? Well, it would just let OS manage the tabs, afterall that is the main functionality of the Operating System. Hardly everyone wants their vim to create a bunch of tmux windows messing up their workflow: constantly changing IDs of tmux windows; slow navigation between vim files as user now has to open ID 15 (tmux); mixed order... Oh that sounds as bad as seeing all your open websites in Meta/Alt+Tab. So please, do not speak for everyone with arguments "vim shouldn't have its own window functionality".
- xiaq 12y ago
  There is uzbl-tabbed, which separates the browser proper from the tab manager. It is not the OS which manages the tab though, since most WMs don't support hierarchal layouts and having all websites along with other applications is quite a mess. I have always wondered how smooth the workflow can be with a WM that supports hierarchal layouts and tabbing (e.g. i3wm) and having the browser always opening up windows, but I have never done that experiment.
- martanne 12y ago
  If your window manager is not able to manage your windows to your liking, you might want to fix it? Arguably creating a new window per tab is the correct thing to do. This allows your window manager to do its job. It is also more flexible, for example you can use something like tabbed (http://tools.suckless.org/tabbed/ http://tools.suckless.org/tabbed/) to group multiple applications into a tab-like interface. As for the editor case, in dwm/dvtm lingo each editor instance (or filename?) would get its own (dynamic?) tag. Therefore you can easily switch to a view which only contains your editor related windows. Again if your navigation among tmux windows is slow/cumbersome you might want to improve that instead of duplicating the functionality at another layer.
xiaq 12y ago
I think the goal we are trying to achieve are the same. Having the editor and the terminal multiplexer communicating with each other is basically a modular approach to the "editor and terminal multiplexer in one" idea, which allows you to combine the editor and the terminal multiplexer freely. However, such integration requires the editor to have specific knowledge of the terminal multiplexer, e.g. the editor needs to know that tmux uses the split-window command to split a window, and the -h and -v options (or similar knowledge on dvtm); any knowledge mismatch can lead to subtle interop bugs. Also, the editor might gradually evolve to require specific versions of the terminal multiplexer and that will make installation a bit more cumbersome. These are signs of very tight coupling. So the idea is, if you are going to have unavoidable tight coupling, you might better build them as one piece of software from the beginning. That eliminates all interop issues automatically and since you designed the UI of the editor and terminal multiplexer as a whole, the user experience can be much more smooth. Though I am pessimistic about the modular approach, I would still be very happy to see it implemented. I will admit your success if it turns out to be good enough :) PS. I have looked at your vis before and having modern, alternative vi-like editors is always exciting! Though not quite related, I would like to invite to take a look at my modern, alternative shell: https://github.com/elves/elvish https://github.com/elves/elvish

alandarev 12y ago

Reusing one's functionality is amazing, but not always the best solution. The example you gave is exactly this: imagine if your web-browser would create new windows instead of tabs. Why? Well, it would just let OS manage the tabs, afterall that is the main functionality of the Operating System. Hardly everyone wants their vim to create a bunch of tmux windows messing up their workflow: constantly changing IDs of tmux windows; slow navigation between vim files as user now has to open ID 15 (tmux); mixed order... Oh that sounds as bad as seeing all your open websites in Meta/Alt+Tab. So please, do not speak for everyone with arguments "vim shouldn't have its own window functionality".

xiaq 12y ago
There is uzbl-tabbed, which separates the browser proper from the tab manager. It is not the OS which manages the tab though, since most WMs don't support hierarchal layouts and having all websites along with other applications is quite a mess. I have always wondered how smooth the workflow can be with a WM that supports hierarchal layouts and tabbing (e.g. i3wm) and having the browser always opening up windows, but I have never done that experiment.
martanne 12y ago
If your window manager is not able to manage your windows to your liking, you might want to fix it? Arguably creating a new window per tab is the correct thing to do. This allows your window manager to do its job. It is also more flexible, for example you can use something like tabbed (http://tools.suckless.org/tabbed/ http://tools.suckless.org/tabbed/) to group multiple applications into a tab-like interface. As for the editor case, in dwm/dvtm lingo each editor instance (or filename?) would get its own (dynamic?) tag. Therefore you can easily switch to a view which only contains your editor related windows. Again if your navigation among tmux windows is slow/cumbersome you might want to improve that instead of duplicating the functionality at another layer.

xiaq 12y ago

I think the goal we are trying to achieve are the same. Having the editor and the terminal multiplexer communicating with each other is basically a modular approach to the "editor and terminal multiplexer in one" idea, which allows you to combine the editor and the terminal multiplexer freely. However, such integration requires the editor to have specific knowledge of the terminal multiplexer, e.g. the editor needs to know that tmux uses the split-window command to split a window, and the -h and -v options (or similar knowledge on dvtm); any knowledge mismatch can lead to subtle interop bugs. Also, the editor might gradually evolve to require specific versions of the terminal multiplexer and that will make installation a bit more cumbersome. These are signs of very tight coupling. So the idea is, if you are going to have unavoidable tight coupling, you might better build them as one piece of software from the beginning. That eliminates all interop issues automatically and since you designed the UI of the editor and terminal multiplexer as a whole, the user experience can be much more smooth. Though I am pessimistic about the modular approach, I would still be very happy to see it implemented. I will admit your success if it turns out to be good enough :) PS. I have looked at your vis before and having modern, alternative vi-like editors is always exciting! Though not quite related, I would like to invite to take a look at my modern, alternative shell: https://github.com/elves/elvish https://github.com/elves/elvish