Bug 104997 - kate wish: stacked document switching (history-based, most recent first)
Summary: kate wish: stacked document switching (history-based, most recent first)
Status: RESOLVED FIXED
Alias: None
Product: kate
Classification: Unclassified
Component: general (show other bugs)
Version: unspecified
Platform: Gentoo Packages Linux
: NOR wishlist with 211 votes (vote)
Target Milestone: ---
Assignee: KWrite Developers
URL:
Keywords:
: 115623 179112 202093 226245 229113 (view as bug list)
Depends on:
Blocks:
 
Reported: 2005-05-03 03:29 UTC by kde
Modified: 2013-12-30 13:38 UTC (History)
14 users (show)

See Also:
Latest Commit:
Version Fixed In:


Attachments
hotkey category is unknown (59.84 KB, image/png)
2011-02-01 05:36 UTC, Kevin
Details

Note You need to log in before you can comment on or make changes to this bug.
Description kde 2005-05-03 03:29:31 UTC
Version:            (using KDE KDE 3.4.0)
Installed from:    Gentoo Packages

Kate's documents/tabbed view can be navigated via Alt+forward/back, but only in a linear manner. Most MDIs provide the ability to switch to the most recent document first, like the alt+tab shortcut in the window manager (in non-KDE editors this is usually bound to ctrl+tab, ctrl+shift+tab). A nice extra would be to have a pop-up list of all documents on keydown, and the actual switch on keyup (like in Eclipse IDE).
Comment 1 hil.biz 2006-02-01 08:38:41 UTC
It would be very nice that someone has interrest to it. It is really the most important feature that I'm waiting from kate...
Comment 2 Clement Raievsky 2007-06-19 16:13:01 UTC
*** This bug has been confirmed by popular vote. ***
Comment 3 Solar Energy 2007-12-05 09:58:20 UTC
For editing, stacked document switching is something like two-paned file management (Krusader, GNOME Commander, Midnight Commander) is for file-management.

A crucial, unfortunatelly still missing feature.
Comment 4 Thomas Friedrichsmeier 2007-12-09 21:23:36 UTC
*** Bug 115623 has been marked as a duplicate of this bug. ***
Comment 5 Thomas Friedrichsmeier 2007-12-09 21:26:52 UTC
One comment (number 8 in bug #115623) points out that switching documents can also be very CPU intensive, which further strengthens the point of the summary, that the actual switch should happen only on keyup, so that, e.g. if you want to access the fourth-most recent document, you do not need to activate each one in turn.
Comment 6 Nick Shaforostoff 2008-12-06 06:25:25 UTC
kate marks files with color based on when file was last opened
Comment 7 kde 2008-12-06 15:45:30 UTC
(In reply to comment #6)
> kate marks files with color based on when file was last opened
> 

That is only tangentially relevant to the feature under discussion. We're discussing a stacked document switcher, like alt+tab switching in Windows/OS X.
Comment 8 Russ Brown 2009-09-02 18:13:20 UTC
*** Bug 202093 has been marked as a duplicate of this bug. ***
Comment 9 Thomas Friedrichsmeier 2009-09-06 11:14:37 UTC
*** Bug 179112 has been marked as a duplicate of this bug. ***
Comment 10 Diggory Hardy 2009-12-04 10:59:53 UTC
(In reply to comment #6)
> kate marks files with color based on when file was last opened

Could at least documents be ordered by last access? This would partially achieve what the OP requested, though not fully.
Comment 11 Maciej Pilichowski 2009-12-04 13:42:48 UTC
This would be useless in case of using session (all access times would be equal). And if you meant reordering tabs on-fly each time user switched tab, I doubt anyone would use it.
Comment 12 Diggory Hardy 2009-12-04 14:21:57 UTC
I mean the last time the document was switched to, yes.

What I've actually wanted a few times is automatic closure of not-recently-used documents to avoid having to scroll the list. (Off topic... that's why I made the suggestion though.)
Comment 13 Thomas Friedrichsmeier 2010-03-02 12:05:54 UTC
*** Bug 229113 has been marked as a duplicate of this bug. ***
Comment 14 Diederik van der Boor 2010-03-09 17:59:33 UTC
I'd like this too. Example use case:

- Bob a web developer, working on a web site project
- He has 10 files open, and is editing "style.css" and "default.html".
- Bob is editing both files in parallel.
- He likes to have his files ordered alphabetically, for quick lookup.

Currently Bob has to use Alt+Left 5 times to get to that other file, or leave the keyboard and pick the mouse to do it.

Instead, Bob likes to switch between both files instantly.

(In previous times, Bob used Visual Studio or Eclipse, which allows him to do this. They even open a "window manager" like tab box when holding Ctrl+Tab longer).
Comment 15 Milian Wolff 2010-03-09 18:03:43 UTC
At least some of the use cases are already solved by the Quick Document Switcher plugin for kate.
Comment 16 Anders Lund 2010-03-09 18:20:29 UTC
I agree that history based navigation is very nice, I would use it a lot, 
whereas I never use the linear browsing.
Comment 17 Russ Brown 2010-03-09 18:37:39 UTC
I would argue that the Quick Document Switcher plugin handles a completely different use case (although a very important one).

In my workflow, there are only two document switching methods that I (want to) make use of. The first is the Quick Document switcher, which I use when I want to edit a document by name. This works very well, but usually only happens when I want to switch context. However, most of the time I'm editing a small subset of the files I have open, and want to be able to switch between them quickly and without having to mess with filenames etc. For this, a recent history-based switching method is essential.

It's probably worth noting that I don't think I've *ever* switched between documents in the next/previous fashion that Kate offers by default. Personally, I find it completely useless as the ordering of the files is completely arbitrary from the perspective of their relative context.
Comment 18 Eric 2010-08-11 13:32:46 UTC
It's the only feature missing from kate that keeps me from using it (it's crucial for me).

Nota: It's a very basic feature in most text editors, it seems very strange to me that kate doesn't support it.
Comment 19 Milian Wolff 2010-08-11 14:13:29 UTC
*** Bug 226245 has been marked as a duplicate of this bug. ***
Comment 20 Diederik van der Boor 2010-09-01 22:55:40 UTC
KDevelop already offers this, with Ctrl+Tab and Ctrl+Shift+Tab.
In a crude way, but it does the job! :-)

