Comment by finaard | Hacker News Reader

Comment by finaard | Hacker News Reader

We're now at Emacs 29. I've been following the threads stuff back then out of curiosity - but never seen it as game changer, as most of the annoyances where stuff hangs could just be solved by using async methods.

I just went over all my packages - I'm not using a single one which does make use of the threads API. I used to use lsp-mode, which _does_ create a thread in one situation - which also could've been solved by doing async calls.

A lot of the stuff that should've used async, but didn't got fixed, plus there's an external library to move some other stuff along. I've moved gnus (which used to be notorious for blocking everything) into my main emacs process years ago - and last year even tried setting up a new notebook without the local imap, and made it directly go to upstream servers. Turns out, so much improvements landed in the imap code over the years that doing this works so well now that I've dropped the local cache from all my existing systems by now.

> I used to use lsp-mode

Do you not use it any more? Have you switched to Eglot or something?

I use lsp-mode, was going to switch to eglot, but it doesn't have the features that lsp-mode has, like lsp-ui (as far as I can remember), and the last time a compared (last year), the performance impact was somewhat noticeable.

Eglot philosophy is to hook into existing emacs features instead of reinventing the wheel, so you may find some of the lsp-mode/lsp-ui features in other packages. imenu-list for sideline navigation, breadcrumb, flymake has a way to display inline diagnostics (can never remember how as I don't use it and google does not help).

I work on a huge codebase with eglot+clangd and the few times where it gets slow is where there are tons of flymake warnings. Like when you enable all the clang-tidy checks.

eglot is part of emacs 29. I have been testing it out for my .NET development (with Omnisharp)

I officially started with .NET back in 2008 and, at the time, you really had to use Visual Studio. I knew emacs was not an option at that time. Since .NET Core I knew I was getting closer and closer for emacs becomming an option.

Then comes Visual Studio Code.

I have experiemented with C# development in emacs for a few years, now. I cannot remember now but it was likely with lsp-mode. When I found out eglot is in v29, it was time to revisit it. It has been positive so far.

I actually forced myself doing .net development in emacs this weekend. I am 90% there! Need to see if I can debug in emacs, now. I hope so!

Once I am happy, I will continue to add more interactive functions, saving me typing 'dotnet cli..' commands. I also need to revisit yasnippet to make coding more effecient in C#.

Getting started with eglot and C# was pretty painless, thanks to this link:- https://www.johansivertsen.com/post/emacs-29-csharp/

I had a customer request a project that required C# due to a few fancy dependencies they had purchased back in 2008 - which was my first proper contact with .NET. I got frustrated with the Visual Studio UI after a few hours, and switched to editing in Emacs and compiling via CLI tools, only using Visual Studio for editing the project data. It wasn't too complicated to kick cc-mode into behaving somewhat sensibly with C# code.

It was not just about C# editing. There were other things being used in Visual Studio at that time. Also being inexperienced in VB.NET (my first job) surrounded by 10 other seasoned devs, they discouraged anything outside of Visual Studio. I understand why when looking back.

This was also the Visual SourceSafe days. How I do not miss that!

C# wiggled its way in eventually.

Back in 2008, I was pretty much using Emacs for most programming languages. The only exception was C# and Javascript.

As the years pass to now, I rarely use a programming language outside of emacs. I have enough years in my career to not tell me what I can and cannot do to get things done.

I had my emacs setup to edit LotusScript (one of the scripting options for Lotus Notes), which is close enough to VB that it could handle the occasional file - this was a new codebase, though, so it made sense to just start with C#.

That was also the project where I tested if git reached the point where you can have "normal" people work with it as well (which worked pretty well). I never accepted any project where they'd have me work with idiotic proprietary source control, unless the project was "migrate away from that".

I was happy when I changed job, using SVN (Subversion) instead on Visual Sourcesafe. Then I dabbled a bit with TFS (Team Foundation Server)

Since around 2014 -- It has been Git all the way.

Well, until recently. Codebase at my current job is all contained in a single Subversion repo. It is difficult to maintain and branching takes GBs!

One of my first goals is to move over to Git, and into smaller Git repos. Of course, I have Magit to get it done. :-)

... also (continued)

I like how people think I am purposely being different or difficult because I do C# development in emacs. Many have never heard of it. If they have its from forums or youtube videos.

Think of their mindset -- Its not like I have moved away from Visual Studio to Visual Studio Code. I am using Emacs. They must think I am trying to be difficult or special.

I have also swapped my L-CTRL key with CAPS specially for improving my emacs experience.

Regardless, when we do pair programming (or something) on my screen and they watch me use Emacs on a C# project, they soon understand. :-)

I've found lsp-mode to troublesome to configure for what it provided, and occasionally getting in the way, so with emacs 29 I just moved to the integrated eglot. Not that I'm using it much, though - I've found it marginally useful for getting used to new languages, but generally prefer to just have full documentation open - once I'm familiar with the code base completion tends to just get in the way, so I often have any form of completion switched off anyway.

I've been curious why threads will be so much better than async. My gut was that they are both hard to do and the default will be to just run the compute. But once you have to offload compute from main thread, seemed we already had facilities and examples. What is new with threads?

Reply on news.ycombinator.com