eza-community
feat: Order of the columns
A resource to define the order of the columns. If I want for example:
User, Group, Octal, Permission, Date Modified, Size, Icon, Name
would be beyond the perfection, it is a lot better than lsd and other already
I am re-posting this here because I think that is a good feature request.
I am going to check it out and see what it would take to implement, but I have a feeling it will be much more complicated than it sounds.
This does indeed look tricky. Not using clap for arg parsing is something to get used to for sure. You think this belongs in the command line arguments at all?
Individually specifying the order of the columns sounds like an ENV_VAR "gi=42;2" type deal, where
EZA_COLUMN_ORD="t;u;p;g;n" (Time, user, permissions, git, name)
Thoughts? Or is this maybe something to revisit in #139 ? When users can be more expressive
Thoughts? Or is this maybe something to revisit in https://github.com/eza-community/eza/issues/139 ? When users can be more expressive
The feature could be really cool, EZA_COLUMN_ORD="t;u;p;g;n" makes sense to me, although it could also perhaps allow full names as well EZA_COLUMN_ORD="time;user;permissions;git;name" and such?
Not using clap for arg parsing is something to get used to for sure.
Yeop...
I'm going to go the ENV route and see if I can put something together. Can you assign this to me?
although it could also perhaps allow full names as well EZA_COLUMN_ORD="time;user;permissions;git;name" and such?
Agreed that looks much better
This issue is stale because it has been open for 30 days with no activity.
![github-actions[bot] avatar](https://avatars.githubusercontent.com/in/15368?v=4 "Published by a pub.dev verified publisher"){kind=small}
This issue was closed because it has been inactive for 14 days since being marked as stale.
14 days of inactivity is pretty short, why even close? Looks like it's only waiting for an implementation here, no rush imo
I guess I should look at this again. I think I stopped after realizing there's no way to change the order of the file/dir names, but there still might be some use for this feature
Just to drop one more feedback point: currently in the -l output the permission and ownership info is separated by the size info – while it feels like the permission and ownership info are much more closely related to each other, than size related to either one of them.
To be fair, it's the same with ls -l output too, but with hard-link counts instead of size (which I find slightly less distracting, though).
Therefore, the idea of configurable output column order sounds awesome! :+1:
Perhaps it's worth considering to use full words for the name of environment variable: EZA_COLUMN_ORDER instead of EZA_COLUMN_ORD
Would love to see this implemented. For some reason the current order really bugs me way more than it should.
+1, This would be very handy to have. For example, the file size column is in a different place than in ls, I understand some people may prefer that default and that's fine, but I would prefer for it to be in the traditional place.
I would love if it could be configured by command line flags like in the --help mockup below:
❯ eza --help
Usage:
eza [options] [files...]
...
LONG VIEW OPTIONS
-b, --binary list file sizes with binary prefixes
-B, --bytes list file sizes in bytes, without any prefixes
-C, --columns-order CORD comma separated list to set the columns order
(regardless of their inclusion/exclusion by other flags)
...
Valid CORD fields: blocksize, context, filesize, flags,
git, git-repos, group, inode, links,
mounts, permissions, time, user.
...
I've been evaluating lsd vs eza as an ls replacement and, FWIW, while I prefer eza overall, this one ended up being a deal breaker. It's not even just decades of expecting something to be in a certain place, but that, at least to me, file size is among the most important attributes of a file apart from its name, so the degree of left/right scanning was a surprising UX obstacle.
I ran into this today as well. Is this planned at all? Would a contribution implementing this be considered?
I ran into this today as well. Is this planned at all? Would a contribution implementing this be considered?
I think it would be welcome, but I'd personally be a bit opinionated on implementation, if someone does try to implement it I'd recommend joining the eza matrix room.
Damn, wish I came across this issue sooner--spent nearly an hour to replicate all my aliases and functions + scripts to convert all the ls to eza equivalents. I just assumed eza is close to a drop-in or the advertised "modern replacement" for ls but not being able to replicate the column order is a deal breaker, especially with the size column being such an awkward spot further away from the file name.
@jtackaberry curious what made you prefer eza overall to lsd?
Still no updates? Whats the obstacle for implementation?
As an open-source project, features like this often come to life through the efforts of our community members. If you're interested in seeing this implemented, contributing the changes would be the most direct way to make it happen.
Still no updates? Whats the obstacle for implementation?
As an open-source project, features like this often come to life through the efforts of our community members. If you're interested in seeing this implemented, contributing the changes would be the most direct way to make it happen.
Sure. But if so many people request it but no-one created a PR yet I wonder if this might be more complicated than I originally thought. Are there any things I have to keep in mind when trying to add this feature?
I wonder if this might be more complicated than I originally thought. Are there any things I have to keep in mind when trying to add this feature?
One aspect here is to keep it ergonomic both for users and developers, so later extensions if new columns emerge isn't an issue, meaning it will be a somewhat larger change than e.g. just adding a feature, depending on how much of the current structure can be reused. Another aspect will likely be adding tests for column ordering, which I can assist with, since we'd like to include this in our snapshot testing of arg combinations. I imagine most of these challenges will also become apparent as work on this proceeds, and I encourage joining the matrix channel to keep an open dialogue about issues that come up and to avoid going into any potential dead ends, and having a development PR that's open as a draft while working for the same reason.
Haven't done Rust for a long time (don't even have a toolchain installed) but when I wanted that functionality found it is not implemented yet and just out of curiosity semi-vibe coded (i.e. manually directing the robot step by step) columns order parameter. Prefer it as a parameter, but don't see a problem adding env var as well if requested.
It still need to be at least compiled 🤪, have tests added, properly formatted as a PR, but I wonder if someone could have a look and tell me this make sense at all. Happy to jump all the hoops (never done OSS PR yet, but keen) if the change make sense and my change goes in right direction. Would appreciate an early feedback
https://github.com/kirhgoff/eza/pull/1
I wonder if someone could have a look and tell me this make sense at all
Some LLM artifacts/hallucinations but does vaguely make sense to me, at least from a quick skim. Does this pass tests (i.e. nix flake check?)
I know there is a pull request from @kirhgoff but I also forked this and got column ordering working quite well (at least in my use cases). Unit tests pass and documentation was updated. In my implementation you simply set the EZA_COLUMN_ORDER environment variable with the column order. Full disclosure, I just used Claude 4.5 to help me refactor this which is by I am not issuing a PR for the changes. But if anyone is looking for just this one feature you can look at my code or just cargo build for yourself.
https://github.com/dsandor/eza
