Atom: Tab switching (ctrl-tab) should be in MRU order

[weijarz]

Current switching order is as tab display order, which is useless when opening many tabs.
Other editors uses MRU order to improve it (Intellij IDEA, Sublimetext, VS.net, Windows alt-tab etc..)

It's better to popup an open file list (in MRU order) when do switching (like IntelliJ IDEA / Windows alt-tab does).

[lee-dohm]

To be clear, I assume you mean Last Recently Used? LRU by itself is ambiguous because it is often paired with MRU to mean Most Recently Used and Least Recently Used ... but I doubt that's the sense you mean?

[50Wliu]

This is an interesting suggestion that'll probably be a bit controversial because:

• Chrome uses left-to-right order when switching tabs, but...
• Alt+Tab is organized by most recently used

I for one would prefer left-to-right order for switching tabs, since tabs can be re-ordered, unlike windows.

[mark-hahn]

I will add this feature to my smart-tab-order package.

On Sun, Feb 1, 2015 at 11:50 AM, Wliu [email protected] wrote:

This is an interesting suggestion that'll probably be a bit controversial
because:

• Chrome uses left-to-right order when switching tabs, but...
• Alt+Tab is organized by most recently used

I for one would prefer left-to-right order for switching tabs, since tabs
can be re-ordered, unlike windows.

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-72380680.

[mehcode]

:+1: for making this a core feature of https://github.com/atom/tabs

[mark-hahn]

[image: :+1:] for making this a core feature

Why do people want things in core all the time? Why does it matter? I'm
not pushing my package, it may very well suck. But if someone does a good
package for a feature then what the heck difference does it make? Actually
it makes core more bloated for people that don't want the feature so it is
actually a disadvantage.

On Sun, Feb 1, 2015 at 1:50 PM, Ryan Leckey [email protected]
wrote:

[image: :+1:] for making this a core feature of
https://github.com/atom/tabs

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-72386331.

[mehcode]

Why do people want things in core all the time?

Because how is random user A going to _know_ that this wonderful feature is found in smart-tab-order? Because when searching for git I get a million responses not necessarily helping my git workflow like sublime did. Because when searching for scss I get: language-SCSS, language-sass, ScssBundle and Atom-Syntax-Highlighting-For-Sass.

---

A reasonable alternative is a recommended or best-for document describing what packages to use for what use case scenarios (in an opinionated manner perhaps listing alternatives for each use-case).

[mark-hahn]

Because how is random user A going to _know_ that this wonderful feature
is found

I don't know. Blogs, the forum, word of mouth. I look at every new
package released but I'm a nut. There are only one or two a day to look at.

in an opinionated manner

There is a release of node that includes a selected set of packages.
People should do the same thing with their opinions. Ordinary users should
be able to release sets of packages. They could be in a list on atom.io and
the sets could be starred and the downloads counted like packages.

Some could make sets for specific environments. Many users would like an
ST set. I personally set everything up to match webstorm (intelliJ).

Now that I think about it things in core are a "set" of selected features
chosen by the core developers. They shouldn't have a monopoly.

On Sun, Feb 1, 2015 at 6:41 PM, Ryan Leckey [email protected]
wrote:

Why do people want things in core all the time?

Because how is random user A going to _know_ that this wonderful feature
is found in smart-tab-order? Because when searching for git I get a
million responses not necessarily helping my git workflow like sublime did.
Because when searching for scss I get: language-SCSS, language-sass,

ScssBundle and Atom-Syntax-Highlighting-For-Sass.

A reasonable alternative is a recommended or best-for document describing
what packages to use for what use case scenarios (in an opinionated manner
perhaps listing alternatives for each use-case).

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-72399727.

[mark-hahn]

An Idea: Someone should develop a package-feature taxonomy and then create a catalog indexed by that taxonomy. Once generated it would be easy to maintain with only 2 or 3 new packages a day to categorize and catalog.. It would be fun. I'll put it on my to-do list.

[ianharrigan]

@mark-hahn Is this something you have implemented? (19 hours ago i know!), but this is a painfully useful feature that makes me consider not using atom (which i really like)... Im happy to help if you need! :)

[mark-hahn]

@mark-hahn https://github.com/mark-hahn Is this something you have
implemented?

So far this has only on my to-do list but with encouragement like yours I
will move it to the top. It would only take a day or two. I am familiar
with the tab module code.

I was thinking it should be a feature in tab-smart-sort but maybe it
should be a separate package.

On Mon, Feb 2, 2015 at 2:29 PM, Ian Harrigan [email protected]
wrote:

@mark-hahn https://github.com/mark-hahn Is this something you have
implemented? (19 hours ago i know!), but this is a painfully useful feature
that makes me consider not using atom (which i really like)... Im happy to
help if you need! :)

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-72552300.

[mark-hahn]

@mark-hahn https://github.com/mark-hahn Is this something you have
implemented?

You meant the original topic of tab-switching, not the taxonomy idea, right?

[ianharrigan]

Hi Mark, Yeah, i meant the original Ctrl+Tab/Ctrl+Shit+Tab to switch tabs in a smart order (instead of right to left or what ever the default is) and possibly to bring a dialog (like eclipse), but main pain is having two windows you are working on (that arent in tab order) and trying to flip back and forth between them with Ctrl+Tab/Ctrl+Shit+Tab - Its annoying verrrry fast. :)

Also, FWIW, i agree with you about "why not use a plugin"... The best thing about atom it seems is that if something is "lacking" from the core then you can easily implement it yourself. And i would imagine that Ctrl+Tab isnt ubiqitous across OS's and therefore users, so its a perfect example of when adding to the core could confuse annoy users.

Cheers!
Ian

[mark-hahn]

So far this has only on my to-do list but with encouragement like yours I will move it to the top.

I lied. A fix for the webview tag has just been released in 177 and I have been promising a web-browser update for months that has been waiting for this fix. I'll get this out in a few weeks.

[jmm]

I don't care if this gets implemented, but it has to be an option. I definitely don't want to be forced to anything other than sequential tabbing order. The popup list (again, probably as an option) sounds interesting.

[perlun]