Perhaps that code can be moved to kate?
Comment 21 Nicolas Bigaouette 2011-01-31 21:59:01 UTC
I just updated to KDE 4.6.0 and I think this is now the default behaviour.

I think this is BAD.
First, Kate always did one way, why suddenly change it to this way instead?
Second, I use the tab plugin to see the tabs. I have multiple desktops and multilple instances of Kate opened. When I switch from one to the other, I don't know what is the last document that was selected. But normally I just look at the tab and can see right away where to go: three documents to the left, or two to the right for example. Now, with the behaviour of switching the last selected, there is NO visual clue as to which document the switch will be done: I want to go to one document on the right but an ctrl+tab (bind to next document) will bring me to a "random" document (random as just the previous focused document which I have forgotten).

I'm not against such a behaviour per se. I just want to be able to use the linear one, be it by default or AT LEAST an option somewhere.

KDevelop introduced something similar some time ago. I found it interesting, tried it, but did not liked it in the end. But at least I could choose which one to use.

Please fix this...
Comment 22 Shreshtha 2011-02-01 05:16:27 UTC
IMO this is a really nice feature when you have opened many files in same
Kate and working in it. This is because if two files have drifted away,
which
most commonly happens, then its nice to go to previous file in one shot,
rather than multiple left/right steering.

Having an option to switch between the traversal way is okay, or some more
key combination to switch sequentially or based on access history.
But only the great developer of this great feature can comment about the
complexity and the effort required.

Still I am very thankful to the developer for introducing this nice feature.

/Regards
/Shreshtha

On Tue, Feb 1, 2011 at 2:29 AM, Nicolas Bigaouette <nbigaouette@gmail.com>wrote:

