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

[Tobias Hunger]

On 12.05.2014 18:31, Cristian Tibirna wrote:
> Hello
>
> Before I get a bad case of neck muscles soreness, I guess it's better to ask
> here:
>
> 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. E.g. Ctrl+K does the
> good thing (opens a new editor on-top/instead-of the one that currently has
> the focus).
>
> I guess I can get the logic of not obscuring the current editing with the
> results of commands that open new editors, but could be this rendered
> configurable somehow (e.g. be able to choose not to apply it to git
> navigations originated in a git result buffer?).
>
> Thanks!

Hallo Christian,

Let's call those areas that creator can put editors in "splits". You can 
have one split per monitor, but you can get the same behavior with 
multiple splits in the Qt Creator main window.

I think in the Git plugin we are just opening and activating editors and 
go with the default behavior. Unfortunately I am not an expert in this 
area and never did any serious looking into the editors and how we open 
them, but I would expect creator to keep the split with focus visible 
and to open new editors in other split -- if there are any. In general I 
think that approach does make sense. You seem to agree that it is the 
right thing to do when opening git blame.

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?



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.



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.

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.

Best Regards,
Tobias

-- 
Tobias Hunger, Senior Software Engineer - Digia, Qt
Digia Germany GmbH, Rudower Chaussee 13, D-12489 Berlin
Geschäftsführer: Mika Pälsi, Juha Varelius, Tuula Haataja
Sitz der Gesellschaft: Berlin. USt-IdNr: DE 286 306 868
Registergericht: Amtsgericht Charlottenburg, HRB 144331 B