On 15 Sep 2019, at 22:14, Allan Odgaard wrote:
To be honest, I'm surprised it isn't the default. This is of course just a subjective opinion!
My thinking was that a full tab bar (that degrades into an overflow menu) is a bigger annoyance than having stale tabs auto-close.
It is definitely a subjective opinion only. I would prefer to have an alternative to just overflow too ;-) (we get into that later) but I find it better than the unpredictability of auto-close. The overflow menu is really sort of like auto-close anyway - it's more a "recently hidden tabs" thing, in my mind - just with excess tabs cached, rather than closed, for rapid access & undo preservation. That said, it is good to have the choice especially for those who want tabs to *really* close, so that TextMate's overall runtime memory footprint is more constrained.
For me, having tabs close and lose tab ordering and positioning is quite destructive to workflow, especially when working in projects with large numbers of files. I have to go scrolling up and down in the file browser trying to relocate something I'd opened for reference but has now closed again.
Are you aware of File → Open Quickly… (⌘T)?
Yes, I use it heavily. It's always been one of my favourite features :-)
On Ruby On Rails projects, as an example, one might well be adding a new model & controller to add some single resource feature to a site. This might mean the following are open: en.yml, application.rb, routes.rb, new_model.rb, new_model_spec.rb, new_model_serializer.rb, new_model_policy.rb, new_model_controller.rb, a system and request spec for new_model, new_model_helper.rb, index.html.erb, possibly the application.css and application.js file - and so-on. I tend to "work horizontally" across files (in terms of the way TextMate is laid out) and I heavily use a combination of both Cmd+T and large numbers of tabs to work efficiently. Rails can have quite long filenames a lot of the time, which doesn't help matters. I usually have en.yml, routes.rb and application_controller.rb pinned, but after that it becomes quite difficult to keep track and if things close.
I find I use Cmd+[ / Cmd+ ] along with Cmd+<number> to jump around a lot and rapidly know "where a tab is" as I'm working (re-order when opening files is turned off).
I've also (unfortunately) had to spend a lot of time in VSCode. Its Sublime-borrowed feature of "temporary tabs" (italicised text in tab entry) off the Cmd+T quick-open popup and from whole-project search/replace is often at times useful as it is at times annoying. While I understand their solution, it's not something I'd be in a rush to implement in TextMate. It *might* be a blocker for people from other platforms who have never known any other paradigm though and is an interesting solution to "tab overload" issues.
I think in the end, I prefer an editor to do the last amount of magic "stuff" so it imposes the lowest possible cognitive burden, allowing me to focus on the code. I don't want to have to be wasting brain on remembering the editor's state (do I need to pin the tab as sticky, will I lose undo, is this tab temporary & going to get replaced if I open another file, are the tabs going to reorder etc. etc.) if I can help it.
But you do have a point that it’s not expected behavior, for now, I have made the `disableTabAutoClose` available through a checkbox in preferences: https://github.com/textmate/textmate/commit/d9ac41d7900370b85bcf1d0c25ef58c4fbc44a60
This is very awesome and much appreciated - having something like this as a visible option puts the power into the user's hands with pretty much no learning curve and is great to see. Also, congrats on v2.0!
I think you’re the first user to bring up this issue, so I’m hesitant to change the current defaults
For sure, if that's the case. I doubt I'm your "average user".
Has there been any consideration to using the current macOS system-wide tab bar instead?
As far as I know this is only available by using the document based architecture where the system basically collapses the applications multiple windows into tabs. So it’s not a component that can just be adopted, we would have to re-engineer the application to use the document based APIs [...]
Ah, I see. I imagine there would have to be some definite known advantages and few to no disadvantages of spending engineering time on that kind of thing, then.