5 ms·
I enjoy reading stories like this, considering Emacs is still going today --- and I am a regular! I use emacs for many programming languages. However, when it
by masfoobar 2y ago
I enjoy reading stories like this, considering Emacs is still going today --- and I am a regular!
I use emacs for many programming languages. However, when it came to .NET development (at work) - I had to stick with Visual Studio. I always toyed the idea of Visual Studio Code but, due to some of the projects, it was not easy to do when we were using .NET Framework. Once we were getting closer to .NET Core, however, I knew emacs was becomming a possibility.
My work colleagues see "emacs" on one of my screens at work. They are puzzled why I use it to generate code or do git, etc, with it - but rarely ask questions.
One thing I was surprised about, when we finally moved away from .NET framework to .NET Core (.NET 6 and later) -- I was surprised when one member of the team said he was planning to switch from using Visual Studio.. the IDE, to Visual Studio Code.
I asked why and he said is just likes it behaving more as a text editor than a full development environment. Of course, I understood what he meant by that.
Its weird, especially in microsoft stack land, to hear a .NET developer say this. Truth is -- many seem to be moving to Visual Studio Code. It had to take another Microsoft product to do that, considering we always had vi/vim, emacs, or others like sublime text, etc. Before Visual Studio Code, if I dare mention using a text editor for a .NET project, I would have been given all sorts of puzzled faces. How times change.
Today... while most are still using Visual Studio (IDE).. we now have 2 developers using Visual Studio Code. As for me... I am using:- eglot, company, yasnipet, flycheck, etc... EMACS+Omnisharp!
I even wrote functions to easily create new solutions, projects, unit tests, etc.
Programming is enjoyable with emacs. It makes me happy.
- DeathArrow 2y agoI use VS Code for Javascript when I am working on Frontend, but even if all of our backend stack is at least .NET 6, I still prefer using Visual Studio for .NET code. Maybe I am too attuned to keyboard shortcuts in VS, but I also like hitting buttons to launch containers, debug, jump to definitions, run tests and so on. I quite enjoy working in Visual Studio. Also, before using VS for .NET I was using VS for C and C++. Even when I coded in Linux I searched for IDEs instead of text editors. For git I prefer the command line. I don't think there's right or wrong, use whatever tool makes you comfortable and productive.
- masfoobar 2y agoI totally understand that. There will always be a debate like IDE vs Text editors... just as much as IDE vs IDE or Text editor vs text editor. At the end of the day - use what you want to get it done! I have no issues with that.
- kmarc 2y agoI converted 140+ CLion users to VS Code / vim / Emacs (mostly vscode) at our company. It's not about the "text editor". It's about the LSP and implementations for it. Like it or not, before LSP, code intelligence tooling was quite bad in the "text editor" land (except for some tools like clangd or jedi). Today it's a bliss to use a performante, small footprint editor and offload code intelligence. Although, IDE-lover users swear that their IDE's built-in code intelligence is superior (which, in some cases, is objectively true). Thanks to Microsoft, I guess. Thanks to the FOSS world for the implementations, too.
- thom 2y agoWas this before or after Nova? I’ve found CLion quite pleasant coming from Emacs - it’d been years since I wrote C++ and I’d never used CMake so I was finding myself spending too long feeding Emacs to get an environment I was happy with. It’s nowhere near as powerful as a modern Java or .NET IDE (I have indulged this new guilty pleasure and played with the whole JetBrains suite at this point) but I’ve found it plenty powerful. I still default to Emacs for ecosystems I know well though, and expect I’ll migrate back fully at some point.
- kmarc 2y agoWe were among the first to try Nova (talking directly with the Developers) and while it's slightly better than CLion classic, the double size package and still no remote index support didn't warrant rolling it out, unfortunately. We created a clangd-based setup with remote indexes so that our developers can open their editor (vim / vscode) and within 10 seconds they get access to full code intelligence on the 20M+ SLOC monorepo. This is unimaginable with CLion, where developers have to scope down their "view" on the monorepo to a handful of directories, and still wait half an hour for the indexing to happen