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

Marc Wilson posguy99 at gmail.com
Sat Sep 7 21:00:45 UTC 2019


*Anything* but the system tab implementation, please.  Apple’s broken idea of what tabs are is completely unusable.  Poorly implemented and hard to use, hard to distinguish between tabs, etc.

This was previously discussed on this list.

-- 
 Marc Wilson
 posguy99 at gmail.com

On Thu, Sep 5, 2019, at 1:32 PM, Andrew Hodgkinson wrote:
> I hope this is the correct place to post about this; the TextMate GitHub 
> repo doesn't seem to let anyone add issues. This setting:
> 
>    defaults write com.macromates.TextMate.preview disableTabAutoClose 
> -bool YES
> 
> ...is being ignored by RC 29, 30 and 31 (if not earlier, I didn't try). 
> The last "mainstream" release appears to be RC10, which works fine.
> 
> The setting is absolutely vital to me, so I'd really love to see this 
> issue fixed. In the mean time I'll stick to RC10.
> 
> To be honest, I'm surprised it isn't the default. This is of course just 
> a subjective opinion! 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. The behaviour feels rather 
> arbitrary / random too; the threshold depends on window dimensions, so 
> it isn't very user-predictable. I never remember to right-click and 
> choose "Sticky"; it's not something I've ever had to do in any other 
> text editor or IDE, so it's just not in my muscle memory.
> 
> Has there been any consideration to using the current macOS system-wide 
> tab bar instead? This "compresses" tabs when the tab bar gets full & 
> automatically expands tabs towards the side of the tab bar most recently 
> selected (at least in Finder or Safari, but maybe Apple implemented 
> special subclasses and this isn't out-of-box Cocoa behaviour). If it's 
> good enough for web browsers, where having very large numbers of tabs 
> open is common, it's hopefully good enough for a text editor too. The 
> "hide if overflowing" behaviour, if it were kept, could then become 
> opt-in instead of opt-out. While other editors seem to be adopting 
> Sublime's "temporary tab" approach, I've never been sure I like it; and 
> going with the best-practice OS X core system approach has always felt 
> like the TextMate ethos.
> 
> -- 
> 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
> 
> _______________________________________________
> TextMate mailing list
> TextMate at lists.macromates.com
> https://lists.macromates.com/listinfo/textmate
>


More information about the TextMate mailing list