[TxMt] Re: RC29-30-31 don't obey tab auto-close override

[Andrew Hodgkinson]

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.

-- 
TTFN, Andrew Hodgkinson
Find photos, software, music and more at my home site, Bandcamp and 
GitHub:
https://pond.org.uk / https://pondnz.bandcamp.com / 
https://github.com/pond