Skip Navigation
General Programming Discussion @lemmy.ml
Kelho @lemmy.ml

Why use VIM/Nano/Emacs over VS Code?

Hey everyone!

I was just wondering why one would use any of the programs I mentioned above instead of VS Code to write Code.

Can someone give me a brief overview of the advantages?

Thanks in advance!

53 comments

  • From the perspective of someone who uses Visual Studio Code, but also knows how to exit vim, there are a couple reasons that most developers who prefer one of the three, at least those I've spoken to.

    1. VS Code is a Microsoft product, and while "open source" it isn't really open source. The core utility is but Microsoft ships the final application with some proprietary features. If this is your main gripe, then you can try VSCodium instead, which is a "fork" that doesn't have the Microsoft additions.
    2. VS Code uses Electron, which is essentially browser emulation and isn't exactly optimized. CLI editors like the above take up far fewer resources than a Visual Studio Code instance would. Unlike point (1), I don't think there's really a way around this in all practicality. It's just an unavoidable fact. You can chose to still use VS Code of course, most personal computers can easily handle the load. But many see that as unnecessary when they get the same amount of "power" from a CLI editor.
    3. Plugins for the CLI applications are very powerful, and the ability to navigate using only the keyboard is by design. Many swear by keyboard-only operation of a computer because it's faster and promotes more optimal methods of doing tasks. It forces discovery of new features and hotkeys by making things annoying to do otherwise. VS Code (and most editors) include a "vim keybindings" specifically for this reason. You'll find that it's a very popular method of working.

    Really it comes down to personal preferences and what you "grew up" using. It's really hard to transition into something like vim and it takes a concerted effort to switch by most users. You have to want to switch, otherwise you'll find it too difficult a learning curve or find yourself wandering back to more "featured" applications.

    There are likely more reasons out there, but these are, in my experience, the primary reasons.

  • I use Textadept over any of the named ones, including VS Code. (I use the vi subset of Vim for remote access to machines I haven't yet installed Textadept on.)

    Why?

    I have a moral objection to ... Well let me show you:

    One of those is VSCode (well, VSCodium, which is VSCode without Microsoft's spyware installed), and the other is Textadept. One of those is occupying almost 30MB of memory to do nothing. The other is occupying about 1.5-2GB of memory ... to do nothing. In both cases there are no files open and no compilers being run, etc. I find this kind of intense wastefulness a sign of garbage software and I try not to use garbage software. (Unfortunately I'm required to use garbage Windows 10 at work. 😒)

    Oh, and Textadapt has both a GUI version (and not the shit GUI that Emacs provides in its GUI version!) and a console version, allowing me to quickly get it running even on remote machines I have to use. VSCode/Codium ... not so much. I'd have to run it with remote X and ... that is painful when doing long-distance stuff.

    • Very interesting. I appreciate you for this thorough research and report! I will have to try textadept out.

      • The thing that made me go to it was its syntax highlighting engine. I tend to use languages that aren't well-supported by common tools (like VSCode), and Textadept makes it simple. REALLY simple.

        As an example, I supplied the lexer for Prolog and Logtalk. Prolog is a large language and very fractious: there's MANY dialects with some rather sizable differences. The lexer I supplied for Prolog is ~350 lines long and supplies full, detailed syntax highlighting for three (very) different dialects of Prolog: ISO, GNU, and SWI. (I'll be adding Trealla in my Copious Free Time™ Real Soon Now™. On average it will be about another 100 lines for any decently-sized dialect.) I've never encountered another syntax highlighting system that can do what I did in Textadept in anywhere near that small a number of lines. If they can do them at all (most can't cope with the dialect issue), they do them in ways that are painful and error-prone.

        And then there's Logtalk.

        Logtalk is a cap language. It's a declarative OOP language that uses various Prologs as a back-end. Which is to say there is, in effect, a dialect of Logtalk for each dialect of Prolog. So given that Logtalk is a superset of Prolog you'd expect the lexer file for it to be as big or bigger, right?

        Nope.

        64 lines.

        The Logtalk support—a superset of Prolog—adds only 64 lines. And it's not like it copies the Prolog support and adds 64 lines for a total of ~420 in the file. The Logtalk lexer file is 64 lines long. Because Textadept lexers can inherit from other lexers and extend them, OOP-style. This has several implications.

        1. It seriously reduced the number of lines of code to comprehend.
        2. It made adding support for another backend dialect automatic. Originally I wrote the Prolog support for just SWI-Prolog and then wrote Logtalk in terms of the Prolog support. When I later added dialect support, adding ISO Prolog and GProlog, to the Prolog support file, Logtalk automatically got those pieces of dialect support added without any changes.

        In addition to this inheritance mechanism, take a look at this beautiful bit of bounty from the HTML lexer: 

         lua
            
-- Embedded JavaScript ().
local js = lexer.load('javascript')
local script_tag = word_match('script', true)
local js_start_rule = #('<' * script_tag * ('>' + P(function(input, index)
  if input:find('^%s+type%s*=%s*(["\'])text/javascript%1', index) then return true end
end))) * lex.embed_start_tag
local js_end_rule = #('') * lex.embed_end_tag
lex:embed(js, js_start_rule, js_end_rule)

-- Embedded CoffeeScript ().
local cs = lexer.load('coffeescript')
script_tag = word_match('script', true)
local cs_start_rule = #('<' * script_tag * P(function(input, index)
  if input:find('^[^>]+type%s*=%s*(["\'])text/coffeescript%1', index) then return true end