> https://bugs.kde.org/show_bug.cgi?id=104997
>
>
> Nicolas Bigaouette <nbigaouette@gmail.com> changed:
>
>           What    |Removed                     |Added
>
> ----------------------------------------------------------------------------
>                 CC|                            |nbigaouette@gmail.com
>
>
>
>
> --- Comment #21 from Nicolas Bigaouette <nbigaouette gmail com>  2011-01-31
> 21:59:01 ---
> I just updated to KDE 4.6.0 and I think this is now the default behaviour.
>
> I think this is BAD.
> First, Kate always did one way, why suddenly change it to this way instead?
> Second, I use the tab plugin to see the tabs. I have multiple desktops and
> multilple instances of Kate opened. When I switch from one to the other, I
> don't know what is the last document that was selected. But normally I just
> look at the tab and can see right away where to go: three documents to the
> left, or two to the right for example. Now, with the behaviour of switching
> the
> last selected, there is NO visual clue as to which document the switch will
> be
> done: I want to go to one document on the right but an ctrl+tab (bind to
> next
> document) will bring me to a "random" document (random as just the previous
> focused document which I have forgotten).
>
> I'm not against such a behaviour per se. I just want to be able to use the
> linear one, be it by default or AT LEAST an option somewhere.
>
> KDevelop introduced something similar some time ago. I found it
> interesting,
> tried it, but did not liked it in the end. But at least I could choose
> which
> one to use.
>
> Please fix this...
>
> --
> Configure bugmail: https://bugs.kde.org/userprefs.cgi?tab=email
> ------- You are receiving this mail because: -------
> You are on the CC list for the bug.
>
Comment 23 Kevin 2011-02-01 05:36:07 UTC
Created attachment 56718 [details]
hotkey category is unknown
Comment 24 Kevin 2011-02-01 05:38:45 UTC
I wanted this feature but I can figure out how to use it. For me, Alt-Left and Alt-Right still have the old behavior. I use KDE 4.6.0 on Archlinux.
Maybe the above screen shot suggests that this is a bug? (and I suppose a workaround for Nicolas Bigaouette :)

However, I don't think the behavior of Alt-Left and Alt-Right should change. I think an _additional_ hotkey should be added.

(In reply to comment #23)
> Created an attachment (id=56718) [details]
> hotkey category is unknown
Comment 25 Diggory Hardy 2011-02-01 09:14:41 UTC
Ctrl+Tab would in any case be the preferable short-cut for recent-document switching.

I used to use Alt+Left and Alt+Right switching, but when you have a lot of documents, the quick document switcher plugin (Ctrl+1) is often more useful.
Comment 26 Nicolas Bigaouette 2011-02-01 16:20:55 UTC
@Shreshtha #23
Maybe this is another bug?

@Kevin #24
I tried Alt-left/right but it is the same behaviour: it goes back/forward in history rather then file opening order. Maybe these two are the same for you because you opened the files one after the other so the history is the same as the tab order?
I agree with you that the old behaviour should not be discarded. Rather, a new hotkey/button should be added instead.

@Diggory #25
I disagree that Ctrl+Tab should be the new history-based switching. I always used it for the tab-order switching in all my applications. Ctrl+Tab is also tab-order in other applications like firefox, chromium, gedit, etc. I think the window managers have been the exception here.

I any case, I don't disagree that the history-based switching is a nice addition, but it shouldn't replace an already existing feature that works fine. Even though I'm trying to learn the new behaviour, there is just NO visual clue as to which tab/document I'm going to jump too. I often have a dozen files opened in one session, and have multiple sessions opened. There is no way I can remember the history of each opened sessions. The window managers do give a visual clue as to which document it would switch too. This is the reason why nobody complains. If you remember the order of the history (I know I used the console before typing something in the editor), you can quickly go from one to the other. If you forgot the history (did I typed that email before I copy-pasted the file to another file manager window or after I typed the command in the console?) you have a visual clue of that history and can choose from that.

I'm really angry right now as I cannot use Kate reliably. It is a real pain to use...
Comment 27 Diggory Hardy 2011-02-01 17:29:31 UTC
Oh, I haven't actually used this (presumably kate 3.6.0) yet. Recent-document switch doesn't use a pop-up like in kdevelop then? I was hoping it would mimic that...
Comment 28 Nicolas Bigaouette 2011-02-01 19:07:08 UTC
KDevelop did have that visual clue where a small popup would show the next document in list (it crashed like crazy initially ;) but that was a git/svn build so it was still in its infancy). But Kate does not.

