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

[Cristian Tibirna]

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

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

Exactly.

> 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