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 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.
I found the neovim community to operate a bit like the node ecosystem, you pull in a plugin for every problem that solves already solved problems their own way. The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting. That said I think people should use what they like, and I am happy that there is a big community developing an alternative to VSCode. I just didn't feel it was for me.
I ended up moving to Kakoune. The community is small but the tool is so much better designed and integrates well with unix. That means that i can usually glue together whatever I need myself with 1-3 lines of config and don't need an entire plugin when I want something that isn't built-in.
> 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).
The Unix integration is so very good. I have keybinds to fmt for line wrapping and date to insert timestamps, and I like being able to pipe a selection to dc to do some quick math. It’s so easy, I do it without even thinking about it.
> The plugins are also very flashy with tons of animations, colors and emojis, which to me is just distracting.
I don't think I've seen plugins with animations (nor would I want to). Agreed that emoji in the terminal, modulo useful glyphs like language logos next to files in a directory tree [0], are distracting.
What I don't understand are people who add a million plugins, and then wonder why the startup performance is terrible. I have a fair amount, including some I honestly rarely or never need, and startup time is still 75 msec, which is fast enough for me not to be bothered.
When I migrated years ago (mostly to get access to some plugins), nvim gladly swallowed my old configuration with no changes. Then I could change to lua and other modern features at my own pace.
> 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.
I don't think that's inherently true; what would prevent someone making a wayland compositor that implemented the X11 protocols for interacting with other windows?
I am aware of several of these attempts; so far they all fall flat precisely because wayland compositors tend to not provide enough API surface to actually recreate xdotool et al. entirely (ex. wtype will always blindly type into whatever window is active, it can't provide xdotool's --window option to pick where keystrokes are going).
