@AndrewRadev @realestninja IPC and client-server decoupling = ridiculously overrated and zero gain for the end user

@AndrewRadev @realestninja IPC and client-server decoupling = ridiculously overrated and zero gain for the end user

@AndrewRadev @realestninja and both expect real-time feedback when the data is stimulated by the user 😅 so essentially same piece of software

@AndrewRadev @realestninja what works in digital audio workstations can be claimed to be work also in text editors because both are model data editors for different type of artifacts.

@AndrewRadev @realestninja And a C lib could be then provided for ”LSP host” which would be trivial to integrate to any text editor.

@AndrewRadev @realestninja IMHO plugin based system similar to VST3 and CLAP in audio could be much more ideal architecture. Editor can eg then decide how to organize threads and can have a clock and scheduler which can orchestrate dynamic or even real-time behavior.

Generally speaking, C is pretty straightforward. It takes about 20 days to learn 80% of it, and then no more than 20 years to cover the remaining 20%

@thomholwerda too much tolerance for uncosidered language results a toxic community.
The flip side is that too much intolerance results a toxic positive community where self-censorship blocks fluid technical communications.

@thomholwerda In Github Ive noticed in some project that rejection of a PR without comment is safe-play for a maintainer. Ive seen cases where a maintainer has taken time to go into details why something is a bad idea and that has resulted blog entries etc talking about toxic behavior.

In this case I’d vote for some tolerance for bad humor and uncosidered commentary. It is just one commit in a high-bandwidth project. Not a big deal, and Im one of those sad gray people.

I can also feel how much snappier vim is given that it does decouple UI and the editor. It is kind of thing that in architecture it is for sure fancy BUT the problem comes from that as a user it can only cause more latency.

I prefer modular code-base over modular run-time :-)

If you pile that up with LSP you have decouple text editor managing decoupled static analysis, i.e. two layers of IPC at run-time, which is crazy IMHO. And since I use mostly the terminal, being e.g. able to integrate to vscode has total zero value for me.

I added the vim LSP shenanigans because I want to see whether it feels different when the editor stack is more stable and simplified. I give it a shot for Rust.

@AndrewRadev @realestninja Well it took me about 30 minutes to rewrite a vim config as i used already quite minimal set of plugins. I know my way with Vimscript as I've used it 20+ years.

I did add 'prabirshrestha/vim-lsp' and 'mattn/vim-lsp-settings' so that i can check at some point if they are usable with Rust. If they do less but the overall experience feels more "stable" than then it might work ;-)

With Linux kernel tree any LSP is pretty much useless, as any time I change kernel config I need to also re-generate a new JSON file. I use ctags because it can carve the whole kernel tree and does not care about the configuration.

@realestninja Even macOS stock installation has vim right off the bat.

In addition Evolution allows to configure custom command for fetch. E.g one could execute IMAP in the remote server with ssh, and use that to fetch the email.

This is still IMHO a strong merit in #GNOME #Evolution, when having multiple identities.

In my case, I use a sub-address (RFC 5233) for bouncing kernel.org but it shares the account with my personal email address. Identities map to envelope addresses, and based on that msmtp will pick the correct SMTP server.

msmtp also allows to share SMTP configuration with #Git. E.g. for a freshly cloned repository, I might for instance:

git config from "Jarkko Sakkinen <jarkko@kernel.org>"
git config sendemail.envelopeSender "jarkko@kernel.org"
git config sendemail.sendmailCmd "/usr/bin/env msmtp"

#email #smtp

@realestninja I have not e.g. used auto-complete in my life. It slows down the phase to the level that I actually need to understand what I'm doing, which over longer period of time results in deeper understanding because you actually have study also the API documentation. Downshifting in production pays back with a huge interest, and usually tends to result more mature software.

track i did early winter. after that not much time for music but hopefully during my holiday i have some time to finish a few tracks :-) https://soundcloud.com/dopeda/robottien-siivouspaiva

Migrated from #neovim back to #vim after several years of use because:

1. I neither need nor use LSP.
2. I don’t need two scripting languages in a text editor.
3. Neovim #plugin ecosystem is a dependency hell.
4. Neovim #plugins are fancy but that results in also a fancy configuration to maintain.
5. I don’t mind a slow release cycle. My vim workflow hasn’t changed for ages.
6. When logging into remote machines, an off-the-shelf vim installation is almost guaranteed.
7. Even if neovim is installed to a remote machine, it usually fails to load my configuration, given the rapidly changing upstream and plugins requiring always the bleeding edge.
8. I learned #vimscript in 1998 before I had even heard about #lua, and it is more comfortable programming environment for me :-) Before 1998 I was using #qedit in MS-DOS.
9. For local IPC with neovim, a Python package neovim-remote is required. Vim has full local IPC workflow builtin.

#Ghostbusters use #ESP32 chips for their "ghost extracting machine". That's for sure an ESP32 DevkitC board from #Espressif on the #GhostbustersFrozenEmpire movie!

I love these kind of details in pictures. Like for example in Tron Legacy when you can see the output from a Unix history command, or a guy using emacs.

Do you know about more examples like these?

@AKernelPanic yes ive even paid my mortgage loan solely with GPL licensed code.

@Edent https://typst.app/universe/package/polylux/