Add config option for MRU tabs

[winstliu]

Prerequisites

• Can you reproduce the problem in safe mode?
• Are you running the latest version of Atom?
• Did you check the debugging guide?
• Did you check the FAQs on Discuss?
• Are you reporting to the correct repository?
• Did you perform a cursory search to see if your bug or enhancement is already reported?

Description

#10737 made ctrl+tabbing MRU-based, but did not offer a config option to revert to the existing left->right behavior. Given that this is a very significant change to default behavior, we should keep the old sequential behavior as the default switching technique and expose MRU tabbing through its own setting.

/cc @natalieogle, @benogle

Versions

You can get this information from executing atom --version and apm --version at the command line.

Atom    : 1.7.0-dev-6beed1d
Electron: 0.36.8
Chrome  : 47.0.2526.110
Node    : 5.1.1

[benogle]

I really think we should make MRU ordering the default. Many other editors ship with it as the default, many people want it out of the box, and there are already 3 other pairs of commands (cmd-{|}, cmd-alt-left|right, ctrl-pageup|pagedown) that move left / right through the tabs.

If MRU switching is going to be the default, there will need to be a behavior change at some point. Why not now? I suppose the reason for why not now is if we're worried that it is buggy. But that's sort of what beta is for. If people are super worried about bugginess, maybe it wouldn't be the default for a release or so, then we'd need to do the behavior change.

But even then, I think it will be interesting to see if there are complaints or confusion when this hits beta.

People can revert via a keymap change, which we can advertise in the release notes or the blog post:

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

Edit by @50Wliu: Fixed keymap changes to use unset! instead of abort!

[xak2000]

What this ^ctrl and abort! really do and why simple rebinding 'ctrl-tab': 'pane:show-next-item' is not enought? I think this syntax is not intuitive for many people. I thought long and hard what that might mean and why we need write ^ctrl second time if we already wrote ctrl-tab and still I have no idea what this means. And I saw other people post similar feelings.

I think the problem for people who want back left-to-right behaviour not with defalut, but with this cryptographic settings. :)

[lee-dohm]

abort! is the same thing as abortKeyBinding() documented in the Flight Manual. The ^ctrl is a new ability for the atom-keymap package that was added specifically for MRU tab switching, it means that the command isn't activated until Ctrl is released. (You can find more information on this new ability in this PR.)

[xak2000]

Thanks for the answer. Now I read the docs and especially useful information in PR. It's really magic... ✨

Now I understand what each of this construction do separately, but I still doesn't understand what they do in this concrete binding:

'ctrl-tab': 'pane:show-next-item'
'ctrl-tab ^ctrl': 'abort!'

My attempt to understand:
If user presses Ctrl+TAB, then do command switch to next tab in left-to-right order. If user then releases Ctrl, then abort this key binding (what keybinding? releasing Ctrl key? Or pressing Ctrl+TAB?) and continue searching for another matching binding. But why we need this? Maybe MRU switching in new release uses exactly this binding 'ctrl-tab ^ctrl' and we just want to unbind it? But why we don't use unset! then? I'm totally confused now.

[lee-dohm]

Maybe MRU switching in new release uses exactly this binding 'ctrl-tab ^ctrl' and we just want to unbind it?

☝️ This is the reason. There's really very little difference between abort! and unset! in this instance. You can use either.

[UltCombo]

I'd say to keep the old behavior by default and add a config option for MRU tab switching.

Such changes to the defaults are very disruptive for users and, IMHO, this is a huge downgrade—sequential tab switching by default is one of the few things that Atom had got better than Sublime.

At least for me, MRU is very hard to work with once you are working with more than two tabs—I don't have enough spare cognitive load to remember and update the order of the tabs I've used recently, I'm spending it with things that actually matter such as code logic and flow. And in case I'm working with just a few tabs of a larger set, it is easy to reorder them to be next to each other and sequentially switch between them forwards/backwards, thus only a single tabs order needs to be remembered and you can always take a quick look at the tabs bar to refresh your memory. Therefore, sequential switching is superior in every single aspect and MRU is completely useless to me.

Okay, sorry for the small rant.

In any case though, I know I have no say here and you guys can do whatever you want, but please, please make sure to document a way to disable MRU when you announce v1.7.0 stable in the blog (and perhaps somewhere in the official documentation?) if it ships with MRU by default.

