This cannot currently be changed. Can you tell me what you would like to change it to?
I often a) have a lot of files open that are relevant for some project (source files, plus several plain text "notes" files), and b) several of them have long file names.
The long file name tabs take away a lot of tab bar space; as a workaround, I try to rename them to something shorter, if possible, or I close/reopen them. It's not my ideal workflow though, where I just cycle through the open tabs, and the names can be as long they need to be.
Ideally, I'd *cut down* the file name via some regex, say, stripping the file ending, and generally, only displaying the last n characters of the name, so that all tabs would have the same width (and I can have more of them open without the tab bar overflowing).
I know... bit of a minor/OCD-ish problem, but that would be my ideal scenario -- it would be similar to what I can already do with the window title.
You _can_ give documents a custom display name, but currently only via `mate` when they are opened, but this display name is used beyond just the tab titles, I assume you want to keep the original display name in other locations.
I wouldn't mind it, since I'm more interested in *shortening* the tab title than I am in displaying permanently the full title (which I can always get it via tab mouse over).
But to be sure: does the 'mate' solution work together with "open (recent, favorite) project" at TM startup? Because that's what I do it now, having set "showFavoritesInsteadOfUntitled" to true (and actually using a bit of a hack to "bookmark" different projects, consisting of files across various directories, by abusing that the relevant information seems to be stored in "RecentProjects.db").
On 6 Aug 2016, at 19:20, M. wrote:
Ideally, I'd *cut down* the file name via some regex, say, stripping the file ending, and generally, only displaying the last n characters of the name, so that all tabs would have the same width (and I can have more of them open without the tab bar overflowing).
This does sound more like something that needs to be a “native” feature rather than something you can achieve by setting the tab title for your documents.
Currently the tab widths have a minimum width of 120 pixels set here: https://github.com/textmate/textmate/blob/master/Frameworks/OakAppKit/src/Oa...
It would be easy to read this from user defaults instead, though you may also need preferences as to how to truncate a title. Currently it’s truncating the middle part.
[Apologies, duplicate, because previous message was sent with 'reply to' instead of 'in reply to'... Yeah, I suck]
It would be easy to read this from user defaults instead, though you may also need preferences as to how to truncate a title.
Tinkered a bit myself yesterday with the source, it sort of worked, but I always seemed to break the layout in some subtle way (I guess it didn't help that I didn't quite understand what 'tabViewSpacing' does exactly). So when I noticed the brandnew build with the new user default settings I felt a bit stupid.
Seriously though, thanks!
One last question if you allow: minimumTabSize and maximumTabSize don't behave exactly like I initially thought they would. For example, setting minimumTabSize = maximumTabSize = some_value made me expect all tabs would now be of identical (horizontal) width, at any time, but that's not the case (long file names still get wider tabs than what is set in maximumTabSize).
That's by design I assume, as in: maximumTabSize only kicks in when the tab bar overflows. Did I get that right?
On 8 Aug 2016, at 15:11, Bert wrote:
One last question if you allow: minimumTabSize and maximumTabSize don't behave exactly like I initially thought they would. For example, setting minimumTabSize = maximumTabSize = some_value made me expect all tabs would now be of identical (horizontal) width, at any time, but that's not the case (long file names still get wider tabs than what is set in maximumTabSize).
That's by design I assume, as in: maximumTabSize only kicks in when the tab bar overflows. Did I get that right?
Sort of, yes. I now realize that `tabItemMaxWidth` is a bit of a misnomer because it’s actually `tabItemDefaultWidth`.
That is, by default, each tab item will be the width set using this setting. If the tab bar overflows, they’ll be shrunken, but never to less than `tabItemMinWidth`, however, if one tab item has excess space and another item would be truncated, we redistribute, as we do with everything here in Scandinavia :)