Editors (Vim) | Hacker News Reader

Editors (Vim)

missing.csail.mit.edu

155 pointsAustin_Conlon115 comments

This (advanced?) vi/m tutorial I really liked and found it useful over the years https://www.ele.uri.edu/faculty/vetter/Other-stuff/vi/009-in.... It is by Walter Alan Zintz, originally published in UnixWorld Online, dvelves into more advanced vi/m use. From https://sanctum.geek.nz/arabesque/unidex/, that itself I find a gem (e.g https://sanctum.geek.nz/arabesque/series/unix-as-ide/). Long time lurker first time poster, registered for this :-O

I feel about Vim the way RMS seems to feel about Linux. Even though, (presumably) everyone knows the relationship of vim to vi, I don’t feel there is enough explicit acknowledgement of that fact. Vim is evidently a wonderful tool, (I say this as a confirmed 20 year emacs user for whom emacs is only usable due to excellent vi emulation possibilities) but it clearly wouldn’t exist without the basic foundation provided by canonical vi which is in my estimation a work of genius.

It's hard to sense how much of vi is in vim, having only ever used vim. But I've never been very happy with vim, even though I've used it for 15 years. Maybe I need to find a "vim, the good parts (aka vi)" book.

use spacemacs with vim emulation :-)

I used Vim for a number of years (I'd guess around 10), and for the last year or so I've been using Spacemacs. I think there's so much that's great about both of them, and I'll continue to use one or the other, but geez, there's so many niggling issues with both that can be offputting.

A couple of examples. In Spacemacs, the screen regularly goes blank for a while. Or if I have a file open in Spacemacs, close its window, then rename it in the OS, then reopen it in Spacemacs (by double-clicking it in Finder) it reopens it with it's old name. I'm sure there's a way to avoid this, but the fact that it happens in the first place is the issue.

Never had the screen issue, gotta imagine that's the os and emacs.

As for the file rename issue, certainly if that's part of your workflow, it's helpful to figure out why it happens. I suspect it's due to the way filesystems work on Linux /Unix.

If you’re on macOS, the screen blanking is a known issue that’s happening because of some unknown interaction between the OS rendering and Emacs double buffering. IIRC, the mailing list thread about it concluded saying that nobody who wanted to work on the Emacs source had the requisite macOS knowledge to fix it and it’s been stuck there for a while?

Yes, I am on MacOS. Thanks for the info.

Oh yes i LOVE Spacemacs, but not vim-mode but the 'IvoryTower'-Mode

vi itself is just a natural progression from ed, the standard editor.

as is Plan 9's Sam - jumping beyond the Command Line ;)

But...who cares? Yes, Vim owes a debt of gratitude to Bill Joy's vi. And vi was built from ex, which was built from ed, ad infinitum back to the dawn of computing. I like trivia, especially computer trivia, and I was there for much of this evolution. But it's not important to know any of it.

> And vi was built from ex, which was built from ed, [...]

I think vi might more charitably be described as a paradigm shift. It also happened to bring terminal independence to everybody by later prompting the development of termcap (like vi, brought to us by Bill Joy). Of course termcap begat terminfo, [n]curses, ...

I feel like grandparent wishing for acknowledgement isn’t really out of line. It’s “Show a little respect; you have no idea where we were before vi.”

I use vim regularly on my day job. However, I am not familiar with more of the advanced side of things, and would never call myself an advanced user. That aside, I was always of the impression that vim was simply vi but extended in a sense.

Is that not the case? How different is vi to vim?

In my eyes, vi is ok for system administration, but not for programming.

The differences are not huge, but even if I have a "small" .vimrc with one single plugin, I have issues using the vim.tiny installed on Debian by default.

The Vim help has a list of the differences:

https://vimhelp.org/vim_faq.txt.html#faq-1.4

The most important to me are:

- a real undo - buffers - macros (recorded on the fly with ththe q key) - visual mode (included the block selection mode) - text completion (ctrl-p, ctrl-x-f) - automatic indenting - advanced text objects (selecting everyting between '()')

Not having one single of them would not hinder me much... but all of them at once: that hurts!

The "killer feature" for me is asynchronous jobs. It makes life so much easier.

This advanced tutorial helped me https://www.ele.uri.edu/faculty/vetter/Other-stuff/vi/009-in.... I have not found many advanced vi/m tutorials, I wish there were more. hth

Has eye-tracking been explored for improved code editing beyond Vim?

Vim does away with the hand-travel delays, but many of these ninja keystroke moves to navigate code are just what your eyes do already (but not all, such as the search function).

Looks like it has. E.g.

- https://medium.com/fast-company/the-mouse-of-the-future-your...

- https://purehost.bath.ac.uk/ws/portalfiles/portal/190368020/...

more https://www.google.com/search?q=eye+tracking+text+editing&oq...

Was going to read the first link, but can't be bothered to sign up / sign in to medium.com. Screw that platform.

Recently, I had an idea (which is somewhat stupid and makes me think I am rather lazy) to switch window context between two monitors using my eyes. Mainly because, right now, most of my workflow is from my keyboard, but to switch windows, I have to make either a weird hand twisting shortcut or use the mouse.

I haven't yet found such a solution but I do wonder how hard it would be build such a thing.

Possibly cheaper and more reliable you could attach a pedal to your usb port. As a next step you can start training an ai connected to your cam. Could be a nice project.

Vim is a well-sharpened pocket knife, a precision tool that excels at editing text interactively.

It’s interesting to me the different models for tools that address similar problems. I used to use vim, and the chords of keystrokes are still fresh in my mind, even though I switched to emacs years ago.

And now I use vanilla emacs —but that model is totally different, it’s an okay text editor but an excellent customizable user shell. It’s not a matter of better//worse, but of different philosophical approaches

When deciding between whether to learn Vim or Emacs, Vim won me over with three things:

1) Learning Vim increased my efficiency across multiple machines, and not just my dev machine.

