I’ve been looking into this further with the thought of submitting a bug report. But it’s not at all clear how to tailor it to Apple’s bug reporting protocol, or even how many bugs are involved! I’ve also run the same tests on my El Capitan (10.11.6) machine to see if there are any differences. For anyone who’s interested, or who doesn’t mind being strangled to death by their own intestines, here’s what I’ve found:
• In both El Capitan and Mojave, scripted changes in a Finder window’s ‘list view’, ‘icon view’, or ‘column view’ options have no visible effect until the window’s either closed and reopened or its ‘target’ is switched to another folder and back. However, the new values are correctly returned to scripts.
• There are no scriptable view options for the “Cover Flow” view which exists in El Capitan or for the “Gallery View” which exists in Mojave. On both systems, though, a window can be scripted to switch instantly to the relevant view by setting its ‘current view’ to ‘flow view’. The Finder dictionaries on both systems also offer a ‘group view’. In El Capitan, this compiles as is but errors when run. In Mojave, it recompiles as ‘flow view’ and changes the view to Gallery View! This ‘group view’ setting has no connection with the Toolbar button labelled “Group By” in Mojave or “Arrange By” in El Capitan.
• On both systems, if a Finder window’s ‘sort column’ in list view is the same as its ‘arrangement’ in icon view (eg. ‘sort column’ = ‘column modification date column’ and ‘arrangement’ = ‘arranged by modification date’), changing the ‘sort column’ by script also changes the ‘arrangement’ to a matching setting. This doesn’t happen when the sort column is set manually or when the views’ sorting arrangements are different to begin with. Changing an icon view’s ‘arrangement’ by script doesn’t change the list view’s ‘sort column’. The term ‘arranged by’ in the icon view options is to do with sorting, not with what El Capitan’s Toolbar button calls “Arrange By” or Mojave’s calls “Group By”.
• On neither system does changing a list view column’s ‘visible’ setting have any effect on the number of columns visible in the window. The width of other columns may be changed in El Capitan, but in Mojave there’s no visible effect at all. In Mojave, though, each time a script sets a column’s ‘visible’ property, the number of columns subsequently returned to scripts doubles. The extra columns are all zero-width ‘name’ columns at the beginning of the returned list. The number of columns, initially 8, maxes out at 256, whereafter it becomes impossible to change any of the columns’ ‘visible’ values ever again. Attempts to change the ‘name’ column’s ‘visible’ to ‘false’ correctly raise errors, but commands setting the ‘visible’ of other columns are simply ignored. This means that if a column’s last successful ‘visible’ setting was to ‘false’, it can never again be scripted to be the sort column. This appears to be permanent for the folder to which the view belongs, but only affects Finder AppleScripting. It’s still possible to do whatever’s necessary manually in the GUI. It’s also still possible to script changes to the columns’ sort directions, even if they’re neither visible nor the sort column as far as AppleScript’s concerned. While the number of columns returned to a script can be up to 256, commands which count them directly (as opposed to counting the returned list) only see eight. Similarly, it’s not possible to use an index specifier higher than 8 to address them and ‘whose’ filters only return matches from the first eight columns.
As an experiment, I copied a “256 column” folder over my network from my Mojave machine to my El Capitan one. The El Capitan Finder also returns 256 columns from the folder window’s list view options — but there are no invisible files in the folder, so it’s not clear how this information has been conveyed. The widths of the additional ‘name’ columns are returned as 457 instead of 0. The other columns’ ‘visible’ properties can be changed in El Capitan, but the eight-column limit still applies for counts, index references, and ‘whose’ filters.
It’s time for another coffee!