I think this is a very important feature actually. Small and subtle, but it's the kind of annoyances that keeps people (like me) away from switching over to Atom. Sublime simply "works" in this regard, and I'm lazy. :stuck_out_tongue: So @mark-hahn - really looking forward to seeing this, either in core or in your package. IMHO, the current behavior (left-to-right) is so stupid that the LRU/MRU/whatever-its-called should probably be the default. But that's only MHO of course.

[mark-hahn]

I'll move it up my list.

On Mon, Mar 16, 2015 at 12:32 PM, Per Lundberg [email protected]
wrote:

I think this is a very important feature actually. Small and subtle, but
it's the kind of annoyances that keeps people (like me) away from switching
over to Atom. Sublime simply "works" in this regard, and I'm lazy. [image:
:stuck_out_tongue:] So @mark-hahn https://github.com/mark-hahn - really
looking forward to seeing this, either in core or in your package. IMHO,
the current behavior (left-to-right) is so stupid that the
LRU/MRU/whatever-its-called should probably be the default. But that's only
MHO of course.

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-81888464.

[elgerm]

+1 for the LRU/MRU - thingy implementation

[weijarz]

Microsoft got it right Visual Studio Code.

[perlun]

Microsoft got it right Visual Studio Code.

Well yeah, but they got the license wrong... :wink:

[joozek78]

IMHO, the current behavior (left-to-right) is so stupid that the LRU/MRU/whatever-its-called should probably be the default.

+1

[tobysteward]

+1 - this would be great

[xak2000]

All extensions for MRU switching not works anymore in atom 1.0. Maybe it is time to do it in the core? All code editors that I know have this as default and I think there's a reason!

@50Wliu, I cant realize that any developer want to use left-ro-right switching. Maybe this can be convinient for not developer, I don't know. But as developer I often working on the project with 5-10 opened tabs. And often I need to switch from controller file to template file, from template to css etc many times in a row. This is ideal case for MRU mode.

Maybe not always, right. Maybe sometimes I need to switch to specific tab. But with left-to-right mode it's anyway so inconvinient that I still have to use my mouse to open specific tab. For example if I'm on tab2 and want to switch to tab7. In this case I will use my mouse anyway. Not press CTRL-Tab five times. Because when I pressing it five times I almost always pressing it six and BOOM. I need to cycle through all tabs again. Or pressing it slowly and in this case using mouse still be faster.

So I can't see any use case for left-to-right mode.
Maybe it is just me? But if it is - anybody that likes left-to-right mode - give me your use case.

[jhasse]

There is a use case, but it doesn't matter anyway since
left-to-right-switching will be still available via ctrl + page up/down.

[jmm]

@xak2000

I cant realize that any developer want to use left-ro-right switching.

I do.

In this case I will use my mouse anyway.

I won't.

Because when I pressing it five times I almost always pressing it six and BOOM. I need to cycle through all tabs again. Or pressing it slowly and in this case using mouse still be faster.

Ctrl+Shift+Tab.

So I can't see any use case for left-to-right mode.
Maybe it is just me? But if it is - anybody that likes left-to-right mode - give me your use case.

