Interlisp
DIR and FILEBROWSER columns ?
Some odd things:
DIR * LENGTH shows a column of lengths
DIR * LE shows a column of lengths, plus a BYTESIZE column that has ( ) on every line.
Shouldn't those be the same? And, does BYTESIZE make any sense any more?
For the FB command, the default presentation has columns Name Length Pages Created Author
Would a modern user know (or care) how pages are measured? A KB column would be more useful, albeit redundant with Lenght. And, isn't the Author now always the current user?
Author is the unix user that created that file - if you're looking at a directory created by another user of the machine then it would be their login name. There are certainly files created by "root" that you might look at.
I think there may be issues with the filing code returning the correct attributes when looking at {unix} files.
I like the idea of modernizing FB, but I'm not sure it's clear what the 'right' thing to do is.
I think fixing this is better done by individual users' INIT. Whether the OS can return meaningful creator IDs for example probably depends on the backend.
Every change introduces the possibility of destablization. Obvious bugs and errors and completely useless stuff are legit targets, and I wanted FB defaults to change. It might depend on the file system mounted.
If it were up to me I'd mark this as WONTFIX.
Maybe author is useful
Generally, I think default displays should at least make sense to new users, the ones that wouldn't yet know how to fix their INIT files, and changing default displays shouldn't be destabilizing.
LEN ought to be an abbreviation for LENGTH, but it isn't.
On Nov 3, 2025, at 4:22 PM, Larry Masinter @.***> wrote:
masinter left a comment (Interlisp/medley#2353) https://github.com/Interlisp/medley/issues/2353#issuecomment-3483172063 I like the idea of modernizing FB, but I'm not sure it's clear what the 'right' thing to do is.
I think fixing this is better done by individual users' INIT. Whether the OS can return meaningful creator IDs for example probably depends on the backend.
Every change introduces the possibility of destablization. Obvious bugs and errors and completely useless stuff are legit targets, and I wanted FB defaults to change. It might depend on the file system mounted.
— Reply to this email directly, view it on GitHub https://github.com/Interlisp/medley/issues/2353#issuecomment-3483172063, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQSTUJNYFPBJ2D26TRFA3ZT327PSBAVCNFSM6AAAAACLAMDNPCVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTIOBTGE3TEMBWGM. You are receiving this because you authored the thread.
Some other changes/enhancements to the file browser were discussed at the 11/5/25 meeting.
The question was raised whether the submenu options under the See menu (fast see pretty, fast see unscrollable, scrollable & pretty) should be removed. The default is scrollable & pretty (using readonly Tedit or a browser pdf window), and that is fast enough now that there is no need for the less useful hidden under the main menu. It is also odd that there is a "file browse" submenu item since that's redundant with the behavior that you get when you "See" a directory.
There was also a general consensus that it would be useful to be able to move back in the directory hierarchy, not just down, and to have an option for reusing the current window for browsing a directory rather than opening up a new window for each directory you look at.
So here's a proposal. We could remove all the subitems from the See command, so you always get the scroll/pretty behavior for files. And then add a new Browse item for directories with a submenu that let's you say whether you wanted a new window or reuse the current one (which would only be allowed if only a single directory is selected). Maybe reuse would be the default in the single-selection case.
There could also be a Back subitem under Browse that would let you go backwards to the next higher directory no matter what was selected (in the same or different window).
Setting up the interface would be trivial, not sure how hard it would be to set up a browser window for reuse.
What about augmenting the submenu (or main menu) with new options rather than removing all the subitems? It think the historical context of Medley is part of its value.
It appears that the code for reusing the current window (up or down) is already there, just hidden under the Recompute menu item. Under the Recompute there is a New Pattern subitem that prompts you with the current pattern. If you edit it to put >..> at the end, you go up in the same window, if you put a subdirectory at the end, you go down in the same window.
So it is really about designing a more obvious and convenient interface.
why dont we go ahead with addressing the issue that this thread started with -- changing the default columns == and leave for another issue the larger set of interface issues.
I think the discussion on the menus shows there are lots of factors for possible redesign of the menus.
For the default columns, I think the constraints are: (1) the window width is constrained, file names are often longer than they were (2) some columns don't ake much sense or aren't so useful
by setting (FB.DEFAULT.INFO '(LENGTH CREATIONDATE)) anyone have an alternative idea for the initial value? In the INIT file or change filebrowser?
Changing the browser to show LENGTH and CREATIONDATE by default would help new users.