2) It's extremely lightweight. Note: you still need to be careful with plugins!

3) Modal editing is easier on the wrists. Most of my time as a developer is spent navigating through code (whether editing or browsing), and Vim's normal mode keybindings are much less modifier-based.

I've been a happy vim user for many years, over a decade. But I was shocked at how this talk, published on YouTube in 2018 from a recorded lecture by an engineer at Yelp named Leeren Chang, basically made vim’s internal model “click” for me and made vim even more fun to use. I really feel the presenter did such a great job showcasing vim ideas — conceptually, visually, and by direct example — that, by the end, I downloaded the talk into my “great tech talks” stash and labeled it, “vim’s missing manual.”

Here it is: https://youtu.be/E-ZbrtoSuzw

Heh, "how you access ex commands shipped with Unix since like the 90s"

I have been using vim as an advanced beginner off and on for more than 15 years I think.

I use it lots of times (not for everything, I also use Visual Studio Code), mainly because it means that I can just ssh over to a VPS and edit a file in there, without having to set up fuse or some other way to edit locally. It seems like less work to just get into files and set up a new VPS. And I know there will be syntax highlighting for everything.

And also I have kind of a sunk cost of finally learning how to do basic things over the course of many years.

But personally, I think that it is embarrassing for people who seriously espouse that modal editing is better than more modern concepts. The reason we have hjkl for movement is because that is what the terminal was like when vi was invented. And the reason its Escape which is a little inconvenient on modern keyboards is because the Escape key on that terminal was more like where Tab is. And the reason its modal editing is because "real time editing" didn't even generally exist when vi was invented:

"Back in 1970s, terminal screen are 80 columns by 24 lines. There's no real-time editing. You edit by typing a command, then call another command to have the screen update to show the result of your command. Vi's “modal editing” is evolved from this." http://xahlee.info/kbd/keyboard_hardware_and_key_choices.htm...

I feel like it would be far more useful to just talk about vimtutor. At least for me, it was the only way I was able to grok vim.

This. And if you get to the end of vimtutor, you'll see a recommendation to continue learning via `:help user-manual`. I would have saved myself months of effort trying to learn Vim if I would have just RTFM.