It's just you and whoever else wants MRU. Some people do, some people don't. The solution is simple: if it gets implemented make it an option (on or off by default, doesn't particularly matter), then no one has to worry about anticipating or trampling anyone else's use case.

@jhasse

There is a use case, but it doesn't matter anyway since
left-to-right-switching will be still available via ctrl + page up/down.

It matters very much -- because I want to use Tab, not Page Up|Page Down.

[lee-dohm]

My use case for left-to-right tab switching is that every other program I use that has tabs works that way.

If you want to jump to a specific tab there's always Cmd+1-9 on OS X or Alt+1-9 on other platforms. If you want to switch back and forth between two files easily, there's Cmd+B followed by Enter.

[mnquintana]

I agree with @lee-dohm– I could still see this being added as a config option, but it's extremely, extremely unlikely that we'd ever make this the default (especially now that 1.0 has shipped).

[jhasse]

@jmm Okay, but can we agree that having Ctrl+Tab and Ctrl+Page Down doing the same thing will result in one group being unsatisfied (currently it's the one with people looking for MRU switching)?

@mnquintana So "bugs" should not be fixed because 1.0 has shipped?

This reminds me of the Ctrl+Backspace issue. It's another tiny difference where Sublime Text behaves smarter in my opinion. That 1.0 has shipped and people have gotten used to these (IMHO broken) behaviors should be no excuse, because there are still plenty of people making the switch from Sublime Text and other editors who'll expect Atom to behave similar.

[lee-dohm]

@jhasse Nobody is advocating for MRU to not be an option. What I feel people are objecting to is that it appears this conversation has descended into, "I don't understand why people would want left-to-right tab switching, let's just assume there aren't any and remove it."

So "bugs" should not be fixed because 1.0 has shipped?

1. This isn't a bug
2. Changing defaults isn't "fixing a bug", it is a breaking change that will be disruptive to other users

Inflammatory statements that belittle or disregard the preferences of other users only encourage others to dig their heels in and fight against what you want. How about we work together?

[xak2000]

Ok now I see.

The main reason that one likes left-to-right or MRU is consistency between other applications that one uses. I still can't understand how switching from tab3 to tab17 can be convinient for anybody with left-to-right mode but this doesn't matter if it will be config option.

P.S. I know only one program that I using day-to-day that uses left-to-right and it is Chrome. I love this browser but I hate this tab switching for same reasons. Often I have 20 opened tabs but now working with only two. The documentation tab and my-appication tab (+ code editor). I'm even going several times to change the browser but.. I love this browser for other reasons. :)

[jhasse]

@xak2000 There are other reasons! How do you switch two taps to the right without using your mouse?

@lee-dohm Yes, let's work together :)

What do others think about the approach Sublime Text uses: Ctrl(+Shift)+Tab for MRU and Ctrl+Page Up/Down for left-to-right?

[mnquintana]

@jhasse I think that still amounts to changing the default – I'm very :-1: for changing the behavior of the existing keybinding. I'd much rather see a config option or an alternate keybinding for switching tabs in MRU order.

[lee-dohm]

Yes, let's leave the key bindings aside for the moment. New commands can be implemented pane:show-next-most-recent-item and pane:show-previous-most-recent-item and then people can map them to whatever keys they want.

[jhasse]

A config option would be overkill IMO, since adding a few lines to the keymap.cson should be fine.

Btw: Since nobody has mentioned it: https://github.com/martinruenz/atom-ctrl-last-tab provides the functionality already.

[jmm]

@jhasse: @lee-dohm already made a great reply to your post, but I still wanted to reply personally.

Okay, but can we agree that having Ctrl+Tab and Ctrl+Page Down doing the same thing will result in one group being unsatisfied (currently it's the one with people looking for MRU switching)?

No, why would we agree on that? We can agree that if MRU is added there's a config option for it so both groups can be satisfied.

So "bugs" should not be fixed because 1.0 has shipped?

I will repeat: it's not a bug.

@xak2000

The main reason that one likes left-to-right or MRU is consistency between other applications that one uses.

You're overgeneralizing. The big picture is that with an option you don't have to worry about anticipating or understanding other people's preferences.

@jhasse

What do others think about the approach Sublime Text uses: Ctrl(+Shift)+Tab for MRU and Ctrl+Page Up/Down for left-to-right?

:-1::-1:

[jhasse]

@jmm Can you explain a little bit more _why_, instead of just giving me two thumbs down? Is it because you are using Ctrl+Tab for left-to-right switching? What would you say to Ctrl(+Shift)+Tab for left-to-right and Ctrl+Page Up/Down for MRU?

[xak2000]

Alternative keybindig is bad choice imho. The config option MRU Tab switching will be good. It definitely must be CTRL-TAB as like @lee-dohm says "My use case for left-to-right tab switching is that every other program I use that has tabs works that way". The same reason for other people that likes MRU. My fingers just knows "to switch tabs press CTRL-TAB". Not CTRL-Q. Not ALT-[.

So I think the config option MRU Tab switching will be ideal. Of course disabled by default for consistency with previous atom versions. We don't need a separate hotkey as people that prefers left-to-right switching just don't need MRU anyway and will use CTRL-TAB as always. And people that prefers MRU also will use CTRL-TAB as always but can switch left-to-right with CTRL-PGDN if ever need.

[jmm]

@jhasse

Can you explain a little bit more _why_, instead of just giving me two thumbs down?

Sure, I don't know what I can really add to what I've already said though: I want to navigate tabs sequentially using Ctrl[+Shift]+Tab.

Is it because you are using Ctrl+Tab for left-to-right switching?

For sequential switching, yes.

What would you say to Ctrl(+Shift)+Tab for left-to-right and Ctrl+Page Up/Down for MRU?

I would say, again, two thumbs way down :) For my previously stated reason: I want to use Tab, not Page Up|Page Down. (I might _also_ want to use that, but not mutually exclusive to using Tab).

[loureirorg]

+1 for MRU/LRU as a core option

[bronson]

It seems to me Ctrl+Tab is always left-to-right switching. Are there any apps that do it differently?

edit: the Idea tab switcher seems so different from everything else that it probably merits its own package... https://www.jetbrains.com/idea/help/navigating-between-files-and-tool-windows.html Do any other apps do this? Because I can point to at least ten that do left-to-right, including all popular browsers.

A jetbrains-tabs package would complement all the sublime-tabs, sublime-selections, etc packages out there.

If you want LRU now, why not use tab-switcher? edit: or @mark-hahn's?

Surely anyone who wants different tab behavior is more likely to find it in a package than buried in some unsearchable setting, no?

[loureirorg]

thanks for the answer @bronson . I'm an Atom newbie, and I was looking for an extension like that for the last 2 or 3 hours and couldn't find anything (yes, I've tried google, and I've read a lot of discussions before get here). I'll try this extension.

About the question "Are there any apps that do it differently?": yeap, there's a plenty of softwares that works not by using left-to-right, but MRU. And believe me, there's a lot of developers that prefers MRU. I will not discuss here which one is better, because it's like discuss which language or which color is the best. It's a matter of personal taste, some brains achieve more productivity using MRU and some others LTR. Maybe I'm wrong, but I presume that this is an unnecessary obstacle for many newcomers.

[bronson]

Glad to hear. I hope you'll report back, both if you find something you like or if you're still searching.

Unless it is the default behavior, won't there always be an obstacle for newcomers? Personally, I find it easier to discover packages than settings. You can't search settings based on descriptions or link to them from blog posts.

If you have a suggestion on how to make these particular packages more discoverable, that could help Atom users everywhere. I'd sure be interested.

Finally, even if it's included in core, _what_ exactly would be included? Just forward and back bindings? A JetBrains-style UI? Something in between?

[benogle]

For the record: I would like to eventually transition to MRU as the default for ctrl-tab. Currently, pane:show-next-item is available by default via cmd-option-right (and pane:show-previous-item via cmd-option-left), and it makes a lot of sense to reduce this duplication and provide the MRU switching functionality.

[bronson]

@benogle yikes, why? Then Atom will behave differently from the other Mac apps that I use.

If you make this change then I'm happy to make a 'traditional-tab-switching' package to keep the current behavior. Just curious why you want Atom to be different?

[benogle]

It's the default in other editors (sublime, and visual studio for example), it's enabling something people arent able to do today, it's clearly something people want, and there is no reason to have multiple keybindings triggering the same functionality.

It will just be a different command that can be remapped, so no need for a whole package. Initially it will be a new command not mapped to any keybinding, then we may change the default after we're comfortable that it's the right choice.

[bronson]

OK, if it's the default for most other text editors then that makes sense. I only have experience with browsers, macvim (which has utterly broken tabs anyway) and graphics packages.

Hopefully the browsers can all change to match!

[loureirorg]

@bronson it was my fault to not have found it before, I've looked on "settings" > "packages" and didn't noticed that I was searching not for new packages, but on installed packages, so that's why I couldn't find it. So, I googled for "atom editor mru" and didn't found anything (I looked until the page 5) - this page was the best thing that I found.

So I took a look on the tab-switcher, but I couldn't understand on how to install a new package. So, I've tried the same Sublime code (Ctrl+Shift+P) and it worked. Now I need to find a way to work with ctrl+(shift)+tab and also remove the dialog box :P

[bronson]

@loureirorg I agree 100% on the packages UI. It's been through a few changes but it still has a poor first user experience. It works well enough that it's hard to justify spending time on it though, not when there are so many other things to fix.

If that's what you want, maybe give this a try? https://github.com/martinruenz/atom-ctrl-last-tab It even has the right keybindings: https://github.com/martinruenz/atom-ctrl-last-tab/blob/master/keymaps/ctrl-last-tab.cson

[loureirorg]

@benogle . It's great to hear this from a core developer. Keep up the good work!

[loureirorg]

thank you very much @bronson it worked like a charm. Thanks again!

[jmm]

@jhasse

Sorry, I misread what you wrote here:

What would you say to Ctrl(+Shift)+Tab for left-to-right and Ctrl+Page Up/Down for MRU?

If we're talking about defaults, I'm not too concerned. I'm skeptical of locking any keybindings related to tab switching into MRU order though. If MRU is going to happen in core then I think it should just be an option or as benogle said a command that can be mapped to a keybinding. Then people can choose whichever they want and all that's left to be unhappy about is the defaults, right? :)

[elektronik2k5]

Sorry, I didn't read all comments above.
+1 for MRU by default, like in all sane editors.

[jatin-pathangi]

Hi, I'm looking for an entry point to contribute to Atom, and seeing as this is a beginner issue, thought I could work on this?

[mark-hahn]

That would be great. Go for it. You can ask questions on the forum where
you will get help almost immediately.

On Sun, Oct 18, 2015 at 9:26 AM, Pathangi Jatinshravan <
[email protected]> wrote:

Hi, I'm looking for an entry point to contribute to Atom, and seeing as
this is a beginner issue, thought I could work on this?

—
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-149028010.

[jatin-pathangi]

I've only got a bit of time in the past few days to see this, but I'm thinking of adding another method in src/pane.coffee similar to activateNextItem and others, and also adding another new coffee/js file with a MRU structure implemented, as a list or linked list and use this in a method called activateMruItem in src/pane.coffee. Am I thinking in the right direction @mark-hahn ?

[benogle]

cc @nathansobo for guidance on implementation :point_up_2:

[nathansobo]

I have some thoughts and some questions.

Thoughts:

I do think it's smart to implement this in core and not in the tabs package. As for the name of the method, I'd like to stick to whole words if we can help it. activateNextMostRecentItem or something similar. I want to avoid initialisms unless they're super well-known (like URI). I think a simple stack of items in the pane, something like itemsByRecency or similar, could be a good approach, rather than a linked list. When an item got promoted to the top it could be removed from its current location in the array.

Totally open to different naming suggestions as this evolves, just putting these out there.

Questions:

• When is something added to the top of the recency stack? When it is modified?
• How does activating the next most recent item affect the stack?

[jatin-pathangi]

@nathansobo I can use a stack for maintaining tabs. This is how the logic would work

Say there are n tabs t1, t2....tn which were opened by the user in that order, and the user is now at tn. The highest index of the stack is indicated by 'top' and it is the active tab and stack[top] is now tn.

The user now presses ctrl-tab 'k' times. The tab that was at stack[top-k] now moves to stack[top] and is the top most and active tab and the tab that was at stack[top] now moves one place below, i.e. stack[top-1] is now tn. And the tab at stack[top-1] moves to stack[top-2], stack[top-2] moves to stack[top-3]......stack[top-k-1] moves to stack[top-k].

Whenever the user opens a new tab (tn+1), that stack[top] is now tn+1.

[nathansobo]

Not gonna lie... still a bit lost on the stack handling. But seems like you have a clear idea, so maybe you should just proceed we can play around with some running code. Thanks @Pathangi-Jatinshravan!

[slikts]

The enhanced-tabs package already has MRU tab switching, so maybe it's a good idea to integrate that?

[ianharrigan]

Agree... enhanced tabs is actually exactly what i was after. I do think that should be in the default atom package however, using it as an IDE or even as an enhanced text editor seems pretty hard without that package.

[nathansobo]

The enhanced-tabs package already has MRU tab switching

I think it could benefit from being a first-class concept in the pane system, but I can take a look at the behavior they implement.

[xak2000]

tab-switcher package also has this functionality. I like the styles and functionality of popup window with list of tabs (icon, file name, path). I think it is important to show window like this and not just switch tabs. When you just CTRL-TAB back and forth it is not necessary but when you want to switch to different tab it can be challenging to predict switch order without window like this. (_I think this is one reason why some people dislike MRU_)

[rvion]

+1 for sublime like tabs. All people using atom I know miss this feature

[ugoa]

I can't remember how many frustrating moments I had with the left-to-right switch behaviour.

[simion314]

+1 for MRU switching

[kevinkleine]

+1

[tony-h]

My one big frustration with Atom is the lack of MRU. The order in which one opens the tabs usually isn't as important as the last or most recently used tab. It's frustrating to have to look at list of open tabs (usually quite large) to locate the one I was just working on. This should be a one hand operation, not involving the arrow keys, which involves the other hand.

+1 for MRU switching.

[slikts]

It would be better to have MRU switching by default, but you don't have to be frustrated by the lack of it, just use the enhanced-tabs package.

[tony-h]

@slikts, thank you for the recommendation on using enhanced-tabs. It works perfectly. I had not come across this particular one. I tried using other packages, but I did not find one that worked well

[tstrimple]

I completely agree with all the MRU users. Every text editor with tab support that I've used has worked this way. I'm only posting this because this was the page I found when trying to find this functionality, so the plugins definitely have a discoverability problem. Off to install enhanced-tabs!

[s-trooper]

+1 for MRU switching.

[anderssonjohan]

:+1: for MRU order.

[lee-dohm]

I created PR #10663 that should make it easy for someone to create a package to implement MRU tab order. (I just have to write some tests for it.) While implementing MRU tab order is something that the Atom team would like to do long term, we just don't have the bandwidth build and maintain this any time soon. So rather than do something half-baked, we would rather enable the community to build it for themselves.

Thanks to everyone for your passion about Atom and your feedback. I'm going to close this until we decide that we want to and have time to place it back on our roadmap.

[lee-dohm]

My apologies, there was a miscommunication on my end and I got some wires crossed. We are still looking at this, though we still don't have a timeline for when it will be fixed.

[klevstul]

+1 for MRU tab switching

[khmylov]

+1 for this

[benogle]

FWIW, this is moving forward. There is a PR to add the functionality: https://github.com/atom/atom/pull/10737, and a PR was merged (https://github.com/atom/atom/pull/10921) to add the requisite keymap changes. We need to review the PR, which will hopefully happen soon.

[benogle]

This will be in 1.7.0 which should be in beta soon.

[zhongyn]

+1, look forward to the new feature!

[sadovnychyi]

How do I can disable this? Simply changing the keymaps.cson didn't work for me.

'body':
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-shift-tab': 'pane:show-previous-item'

[lee-dohm]

@sadovnychyi You need to add the following to your keymap.cson

'body':
  'ctrl-tab ^ctrl': 'unset!'
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-shift-tab ^ctrl': 'unset!'
  'ctrl-shift-tab': 'pane:show-previous-item'

[dwelle]

I'd add an option to disable this. I can imagine a lot of frustrated people.

[jhasse]

I think that an option will just overcomplicate things as people can always change the keybindings via keymap.cson.

[dwelle]

@jhasse assuming that newcomers will realize they can do that, and find this issue to get the right keybindings (I sure didn't know about the ^ctrl -- still have no idea what it does).

[jhasse]

You can still use Ctrl + Page Up/Down for the old way without touching keymap.cson :)

[dwelle]

That doesn't solve the issue we're talking about.

[50Wliu]

The feature request to add a config option for this is at #11035.

[petemill]

@jhasse not with one hand :-)

[xak2000]

@petemill Use right CTRL :-)

