221–230 of 250 posts
I will join others here to point out that information in readme is not presented the best way. I am developer so I understand this, if you just take feedback from this post here and apply it, it will be much better. - It is not fair to say ls is not maintained - Clarify this is for of exa, I am familiar with exa, I wasn't sure what eza was. - Give example how it can be used, alias ls="exa " for example, give few exam…
Earlier quoted context omitted.
You can hover over the date for an exact timestamp. Maybe someone can write a userscript to replace the relative dates to exact ones.
the point is that you should not need to hover over the dates to get the exact ones. it hinders fast viewing of the data, when it is more than a small amount.
For you. For some, you should not need to hover over exact dates to get humanized relative deltas.
Earlier quoted context omitted.
You're completely missing the point. ~/.programname is an unorganized mess, where someone stuff their dirty laundry, their trash, their food and their passport into the same closet. It doesn't matter if the closet is open or not, nobody but the mentally ill hoarder who created the mess can navigate it. ~/.(local|share|cache) means people put their food in the fridge, their trash into the bin and their sensitive docum…
The one thing I despise about local|share|config is I never know which one they're using or what kind of nested hierarchy they're using that means I might have to search for the company name first. At least with the ~/.whatever system I can just start typing ~/.tool-name, hit tab and it'll show me the thing if it exists. If it's somewhere else I have to look it up.
This really only applies to badly ported Windows software like Unity engine games. There should be no hierarchy, just ~/.{local/share,config,etc.}/$application And nothing stops badly behaved software from deciding to use ~/.$CompanyName or heck I have even seen ~/My\ Documents/$CompanyName
IMO the killer feature of eza/exa is not the pretty colors but the git integration - being able to see the git status of individual files in a listing (ignored, modified, etc) is pretty handy.
Totally —- any idea why eza claims exa doesn’t support it? I know that’s wrong.
Earlier quoted context omitted.
Task is _amazing_ I tried magefiles[0] for a while, but Task just works so much better and isn't Go-specific as heavily. [0] https://github.com/magefile/mage
Justfile is my favorite. Anything that requires complexity I just use Zig build. I hate make with a passion. I could see why people stick with it after learning it for decades, but for the rest of us it is a nightmare.
Those first two are nowhere near as easy to read as Makefiles. The last one, Just, looks good, though.
At least Cmake files are easy to read, but many of these alternatives are just poor UI, compared to Makefiles. I mean, using YAML of all things and thinking it's some sort of improvement over Make syntax?
1. Mage is just insane. In what world is this:
func Build() error {
if err := sh.Run("go", "mod", "download"); err != nil {
return err
}
return sh.Run("go", "install", "./...")
}
build:
go mod download
go install ./...
version: '3'
tasks:
build:
deps: [assets]
cmds:
- go build -v -i main.go
assets:
cmds:
- esbuild --bundle --minify css/index.css > public/bundle.css
build: assets
go build -v -i main.go
assets:
esbuild --bundle --minify css/index.css > public/bundle.css
I find it strange that the README does not mention at that `eza` is a fork of `exa`.
It at least mentions it's existence (though no link or context)
Earlier quoted context omitted.
I agree. GitHub does this too on commits. "foo.cpp modified last year." It makes no sense, at least without the ability to view additional datetime information.
Particularly when many systems I've seen group the past three years into last year. It feels like the categories are: "Today, Yesterday, This Week, This Month, Last Year, Big Bang"
Earlier quoted context omitted.
Justfile is my favorite. Anything that requires complexity I just use Zig build. I hate make with a passion. I could see why people stick with it after learning it for decades, but for the rest of us it is a nightmare.
I looked, just now, at all the Make alternatives mentioned: Task, Mage and Just. Those first two are nowhere near as easy to read as Makefiles. The last one, Just, looks good, though. At least Cmake files are easy to read, but many of these alternatives are just poor UI, compared to Makefiles. I mean, using YAML of all things and thinking it's some sort of improvement over Make syntax? 1. Mage is just insane. In what…
That's just your opinion. I'll take YAML whitespaces over Makefile whitespaces any day.
> Compare with Makefile that does exactly the same thing
Good example in favor of Task, I prefer the explicitness :) Especially when the file starts to get big. You forgot the .PHONY by the way, I hope for you there's no build/ or assets/ folder where your Makefile is.
For a more useful comparison, with actual source dependencies and build target:
Makefile:
GO_FILES = $(shell find . -type f -name '*.go')
./myapp: $(GO_FILES)
go build -trimpath -o $@
.PHONY: build
build: ./myapp
tasks:
build:
cmds:
- go build -trimpath -o ./myapp
sources:
- '**/*.go'
generates:
- ./myapp