There is an option in the "Tab bar" plugin to highlight the previous tab/document. I just tried it. But I just discovered something really weird. Actually (on my box...) this feature of highlighting the previous tab/document works fine, but the next/previous document does not even follow this. It literary jumps randomly. I did not pay attention to the actual sequence previously, I assumed it was "previous in history" and that I forgot the history, but now that I explicitly set a history by selecting tabs, I can't even go back/forward in that history: it's really a random jump between documents!!!
Comment 29 Thomas Fjellstrom 2011-02-09 18:39:36 UTC
Since kate now uses the TreeView plugin, ALT+Left/Alt+Right will traverse the TreeView in order, which will change depending on the sorting type you have set. It can be set to Opening order, or Document Name, or Document Path (if you have it set to the plain list view, the two document sorts are the same if its in tree mode).
Comment 30 Nicolas Bigaouette 2011-02-09 19:34:43 UTC
I've checked the configuration, thanks for the hint.

This is problematic though. I don't use the "Documents" left panel. Personnally, I prefer having tabs on top so I enable the "Tab bar" plugin in "Configuration/Configure Kate/Application/Plugins". I simply want to traverse the documents as they appear in the tab bar. When setting the tab bar sort order to "Opening Order" (by clicking the wrench in the tab bar), the sorting is still wrong and alt+tab will jump from one document to the other.

Edit: I just tried by closing all documents of the session, then re-opening them. The order is finally correct. Alt+tab will go through in the right order. For this behaviour, I had to set the tab bar sort order to "Opening Order" and the "Tree View" sorting the same thing. I don't know if the latter was necessary.