I'm by no means a high level expert of command line, but if I need to do a quick edit I just use nano, and if I need to get down and dirty I use VS Code. Is this abnormal? I know a lot of power users use Vim, but I've just never fallen in love with it.

It is not abnormal. I used to use pico as my terminal editor and nedit as X editor the first five years or so I used Linux / Unix. Today I use VSCode as well, but vi rather than pico (nano). Over the course of many years I got more and more comfortable with it. It was never really a conscious choice. But it is always there. Perhaps it was the times I needed to fix things when booting in emergency mode that forced me to learn vim enough to get by, and eventually proficient.

This is unfortunately not uncommon. I feel like most of my coworkers at most companies Ive worked for don't use vim. One killer app of vim for me is macros. You can record a string of commands and map doing that to a letter. This makes certain mundane changes you have to do sometimes in software a breeze. For example, I had some code where someone was using string literals everywhere when they should have defined an enum. The convention we use for this kind of thing is to use UPPER_SNAKE_CASE and the strings were in camelCase. I was able to define two macros that let me improve this code in a few seconds. If I wasn't using vim I'd probably just leave that code as it was because it would have been so much effort.

> If I wasn't using vim I'd probably just leave that code as it was because it would have been so much effort.

Most modern editors, Visual Studio Code included, have powerful refactoring abilities. Not only that, but they're usable without needing to be an editor expert - just right-clicking and selecting "Change all occurrences" (or pressing F2) does the trick.

This is reasonably fast, but not nearly as fast as if can be on Vim. IDK how GP did it, but one quick way might be searching for strings and hitting . whenever the macro needs to be applied. So you would end up doing something like n n n . n n . n n and so on, where each n means “go to next string” and each dot corresponds to finding and renaming something manually in other editors. You can go through dozens of occurrences in seconds, orders of magnitude faster than other editors.

The vscode rename is much simpler/faster than that - cursor over the symbol/variable, press F2, type in the new name, press enter. Renames all references across all files in your project.

edit: no shade on VIM and VIM macros; they're great. I'm a very experienced vim power user, but have switched to vscode with vim keybindings, and I'm very very happy with the switch.

You're conveniently forgetting that this works for only supported languages. These things are also possible in vim with additional plugin for your language.