end)) * lex.embed_start_tag
local cs_end_rule = #('') * lex.embed_end_tag
lex:embed(cs, cs_start_rule, cs_end_rule)

        You can embed other languages into a top level language. The code you read here will look for the tags that start JavaScript or CoffeeScript and, upon finding them, will process the Java/CoffeeScript with their own independent lexer before coming back to the HTML lexer. (Similar code is in the HTML lexer for CSS.)

        Similarly, for those unfortunate enough to have to work with JSP, the JSP lexer will invoke the Java lexer for embedded Java code, with similar benefits for when Java changes. Even more fun: the JSP lexer just extends the HTML lexer with that embedding. So when you edit JSP code at any given point you can be in the HTML lexer, the CSS lexer, the JavaScript lexer, the CoffeeScript lexer, or the Java Lexer and you don't know or care why or when. It's completely seamless, and any changes to any of the individual lexers are automatically reflected in any of the lexers that inherit from or embed another lexer.

        Out of the box, Textadept comes with lexer support for ~150 languages of which ~25 use inheritance and/or embedding giving it some pretty spiffy flexibility. And yet this is only ~15,000 LOC total, or an average of 100 lines of code per language. Again, nothing else I've seen comes close (and that doesn't even address how much EASIER writing a Textadept lexer is than any other system I've ever seen).

    • I mean it's not doing nothing. It's an entire js engine running right?

      Personally not a fan but being portable to the browser is certainly an advantage in some cases.

      • Doing nothing from the problem domain. I mean I could make a "hello world" program that occupies 16TB of RAM because it does weird crap before printing the message.

        The problem domain is text editing. An idle text editor (not even displaying text!) is "doing nothing". The fact it was programmed by someone to occupy multiple GB of space to do that nothing is bad programming.

  • As a Vim/NeoVim user my number one reason is speed. There's a pretty steep learning curve, but it doesn't take long to see noticeable improvements.

    Aside from terminal applications generally running faster than GUI ones, there is a tremendous amount of flexibility that it offers when it comes to actual text editing. For example, you learn how to type things like _f(vi(cfoo _f(ci(foo† which goes to the beginning of the line, finds the first open parens, selects everything inside of the parens expression, then replaces that text with "foo". After a while these kinds of inputs become second nature, and you can start using them to construct macros on the fly that can be applied to different places in your code.

    One major downside is that it can take some configuration to get working the way you want it, especially if you want an IDE-like environment. NeoVim comes with a built-in LSP interface, which I've been able to get working pretty well for all of the languages that I use the most, but it's still kind of a pain to configure.

    I'm sure Emacs is similar, but I've never used it. I don't think many people use Nano unless they need to edit something in a terminal but don't know how to use Vim. On that note, being comfortable with a terminal editor means that you'll have no problem if you're SSH-ing into a server or using the TTY console.

    † _f(ci(foo avoids an unnecessary mode change, see comment below

    • you don't need visual mode for that, use _f(ci(foo

      • Ah true! Thanks, yeah that's a better way to do that. It seems I've developed a bad habit of going into visual more often than I need to- will keep an eye out for that

  • For me NVIM has several really cool advantages: NVIM is really fast. With a good terminal emulator I can open enormous log files and be able to navigate around/search immediately. I have recently pivoted to DevOps, and using VSCode to interact with large log files made me realize how slow and sluggish it actually is.

    Motions and modal editing. Plenty of people have already said how fast it is, I will just add that it is also very fun and, if you dig around a bit, not that hard to learn.

    Configuration using Lua - I like it because my configs are simple git repos, so the file structure and the logic of configuration is easy for me to work with. I always thought VSCode to be quite awkward to configure. Also, using Lua instead of JSON makes it incredibly flexible, and as a tinkerer I find a lot of joy in customizing things.

    NVIM (or VIM) is ubiquitous. You can expect it everywhere, and every other IDE has VIM-like bindings. Learn VIM = be comfortable anywhere.

    A personal perk for me personally is that NVIM is designed to be used without a mouse. Mice give me wrist pain, and switching to NVIM made my work a lot more bearable.

    If you're thinking about trying it out, I would recommend going for a community-maintained distributions like AstroNvim or ChadNvim. It's also quite cool to go back to your preferred editor, knowing your preferences are now more refined after trying alternatives.

    Anyway, good luck

  • Even today, it's often the smallest common denominator in large scale hardened enterprise environments. Absolutely zero chance of getting vscode or anything outside of the bare RHEL/SUSE packages running for mere convenience reasons on the servers. So we are forced to learn vim and bash scripting on the fly whenever the higher level tools ( config management, CI/CD) fail that - in theory - make direct access completely unnecessary. But that's not a good reason, it's more an indication for a badly managed project/environment.

    And no, I'm not an oldie, so I grew up with IDEs being ubiquitous and versatile.

    Advantages of being forced on bare vim/emacs are slim. It's cumbersome, it's hard to teach newcomers, syntax highlighting rarely works, etc. Overall efficiency and productivity is very low in environments where people are forced to use them. But yes, as is true with any other tool, the wizards of old can cast amazing shortcut spells and be highly productive. But it's very tedious and time consuming to learn, and there's little point in wasting time on it when modern tools are much more accessible and equally flexible.

53 comments