Hacker News Reader

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

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/

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".

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.

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/) 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.

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

I don't think terminal multiplexers are the same thing as editors at all. Arguing that tmux should just get bundled into an editor like neovim is dismissive of how great tmux is. I.e., It stands on its own, and it's doubtful that a well designed terminal multiplexer like tmux could've been created as a sidecar project for a larger editor app.

As much as I like emacs, I think it's suffered from this very problem over the years.

The fact that a terminal multiplexer can not be created just as a sidecar project is exactly the reason why it is better to build them as a whole. The editor does need a lot of terminal multiplexer features, and instead of letting them grow into a mess, it's better to do it systematically from the beginning.

To put it another way: If you are going to have an ad hoc, informally-specified, bug-ridden, slow implementation of half of Common Lisp anyway, why not just have Common Lisp as part of the program when you start?

"I always find vim's window-manipulating commands obscure. . . ."

What's obscure? I assume you're talking about the keys mapped to the commands, which can easily be changed to whatever you want them to be. Trivial. Other than that, the operations themselves just seem to be basic stuff, splitting windows, closing windows, moving between windows. The common and obvious manipulations.

Remapping default key commands is a fraught problem. Doing so acclimates the user to a custom environment which is not strictly a superset of the default environment. This makes it very difficult to switch to other environments and remain productive.

Defaults enjoy privileged status.

Personally as a developer (not a sysadmin), I choose to be more productive 99% of the time than eschew customizations because I might vim in remotely here and there.

I was referring to the commands to manipulate complex layouts. Take the following transformation for example:

    +---+---+---+      +---+---+
    |   | 1 |   |      | 0 | 1 |
    | 0 +---+ 3 |  =>  |---+---+
    |   | 2 |   |      | 3 | 2 |
    +---+---+---+      +---+---+

The tmux command to achieve this is "move-pane -s .3 -t .0 -v", which reads very natural once you know the options. "Move the source pane 3 to the target pane 0 by creating a vertical split in the target pane".

I then looked up windows.txt of the vim reference manual. In the window-moving section, we are given commands to rotate and exchange windows and move windows to the far left, right, top and bottom. So apparently I can achieve my goal by moving 3 to the far left, splitting 0 into 0a and 0b, exchanging 3 with 0a, and closing 0a. Which is why I always end up closing 3, splitting 0 into 0a and 0b and redo what I used to open 3 in 0b instead.

Also, how do you split 0 when you are in 3, without leaving 3? In tmux it is simply "split-window .0". Apparently there is no way to do that in vim...

Instead of consisting of a set of simple, powerful primitives, vim's window-manipulating commands are built from the perspective of special use cases. This makes these specific use cases easy but everything else hard. This is why I call them obscure.

Thanks, I see what you mean. However, I think 'obscure' is the wrong word. Tmux seems to have analogous commands for most of Vim's, mapped to keys for use just like Vim's; they're simply the usual commands many people use to move windows(vim)/panes(tmux) around.

The commands you mention (at least move-pane) are more flexible than Vim's window manipulation commands. That's the word I would use, 'flexible'. I think building a Vim plugin to emulate those tmux commands would be interesting project; I've put it on my list.

One last thing. I'm curious what tmux command(s) you would use to transform the layout above back to its original state. In Vim it's quite simple, with cursor in your window 3, just issue command ':winc L'. I don't see anything as straightforward with the tmux commands you've described, but I could be missing something.