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

[Ziller Eike]

On May 13, 2014, at 4:08 PM, Cristian Tibirna <tibirna at kde.org> wrote:

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

There’s even a task for that: https://bugreports.qt-project.org/browse/QTCREATORBUG-9141
I hadn’t thought about any automatism yet. And since actually documents are always “open” in all splits simultaneously, that couldn’t depend on which mime-types are currently shown in a split (because that’s a condition that does not exist :) ). But maybe it could be an option to automatically pull editors to a split if the mime type matches the currently shown editor in that split.

In addition I would like to have shortcuts to “make the current document visible in the next/previous split instead of the current split (potentially opening a new split or window)”. So, when you e.g. “blame” a file, the blame opens in your current split, but you can easily and with little pain just “move” it to a different split.

Br, Eike

-- 
Eike Ziller, 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, Registergericht: Amtsgericht Charlottenburg, HRB 144331 B