[petemill]

@xak2000 well my minor gripe with that is then I'd have to move my hand off my mouse, or move my left hand to the right side of keyboard. I'm ok changing my keymap.cson...

[smaili]

Stumbled on this because as a regular user I never expected to be disrupted with my tab switching :)

I'm sure there are many that strongly desire MRU but just wanted to put my vote in for those of us that do prefer display order.

[petemill]

I think it's clear that this there are people with preferences for both of the ways. And it is configurable either way, so that's good. But the question becomes: do you want to change the default to disrupt the many many current users and favor the percentage of new users who prefer MRU. Or keep the default but publicize the new option to allow new and existing users to choose their preference alike.

[ptrwllrd]

So I received the update today and it turns out you guys decided to mess with my muscle memory. Please provide a setting in the config panel for the non-borg of us who don't want to do a Google syntax search and edit a config file just to change a single setting.

[jhasse]

a vocal _minority_

source?

[Tathanen]

I suspect those requesting it in this thread are far fewer than total Atom userbase, a minority by definition wouldn't you say.

[50Wliu]

without notifying users.

The release notes and the blog post both make it very clear that this feature was added, and the blog post also provided instructions on how to revert to the old sequential tab switching.

[jburson]

Perhaps it would be helpful to have an in-app notification that refers to the breaking changes, since most users aren't going to be checking the blog every day.