This is true for renaming a variable but GP mentioned converting string literals to enums. For tasks like that, I think Vim is pretty much the fastest. Also, Vim can also rename variables with coc (https://github.com/neoclide/coc.nvim)

The change I was just describing is much more complicated than a simple rename.

> One killer app of vim for me is macros. You can record a string of commands and map doing that to a letter.

Nano lets you do that too.

I've been using Vim since before it was Vim. I learned C on the 'ed' editor in the mid-80s, which was a predecessor to vi and Vim (and a subset of its command line UI). So Vim is always my go-to editor.

nano is fine for quick edits, but the more Vim you know, the better off you'll be in that situation. If you're not a devops/sysadmin person, or you don't spend a lot of time in command-line Unix, there's no shame in not knowing Vim. But it is universally better than nano.

> no matter what shell you use, you can export EDITOR=vim

Nit: in csh, it's 'setenv EDITOR vim'

Researched a bit for last few days about IDE and Vim seems to be the only viable long term option. I like Atom but it crashes all the time, VSCode doesn't feel clean to me. IntelliJ is the best but expensive. Only option I think is vim or Emacs. I loved the time I spent with Emacs last time, but gave up quick. I will learn to use Vim this time.

Or both! I was a long time Vim user that switched to Emacs with evil mode. Using spacemacs.

I have a couple friends that swear by Sublime Text. It costs money but its not terribly expensive, and super fast. Its vim plugin is a bit lacking though so it wasn't that usable for me.

20 years ago I got a job and went from Windows to Unix. Tinkered with both emacs and vim, and for some reason had this craziness where I'd start new files in emacs and make small edits in vi/vim. I have dabbled with neovim and vim-modes in other editors, but I keep going back to a somewhat-customized vim with ~8 packages.

I'm not really an advanced vim user. I have to think and remember how to do column edits, and I never yank to registers. For some reason I want to make a concerted effort to learn emacs again but the idea of not having edit modes concerns me.

Evil mode in Emacs is almost perfect. My biggest complaint is that undo works differently than vim (if anyone knows how to fix that, I would be forever grateful!) I originally used Emacs for about 20 years and then switched to Vim for a variety of reasons. I love the editing model in Vim. But for the last few years I've been using Emacs with Evil and it's been the best of both worlds.

Here you go: (setq evil-want-fine-undo t)

You are my hero!!!!

If you like modal editing, consider https://www.spacemacs.org/

The org-mode[1] outlining and magit[2] wrapper for git are most worthy.

[1] https://orgmode.org/

[2] https://magit.vc/

I used spacemacs for a while, but once you use several layers it becomes so slow that it makes VSCode feel snappy.

I also find that because it has such a customized way of doing things it often becomes quite difficult to make your own customizations, especially if you try to follow guides written for pure emacs.

I've just started using doom emacs, another "distribution" around evil-mode. So far I really like it, it is much snappier than spacemacs and the layering and customization system is much closer to traditional emacs.

I'm one of those for whom the 'space' in spacemacs is essential.

The regular key chords tore me up badly.

The performance/layers have never given me grief with spacemacs.

I agree, fortunately Doom uses the same type of keybindings as spacemacs

If anyone is looking for some vim-porn (in the form of screencasts of a decade-long user going through various workflows), I'd like to use this opportunity to share some screencasts I recorded that I think will resonate with fellow HN readers:

https://www.youtube.com/watch?v=futay9NjOac

The best part about vim is modal editing and the key-command interface. Other than that, it’s pretty much the same as everything else, worse, cus vimscript is an abomination.

Best setup is vscode with vim emulation and I’ve been using vim profesionally almost 15 years now.

Funny enough, I actually liked writing prose with Vim but I’m using Ulysses as an editor for writing prose now

I’m so used to vim as a code editor that I assumed, after the introduction, this article was going to be castigating me for trying to write prose in vim (which I indeed try to do on a regular basis, with what feels like a lot of friction.)

Perhaps, as they imply, I should dust off a copy of Microsoft Word and switch back to that!

There is no conflict if you use LaTeX :)

Goyo.vim was pretty helpful. So was formatoptions +a.

(The typesetting part isn’t the issue. Concentration and ease of flow in the editor feel hard in vim, and LaTeX wouldn’t fix that.)

complete the circle and use a vi plugin for Word http://www.viemu.com/

I respect Vim, I've seen it used with impressive speed, BUT I am so used to command-s to save, that I don't feel ready to :w enter all the time. VS Code is powerful, and learning the keyboard shortcuts for that are getting better every day (command-shift-p format-selection enter).

macvim still supports command+S

You can put something like this in your .vimrc:

  " save with ctrl+s
  nmap <c-s> :w<CR>
  imap <c-s> <Esc>:w<CR>a

Edit: I guess it should be:

  nmap <D-s> :w<CR>
  imap <D-s> <Esc>:w<CR>a

You can also use

    imap <C-s> <C-o>:w<CR>

<C-o> in insert mode can be used to execute normal mode commands.

VScode has a vim plugin. You can easily customise your key bindings as well.

You get over it fast.

1. You can bind save to any key combo you want. I personally use <leader>w. I find it more ergonomic, fast, and portable than command-s.

2. Every action in vim reads like a little story. You start to speak the stories to yourself. For example:

Select the entire line (V), move to the end of the line ($), move to the matching end brace (%), delete (d)

3. Then you realize you can store those stories into a macro and execute them ad hoc, and the world becomes amazing.

The things you learn are cumulative. You begin to expect the pattern to continue and more often than not it does.

I used to have something like

  nmap ,w :w<cr>

in my vimrc so I can only press two keys to save the file. I think the colon character (:) adds a little overhead to such a common command because one has to press shift with the colon/semicolon key (depending on the keyboard layout), and then release them to continue pressing the remaining keys. And this is if you're already in normal mode; if you're in visual/insert mode you'd have to press Esc or Ctrl+[ first. Of course, these are small details that you don't normally think about, but it does feel a little cumbersome when coming from an editor where you can just press Ctrl+s or C-x C-s (in the case of Emacs) and continue working.