[jneubrand]

For anyone else annoyed by this change: according to my (limited) testing, abort! doesn't work with the config changes posted above. Use unset! instead 😄

[BlaM]

So a temporary fix for this issue is to insert this into the keymap, correct?

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

[Alhadis]

Yep, unset! appears to do the trick. Using abort! makes things even weirder. :|

In all honesty, this level of customisation shouldn't be necessary for something as fundamental as window navigation...

[perlun]

I agree that it wasn't perhaps so wise to let this slip into a "minor" release (1.6 -> 1.7) without a UI to disable it. (I think I already had an MRU package in place, since I found the old behavior completely wrong for me, so I think the feature is nice, it's just the way that we delivered it to be a bit obtrusive.)

[Ajedi32]

Why not just make MRU the default for new installs, while keeping the old behavior for existing installs? That would allow a smooth transition to default MRU tab switching without disrupting existing users who are used to the current tab switching behavior.

[jneubrand]

@Ajedi32 idk, IMHO I think it'd be fine if it's made very clear in the release notes that there's a toggle (and where it is)

[BlaM]

How many people actually read the release notes? Most users just want to have a stable development environment, only few actually have the time to actively manage it.

[Alhadis]

I read the release notes, but I fully agree. Most casual Atom users will see an upgrade, install it habitually in an age of evergreen browsers, and not think twice about what it added until they notice a new feature... or bug.

[phrz]

This is not at all intuitive — I have been looking over the course of days in Atom Discuss and these issues to find this exact issue. I use Xcode, Sublime, and Atom, and now Atom is the odd one out on tab behaviour — I have never touched an IDE with MRU tab ordering.

If Atom is going to implement a very opinionated change like this, there at least needs to be a Settings switch for it.

Even if the prevailing opinion is that MRU is superior, the large group of more novice users who prefer the old tab behaviour have no switch, either in General Settings or the tabs package, to tweak this. I am not a beta tester, yet for the editor behaviour to change so radically and not provide me with an "out" makes me feel like one.

[UltCombo]

By the way, you guys say MRU was a "heavily requested feature", but I've read the relevant thread and I can see that most of Atom's core contributors opposed changing the default tabbing behavior to MRU. Also, you have to consider that people who were looking for MRU tabs switching in Atom are likely to reach that thread and +1 it, meanwhile casual Atom users who were happy with the sequential tab switching behavior and don't follow this repository (e.g. me) are very unlikely to reach such a thread. Therefore, your metrics were completely unfair and skewed!

The next time you consider such a drastic fundamental change to defaults, at the very least please perform a poll in an unbiased way for the community to decide (something simple like a Twitter poll may be enough, I think).

[maxnowack]

MRU is only intuitive if you can see the items ordered while switching.
Like cmd-tab on OSX or alt-tab on windows.

Please switch back to the old behavior or provide a config option for that! The workaround doesn't work for me ...

[Ajedi32]

@UltCombo Agreed. I think the same effect is also happening here. With the exception of one or two people, everyone in this thread got here by noticing the change, not liking it, then searching Google to find out what happened and how to fix it. We're not going to hear much here from the people who noticed the change and liked it, or the people who didn't notice the change because they already had some kind of MRU tab switching plugin installed.

I think a poll of some kind would be a good idea here. Ideally we'd just have Atom ask users which option they prefer when they update, then use that selection to determine which behavior the editor uses for them, and which option becomes the default for new installs.

[Macil]

It baffled me that the order that I cycle through tabs seemed to be random, and to add insult to injury, it would then change throughout the session. The logic of the ordering was entirely lost on me. I've always expected the tab behavior to be consistent with tabbed browsers (Firefox, Chrome, etc) and had been very happy when I first tried Atom and found that it was. I typed up a bug report that tab order was completely broken by 1.7 and was about to report it before I found this thread. It didn't even occur to me that this might be a configuration issue/change.

[xak2000]

I just want to give my voice for MRU.

And yes, I read this thread only because I posted in it early. Other people who prefer MRU just never see this thread. Therefore discussions like this never be constructive. There will be always many people who don't like the subject and almost none who likes because they just don't ask google for it. They just say "Ok. I like this new feature." and that's it.

