On 8 Sep 2019, at 9:00, Marc Wilson wrote:

Apple’s broken idea of what tabs are is completely unusable. Poorly implemented and hard to use, hard to distinguish between tabs, etc.

Well, it seems to me at least that:

* TextMate's implementation uses the same colours, fonts and outlines. * TextMate's tabs are a bit thinner, which saves a bit of screen space but at the expense of making it easier to "miss" when dragging and dropping tabs to reorder. * Tab height aside, TextMate and Apple tabs appear to be visually almost indistinguishable. * TextMate and Apple tabs both support drag-to-reorder. * Apple's dragging seems as responsive as TextMate's, but I've had a few bugs with TextMate's tabs where they don't drop where you expect, or the tab bar gains "gaps" where closed windows leave spaces behind.

There are few things that seem to differ.

* Double-click on a tab to open in a new window. I seem to trigger this accidentally when clicking on a window to bring it to the foreground way more often than triggering it intentionally. * Dragging a tab away from the tab bar with Apple tabs "tears off" the tab into its own window, similar to TextMate double-click. In TextMate, dragging a tab turns it into a thing which inserts "context dependent things" (e.g. entire file contents, file path, a Ruby 'require' statement) when dropped. This happens usually for me from a failed drag-to-reorder and the same feature is already available by dragging in a file from the File Browser anyway. * Equally sized tabs with text truncation. This is IIRC how Apple tabs *used* to work until a couple of OS X versions or so ago; now they do the compression and expansion thing, which seems more helpful in a web browser but perhaps less so in a text editor. I'm on the fence. I did have a look at the Apple API docs to see if the application could choose the display style, but more on that below.

So what am I missing that makes OS X native tabs so bad compared to TextMate's? Doing all this dev work bespoke is surely gallant, but feels like it might be effort that could instead be spent elsewhere.

All this said - the API docs for Apple's tabs are a complete joke, to the point of utterly embarrassing. There is literally no documentation at all, beyond auto-generated lists of properties and methods with no descriptions of any kind whatsoever. Even more of a horror story for usability and consistency is the failure to update the HIG with any information on window level tabs; https://developer.apple.com/design/human-interface-guidelines/macos/windows-... is a different thing entirely. There have been no documentation updates for this at all, at least, that I can find. This all comes from a company that used to set almost the gold standard in API design and documentation.

A nice UI thing might be to add a ⌘T button in the tab bar (i.e if that's the replacement for clicking on a stale tab, then make it click-accessible too.

Less discoverable, add new tab + sign could change to a ⌘T button when user holds down option?

Thinking about it, in mail.app right now, I have a tool bar in the title bar... For TextMate where several of the most powerful innovations are hidden away (all the Ts :-) ), adding these to the title bar would be a win, esp for users who fail to learn less-than-daily-use multi-key commands

PS: Removing the "add license" button text would be nice for those us who have added a license already :-)

t

On 15 Sep 2019, at 11:14 am, Allan Odgaard mailinglist@textmate.org wrote:

On 5 Sep 2019, at 22:32, Andrew Hodgkinson 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.

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)?

This opens a list of recently used files and offers a much faster way to re-open files.

When using ⌘T the order of tabs, and which are open, becomes less important, and this also influenced my decision about the current behavior with re-ordering and auto-closing.

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/d9ac41d7900370b85bcf1d0c25ef58c4... https://github.com/textmate/textmate/commit/d9ac41d7900370b85bcf1d0c25ef58c4fbc44a60 I think you’re the first user to bring up this issue, so I’m hesitant to change the current defaults, but you do have a good point that tabs should behave predictable, so I may reconsider them in the future.

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, and there is likely to be some disadvantages to doing that. But I am slowly moving the internals toward NSDocument and friends.

---

TextMate mailing list TextMate@lists.macromates.com https://lists.macromates.com/listinfo/textmate

PS: Removing the "add license" button text would be nice for those us who have added a license already :-)

That button should definitely not appear, if TextMate can find your license in the keychain...

Curious: It’s been there for years… I clicked on the button now, and the license is there, but instead of hitting cancel, I just clicked outside the license pane, it closed, and now that reminder is gone Bingo! Hitting cancel does nothing, but dimissing by clicking outside and it updates whatever counter is involved.

Thanks! t

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.