[jhasse]

I suspect those requesting it in this thread are far fewer than total Atom userbase, a minority by definition wouldn't you say.

Not all users state their opinion in a bug tracker. Also some users simply don't care. Point is: We don't know the numbers, so you can't say that MRU-preferring users are just a minority.

[slikts]

Every code editor or IDE I know uses MRU switching: Visual Studio, Visual Studio Code, Eclipse, all the JetBrains IDEs, Sublime Text, Notepad++, NetBeans, etc. It's very unlikely that the majority of users would have a problem with it.

[petemill]

...so since non-MRU was a default for so long in Atom, and then a sudden change, why don't, instead of it being an argument between one side vs another, be kind to _all_ people and make it easily configurable one way or another, and communicated in the best way.

[nathansobo]

We hear you... We plan on being more conservative with defaults in the future. It's going to take some resources to build that experience but I think we should avoid major behavior changes without more notice. In the end I will usually favor moving forward, but if we can ease transitions I think we should.

[diego-vieira]

Thank you!

I really like that feature, it's the same behavior I used in phpStorm. When I switch to atom I had to get used to the way atom does, but without seeing the files I'm moving to like @weijarz mentioned in the first post is kind of useless, unless you're working with up to 3 files, but once you have 5, you don't know where you're going when you hold CTRL and switch tabs.

For now I'll just switch back to the default behavior.

[slikts]

The purpose of MRU switching is to switch between tabs in the MRU order, so it's hardly "useless" without a list of tabs, it's just not useful for cycling through a larger number of tabs. It's somewhat of a moot point, though, because cycling through a larger number of tabs is slow and not very useful anyway compared to just using the mouse.

[edgartheunready]

Those wanting the old behavior: go here or add this to your keymap.cson:

'body':
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-tab ^ctrl': 'unset!'
  'ctrl-shift-tab': 'pane:show-previous-item'
  'ctrl-shift-tab ^ctrl': 'unset!'

Thanks BLaM for posting the fix on another thread.

[ugoa]

The MRU tab switching in 1.7 is great, however it would be even better to pop up a tabs list panel in MRU order when pressing ctrl-tab, so that I can choose which specific tab to go to by holding ctrl and pressing tab key. The current behaviour would just jump to the first tab in the MRU stack, which is fine but really doesn't cover the most of editing scenarios.

Thanks!

[50Wliu]

however it would be even better to pop up a tabs list panel in MRU order when pressing ctrl-tab, so that I can choose which specific tab to go to by holding ctrl and pressing tab key.

Can you please open a new issue for this?

[ugoa]

@50Wliu Okay I've opened a new issue: https://github.com/atom/atom/issues/11535, Thanks

[mehcode]

Not sure if this is clear to anyone here arguing/complaining/discussing but atom still has a next/previous tab keybinding to move through tabs in left-right order: ctrl-pagedown / ctrl-pageup.

