/tech/ - Technology★

The concept is solid. The implementation is absolute _bloat_.

>>1043926

That doesn't tell me jack shit about it, given that /tech/ and /g/ treat any kind of feature they don't use as "muh bloat".

It's gay.

Why would they use JSON-RPC instead of something lighter-weight like MessagePack RPC? There is no advantage to the messages being human-readable, so you might as well make it binary. The big advantage of JSON is how easy it is to read and write for humans.

>>1043987

last time I tried lsp on emacs there was a 100% cpu usage thing because neither implementation had the ability to set a default settings file so it would just lag like crazy in the background.

Unsurprisingly vim doesn't have this problem because more than 15 people use vim.

>>1044076

I don't think that happens anymore, since I'm not getting 100% load from running lsp-mode or eglot. Probably happened back when those packages were far less stable, I hear lsp-mode has been reworked quite a bit, to the point where the comparison the eglot dev made between lsp-mode and eglot a while ago is now inaccurate, according to him.

>Unsurprisingly vim doesn't have this problem because more than 15 people use vim.

Emacs is still widely used, I have seen it installed on hundreds of machines at an organization (doesn't translate to usercount, but dispels the myth of "not on MY machine(s)"). I think the userbase is steady, maybe not as popular as Vim and derivatives, but it seems like a stable amount of users. It would be nice to have a new Emacs, essentially the same concept but with better languages replacing both elisp and C, perhaps some modern Scheme that is well documented and is ready for the future of machines with more parallel processing power/the focus on concurrency as well, and whatever systems programming language (Ada, Rust, Zig?, maybe even modern C++, et al) is suitable for a small core. Perhaps some default improvements: CUA mode by default, ido replaced with a helm/ivy-like, the frumpy old I-search and the query replace replaced with a swiper-like and something similar for the query replace, an optional minimap that some people seem to love so much, new and improved tree directory frame, etc. Generally, faster, safer, easier to use by default, multithreaded and concurrency ready. But the situation isn't as messy as with Vim, theres no panic to make a NeoEmacs, the code simply doesn't suck as much as Vim's.

>>1044087

I just use Irony-server myself, it works well for me. For now, the C/C++ LSP servers are probably still much slower, but then again they are young projects. One probable reason for Microsoft doing this is to get the disparate developers to work for them indirectly, by making servers that can all be used with VSCode, instead of working on stuff specific to a text editor.

>>1044072

Wouldn't human-readable make creating plugins easier? If plugins are easy to make then the protocol has a better chance of succeeding

>>1044089

>I think the userbase is steady,

>I think

Instead of doing the emacs larpathon just go look at the numbers.

>microsoft conspiracy to make text editors better

oh those dastardly faggots.

>>1044087

>All the C LSPs require an own version of clang running in the background.

There's clangd, though.

>>1044148

>There's clangd, though.

it also only supports half of the protocol

>>1044288

Works fine with eglot here. You're better off with clangd >= 7, though.

What's the point? Instead of making all editors better it will make all editors equally shit.

>>1044133

>Instead of doing the emacs larpathon just go look at the numbers.

I have seen them already.

>microsoft conspiracy to make text editors better

Its to make their text editor better, any other text editors improving is a side effect.

>Microsoft

embrace, extend, extinguish

>>1044360

> Its to make their text editor better, any other text editors improving is a side effect.

That's still a win in my book.

neither eglot nor lsp-mode work. using LSP just made me want to use VS Code instead of Emacs.

>>1044089

>It would be nice to have a new Emacs, essentially the same concept but with better languages replacing both elisp and C

people have been trying to do this for decades and failing. rewriting Emacs is a lot more difficult than you think.

if you want all the latest and greatest stuff, you might as well just use one of the latest and greatest editors instead of reinventing the wheel to pretend to be retro.

We already had a thread on this