So much time wasted for such a simple thing...
Comment 31 Thomas Fjellstrom 2011-02-10 09:26:18 UTC
(In reply to comment #30)
> I've checked the configuration, thanks for the hint.
> 
> This is problematic though. I don't use the "Documents" left panel.
> Personnally, I prefer having tabs on top so I enable the "Tab bar" plugin in
> "Configuration/Configure Kate/Application/Plugins". I simply want to traverse
> the documents as they appear in the tab bar. When setting the tab bar sort
> order to "Opening Order" (by clicking the wrench in the tab bar), the sorting
> is still wrong and alt+tab will jump from one document to the other.
> 
> Edit: I just tried by closing all documents of the session, then re-opening
> them. The order is finally correct. Alt+tab will go through in the right order.
> For this behaviour, I had to set the tab bar sort order to "Opening Order" and
> the "Tree View" sorting the same thing. I don't know if the latter was
> necessary.
> 
> So much time wasted for such a simple thing...

I think you would have saved some time if you just set the tree view settings to sort by Opening Order. The TreeView is what implements the ALT+Left/ALT+Right key bindings, so if you set the TreeView to sort by opening order and display in list view, things will just work. The Opening Order is implemented by just not sorting the document list retrieved from Kate's Document Model. And setting it to a list view will skip building the tree and causing the order to be slightly different because of that.
Comment 32 Nicolas Bigaouette 2011-02-10 15:54:27 UTC
I wish I had saved that time.

The behavior changed unexpectedly. One day the default behavior was sane, the other it changed to something impossible to understand. I know people want that ordering and I think it is great that there is an option somewhere to set this. But an update shouldn't have re-setted that though! Also, the default should be to what was there before, mainly order of opening. If power users want to change it, they can.
Comment 33 Russ Brown 2011-02-10 16:08:45 UTC
It's worth commenting at this point that the original request in this bug has not yet been done (at least, as far as I can tell). Yes, I can change the ordering of the files in the Tree View, but switching is still based on that ordering, and not the order of most recently viewed (which is what this bug is actually about).

The acid test is this. With >2 files open, if I press CTRL+TAB and then release, I switch for file A to file B. If I do it again, I should be back at file A. Right now, it just carries on running down the list and switches to file C.
Comment 34 Thomas Fjellstrom 2011-02-10 16:14:59 UTC
(In reply to comment #32)
> I wish I had saved that time.
> 
> The behavior changed unexpectedly. One day the default behavior was sane, the
> other it changed to something impossible to understand. I know people want that
> ordering and I think it is great that there is an option somewhere to set this.
> But an update shouldn't have re-setted that though! Also, the default should be
> to what was there before, mainly order of opening. If power users want to
> change it, they can.

In all fairness, it was a major update. You can't really expect nothing to change from one major 4.x release to the next.

(In reply to comment #33)
> It's worth commenting at this point that the original request in this bug has
> not yet been done (at least, as far as I can tell). Yes, I can change the
> ordering of the files in the Tree View, but switching is still based on that
> ordering, and not the order of most recently viewed (which is what this bug is
> actually about).
> 
> The acid test is this. With >2 files open, if I press CTRL+TAB and then
> release, I switch for file A to file B. If I do it again, I should be back at
> file A. Right now, it just carries on running down the list and switches to
> file C.

Indeed, there is no real tracking of the most recent document. Sure the coloring could probably help in that regard, but I personally have no need for it.

And if it were implemented, people would probably complain about that, so yymv.
Comment 35 Eric 2011-02-10 16:29:24 UTC
(In reply to comment #33)
> It's worth commenting at this point that the original request in this bug has
> not yet been done (at least, as far as I can tell). Yes, I can change the
> ordering of the files in the Tree View, but switching is still based on that
> ordering, and not the order of most recently viewed (which is what this bug is
> actually about).
> 
> The acid test is this. With >2 files open, if I press CTRL+TAB and then
> release, I switch for file A to file B. If I do it again, I should be back at
> file A. Right now, it just carries on running down the list and switches to
> file C.

Finally someone IN-TOPIC!

+1 +2 +3

The sad thing is that a lot of text editors and developers gui works that way: ALL of them in windows and mac - in unix there is no standard about it and this is a GREAT usability lack
Comment 36 northon_patrick3 2011-03-24 22:39:07 UTC
I am oh so desperately waiting for this feature. Too many editors fail on this part. I simply cannot use an editor productively without it.
Comment 37 Terenyi Balazs 2011-11-07 09:20:33 UTC
I'm waiting for this too. I insert at least 50 tabs per day into my documents while pressing ctrl+tab in kate :)

It works in all the editors & IDEs I use (qtcreator, netbeans, eclipse, notepad++). It's a standard.
Comment 38 Christoph Cullmann 2012-11-11 20:22:18 UTC
Git commit cc340e879f31d1facc4b90067798a7bfbf851f39 by Christoph Cullmann.
Committed on 11/11/2012 at 21:18.
Pushed by cullmann into branch 'master'.

LRU sorted document switching
will keep track on view activation
the CTRL-ALT-O list is LRU sorted, latest used doc first
pre-seletected is the previous used doc
just cursor down to broswe in LRU history order
we can't have CTRL-ALT-LEFT/RIGHT do that without such a dialog, otherwise you just would
swap between the latest 2 documents, as as soon as the next one is activated, the last
used one will be next in lru stack

M  +68   -36   kate/app/katequickopen.cpp
M  +4    -18   kate/app/katequickopen.h
M  +8    -0    kate/app/kateviewmanager.cpp
M  +21   -0    kate/app/kateviewmanager.h

http://commits.kde.org/kate/cc340e879f31d1facc4b90067798a7bfbf851f39
Comment 39 mel 2013-12-30 13:11:11 UTC
So if this has been "RESOLVED FIXED", how does one make use of it? Either I'm missing something, or only a pre-cursor aspect of this feature has actually been implemented (the history-order "quick open" list).
There appears to be no shortcut I can assign which will immediately switch to the previously-used document, or cycle through them. There are "Back" and "Forwards" shortcuts by default mapped to ctrl+alt+left/right, but they're under a section called "Hello World", and seem to do nothing at all.

The only way I've managed to vaguely get this to work is to: <ctrl+alt+o>, <enter>. Which is:
1. more than a single ctrl+tab press
2. really disconcerting to see the whole document view replaced with a big list every time; a smaller popup would be nicer
3. even more awkward to go further back into the history at once: <ctrl-alt-o>, <down-down-down-down>, <enter>, compared to <ctrl+tab-tab-tab-tab-tab>, for example)

Am I missing something?
Comment 40 Dominik Haumann 2013-12-30 13:38:47 UTC
Right, this part of the bug is still open, see bug #324348 for further info (where this is tracked). This is something we'll have to work on for future releases.