Sublime Forum

Behaviour after closing a tab and placement of close button

#1

Why after closing a tab the active one is the left neighbour instead of the last active one? Who changed this and why? And how do I change it?

Also, why the close tab widget is on the wrong (right) hand side of the tab instead of the left?

0 Likes
#2

Regarding the close tab behaviour, I found also this thread:

https://forum.sublimetext.com/t/change-tab-close-behaviour-right-not-left/12300/1

I tried facelessuser’s TabsExtra plugin where there is an option

"fallback_focus": "last_active"

but it didn’t work in Linux. I will try it in MacOSX too. Haven’t checked the source code yet. Anyway, even in theory, facelessuser writes that it wouldn’t override the event of physically pressing the close (X) button. It’s annoying and dissapointing. Sublime Text should be about configurability; working effectively with multiple files is crucial for many users.

0 Likes
#3

OK, tried again and it worked both in Linux and MacOSX. Using the shortcut, not by mouse pressing the close button.

The issue about the placement of the close button remains. I don’t know if there is a setting to change it in the general preferences or a theme that can be used.

0 Likes
#4

TabsExtra cannot replace the tab “button” command because it is called directly without going through the Python API. I cannot override the tab close button unless Jon redirects it through the API like the menu options. I personally disable the tab close buttons in my theme and just use the tab context menu to close files now. Just thought I’d throw that out there for what its worth.

I do not know of any way to put the close buttons in a different location.

0 Likes
#5

There might be a way to pull it off, but I will need to experiment.

0 Likes
#6

That would be great !

0 Likes
#7

[quote=“facelessuser”]TabsExtra cannot replace the tab “button” command because it is called directly without going through the Python API. I cannot override the tab close button unless Jon redirects it through the API like the menu options. I personally disable the tab close buttons in my theme and just use the tab context menu to close files now. Just thought I’d throw that out there for what its worth.

I do not know of any way to put the close buttons in a different location.[/quote]

Thanks for the answer.

There is no problem when I am working on the desktop as I usually have a multibutton mouse (I always program one of the buttons as ctrl+w in Linux or cmd+w in Mac) and also pressing a middle mouse button is never a problem when I want to selectively close tabs (without having to activate them first). But when I am on the go with just my laptop I would prefer to have the flexibility of using the close tab button/widget.

0 Likes
#8

:frowning:

IMHO there is no reason why the close tab button shouldn’t be by default at the left-hand-side for Macs, read from e.g. dconf/gsettings button layout in Linux, AND have the option of choosing whether to override the default in Sublime general settings for everyone.

0 Likes
#9

Added some hackery fu. TabsExtra should be able to predict when a close occurs outside of the API, so tab buttons should work now. Let me know if I inadvertently broke something else.

0 Likes
#10

Thanks ! It’s too late here so I will test it tomorrow. From a first view it seems to work but not if you rearrange (with the mouse) the tabs, it gets confused. I guess we can’t have it all.

0 Likes
#11

Tab rearranging shouldn’t have any effect. Try restarting ST tomorrow and playing with it. If you can give me more specific details on how to reproduce an the issue, I can probably do something. Rearranging tabs on my system has no adverse effect.

0 Likes
#12

I get inconsistent behaviour after closing all tabs or window (in Mac). Both with 3059 and 3061, Mac/Linux.

(7.txt is activated)

activate: 1,3,5,7,2,4,6

start closing all tabs either by shortcut or mouse: 1st time it works. Repeat opening and activating the {1…7}.txt files and it gets confused.

0 Likes
#13

[quote=“gorg”]I get inconsistent behaviour after closing all tabs or window (in Mac). Both with 3059 and 3061, Mac/Linux.

mkdir tabs
touch tabs/{1…7}.txt
subl3 tabs/{1…7}.txt

(7.txt os activated)

activate: 1,3,5,7,2,4,6

start closing all tabs either by shortcut or mouse: 1st time it works. Repeat opening and activating the {1…7}.txt files and it gets confused.[/quote]

I will check this later today. It is possible I get in a bad state and am no longer timestamping the views or miss some. I try to guard against timestamping certain focus calls I do when closing the files so not to update the timestamp when batch closing the files. It is possible a flag is getting set in a bad state. I will let you know later, but I think this can be ironed out.

0 Likes
#14

I had some syntax issues and a case where a close gets called with views at index -1. I just pushed fixes for those.

What was probably happening was, apparently sublime when there are no views open, and you open a new file, sublime closes some invisible view with index -1. So that probably caused the listener class to bomb, and then it couldn’t detect tabs closes anymore.

Update and give the new version a try. You may need to restart.

0 Likes
#15

facelessuser, thanks for your hard work. The problem with the wrong indexing after closing all tabs or the program window has been solved. But still there is a problem with updating the idnexing queue if tabs are rearranged. In my previous example:

Open (or activate) in order: 1,2,3,4,5,6,7

then activate 2 and move it a few places, e.g. after 5 and before 6. After closing 2, 1 gets the focus instead of 7.

0 Likes
#16

I found out why it does it…not sure yet what I can do.

The reason it gets “confused” is because when you move a tab, it activates the tab to its left, and then re-activates the tab that got moved.

So when you move tab 2 between 5 and 6, tab 1 gets activated, and then tab 2 gets re-activated. The only way to fix this is somehow detect the tab 1 is getting activated because of a move. It is possible I can save the tab ids or something and if tab ids are all the same, but re-ordered, then the activation can be ignored. I might try it out this weekend. If it works, I will let you know.

0 Likes
#17

Turns out the fix was a bit easier than I thought it would be. The tab on move is actually removed from the window. That is why the adjacent tab gets selected. But I put in a fix to detect when this “move” is occurring, and it should skip timestampping the adjacent view during move.

Give it a try. Hopefully, I finally have it working reasonably in most scenarios now.

0 Likes
#18

That should do it. It works great. You did a good job. Thanks! If I find any problems in the future or have an interesting suggestion I will contact you.

0 Likes