In the end, vim doesn't stop you from defining key bindings to improve your workflow.

do set -o vi in bash and watch all your dreams come true.

even though I have always used ViM, I can't do this, I am too used to using control-a and control-e

I discovered this last year and it has made me so happy

I love vim but I always get a feeling that I'm only using 1% of its features. It is hard to memorize all the availanle keybindings, specially if it is something that you don't use often.

Does anyone have suggestions of what worked to help learn mor Vim commands?

Once you understand the verbs and nouns of Vim, you don't need to memorize nearly as much.

[1] Learn vim For the Last Time: A Tutorial and Primer— https://danielmiessler.com/study/vim/

[2] The Vim Learning Curve is a Myth—https://thoughtbot.com/blog/the-vim-learning-curve-is-a-myth

[3] Vimcasts—http://vimcasts.org

I spend a lot of time in tmux and I frequently open and close terminal sessions so I made this

https://github.com/cboppert/motd

It’s message of the day but with ViM tips. It worked fantastically for getting small tips throughout my day that allowed me to consume and learn without necessarily dedicating any tangible amount of time to it.

I love this idea! Basically a vim version of "fortune". Did you compile that list yourself?

I think I took them from a big ViM cheatsheet somewhere.

I suspect it’ll take a long time for that feeling to go away, but what helped me for learning is just using Vim everywhere and sometimes when you run into a particular problem where you think there might be efficient ways to solve it, look it up. Give yourself some time to get used to the new commands and really add them to your repertoire before you look up something new.

If you think Vim emulation is a replacement for Vim, either you don't know Vim or you don't like Vim. VSCode Vim emulation? Spacemacs? They are miniscule, pale comparisons. VSCode is a fine editor. Emacs is a fine editor. Spacemacs is pretty fantastic. But if you you think that's Vim, you simply don't know and appreciate Vim. That's ok, but it's not even in the same universe as the real thing. By all means use what you want, but don't try to sell it as close enough.

I agree, but also understand that many people use only a subset of vim and think of that as the full package. And that's fine for them.

Would you care to elaborate and point to some specific features and workflows that you consider to be unique to the real Vim?

I honestly can't think of anything that the vim adds the you can't get from vim emulation. Especially a top notch one like Emacs Evil. Please use vim for the keybindings, not the software.

I would have expected MIT to rep Emacs, not vim...

Intellectual diversity lends itself to a diversity of editors as well.

Vim emulation in VSCode worse than any other IDE I've used.

All extensions have to run on the same thread in a background process and intercepted keystrokes are passed to that process over IPC. So if other extensions (like the TS language tools) are tying up the extension host process, the Vim extension can't respond to your keyboard input until other extensions yield.

Performance issues come and go but for awhile I was stuck waiting for several seconds any time I typed a < after an identifier.

A lot of us have tried to demand a separate process for extensions that intercept keystrokes to solve this issue permanently. But the maintainers don't really care.

This makes so much sense. Thanks for explaining that.

I don't use it myself but it's possible to embed Neo Vim in VSCode. So you're able to use edit text using a real instance instead of relying on a crappy emulation.

I am not entirely sure if you are referring to https://marketplace.visualstudio.com/items?itemName=asvetlia...

I just switched after using vs vim and got much better performance.

I had neovim installed anyway for the EX commands

Yes, that's it.

I use VS Code w/ vim mode for NodeJS/Angular/React development and haven't noticed performance issues; granted, I'm running on a beefy Windows PC since it's the only good option I've found for vim on Windows.

On Mac/Linux I just use neovim with coc[1], which works beautifully.

[1] https://github.com/neoclide/coc.nvim

As a long time vim user, I’ve tried VSCode a few times and I cannot for the life of me figure out what all the hype is about. Can anyone who is proficient with it explain the philosophy behind it and what makes it so great? This is a sincere question, not a rhetorical one.

