It would be very nice that someone has interrest to it. It is really the most important feature that I'm waiting from kate...

*** This bug has been confirmed by popular vote. ***

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.

*** Bug 115623 has been marked as a duplicate of this bug. ***

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.

kate marks files with color based on when file was last opened

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

*** Bug 202093 has been marked as a duplicate of this bug. ***

*** Bug 179112 has been marked as a duplicate of this bug. ***

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

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.

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

*** Bug 229113 has been marked as a duplicate of this bug. ***

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

At least some of the use cases are already solved by the Quick Document Switcher plugin for kate.

I agree that history based navigation is very nice, I would use it a lot, 
whereas I never use the linear browsing.

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.

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.

*** Bug 226245 has been marked as a duplicate of this bug. ***

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?

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

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

Created attachment 56718 [details]
hotkey category is unknown

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

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.

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

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

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

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

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

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

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.

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.

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

(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

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.

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.

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

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?

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.