On Jan 2, 2015, at 6:50 AM, Jacob Carlborg <d...@me.com> wrote:

> This is awesome :D.
> I few comments:
> * I noted there are some issues with synchronizing the tabs and the content. 
> If I open a file from the file browser it will open a new tab, show the 
> correct content but the previous tab is selected. If I open another file the 
> tab for the last opened file before that is selected. This is when no split 
> view is active

I’m surprised I didn’t notice this, but I guess that goes to show just how 
often I use the file browser. Fixed in new commit.

> * When there's a vertical split and TextMate is not the active application, 
> the left border of the gutter is gone. The same thing happens for a 
> horizontal split but for the bottom border of the status bar

I don’t quite know what you mean here. I don’t see anything change, but I 
suppose I am just missing it. Could you provide a picture of what you are 
talking about?

> * It would be nice to have hotkeys for splitting and switch between the splits

There were already hotkeys for changing between splits, ⌃⌘{ and ⌃⌘}. I have 
added hotkeys for creating and removing splits in a new commit. I had to get a 
little long with them to avoid conflicts with bundles.

Split Horizontally: ⌥⇧⌘D
Split Vertically: ⌘D
Remove Current Split: ⌃W
Remove Other Splits: ⌃⌥W

> * Personally I think the way you implemented the split view is a bit 
> confusing. If there are two tabs open and one split. Each file is show in one 
> view of the split. I would expect clicking a tab would active the 
> corresponding split view, not chaining the content in the current split view.
> Alternatively implement separate split views for each tab, this is how both 
> iTerm and Xcode work.

Perhaps I should explain a bit more why I implemented it the way I did:

The main concerns that drive the implementation are that it should be flexible 
(allow splitting the same document, arbitrary split locations, etc.) and at the 
same time be minimally invasive to the existing code. I believe that these 
goals are fairly well achieved as most of the code changes (and definitely the 
major ones) are contained to DocumentController and the new class, and 
splitting is quite flexible and easy.

Implementing the tab bar the ways you suggest would infringe on one or both of 
these concerns. Just making the tab bar select the split with that document 
open would make it tedious to split a single document and confuse what happens 
on opening and closing documents. Putting multiple tab bars (one for each 
split) would require much more refactoring of the code to make it work, this is 
doable, but unwanted. It also makes managing the splits and locations of the 
documents quite a chore (need to open documents in each split as if they are 
different windows, so they might as well be different windows).

Anyway the way it’s done here is not unprecedented in the editor world 
(QtCreator is similar), and I believe it would make sense to a person brand new 
to split views, so I don’t think the usability is an issue with this 

Steven Clukey

textmate-dev mailing list

Reply via email to