On Jan 2, 2015, at 6:50 AM, Jacob Carlborg <[email protected]> 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
implementation.
Steven Clukey
_______________________________________________
textmate-dev mailing list
[email protected]
http://lists.macromates.com/listinfo/textmate-dev