For existing users something like asking user when updating: "There is new MRU tab switching feature you can use. [Enable MRU tab switching] [Use current behaviour]" would be ideal. Of course only if current CTRL-TAB binding is default and not overriden.

For new installations... I don't know. But all (literally all!) editors which I used before were using MRU. And not only editors. Windows ALT-TAB always used it and I just got used to it since the days of Windows 95. I never used MacOS. Maybe MacOS uses left-to-right behaviour? I don't know. The only exception to this that I use is Google Chrome and me always enraged his left-to-right behavior. Especially when 20 tabs are opened and I only want to switch between two, but know that the other 18 will need soon, therefore not close them.

But the important thing with Windows and all other editors with MRU: If you do not release the modifier key after pressing TAB, then they show overlay window with current items placed in MRU order. And therefore you know the order.

MRU is very convinient when you need continuously switch between two items (tabs). But it can became very inconvinient if you really need to switch to other tab. And in this cases this overlay window with list of items is very important. Without it I can understand @agentme feelings about randomness. :) I like how it's done in tab-history extension. Used it before (when atom does not have this functionality) and it worked like a charm.

[jneubrand]

I think it's fine if there's no modal dialogue for users who upgraded. I just think it's sad that this wasn't mentioned in the release notes and that such a huge change to the default keybindings was made without keeping (simple) configurability in mind.

[alexrussell]

@xak2000 of course you're right about this issue unfairly representing the no-MRU camp, but, as was mentioned earlier by @UltCombo, the original thread that was apparently the basis for the feature's inclusion in Atom was the exact same but the other way around - all the MRU people posted there so the Atom core devs thought there was a lot of call for it and very few people against it. So yeah, creating a decision by asking the community will never be fair unless there's some way to ask every last user their preference.

That said, I say don't bother with the modal - it's too intrusive and more than a little odd to do. As has been said, most other editors use MRU by default, so it probably makes sense for Atom to follow anyway. But all of those editors give a simple setting to change it - not some crazy "if you don't want to opt in to this feature remap the keys and then unset the special keymaps put in place to make MRU actually work properly, it's as simple as these cryptic four lines, I can't believe I even had to spell it out for you!"

Also, FWIW @jneubrand it was mentioned in the release notes - v1.7.0-beta0 and v1.7.0 stable both mention it. They don't go into any more detail but they do say that MRU is in.

[alfuken]

+1 for the option checkbox or the rollback. I've spent quite some time to at least figure out WTF, and how to fix this.

Right now both pane:show-previous-item and pane:show-previous-recently-used-item work absolutely the same, which is pure nonsense!

[mcmar]

It's totally insane that I opened my editor up after updating and my tab behavior was completely changed. This should absolutely have an option to disable it for the sanity of developers everywhere.

[mathvav]

@benogle

3 other pairs of commands (cmd-{|}, cmd-alt-left|right, ctrl-pageup|pagedown) that move left / right through the tabs.

FYI: None of these work on Windows for me with the CTRL equivalents except the page up/down, which is clunky on desktop and impossible on laptop. Furthermore, most users don't know this shortcut. There aren't viable alternatives for Windows users.

The keybinding did work, but it took me 15 minutes longer than it should've to find it (thanks to those who wrote it!).

[cryptoquick]

Boo, Atom. Boo. 😿

[wyqydsyq]

It boggles me as to why when it became apparent making MRU the default method of tab switching without a UI to show the MRU list and without a UI option to disable it was a bad idea that someone didn't revert that.

I just did a fresh Atom install 5 months after I first had this issue and the fact that I still had to search Google to copy-paste some lines into my keymap.cson just to have my tabs behave predictably is absurd.

Based on the current state of this ( @iolsen says the MRU List UI is still TODO ) MRU should not be the default, it should disabled by default and with an opt-in checkbox on the Core settings page.

I understand it was decided to use MRU as the default to appeal more to ST users since Atom is more or less an open-source ST built with Electron, but when the issue was raised that UI-less MRU behaviour is confusing and unintuitive the change to make it default really should have been reverted.

[Keavon]

Indeed, imagine if Chrome suddenly switched its tab behavior to MRU. People would freak out and there would probably be a mass exodus from the browser because a logical feature was suddenly given illogical, unexpected behavior.

[alexrussell]