It's very featureful and very easy to pick up. So I speculate that most of its popularity is with people that unfortunately have not yet been enlightened by vim/emacs.

The article said 1.4 million people have installed the Vim plugin for VSCode. That's a sizeable chunk. Presumably a bunch of those people really like the editor.

I used Vim for several years before switching to Sublime Text 3.0 and now VS Code. VS Code support for TypeScript is just unmatched on any other editor.

Webstorm typescript feel better for me

I use vscode daily for everything, from note taking to programming. Here are my pros and cons.

Pros: - Has plugins for anything.You're doing C++, just install C++ plugin and you're good to go. Want vim key bindings there's a plugin for that as well. I use a plugin that can scrape competitive coding websites and automatically create tests for a problem. - Git, snippets, etc all modern IDE features built-in. - It is also found on many websites as an editor.

Cons: - Since it's electron. System requirements are on the higher end.

cons: extensions.

sharing part of OP's sentiment. in fact, i flipped the table a few weeks back because an extension downloaded a tool to my system and guess what? the installation got stuck. and guess what? my text editor hung!

all i wanted was to edit text. i didn't even ask for an extension. i was presented with one that supposedly would make my text editing experience better.

tiring...

It's worth mentioning that even though it's Electron, it's fairly well optimized Electron.

Idle, it takes up a third of a gig of RAM on my laptop. Language server extensions are responsible for the majority of the load users encounter. That's certainly a good 2-3 times more than Sublime Text, but it's not going to be a deal breaker for a majority of people.

It's Emacs for Javascript people - a good thing since Emacs is moribund and most programmers are at least a little bit Javascript people. A highly programmable, cross-platform editor with zillions of extensions/modes that support all sorts of languages and environments. People complain about its resource requirements and performance, just like they did with Emacs. Vi(m) users are the natural enemy of VSCode, just like they were the natural enemy of Emacs, continuing their long proud tradition of being wrong about everything. I think that's roughly where it fits 'philosophically'.

> continuing their long proud tradition of being wrong about everything.

Why do you think that Vim users were/are wrong about everything?

I don't! That's just a dumb joke. A thing that I semi-seriously think: modal editing is not some uniquely interesting or advantageous way to navigate and edit text. A thing that I mostly-seriously think: most more recent methods for editing and navigating code are a lot better vim-style modal text editing.

The only thing what makes modal editing bearable (from UX PoV) is the unlimited undo.

e.g. Would anyone take a plane that has modal cockpit buttons?

What does flying a plane have to do with editing and navigating code?

It happens me every day: I just start to type while still in command mode, and then have to press "u" a couple of times.

