[Qt-creator] how are git blame and git diff choosing the editor to display in

Cristian Tibirna tibirna at kde.org
Tue May 13 16:08:35 CEST 2014

On Tuesday 13 May 2014 11:14:10 Tobias Hunger wrote:
> On 12.05.2014 18:31, Cristian Tibirna wrote:

> > I have 2 displays (yay!) and I use to open a secondary QtCreator
> > editor(separate window) in the second display. If I hit Alt+G, Alt+B in
> > one
> > editor, the git-blame's output is sent to the other window/frame (the one
> > which doesn't have the focus). Now, if in the blame I click one of the
> > revision numbers, the corresponding git-diff appears in the original
> > (first) window. This, IMHO, breaks the rule of least surprise. 

> How would you think about your use case if you had three splits (e.g.
> you buy your next monitor and wire it up)? Then the text would be on the
> first, the git blame output on the second and the git show output on the
> third. Wouldn't that again be as expected then?

Well I guess that would depend. If I edit in the central screen, have git 
blame pop on the right screen then git diff in the left screen, I'd see it 
would still be "suboptimal".

I should perhaps underline that yes, I get the logic of opening new editors in 
another split. Yet for the vcs editors, I don't really see the necessity. When 
I open "git blame", I don't really need the source code editor right away. I 
anyways have the code *in* the "git blame" editor. (I agree that this is a bit 
more ambiguous for "git show" though...)

(All this remembers me some irc chats long time ago (in another century... in 
another millenium even), when we, Sirtaj Khan[1] and I, were jokingly 
designing "focus follows mind" for KDE's window manager.)

> We have some "InNextSplit" variants for some commands like
> "followSymbol" and some more. Maybe we need to generalize that so that
> we have similar options for all commands that open editors. That way you
> could decide which variation you prefer. You could either trigger
> "gitShow" or "gitShowInNextSplit" based on the current situation or just
> assign your key bindings in such a way that your preferred actions are
> the ones that are trigged by the key sequences you are used to.

I think this (or something like it) is what I was getting at, with my initial 

> Somewhat unrelated to the key bindings: I have a personal wish list
> items for a long time now: Being able to always have headers in one
> split and sources in another (next to each other on one monitor in my
> setup). One approach for that to work could be to have splits that
> "attract" certain mime-types. So all editors opened with documents of
> that mime type would by default end up in the split most attractive to
> that mime-type.
> Could something like that work for you? Basically you would have to set
> up one split attractive to VCS-relevant mime-types and all the editors
> triggered by the VCSes end up there.

Yes indeed. This would be even more useful. It would eliminate almost 
completely the aforementioned surprises.

It might be even rendered automatic, I guess (perhaps also this automatism 
configurable -- on/off). Once a "mime-type" gains a "split" it renders it 
automatically selected for same.

> Let's assume you have splits A and B with B being attractive to VCS
> editors. So if you trigger git blame in split A, then git blame output
> would end up in split B. Triggering git show there would have that
> output in split B, too. That is what I understood you to want. 


> But if
> you trigger git blame in split B, then that would also open in split B,
> covering the editor you were just working with. That in turn does not
> seem to be what you want.

Well, if I understand myself well enough, it _would actually be what I want_, 
if this second scenario is consequent to the first. It would have some sort of 
consistency: "ah, ok, all git blames get opened here".

In conclusion, I believe your idea of mime-type-attractive splits would be 
very useful. And the beauty of it is that it would be highly predictive and 
configurable. And optional.

Thanks. This is constructive.

Cristian Tibirna
KDE developer .. tibirna at kde.org .. http://www.kde.org

More information about the Qt-creator mailing list