Live data from Hacker News

I'm “still afraid to use spaces in file names” years old

twitter.com

71–80 of 817 posts

Re: I'm “still afraid to use spaces in file names” years old

#71
post #25

Looks like I'm in the minority. I always use spaces and non-ASCII characters in filenames. In many languages it's a requirement. For example, in Romanian, there are 8 words that collide with „fata“ if you remove the diacritics (fata, fată, fața, față, făta, făță, fâța, fâță). Given that we have to use diacritics, spaces don't seem like a big deal.

We have a few words that depend on diacritics to be unique in Czech as well - though not as bad as this example - but people just manage without. Hell, I don't even bother installing the Czech keyboard, if I REALLY need it (like in names), I just google for words that have the character and copy it

Re: I'm “still afraid to use spaces in file names” years old

#72
post #24

Earlier quoted context omitted.

What's wrong with camelCase? It's easier to type than snake

There's a tendency away from snake_case and towards kebab-case in things you interact with via CLI. Even moreso towards nocase. Programs like Powershell eschew ease of use in CLI for readability in scripts.

Powershell is case-insensitive, so camelCase is only a writing preference

Re: I'm “still afraid to use spaces in file names” years old

#73
post #5

Slightly off topic but I find myself stuck at being "please for the love of god don't use spaces in git branch names" old. Anno dazumal this might not even have been an issue and I'm just cargo culting.

I enjoy choosing fun branch names from time to time. A few of them: Russian when a user reported a typo in a Russian translation; emoji (mostly added emoji rather than pure emoji); and my personal favourite, a ~250 character diatribe about a single-character bug I was fixing (~250 after I discovered that Git’s error messages when you cause it to try to use file names too long for the file system are fairly mediocre).

Re: I'm “still afraid to use spaces in file names” years old

#74

Earlier quoted context omitted.

Sure. One could also make "move-down-one-line" be the incantation to move the cursor down a line in vi, but I prefer j. Ergonomics isn't all about making everything self-descriptive for someone seeing the thing for the first time. It's about making things comfortable to actually use. If it's so long and complicated that you can't even remember how to do it, it's not very comfortable to use. Even if I could remember,…

It should be based on frequency of usage. I can tell you that moving down a line in vim is a little more common than toggling the mouse acceleration. I would never even type such a command. I would just copy paste it once.

Yeah well, given that mouse acceleration tends to be on by default, I need to turn it off every time I'm on a fresh install or computer I haven't used before. The last time I needed that was yesterday.

I don't want to waste time searching for a command to copy-paste when it could just be made short, simple, memorable and ergonomic. I could type xset m 0 0 faster than I could open a browser and ask google how to disable acceleration with libinput. And again: you can't just copy-paste the xinput command unless you're lucky enough that it matches your device. On my new computer, the device has a different name than on my old laptop even though it's the same damn mouse.

Re: I'm “still afraid to use spaces in file names” years old

#75
post #23

Spaces in file names are a nightmare in Makefiles.

Not if you are careful (a bit like "$@" vs $@ in shell scripts). Edit: replace $@ with quoted version which actually changes the behavior (I was wrong that the difference is between $* and $@).

I don’t think it’s fair to claim that any Make implementation supports spaces: there are too many fundamental bugs and breakages, so that lots of rather important Make functionality is off-limits if any of your file names will have spaces.

https://www.cmcrossroads.com/article/gnu-make-meets-file-nam... explains the situation in GNU Make in 2007 (and I don’t think it’s changed since then, though jgrahamc especially could correct me). Not being able to use such features as $^ and $(patsubst) is severely debilitating for all but the simplest of makefiles.

Re: I'm “still afraid to use spaces in file names” years old

#76
post #24

Earlier quoted context omitted.

What's wrong with camelCase? It's easier to type than snake

camelCase is objectively harder to read than snake_case or kebab-case, though familiarity can mitigate that.

I'd argue it's at most a tiny bit harder to read, and a lot easier to type. On balance I'd rather avoid making a pinky key one of the keys I have to use the most.

Re: I'm “still afraid to use spaces in file names” years old

#77

I'm hardly afraid but I just think it's poor ergonomics. Same as the move from xset m 0 0 to xinput --set-prop 'pointer:Logitech USB Receiver' 'libinput Accel Profile Enabled' 0, 1 Everything seems to be going this way in Linux land. Longer names, harder to type names, camelcase names, spaces... I'm looking forward to an OS that treats command line ergonomics as a first class feature and where camelcase & spaces are…

Long option names are more descriptive, more easily distinguished, and easier to remember. Your shell should be intelligent enough to provide tab completion for option names, assuming it is configured to.

Re: I'm “still afraid to use spaces in file names” years old

#78
post #25

Looks like I'm in the minority. I always use spaces and non-ASCII characters in filenames. In many languages it's a requirement. For example, in Romanian, there are 8 words that collide with „fata“ if you remove the diacritics (fata, fată, fața, față, făta, făță, fâța, fâță). Given that we have to use diacritics, spaces don't seem like a big deal.

>In many languages it's a requirement. For example, in Romanian, there are 8 words that collide with „fata“ if you remove the diacritics

That is what context is for.

Re: I'm “still afraid to use spaces in file names” years old

#80

I'm hardly afraid but I just think it's poor ergonomics. Same as the move from xset m 0 0 to xinput --set-prop 'pointer:Logitech USB Receiver' 'libinput Accel Profile Enabled' 0, 1 Everything seems to be going this way in Linux land. Longer names, harder to type names, camelcase names, spaces... I'm looking forward to an OS that treats command line ergonomics as a first class feature and where camelcase & spaces are…

Long option names are more descriptive, more easily distinguished, and easier to remember. Your shell should be intelligent enough to provide tab completion for option names, assuming it is configured to.

> Long option names are ... easier to remember ... Your shell should be intelligent enough to provide tab completion

They are so easy to remember that you need to configure your shell to remember them for you?

Post reply on HN