(But ok, thats maybe just me - thought this is a common experience, and I just wouldn't like to sit behind a pilot doing the same...)

This sort of thing has been a factor in airplane accidents - pilots becoming confused about stuff like the automation regime they're in.

This problem can be mitigated to an extent with a vim setting to change the cursor from a block to a vertical line when you enter insert mode. After using it for a bit your brain will learn to look for the vertical line before typing.

All editors are modal, just to different extents. In Notepad, if you type a letter it inserts it, unless you have some text highlighted, in which case it replaces that text. "Some text is selected" is a mode.

The big thing that classic vi got wrong with modes from a usability perspective is that changing modes is mostly invisible. In vim, however, you can configure it to change the cursor shape in different modes, and this is a pretty effective cue. (It's also the default behavior in gvim.)

I expected it was because of the vim crowd's belief that a small footprint is essential for some reason. I use evil mode in emacs and can't understand why vim people place arbitrary limits on themselves when emacs is a more full IDE experience that costs them very little to jump to.

I use a remote machine at work for all development. With tmux + Vim, I get persistent editor sessions with native performance.

The alternative used to be writing code over VNC (not fun!), but we’re now moving towards VS Code Remote. I don’t see myself changing to it anytime soon, though.

Modal editing is very efficient imo. Once you get used to it, there is no going back. Plus, in my experience, it’s much easier on the wrists in general.

But I think Vim bindings in an IDE or Vim with a LSP plugin is the killer combo.

I'm going to partially disagree.

> It's Emacs for Javascript people

I'll accept this premise.

> a good thing since Emacs is moribund

And here we part ways.

> and most programmers are at least a little bit Javascript people.

You might be living in a bubble.

> A highly programmable, cross-platform editor with zillions of extensions/modes that support all sorts of languages and environments.

Agreed; I think you're actually underselling how helpful it is that it's apparently a lot easier to get started with than emacs or the vi family. Power tools with a lower learning curve is a good thing.

> People complain about its resource requirements and performance, just like they did with Emacs.

And they're right to do so, especially with Moore's law wearing thin. Besides which, emacs (and n/vim, for that matter) are still around, and are just as functional in a much smaller resource footprint.

> Vi(m) users are the natural enemy of VSCode, just like they were the natural enemy of Emacs, continuing their long proud tradition of being wrong about everything.

LOL, that's... semi-fair, even if you're on the wrong side, of course;)

> I think that's roughly where it fits 'philosophically'.

I think it's fair to call VSCode "EMACS but with JS", but I think you're really glossing over the issues that it has in practice; maybe with a decade of maturation it'll be on par, but today I would argue that it is a resource hog, and still suffers from some poor design choices (such as letting extensions trample eachother, per the upthread discussion).

You might be living in a bubble.

I think the relative sizes of the 'Most programmers have at least some minimal familiarity with Javascript' bubble and the 'Emacs is not moribund' bubble speak for themselves and offer sufficient retort :)

It's not really.

The difference between VSCode and Emacs is the difference between an extensible editor and a software omnitool intended to be extended, shaped, and refined as you work with it. Writing short programs in Emacs Lisp, seeing their effects immediately in the live editor environment, and then (should they prove generally useful) refining them into full-fledged modes or commands is quite a bit different than writing a packaged extension.

There is, still, nothing like Emacs in the editor world today. As much as Visual Studio Code gets right, it has a long way to go to get within spitting distance of Emacs in terms of adaptability and power (to say nothing of resource consumption).

This shows the stance of the people in the different "editor groups" perfectly! I'll never understand why programmers get so attached to their tools that they start evangelizing it for everyone else. Just look at the other responses to this comment. People are either questioning each bit or are trying to defend them.

If it work for you good, if not, fine. Just don't get crazy about it. It's just an editor!!

A big, fun part of any hobby or craft that involves tools is kvetching about the tools. It's often at least as fun as the practice of the hobby or craft itself.

these are my favorite features, in no particular order.

* Tons of quality extensions, incredibly easy to install and manage

* Good color schemes

* ssh extension - remote vscode with all your plugins, themes, etc. with basically zero setup

* integrated terminal

I have no doubt that you can get a better vim setup, but getting vim fine-tuned takes a while for me and figuring out what I like. VSCode is convenient and easy, and works on everything, no suprises. Don't have to worry about fonts, terminal colors, config files, etc. I do think the vim plugin for VSCode is garbage compared with the terminal.

https://marketplace.visualstudio.com/items?itemName=asvetlia...

This is using a real neovim instance rather than emulation, and performance is excellent for me.

I second that and would like to point out that apt-get only saves an old copy of neovim. I had to install the latest version using snap.

This issue is described in the link but I thought it deserves highlighting

> I was stuck waiting for several seconds any time I typed

The worst behaviour of any editing environment is a lagging keyboard response.

In this COVID-19 era I've found myself working remotely over VPN and on some occasions the response times become very slow.

The most noticeable observation for me is how frustration writing code becomes whenever my editing environment slows over that lagging VPN.

Tasks that are normally subconscious suddenly turn into mental challenges as you find yourself constantly checking if these subconscious actions actually complete.

I don't think there is any need to suffer just because you have a slow connection. You can use mosh if you're editing on a remote machine, or sshfs if your editor is on your workstation. I have heard that you can run the Language Server on the remote machine as well, for things like completion/indexing/etc. (I personally always just ssh to the remote machine and use Emacs though. Then I have the same environment at home and work and don't have to sync anything.)

Reply on news.ycombinator.com