It boggles me as to why when it became apparent making MRU the default method of tab switching without a UI to show the MRU list and without a UI option to disable it was a bad idea that someone didn't revert that.

What is particularly ironic is that any requests/discussions to revert it are generally ended with "well we wouldn't want to just suddenly change the behaviour as that would really confuse people". But what about that time you just suddenly changed the tab switching behaviour and really confused people?

[iolsen]

Definitely some mistakes were made pushing this out too fast. 😞

[wyqydsyq]

@iolsen it's not really a huge deal, I was just surprised to find the situation with this hadn't changed in 5 months given how rapidly Atom had been moving in other areas. I guess that's the thing with OSS though, often only the fun sexy parts get attention, so thanks and good on you for being the one to finally step up on this issue 👍

[TheNotary]

Tabbing behavior... changed... in my latest... Atom update...

EDIT:
I'm refering to the case that I just updated from 1.7ish? to the current MRU state (The ppa gave me Atom 1.11.2) sorry if I created any confusion.

Joking aside (and I am in support of taking defaults seriously, btw) I visited the discuss page and found this thread https://discuss.atom.io/t/mru-tab-switching/11146/6 which seems to be the discussion point for this behavior change. I read it, and the discussion seemed to gravitate towards the fact that this feature existed via the ctlr+b command. That discussion would not have prompted me to take action to voice my current dependency on 'absolute tab navigation' (the old way) even if I saw it and did have an account there.

As a workaround for setting up atom just the way I want it with out needing to do very much special tweaking, I manage my configurations in a dotfiles repo, and recently made some changes to my deploy script to compensate for atoms config files. Others may find this kind of setup handy, but be careful not to blow away all your existing dotfiles, that would make me feel bad! https://github.com/TheNotary/dotfiles/blob/master/make.sh#L59-L91 I don't know where is most appropriate to voice this, but the panes we're working with are already visually depicted as tabs, their order is also visually depicted, therefore skilled atom users can rapidly switch to the exact tab they'd like to. I've long felt one of the hallmarks of atom is that fact that it's pretty nice out of the box, and this modification seems to be a step away from that.

[entozoon]

It hasn't has it?

[Ajedi32]

Whoops. Looks like this bug was mistakenly closed by atom/atom-keymap#156. GitHub apparently isn't smart enough to realize that

and is a prerequisite for adding the MRU list UI (atom/tabs#388) that fixes #11035.

isn't the same thing as

fixes #11035

😜

CC: @iolsen

[pehrlich]

Is this still a current fix? With Atom 1.12.2 on OSX, the above code snippet does not revert the exasperating MRU default :/

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

[iolsen]

Is this still a current fix?

Yes it's still current in 1.12.x: I just confirmed it in 1.12.6. You might be able to use the keybinding resolver (cmd-.) to determine what's happening in your install.

[entozoon]

@pehrlich looks right, the plugin:
https://github.com/entozoon/atom-disable-mru-tabbing
Still works for me, on Atom and Atom Beta.

[iolsen]

Fixed in atom/tabs#388. Set to ship in 1.14.

[Keavon]

Thank you!

[dmo-odoo]

Thank you so much !

[alexrussell]

@iolsen, a god amongst men.

[dpanter]

@entozoon Thank you! A mystery why the MRU switching crap isn't easy to disable, or even why it isn't disabled by default.

[iolsen]

@dpanter the option to disable it shipped 9 months ago in Atom 1.14.

[dpanter]

Finding that option was really easy too! It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying ‘Beware of the Leopard'.

Jokes aside, here is the built-in option: https://discuss.atom.io/t/i-want-ctrl-tab-to-work-like-it-used-to-how-do-i-do-that/28639

[iolsen]

😆 that's fair. We've been meaning to add setting search for a long time.

[dkurzaj]

Is there any actual tick-box to enable or disable MRU, or is the official solution to edit the keymap.cson file ?

[Ben3eeE]

@dkurzaj there is a setting in the tabs package see https://discuss.atom.io/t/i-want-ctrl-tab-to-work-like-it-used-to-how-do-i-do-that/28639

[lock]

This issue has been automatically locked since there has not been any recent activity after it was closed. If you can still reproduce this issue in Safe Mode then please open a new issue and fill out the entire issue template to ensure that we have enough information to address your issue. Thanks!