Even if I didn't like MRU by default I'm not a fan of having more than one keybinding to do the same thing (I'm looking at you ctrl-p and ctrl-t, can we "fix" that already).

[benogle]

atom still has a next/previous tab keybinding to move through tabs in left-right order

There are actually three other binding combinations to move through the tabs left to right: cmd-{|}, cmd-alt-left|right, and ctrl-pageup|pagedown. (Edit: only on mac)

[mehcode]

@benogle According to my test and the keybinding resolver those other ones don't exist on linux at least.

[benogle]

You're right, I apologize, they are mac-only.

[slikts]

Ctrl+Page Up/Page Down works on Windows as well.

[samuela]

+1 for defaulting to display order and providing an option for MRU order.

[slikts]

Would be nice to see a case made for display order switching that's based on something other than personal habits. MRU switching is used in code editors because it streamlines a very common workflow, so not sure why display order switching would be preferable. Seems like a case of people just not knowing better.

[petemill]

Ok - I'll have a go for the humble display-order. I personally am more productive with display-order. It is largely due to predictability of navigation. I can see how many times I will need to press ctrl-tab or ctrl-shift-tab to get to a file. Moreover I can do this with one hand unlike the other shortcuts (which I also use often). This is because I am often not working with just two tabs but three, four or more. If I wanted to just go back and forth between two tabs then I would normally only keep those two tabs open. Or...

Here's another reason: atom supports panes. If I'm just working on two tabs I usually use two panes side by side. When I switch back and forth between panes and you use ctrl-tab in MRU-order, I usually have no idea which file I will be taken to in that pane (ctrl-tab does not work across panes).

And that's the crux of the problem for me. I usually press ctrl-tab because I want to be productive with one hand whilst the other hand is on the mouse, without moving the mouse all the way to the tab bar and cycling through tabs with it. With display-order I can cycle through any number of tabs with speed, back and forth, skipping some, ending up at my destination incredibly quickly. With MRU-order what usually happens is I press ctrl-tab once, end up on the wrong file so press it again. If I let go of ctrl between files then when I want to go back to where I was, I usually end up on the wrong file _again_. Someone save me from madness if I want to go between three or four files because I'll be tabbing about 20 times between each to fix the 'order' each time. I'd like to know from MRU-order-preferring people how you keep in your memory, on top of the programming architecture in your mind, the 'used'-order of all your open tabs.

This could all be helped, in MRU's case, with a visual tab-switcher like Visual Studio (Windows) has had for years, but I'm unconvinced still that that's better than display-order which already has a very nice (in Atom's case) visual: he tab bar.

I love productivity, especially one-handed, so if someone can say "you're doing it wrong!" and explain how I can be more productive (and less frustrated) with MRU-order than display-order then I would be very happy. As the last comment mentions, people often "don't know better" so perhaps that's true here for me and the others who have found this Issue. But if it is a personal preference split down the middle (data?) then why change the default suddenly and disrupt people to have to come here to figure out how to change it back? What percentage of people have the display-order preference that will face that disruption of preference and what percentage of those users will then find this thread with a (non-tickbox) method of being able to switch their preference back.

Tldr; productivity. And then disrupting those who do have that preference.

[slikts]

MRU switching is for switching between the last few used tabs, which should take no particular effort to track. You can do the same manually with visual order switching by reordering tabs or limiting their number, but the benefit of MRU switching is that it just happens as you work that the files you probably need since you recently used them are a few steps away at most. Unlike visual order switching, it doesn't lose effectiveness with a larger number of tabs (without manual steps), since it's not used to switch between all the tabs. Your main problem is that you're trying to use MRU switching as the only tab switching mechanism, which is not what it's meant for without an ordered visual tab list. The enhanced-tabs package used to have this list when it worked, and I've also used Visual Studio and other editors that have it, and it's always just gotten in the way for me, because I don't use the keyboard to cycle through a larger number of tabs, since it'll always be faster to just use the mouse. This is a real matter of preference, and there are probably people who just can't use the mouse, so for them the current implementation of MRU switching would be lacking, but this is the only valid problem you've described, and the rest is just habitually trying to use the feature as something it's not or just flat-out misunderstanding what it is (like asking if people memorize the order of all the tabs).

[mcmar]

I want to be clear here that I would actually prefer MRU order if it was implemented correctly. But the critical piece of MRU order is that the tabs get visually re-ordered from left to right when you lift off the ctrl key. MRU relies on visual re-enforcement to know what the current state of the tabs is.

Additionally, going back to the old way is unreasonably difficult.
I thought (reasonably) that this would give me the old behavior:

'body':
  'ctrl-tab': 'pane:show-previous-item'
  'ctrl-shift-tab': 'pane:show-next-item'

But it turns out that I actually need this to give me the old behavior:

'body':
  'ctrl-tab': 'pane:show-next-item'
  'ctrl-tab ^ctrl': 'unset!'
  'ctrl-shift-tab': 'pane:show-previous-item'
  'ctrl-shift-tab ^ctrl': 'unset!'

There really should be a setting that can be toggled rather than mucking about with complicated keymapping behavior.

The poor implementation combined with the difficulty in undoing this change will likely lead to lots of frustrated, angry developers. It's really important to preserve your existing userbase and not churn users by suddenly switching key behavior on them.

[slikts]

… the tabs get visually re-ordered from left to right when you lift off the ctrl key.

I've never seen an implementation of MRU tab switching that would do this, and it doesn't sound very good. Your problem with configuration was that you guessed wrong. Also, not sure how this change would cause churn if every other editor uses MRU switching as well.

[mcmar]

I've never seen an implementation of MRU tab switching that would do this

Both Mac and Windows use it for their window switching.

Your problem with configuration was that you guessed wrong

But crucially, it was a reasonable guess. And even more crucially, I shouldn't have to guess. It should be obvious and intuitive.

not sure how this change would cause churn if every other editor uses MRU switching as well

Because they did it from the start. Right now existing users are opening up Atom and finding that their tab-switching behavior has suddenly changed with no explanation. That's incredibly frustrating.

[xak2000]

I've never seen an implementation of MRU tab switching that would do this

Both Mac and Windows use it for their window switching.

Not sure about Mac, but Windows doesn't visually re-order tabs (or rather taskbar buttons) from left to right when you lift off the ctrl key. It re-order only items in popup window which it shows when user presses Alt-Tab once and then not release Alt. Just like Intellij IDEA (and almost any other editor with MRU) doing it (shown on screenshot in first post of this thread).

[slikts]

