On Apple, there is even this screenshot that they validated on purpose.

https://www.apple.com/v/os/e/images/shared/liquid_glass/dyna...

How can you be okay with that?

You're comparing vi vs microsoft word.

We're still writing C, C++ and other low level languages.

My knowledge, my experience and my passion to development is made from tinkering, failing, retrying and challenging. When a friend or colleague ask me a question there is a high percentage I can already fix the issue just by the experience I've accumulated (obviously, if the question is in an area I already explored, I'm not a book).

Thus, I don't want to be integrated in this new AI world and I feel like someday I'll have to do something else as even companies will tell people to use AI by the fact "you should be more productive and cost less". No, AI is a mental disorder.

Though most of the software do the right thing by checking if the standard output is an actual tty (isatty) to avoid colors when redirecting to something else (e.g. socket, fifo, etc).

The name NO_COLOR suggests a really binary choice which may be okay. Though GNU coreutils usually have a more selective option like --color=always|auto|never.

I'd prefer supporting a more general COLORS=on|off|compatible|...

Meaning:

- on: always on even when redirecting

- off: fully off

- compatible: maybe something like on by default and off if redirecting to a non-tty

- ...: add more choices

Tomorrow we have operating system in the terminal.

prompting is usually the worse choice in a command line utility. on error you lost what you've type and have to copy back and forth unless the terminal disappeared.

> Prefer flags to args

Options are designed to be... wait for it... optional. as the name suggests. If you actually require to pass at least one option to a command to get it working then it's bad designed. An option is there to change what a default is not suitable for you.

For example, tar uses -x, -c to determine what to do. We're all used to it now but that is not the way we should design a command. A correct way is more like tar/untar similarly to zip/unzip. That would make more sense.

To me, rpm is definitely the worse in terms of use of options. If I'd redesign it I'd imagine something like:

- rpm i(nstall) [options...] packages...|files... - rpm e(rase) [options...] packages...

Having fuzzy match for the first argument makes it still convenient to use and much clearer for those who want to type it entirely.

It's okay to have "fun". I consider a software more corporate when it has a large website with dozen of MB of Javascript, analytics, XML documentation, ten automatic bots with CI checking every part of a merge request and a contributing guide larger than the whole got documentation to be more corporate than a clean and simple UX without jokes.

Remember: a clean UX should present output only when necessary. This is exactly where I prefer a lot hg status than git status for example.

I love OpenBSD and I'm really interested in got for several years. I just hope that this https://framagit.org/stsp/got/-/blob/main/got/got.c?ref_type... gets removed at some point.

I also have seen that the very first time I tried neovim. Some people may like it but I consider a terminal to be as simple as possible. Furthermore, I use often the CLI on non-GUI terminals where such non-ASCII characters can have various side effects (e.g. unicode bars, braille like progress bar and so on, those destroy your serial terminal line).

Sure the configuration file is retro compatible, but some of the plugins are better suited for neovim and vice versa. I use a dozen of them and if I switch permanently to neovim I'd like to start fresh using more "modern" alternatives that make use of the newer features.

This is because of the design choice of Lua. Authors do not ensure retro compatibility and this is why there were so much outdated external libraries when Lua 5.2 came in. Even the most popular LuaSocket wasn't updated in years.

In fact, Lua is definitely not intended to be used as a drop-in replacement to Python, Ruby or Perl because of that. It's entirely designed to be embedded as-in in your host-program and that you must provide your own extensions.

However, keep in mind that:

a. you will need to carry the documentation of Lua you've included b. if you plan to upgrade the bundled Lua you will have to polyfill all changes to avoid breaking your userbase code (and this is a real PITA) c. you'll end up with lots of `#ifdef` in your code

I think that are few reasons why Lua stalled that much (without even mentioning all uncommon features `~=`, `goto`/`break` but no `continue`, array start at 1, too minimalist unicode support, ...). I've been including Lua 5.1, 5.2 and 5.3 in one of my projects before I eventually stopped to backport compatibility layers. I also gave up on my LuaSDL repository because it was too much of headaches. It's a shame because I loved this language a lot.