Here’s an English screen-shot:
And thanks for the tip. I have confirmed the same behavior on macOS 15. Column resizing uses the thumb at the bottom of each column’s scroll-bar when scroll-bars are visible. It uses the thin divider (with a cursor change) when scroll-bars are hidden.
I never noticed this before because I have always had my computers configured to show scroll-bars, and this thumb was in the interface going back to the earliest days of Mac OS X.
Same here. Version 25C56
Adam, the Terminal command doesn’t appear to work in MacOS 10.13.6; at least I didn’t see any changes in file names that were truncated. Manually enlargement works but disappears after you close the window.
@Mark_Nagata Thanks for identifying that settings dependency! I do indeed have “When Scrolling” selected for my scrollbars, in part because they’re even uglier in Tahoe than before (and Apple hasn’t really designed for them for years).
This is also how you get to the problem others have called out: the horizontal scrollbar appears over the handles you use to change column size. And wow, those scrollbars are weirdly dark!
Compare that with Sequoia:
[…] ]expands columns only enough to display the currently visible items without truncation. This approach makes perfect sense, since the user is invoking the command to adjust what they’re looking at.
I respectfully disagree with your assessment that this “makes perfect sense,” Adam. Not because of personal opinion, lot alone a desire to enter into an argument.
It simply is a question of consistent behavior of one interaction being applied across different contexts.
Take, for example, double-clicking a column divider in a spreadsheet: this will also adjust the width of the column to the widest cell content in that column. And it does so without depending on whether that widest content is in view, or not. This behavior is exactly identical at least in Apple Numbers, Google Sheets, and Microsoft Excel.
Similarly, the same interaction applied to the sidebar in Apple Mail will adjust the width to the widest folder name. Again without taking into account whether or not that folder name is inside the window’s viewport. It doesn’t even matter if the section containing the widest folder name is collapsed, or not. Double-clicking the divider always adjusts to accommodate the widest name.
Most importantly, the same thing happens when you set a Finder window to List view and double-click a divider. It will adjust the column width — Name, Date Modified, Size, etc. — to its widest content. And yet again, it’s irrelevant whether that widest content is in view, or not.
As an extra bonus, I tried the interaction on a 2014 Mac running macOS Mojave. On that OS, the Finder shows the exact same behavior as all the examples above, including in Column view!
Someone at Apple must have decided, then, that the old, more consistent behavior deserved to be modified. And I wish I knew what the rationale for that change was, given how it has made the behavior uniquely inconsistent.
You may be right! Consistency is almost always good, although I think there’s an argument to be made that in the Finder you mostly care about what you’re looking at, and to expand to meet the requirements of filenames that aren’t in view could itself be confusing. “Why is the column expanding far beyond what’s necessary in the view?”
Or perhaps it’s just a bug. 