Exactly, it's a separate representation that gets reordered, and it's arguably not even a good feature, much less crucial. Since the order keeps changing, it's not good for memorizing, unlike the normal, static representation. The last few used items should be in your memory anyway, and for anything else you might end up cycling through a long list to get to it, so it's like a trap.

Because they did it from the start.

The point is that it's hard to find any alternative that wouldn't have MRU switching as the default.

[mark-hahn]

Since the order keeps changing, it's not good for memorizing, unlike the
normal, static representation.

I use my package tab-smart-sort that keeps tabs always sorted the same
way. After a few days I can go to tabs without looking.

On Sat, Apr 23, 2016 at 11:25 AM, Reinis Ivanovs [email protected]
wrote:

Exactly, it's a separate representation that gets reordered, and it's
arguably not even a good feature, much less crucial. Since the order keeps
changing, it's not good for memorizing, unlike the normal, static
representation. The last few used items should be in your memory anyway,
and for anything else you might end up cycling through a long list to get
to it, so it's like a trap.

Because they did it from the start.

The point is that it's hard to find an alternative that wouldn't have MRU
switching as the default.

Lastly, it's not that reasonable to edit configs based on guesswork.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-213800212

[BigMcLargeHuge]

I want to be clear here that I would actually prefer MRU order if it was implemented correctly. But the critical piece of MRU order is that the tabs get visually re-ordered from left to right when you lift off the ctrl key. MRU relies on visual re-enforcement to know what the current state of the tabs is.

@mcmar Wow, reordering the tabs could actually make MRU usable for me! I'd never thought of that. As it stands now, MRU is almost unbearable.

[xak2000]

My tabs usually show only first few characters of filename (because I like big font and many opened tabs) and not file path of course (that is problem because often there are files with same name but different path). So reordering tabs will do nothing useful for me. But inplementing popup like on first post's screenshot (where always enought space for full file names end even paths) do.

[grgrssll]

I can't believe this switch was made without an option in the settings. MRU is so painfully wrong to me... Luckily the release notes (http://blog.atom.io/2016/04/12/atom-1-7-and-1-8-beta.html) have a work around to put it back to LTR mode. I'm just completely baffled by this "fix".

[sarink]

^^ 👍 @grgrssll

What other software does this? Can you imagine if Chrome did this [suddenly and transparently to all its users]? How annoying would that be? Answer: Just as annoying as your IDE doing it.

Please at least add an option to turn it off in the preferences.

[sriharshakappala]

The main reason why I loved Atom is the left to right order in switching tabs and now you gave a reason to hate! Please add an option to disable this!

[jhasse]

What other software does this?

Sublime Text, VS Code, Visual Studio, IntelliJ, ... nearly every code editor does this.

[sarink]

Huh. I've used Eclipse, WebStorm, RubyMine, Notepad++, vim .... and I've never experienced this. Is it a new thing? In any case, I find it very confusing.

The option to toggle it should exist. Whatever you want the default to be, I don't care, but I shouldn't have had to come here to figure out how to disable it.

[jhasse]

Just tried Notepad++ v6.9.1: It's using LRU switching.

[sarink]

It's not that I don't believe you. It's that, no matter how many IDEs do it this way, suddenly changing every user's default setting overnight with no warning and no option in the preferences to change it back... is very irresponsible, imo.

[slikts]

Can you imagine if Chrome did this? How annoying would that be? Answer: Just as annoying as your IDE doing it.

It would be great if Chrome did it, which is why MRU switching is an oft-requested feature for Chromium. Sadly, it currently can't be implemented even in an extension in that case.

I've used Eclipse, WebStorm, RubyMine, Notepad++, vim .... and I've never experienced this. Is it a new thing?

Out of that list, only vim doesn't have MRU switching by default. It's also not a new thing. Have you tried pressing Alt+Tab or Command+Tab? Task switchers use MRU order too.

In any case, please take a moment to think before assuming that a nonsense feature would have been implemented and pushed as the default. Chances are you would do yourself a favor by adopting MRU switching.

[petemill]

I think we have already established that there are a group of people that
are more productive with display-order switching and many people that are
more productive with MRU-order, and that there is no right way and wrong
way. Perhaps people are wired differently. I personally would challenge
anyone to work as fast as I do when I use display-order with MRU-order as
I'm sure the reverse is true for others. We can live together in harmony!
:-)
On Thu, Apr 28, 2016 at 10:40 AM Reinis Ivanovs [email protected]
wrote:

Can you imagine if Chrome did this? How annoying would that be? Answer:
Just as annoying as your IDE doing it.

It would be great if Chrome did it, which is why MRU switching is an
oft-requested feature for Chromium. Sadly, it currently can't be
implemented even in an extension in that case.

I've used Eclipse, WebStorm, RubyMine, Notepad++, vim .... and I've never
experienced this. Is it a new thing?

Out of that list, only vim doesn't have MRU switching by default. It's
also not a new thing. Have you tried pressing Alt+Tab or Command+Tab? Task
switchers use MRU order too.

In any case, please take moment to think before assuming that a nonsense
feature would have been implemented and pushed as the default. Chances are
you would do yourself a favor by adopting it.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-215505712

[slikts]

MRU switching is so prevalent because it makes a common workflow of switching between recently used tabs more efficient, so there is a difference. You just described that you don't understand MRU switching, so it's not a good basis for comparison.

[xak2000]

I don't understand those people who say that they used Eclipse, Webstorm, RubyMine etc and never knew it uses MRU switching, but suddenly, when Atom has implemented this feature, they noticed it immediately.

May be something wrong with the implementation?

When I first opened Atom after the update, I had the feeling that the tabs are switched randomly, although I'm one of those who always preferred MRU and never tried to disable it in other editors.

Then I installed tab-switcher package and changed the hot keys settings thus:

"atom-workspace":
  "ctrl-tab": "tab-switcher:next"
  "ctrl-tab ^ctrl": "unset!"
  "ctrl-shift-tab": "tab-switcher:previous"
  "ctrl-shift-tab ^ctrl": "unset!"

