openmarkand

Thank you so much codeberg for supporting

  - artists,
  - creators,
  - translators,
  - writers,
  - climate

Thank you so much codeberg for supporting

  - artists,
  - creators,
  - translators,
  - writers,
  - climate

I'm vim poweruser since around 2009. When I use VSCodium (not that much today) I obviously use Vim emulation.

When I use a different editor, there will be lots of jjkk or ,w (I nmap ,w to :w). Habits die hard.

Now I switched to neovim due to the amount of good features I like with it. I use exclusively mini.nvim modules that are awesome.

Started with vim in 2009. Using sometimes VSCodium for few reasons (embedded dev) and now on neovim. AI is a cancer.

macOS 26 (and other *26) are terrible. I wonder how the hell they could release like that.

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?

The same thing happened when higher level languages were introduced and developers didn't need to use assembly.

You're comparing vi vs microsoft word.

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

The day I'll have to use an AI will be the day I either resign to be developer or quit my job. My company first disallowed AI and now they say "if you don't keep up we will pay that off someday" and I disagree and stand by that I'll never touch any AI stuff.

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.

Hmm, why not.

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

First, we got 3D accelerated terminals, then AI assisted terminals, now web browser enabled terminals.

Tomorrow we have operating system in the terminal.

Prompt for user input. If a user doesn’t pass an argument or flag, prompt for it. (See also: Interactivity)

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.

I think removing a joke to be considered as corporate is a bit exaggerated.

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.

Do I miss something? I've been following the project since the beginning and just checked the wiki, the website and all over the documentation and haven't found something relevant to anime.

Yay, another software to escape. A logging daemon really needs AI!

Why Objective-C? This language has use only in Apple ecosystem and even Apple is ditching it out as newer frameworks are going Swift only.

Liquid Glass is an abomination of UX and accessibility. It would be a shame to copy it. I hope this time competitors won't follow

I don't understand which problem its trying to solve

I'm more of a mercurial guy (since 2009) and I honestly never understood the success of git with its total nonsense of options, UX and documentation. Each command does too much thing and has different behavior. Type git diff -x and git switch -x in a non-git repository and check the output...

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.

Was about to asked but you were faster.

I use IRC every day, in fact it's the best way to communicate for techies IMHO, focus on the content and no gif, emoji, images and all other nuisances that you'd get on any other platforms. I've written my https://projects.malikania.fr/irccd/ bot for various tasks. Long live IRC.

I currently dont.

The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting

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).

I have tried several times and I always switched back to vanilla vim. Neovim has various nice features but it requires a lot of time to migrate correctly IMHO. 20 years of habits are hard to leave, I think.

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.

In my opinion, Lua would kill for many use cases... If it had a bigger standard library, and batteries-included module/packaging system. I know LuaRocks exists, but it doesn't seem terribly common.

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.

I love Zephyr. In fact, the RTOS term is sometimes a bit misnomer. I'd rather name Zephyr as a embedded OS framework: you can even use it without scheduling (even though it will be very limited). The amount of pre-built work done with Zephyr is amazing and when we have to use the STM32 HAL API manually we love Zephyr even more. Really, documenting API using PDF should be banned, ST!

That does not make sense, wayland and xorg are fundamentally different. in X11 everything is global given that its the X.Org server that manages clients while the wayland compositor does most of the X.Org server by itself. This is also why writing a pure wayland compositor from scratch is much harder as you need to rewrite half of the X.Org server but at the same time in contrast to X11 you don't have security holes like a keylogger in few lines of code. In short, xdotool relies on the X11 protocol while a similar wayland app need a support in the compositor itself.

There is some attempts though like: https://github.com/atx/wtype

mbed-os was a cool environment but never took off. zephyr is more mature and has an API in C, the learning curve is a bit steeper though.

After 24 years, we're finally adding a legacy feature to 2024.