"ol.tab-switcher-tab-list":
  "^ctrl": "tab-switcher:select"
  "ctrl-up": "tab-switcher:previous"
  "ctrl-down": "tab-switcher:next"
  "ctrl-escape": "tab-switcher:cancel"
  "ctrl-n": "tab-switcher:next"
  "ctrl-p": "tab-switcher:previous"
  "ctrl-w": "tab-switcher:close"
  "ctrl-s": "tab-switcher:save"

This package also implements the MRU, but for some reason now I have no feeling that the tabs are switched randomly.

Why? I really don't know!

Guess that's because pop-up window showing the file names in the current order (that no one can remember, but this window can), as well as due to the fact that I can switch to any file, without switching to intermediate tabs, if I don't release the CTRL key.

In contrary, in default implementation, as soon as I press TAB (even if still not releasing CTRL), I immediately go to the next tab. It's not always fast, and confusing, since the contents of another file (that I was not going to open now) appears before my eyes.

But more importantly, I can't figure out what file I will switch, if I press TAB again while holding CTRL.

So I think this pop-up window is important and without it MRU feature is unusable. Even for me: long time MRU fan.

P.S.

Can you imagine if Chrome did this?

It will be the best day of my life! :) Seriosly. I hated this mouse switching between google-translate tab and github tab, while writing this post. (please do not offer me to press CTRL+SHIFT+TAB - I just can't do it. It's terrible binding.)

[jmm]

@xak2000

(please do not offer me to press CTRL+SHIFT+TAB - I just can't do it. It's terrible binding.)

Use Right Ctrl+Pg[Up|Down] /s

[xak2000]

@jmm thanks! Didn't know this combo work in Chrome too. Will definitely use it!

But unfortunately it's usable only when tabs placed next to each other. Of course I can mouse-move one tab to other. But doing it every time would be tedious.

Also it breaks my mental model. With MRU I can focus on what I'm doing, and not try to figure out each time what key I need to press to switch to other tab (ctrl+up or ctrl+down). It's always ctrl+tab.

[Ajedi32]

@xak2000 There are extensions for MRU switching in Chrome, fyi: https://chrome.google.com/webstore/detail/ctrl%2Btab-mru/ialfjajikhdldpgcfglgndennidgkhik

[sarink]

I'm not arguing about whether it's a "good" feature or not. You can like it, I can dislike it, that's fine.

What I do find completely ridiculous though, is that this occurred transparently to users and there was no option in the preferences to revert it. I had to google and find a github issue. That's Bad

[slikts]

@Ajedi32 Thanks, that's a very good tip. I've had that extension installed but disabled for years since it didn't allow setting the keyboard shortcut to Ctrl+Tab. Apparently it's a recent workaround that allows overriding the default tab switching shortcut in Chrome. The tab switching in that extension doesn't work like in Atom, though, since it shows an intermediate tab list, which just kind of gets in the way (for me anyway).

I can't figure out what file I will switch, if I press TAB again while holding CTRL.

All you need to know is that it will be one of the recently used tabs, and then you can keep switching until you reach it. It works very well for the last few used tabs while switching to anything else with the mouse. The slowness issue would apply to the previous switching behavior as well.

[drewshaver]

Thanks @xak2000 for the link to the tab-switcher package. Very handy.

MRU is basically unusable without the additional info while switching, IMO. I find it absurd that it was merged to core without this package added as well.

[mark-hahn]

Is it my imagination or is this extremely long thread just arguing the same
points over and over?

On Fri, Apr 29, 2016 at 10:26 AM, drewshaver [email protected]
wrote:

Thanks @xak2000 https://github.com/xak2000 for the link to the
tab-switcher package. Very handy.

MRU is basically unusable without the info on switching, IMO. I find it
absurd that it was merged to core without this package added as well.

—
You are receiving this because you were mentioned.
Reply to this email directly or view it on GitHub
https://github.com/atom/atom/issues/5344#issuecomment-215822444

[drewshaver]

@mark-hahn The conversation started as just MRU vs tab-order, but then took a turn to pointing out the need for an overlay to give context while tabbing. Very valuable IMO.

Furthermore, the fact that this thread is so long supports that merging in this half-baked feature was a bold play. That said, I do love the Atom project and the devs have done a great job on it overall 😄.

[Ajedi32]

then took a turn to pointing out the need for an overlay to give context while tabbing

That should really be in a new issue. This one is already closed and anything discussed here is just going to get buried.

[perlun]

Is it my imagination or is this extremely long thread just arguing the same
points over and over?

I agree. Can someone with permissions lock this thread please?

[slikts]

@drewshaver Off the top of my head, MRU switching is also implemented without a tab selector in Sublime Text, Notepad++ and NetBeans. It's presumptuous to call it incomplete or unusable. MRU switching with a tab selector is an alternative implementation with a slightly different use and with its own drawbacks. It's also been explained repeatedly in the comments to this issue.

[drewshaver]

Good point @Ajedi32, submitted issue #11656. Issue #11535 is looking for someone to make a PR.

@slikts I have to disagree. I find MRU without guidance completely unusable. It's clearly not just me, either. I would imagine that a minority of users want MRU without guidance.

But there is no point going round and round on this. +1 lock the thread.

[slikts]

Remembering the last few used tabs that can be switched to doesn't take assistance, which is the use case for MRU switching as it's now implemented in Atom and the other fairly well known projects listed before. It's _quite_ presumptuous of you to try to say that it's completely unusable, considering how many people use it. There's valid reasons to prefer the alternative implementation (like if you can't or don't want to use the mouse to select tabs), but that mostly makes it a matter of preference. I've used both ways extensively, and I prefer no selector, since it's generally an inefficient way to select from any larger number of tabs (same as with no MRU switching), and it's slower to have to release the keys to switch, and reading the list is unnecessary for a small number of recently used tabs. A selector makes more sense in the context of task switching in the OS, where focusing a task might make it read paged memory, or set it to full-screen, but in the context of code editors it seems kind of vestigial.

[lee-dohm]

Thanks everyone for your feedback on all of this! I know that I have enjoyed reading the differing perspectives here and learning about other people's workflows.

As I mentioned in the recent blog post, we're trying to control the amount of Issues and notifications that we have to triage. For discussions like this one where people want to discuss the merits of one approach or design over another, the Atom message board is the best place to hash that out. Then when people have concrete proposals, they can open Issues with a specific plan of action.

Thanks again!