17 ms·

New employee 1 workflow at company X: 1. Install VS Code 2. Click extensions and install language specific plugin 3. Work New employee 2 workflow at company

New employee 1 workflow at company X: 1. Install VS Code 2. Click extensions and install language specific plugin 3. Work New employee 2 workflow at company X: 1. Install emacs 2. Try to install some source code indexing tool 3. Tool is missing 13 dependencies, so spend 4 hours finding, installing and configuring the dependencies. 4. Spend another couple hours reading non-existent to terrible documentation (documentation so bad in places that even Stallman finds it useless) across 3 packages and editing .emacs to configure an otherwise unusable result. It looks like source code indexing is working! It isn’t... 5. Go home 6. The next morning, find the default color theme garish and spend another 4 hours installing themes and theme managers, reading more terrible documentation, and finding that obscure TTY settings must be tweaked for emacs to decide that it can use a theme (even though it has no problem displaying the colors in the first place) 7. Spend the rest of your tenure constantly hitting code indexing and highlighting bugs that need constant tweaking and workarounds. You often find yourself using find/grep because it’s often faster than debugging the latest indexing bug. 8. Discover that the vaunted ‘lightening fast editing’ with ‘multiple cursors!’ and this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing. Emacs is a terrible experience with defaults suitable for a 70s TTY. That you can change it misses the point. The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone. In a few years, VS Code has achieved better out of the box functionality for working professionals than emacs has in 40 years.

MarcScott 6y ago
> The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone. The fact that I have a non trivial .emacs file ensures that when I switch machines, I only have to transfer a single file to enable an identical development environment. I can't speak for VS Code, as I've only ever played with it a couple of times, but can I do the same thing there? I don't want to spend hours finding and installing packages to recreate my dev environment, or play with various GUI settings to recreate my preferred theme. With Emacs, I can `package-install-selected-packages` on a new build, and I'm using an exact clone of my usual config.
- brlewis 6y ago
  > The fact that I have a non trivial .emacs file ensures that when I switch machines, I only have to transfer a single file to enable an identical development environment. I just want to pull this particular sentence out for emphasis in case anyone is reading the "New employee 2 workflow at company X" comment and thinking that it's even the least bit true.
  - danieldk 6y ago
    For me it is home-manager switch and I don't only have my full Emacs configuration, but a full development environment with Rust, Go, etc. Though you could probably also configure VS Code that way.
    - sterlind 6y ago
      Nix support for VS Code is pretty painful. Only a tiny subset of extensions are listed in nixpkgs, and those are often broken (e.g. Python) when old binary versions are pulled from the CDN. If somebody could make a VS code extension that seamlessly pulls down other extensions by altering the nix config, it'd be perfect.
      - danieldk 6y ago
        Thanks for the information! I haven't tried configuring VS Code through Nix yet. I guess I'll wait a while before doing another attempt.
- Osiris 6y ago
  I'm not familiar with emacs. Does that mean that you don't need to install any supporting software like indexers, linters, syntax highlighters, etc? Does the emacs file contain all that or tell it how to download all the plugins? If you could just copy one file and get all that, that's pretty cool.
  - ekko911 6y ago
willberman 6y ago
Workflow on midsized personal project with editor that I'm comfortable with and have customized over the majority of time I've been programming: work. Look, obviously VS Code has emacs beat in the vast majority usability features. Emacs works for a lot of what I work on. For the things it doesn't work for, I use the tool that works better. I have lots of personal qualms with emacs, but to declare it "maximally unsuitable," is overkill.
redis_mlc 6y ago
I use vi. Never had to install anything across thousands of servers.
- dietr1ch 6y ago
  That's true, but I'd rather use tramp-mode and keep my setup instead of sacrificing it for the sake of consistency across servers. It won't really be consistent anyways, you'll get some plugins here and there I guess.
3fe9a03ccd14ca5 6y ago
Better yet, install vscode, then install either the vim or emacs plugin. The best of all worlds!
- ahupp 6y ago
  Kind of. I haven't found a VSCode emacs package that does more than superficially handle emacs keybindings; there's always mismatches that trip me up.
- chipotle_coyote 6y ago
  Eh. Sort of. Like the other person who replied about the Emacs plugin, I find myself running into issues with the Vim plugin -- usually not the keybindings as much as the ex-style commands. For instance, ":20,27m." will move a block of text in Vi/Vim to under the current location; that doesn't work in VSCode Vim. Worse for me personally, I've gotten really used to the ":find" command being the (rough) equivalent of a fuzzy file search: ":find App.php" will find that file no matter where it is in the current project, but again, not a VSCode Vim command. It's a good emulation, but it's not a great emulation.
  - jgalentine007 6y ago
    Ctrl+p will let you search nicely for files in vscode. At least the VI integration is better than the extension I use with Visual Studio.
    - chipotle_coyote 6y ago
      Oh, yeah, I do use that (well, Cmd-P over here in Mac-world). It's just when I get into Vim mode I type ":find" reflexively and I get disappointed for a moment. :) (Ironically, there's a Vim plugin called CtrlP to do the same thing that I never use because I find it confusing and weird compared to everybody else's implementation of the same idea...)
quadrifoliate 6y ago
This view is obviously biased against Emacs, but I don't disagree completely with the premise. As an Emacs user, being "immediately productive" (whatever that means) is not your topmost priority. You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. In a a much better way than I can put it, Emacs users are like Igors [1]. You can be a productive individual contributor writing Clojure inside Emacs, or a productive CEO managing todos in org-mode [2] – it works equally well once you figure out how you mold your editor. VSCode "plugins" and Emacs packages are just not the same, with Emacs you can be far more flexible about changing the behavior of the plugin in specific modes or activating things given specific conditions. You revel in the effectiveness of using one of the last remaining vestiges of the Lisp Machines of Old Valyria. Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason. You would think that giving an employee a week for setting up and tuning their workflow should be totally normal if you want them be there for several years and be maximally productive over time. More power to them I guess. [1] https://chrisdone.com/posts/emacs-users-are-like-igor/ https://chrisdone.com/posts/emacs-users-are-like-igor/ [2] https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html
- TheSpiceIsLife 6y ago
  I’m not a programmer, just a tradesman who’s worn a few different hats over the eons, but I’ve noticed something as I’ve gotten older and lazier: I am equally as unproductive regardless of my setup. My productivity has way more to do with all the other factors at play than it does the fine-tuning of my setup.
  - michaelmrose 6y ago
    In order to be more productive of 10s of thousands of hours one only needs to be slightly more productive to justify spending a handful of hours. 1% per 10k hours is worth 100 hours.
bachmeier 6y ago
> In a few years, VS Code has achieved better out of the box functionality for working professionals than emacs has in 40 years. That's not as clever as you seem to think it is. Emacs was created for a different world. Of course new tools have an easier time in the world for which they were created and with no legacy baggage.
- ipv6ipv4 6y ago
  You’re essentially saying that emacs has been stagnant and hasn’t changed with the world around it. Yes, absolutely. That’s why it’s not a surprise it is losing popularity. Clunkiness and baggage is not a foregone conclusion for software. Software can keep up with a changing world, discarding old baggage along the way. In the end it doesn’t matter. Whether it is old software that adapts and changes or new software that supplants stagnant, clunky software. The world uses whatever is easiest and most relevant and goes on.
jjoonathan 6y ago
That, and while emacs has a reputation as being the ur-editor from which all text editing innovation stems, the reality is quite the opposite. It's stagnant and hasn't been the center of text editing innovation for at least the last decade, and probably quite a bit longer before that. It was a particularly bad string of basic package incompatibilities that woke me from my emacs evangelist phase, but it was the realization that emacs was downstream from TextMate on several non-GUI-centric features that made me realize the entire "platform" value prop was bunk. While emacs might be excused for missing tectonic shifts (e.g. away from CLI and towards GUI), entirely text-centric features like multiple arbitrary simultaneous caret, Smith Waterman quick file/action search, powerful template substitution, parsing-based syntax highlighting, navigation, and refactor tools all developed and matured outside of emacs and then slowly and painfully found their way back in, not the other way around. Emacs was supposed to be a fertile platform for text editing innovation, but history didn't work out that way, even if you ignore the trend towards GUI innovation, which you shouldn't.
- michaelmrose 6y ago
  Emacs is a gui app. You can have if you like a tool bar. A menu-bar, tabs, split windows. If you want something slightly more like a traditional gui emacs application framework enables bidirectional communication with QT applications running in emacs frames. Personally I use it to render HTML mail inside emacs with what amounts to embedded chrome.
  - pjmlp 6y ago
    As far as I am aware it still isn't as GUI oriented as ZWEI used to be.
    - michaelmrose 6y ago
      What gui elements do you find lacking I'm not familiar with ZWEI
      - pjmlp 6y ago
meddlepal 6y ago
I would expect an experienced emacs user to have a config already that more or less "works". Was this a junior developer that just decided to start using emacs one day? I'm not an emacs person myself, but every emacs person I have ever met already has it setup and customized and just brings their config. A new dev starting with emacs on a new job... just sounds like a bad recipe and misunderstood priorities.
- jjoonathan 6y ago
  > already has it setup and customized and just brings their config You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file. I've spent less total time configuring TextMate, Sublime, IntelliJ, Atom, Jupyter, VS Code, and PyCharm than I spent back in the day trying to learn emacs lisp and get the emacs plugins for ObjC syntax highlighting and fuzzy filename matching to play nicely with each other. Meanwhile, each of those GUI editors brought considerably more impactful unique day-to-day functionality to the table than emacs ever did.
  - Scarbutt 6y ago
    You had to spend time learn a new set of keybindings for each one though, for editing and interacting with the interface.
    - jjoonathan 6y ago
      Not really. The most common keybindings of GUI text editing have largely converged, and those that haven't collectively account for similar total complexity to, say, basic file/buffer management and movement in emacs. Yes, the life of an editor nomad sometimes involves hitting the wrong key to build or occasionally forgetting which modifiers trigger block select, but those adjustment pains are typically overshadowed by the joys of high-priority platform integration that works straight out of the box, and they're downright tiny in comparison to the pain I used to experience getting half-assed platform support up and limping in emacs.
  - josteink 6y ago
indogooner 6y ago
I don't contest that VSCode has achieved better out of the box functionality than emacs but it still needs a lot of configuration. My experience is only with C++ extension where intellisense update just goes on indefinitely. Navigation to a function takes ages. Then I exclude some source directories and restart VSCode. And not to talk of resource hog that it is. When it works it is pretty good and that's why I stick to it. May be other language extensions are better. I would say it is the best editor with the resource usage of a full blown IDE.
- _bxg1 6y ago
  The experience varies widely by language. TypeScript support is top-notch. Clojure support used to be bad and then got good. Rust support has been bad for a long time but the nascent rust-analyzer project makes it fantastic. Python support is decent but only if you get an optional, poorly-advertised extension on top of the default one. C# support is quite solid. Etc. Only a couple of languages get first-party support from MS. The rest depend on their respective communities to build extensions. VSCode has a great plugin architecture, but it's entirely possible to write a bad plugin for it, especially if it's simply not a popular enough editor in that community yet. Still, none of the above required dependency-juggling or stepped on each others' toes. Only a couple cases required a configuration step to get them fully working. My worst VSCode setup experiences haven't wasted as much time as the Emacs golden path did.
  - mbeex 6y ago
    > Python support is decent but only if you get an optional, poorly-advertised extension on top of the default one. Which one?
    - _bxg1 6y ago
      This one: https://marketplace.visualstudio.com/items?itemName=ms-pyright.pyright https://marketplace.visualstudio.com/items?itemName=ms-pyrig... I only found out about it by asking here on HN
tiew9Vii 6y ago
Wouldn't class myself as an experienced Emacs user. Used it for 5 or so years. Learnt enough to get by and have my own config that works for me. Not got as far as writing my own elsip functions. When I set up a new computer 1) Check out my emacs config from git 2) Start emacs 3) Wait for emacs to automatically download all the packages declared in my config using use-package. If you never used Emacs before fair enough it's harder than VS Code. VS Code does let you get going knowing less by clicking buttons. It's the same as comparing any CLI app with a full blown point and click GUI. My take on getting a new user setup... "use what ever IDE you are comfortable with, I do not care. This is the IDE I use, here is how I have it set up if you want to use it also. Person C uses this IDE instead if you want to use that, ask them for there setup. No one here uses your IDE? You are on your own setting it up but can help with any project specific questions you need to know to get your IDE of choice running". As far as code searching goes I find myself often outside of any IDE using the silver searcher (ag) so use emacs projectile for the exact same functionality but within emacs. Sometimes the only feature I miss from a full blown IDE like InteliJ is find usages.
- deleted 6y ago
  [deleted]
danieldk 6y ago
I am not a passionate Emacs user and I strongly dislike the weird bugs that rear their heads sometimes. I was always a vim user, but switched to Emacs because it has better support for completion, etc. while having nearly perfect vi emulation. I would even go as far as saying that Evil is vi implemented in Emacs Lisp. I try VS Code every now and then, but I always stop because of two reasons: incomplete vi(m) emulation and the latency feels really bad compared to Emacs/vi. Would like to switch otherwise, but non-leaky vi support and good latency are essentials. Edit, forgot to add: something as good and keyboard-driven as magit.
- thayne 6y ago
  > but switched to Emacs because it has better support for completion, etc. while having nearly perfect vi emulation I switched to emacs for similar reasons (plus the fact that it supported embedded repls that actually worked). But eventually switched to neovim, because it could do things like completion and repls. vim 8 can now as well. > I try VS Code every now and then, but I always stop because of two reasons: incomplete vi(m) emulation and the latency feels really bad compared to Emacs/vi. > Would like to switch otherwise, but non-leaky vi support and good latency are essentials. Same. Also start-up time. I love typing `v <filename>` in a terminal and instantly getting an editor. Lower memory usage is also nice.
- dmarchand90 6y ago
  How long did it take you to switch? I tried spacemacs for a few months but got tired after I was always accidentally breaking things
  - danieldk 6y ago
    Not too long. I also began using Emacs with spacemacs, but it was buggy and slow. Then I just started with a completely pristine Emacs configuration and just added through use-package: - evil for vi emulation - general/which-key so I could define spacemacs-like bindings that start with SPC. - ivy for quick search of buffers, files, etc Then I added things on a by-need basis. I would say that the most important additions were magit for Git, projectile for quickly switching between project files, and some Rust packages. This is now my emacs configuration: https://github.com/danieldk/nix-home/blob/master/cfg/emacs.nix https://github.com/danieldk/nix-home/blob/master/cfg/emacs.n... Rust configuration: https://github.com/danieldk/nix-home/blob/master/cfg/rust.nix https://github.com/danieldk/nix-home/blob/master/cfg/rust.ni... (Sorry for posting Nix files, but it's pretty close to what it would look like in a regular init.el.)
michaelmrose 6y ago
New employee 3 workflow at company X: 1. Install Emacs 2. Sync existing config via git 3. Work New employee 4 workflow at company X: 1. Install Emacs 2. Spend 2 hours learning default Emacs 3. Work New employee 5 workflow at company X: 1. Install Emacs 2. Spend 1 - 2 hours learning default Emacs 3. Spend 2 - 4 hours googling interesting Emacs packages, in each case going to their GitHub repo to read the directions, adding a use package form to your config with the settings that seem best from reading the directions and testing it to see if you like it until you have a useful set of functionality 4. Work You can probably spend plenty of additional time tweaking emacs to be everything from your mail client, your music player, your IRC client, insert task here but if you do this in the time you would be watching Netflix instead of the time you are supposed to be working you probably wont have trouble getting your work done. I literally have no idea what you are talking about insofar as TTY settings, themes, indexing bugs highlighting bugs, or constant workarounds. I installed Emacs the graphical application, opted to spend 2 hours reading a book wherein I learned how to use emacs and picked a theme by searching for the string emacs theme and picking one that looked cool. I ran package-install typed the name of the theme, hit enter and evaluated (load-theme 'theme) in my config. I have no idea why you would be running Emacs in a terminal in the first place.
- yewenjie 6y ago
  I second this so much. Emacs configs like Spacemacs, Doom, or M-Emacs provide an excellent out-of-the box experience.
  - dmarchand90 6y ago
    Disclaimer: mostly vim guy. I agree that Emacs is super powerful for power users, don't agree that it's intuitive or easy for new users. Also I found spacemacs to be pretty brittle when I last tried it a year ago.
    - iimblack 6y ago
      Agreed on Spacemacs. Seems like a lot of stuff I had to switch to the Develop branch for it to work right. Supposedly the next release is coming out soon which will fix a lot. I’ve since switched to Doom which I like better anyways though.
fossuser 6y ago
I largely agree with this and I wasted a lot of time in school and earlier in my career on these tools because of how often they’re positively talked about in online communities and positively compared to what seem to be otherwise obviously better tools.
xf1cf 6y ago
I actually like this viewpoint because I have done both and generally I disagree with you. But here's my take. I use VSCode often because its "just easier". The extensions are at best (in my opinion) ok approximations to what I can get with emacs. Especially for a language I'm inexperienced with in emacs VSCode is a nice integration layer while I adjust my configuration. Emacs (and to that point vim) is vastly superior to any offering VSCode has. The problem is you have to be productive. Many nights I labored over my emacs configuration to tailor to my job. I've done this for the last 10 years. It takes effort. To that, you have a point. VSCode is effortless. On that, VScode doesnt feel like anything to me except a bridge layer. Emacs and vim offer a vastly better experience (without the git politics!) if you're willing to spend the time customizing it. But that is the difference - are you willing to spend the time? Many developers are not and that's fine. But for a marginal additional investment you can have something better. Something to think about at least. I can install my Emacs configuration in 30 seconds from my github.
- random_cynic 6y ago
  Everywhere in this thread I see vague and generic statements like this. Do you have concrete examples of specific things in your 10 year old Emacs configuration you "labored over" that can do something VSCode (and its extensions) can't and which makes Emacs "vastly superior"? If so please share, otherwise don't bother. We have already heard all this vague nonsense for years.
  - nvarsj 6y ago
    There are loads of examples in the comments here. Have you read them?
holri 6y ago
In the long run (now 20 years) the switch from Microsoft products to Emacs was a giant net win for me. Since I am no longer at the mercy of volatile business, but enjoy stability und functionality at its best. The initial investment in configuration and learning had enormous dividends. Don think short term.
pjmlp 6y ago
Younger self used to Borland and Microsoft IDEs, when going into Xenix, DG/UX and frieds, "where is my IDE?!?". The TA on my 2nd year university pissed off with everyone of us using Emacs as Notepad, instead of spending one hour talking about Pascal, decided to teach us how to use Emacs properly. I was one of the few that kept with it, although I ended up moving into XEmacs, which had a much better experience. The large majority of my fellow students decided to adopt Joe, JED instead. After university and after a couple of years on the job market eventually all of us moved back into IDE land. So not sure what Emacs can really do to still cater to younger generations, if even for us it was seen as something to endure on university computer systems, back when options were quite limited.
robotwizard 6y ago
What are you guys talking about... 1. nano code.txt 2. ??? 3. Profit!
_pmf_ 6y ago
> In a few years, VS Code has achieved better out of the box functionality How many years will it take until stock vscode stops lagging randomly every 10 key strokes?
- sterlind 6y ago
  laughs in visual studio Remember that you can open the dev tools and profile VS Code itself. I've debugged a few weird issues that way.
m463 6y ago
I think the productivity graphs look like: | 22 | 22 | 1111121111 | 1 22 |1 22 |122 -------------
zelly 6y ago
> this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing Exactly, the bottleneck is thinking, so why do I need the slick point-and-click tools in an IDE?
enitihas 6y ago
Or even better New employee workflow at company Z 1. Install the Jetbtains toolbox 2. Have IDEs for several languages with consistent features and semantics. 3. Minimal to no configuration needed 4. Profit.
- adrianN 6y ago
  I can use 40% more cores when compiling than my CLion using colleagues because vim doesn't need 10GB of RAM. I tried using CLion, but it was just too slow. Maybe I was holding it wrong.
  - enitihas 6y ago
    Off-course, if majority of your time is spent compiling gigantic C++ codebases, more power to you for using VIM. CPU load in code compilation hasn't been the bottleneck I ever faced and I think this applies to most folks. Plus CLion doesn't just arbitrarily start consuming CPU, if it is not doing indexing(and VIM simply can't do the kind of indexing that CLion does), it doesn't consume much CPU. In the idle state, it consumes very little CPU. Then again, some seconds of CPU might be a good tradeoff against productivity in some scenarios.
    - adrianN 6y ago
      I don't spend the majority of my time compiling (a decent chunk though!), but then again, I also don't spend a large part of my time doing the complex refactorings that an IDE would make much easier. I don't think either vim or clion has dramatic advantages over the other.
  - erikbye 6y ago
    The last time I used a Jetbrains product, it took several seconds to simply open the IDEs Settings page. I'm not kidding, several seconds. Sometimes it would also completely freeze up for seconds when Java's GC kicked in. Great experience...
- Grue3 6y ago
  Lol, tell that to my coworkers who take days trying to fix some problem with their Pycharm, while I just keep coding on my trusty Emacs.
santamarias 6y ago
Hybris & Curiosity => Vim => Emacs => Evil Emacs => Spacemacs => Evil Emacs => Org-mode videos on Youtube => Silent Despair => VS Code + Vim keys (w/o Ctrl*) => Peace of mind.
h91wka 6y ago
In what sad, warped alternative reality did this happen?
fredmorcos 6y ago
I worked for a company where the founder thought everybody should use the same tools (meaning the tools he used: OpenSuse, KDE, VSCode, etc...) so that we can help each other and, like you propose, we wouldn't have to fiddle with anything since he would provide configuration for everything. I've had plenty of problems running this garbage, and everytime he wouldn't help and would just say something along the lines of "what did you do? I've never ever had a problem with it". If you think VSCode or any other tool doesn't need fiddling then you haven't pushed that tool beyond the basics. Use what you know and what you're comfortable with. Sometimes VSCode is lacking at things where Emacs shines and vice-versa.
- scooble 6y ago
  These kinds of discussions tend to overlook that using tools that you enjoy using and are familiar with can be a virtue in itself. I doubt that any of the editors/IDEs under discussion make it impossible to do the work we need to do. And I'm willing to bet that forcing an employee to use a tool they don't enjoy will have a much higher impact on their productivity than any marginal differences in functionality between that tool and their preferred option. I use vim because I enjoy using it and it is sufficient for the tasks I need to do. The idea that this reason is not enough and I need to justify my choice by proving it is a more productive option than all other editors/ides strikes me as deeply odd.
- arvinsim 6y ago
  > I worked for a company where the founder thought everybody should use the same tools (meaning the tools he used: OpenSuse, KDE, VSCode, etc...) so that we can help each other and, like you propose, we wouldn't have to fiddle with anything since he would provide configuration for everything. I will ask this question in my next job interview. This is a red flag for me. I wouldn't want to work in a company that forces the developers onto a specific editor/IDE.
diffeomorphism 6y ago
> The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone. The fact that you don't have one for VS Code shows that any modifications to make it better are too difficult and that you just have to make do with how it comes out of the box.
- 101404 6y ago
  In reality, it is very easy in vscode. The difference is, that in vscode it is a easily readable json. Much, much! better than in both emacs and vim. Edit: downvoting doesn't change reality
  - diffeomorphism 6y ago
    So which is it: VS Code is maximally unsuited for everyone or the previous argument was nonsense?
    - 101404 6y ago
      Your comment doesn't make sense. What are you trying to say?
      - diffeomorphism 6y ago
        ELI5: - Article: Non-trivial config is bad. Hence emacs is bad but VS is good. - My post: Not having non-trivial config is bad. - Your post: VS has non-trivial config and even more/better than emacs. - My reply: So do you agree with article and now VS is "maximally unsuitable for everyone" (the quote for "bad" from the article)? Or do you disagree with article?
        101404 6y ago
        You didn't read the comments correctly, hence your confused reply.
  - 6y ago
z3phyr 6y ago
I use emacs, and I do not have much problem with configs. I mostly work vanilla, and all the configs I needed were done when I was starting out with emacs. Now emacs is ubiquitous to me and the last time I visited my init file was last year actually!
arexxbifs 6y ago
VS Code has its pros and I use it daily, but I have to spend quite a bit of time configuring a fresh install of it. Probably not as much as I would Emacs, had I used it, but it's not insignificant. And that includes changing the theme.
- williamdclt 6y ago
  There's a sync extension. I think it's making it into the core functionalities.
  - arexxbifs 6y ago
    Good news!
indymike 6y ago
This is being replaced by: 1. New employee is added to cloud access management. 2. New employe logs into AWS Code, Apache CHE or Githubs new web editor. 3. ??? 4. Beer.
neutronicus 6y ago
This is exactly what the IDE people say about VSCode
erikbye 6y ago
> and this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing. This is like saying we should just throw out every helpful thing that helps us write code faster/better. On one hand you argue for VSCode's OOTB experience (extensions which are MODES), and on the other hand you're saying modes doesn't matter when it comes to Emacs. Why not rip out every helpful thing from VSCode, too, then? No refactoring, no completion, because that doesn't save time? Why even learn to type with more than 1 digit?
greenshackle2 6y ago
This was kind of my experience with vim. I like vim's UI but I work on multiple languages so I need a bunch of plugins and tweaks. I finally gave up on it after a plugin update broke it one too many times and I didn't have the heart to debug the wall of errors it barfed up on startup. I switched to Sublime Text with the Vintage plugin (vim keybindings). Package Control is just so painless to use, and in a few years of use I have to yet to have a plugin break anything.
jonnypotty 6y ago
Trying vscode even in comparison to eclipse made me want to kill myself especially when everyone was saying how great it was. Did exactly what you're describing here. 4 hours of fucking about to achieve nothing.
lunias 6y ago
In a few years, VS Code has achieved better out of the box functionality for [people who don't already know / don't want to learn emacs]. Emacs has a challenging learning curve. I don't think it's realistic to insist new employees use Emacs that haven't already chosen the path for themselves. Real scenario (for someone experienced with and asking to use Emacs): 1. Install Emacs 2. Clone config 3. Work

MarcScott 6y ago

> The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone. The fact that I have a non trivial .emacs file ensures that when I switch machines, I only have to transfer a single file to enable an identical development environment. I can't speak for VS Code, as I've only ever played with it a couple of times, but can I do the same thing there? I don't want to spend hours finding and installing packages to recreate my dev environment, or play with various GUI settings to recreate my preferred theme. With Emacs, I can `package-install-selected-packages` on a new build, and I'm using an exact clone of my usual config.

brlewis 6y ago
> The fact that I have a non trivial .emacs file ensures that when I switch machines, I only have to transfer a single file to enable an identical development environment. I just want to pull this particular sentence out for emphasis in case anyone is reading the "New employee 2 workflow at company X" comment and thinking that it's even the least bit true.
- danieldk 6y ago
  For me it is home-manager switch and I don't only have my full Emacs configuration, but a full development environment with Rust, Go, etc. Though you could probably also configure VS Code that way.
  - sterlind 6y ago
    Nix support for VS Code is pretty painful. Only a tiny subset of extensions are listed in nixpkgs, and those are often broken (e.g. Python) when old binary versions are pulled from the CDN. If somebody could make a VS code extension that seamlessly pulls down other extensions by altering the nix config, it'd be perfect.
    - danieldk 6y ago
      Thanks for the information! I haven't tried configuring VS Code through Nix yet. I guess I'll wait a while before doing another attempt.
Osiris 6y ago
I'm not familiar with emacs. Does that mean that you don't need to install any supporting software like indexers, linters, syntax highlighters, etc? Does the emacs file contain all that or tell it how to download all the plugins? If you could just copy one file and get all that, that's pretty cool.
- ekko911 6y ago

willberman 6y ago

Workflow on midsized personal project with editor that I'm comfortable with and have customized over the majority of time I've been programming: work. Look, obviously VS Code has emacs beat in the vast majority usability features. Emacs works for a lot of what I work on. For the things it doesn't work for, I use the tool that works better. I have lots of personal qualms with emacs, but to declare it "maximally unsuitable," is overkill.

redis_mlc 6y ago

I use vi. Never had to install anything across thousands of servers.

dietr1ch 6y ago
That's true, but I'd rather use tramp-mode and keep my setup instead of sacrificing it for the sake of consistency across servers. It won't really be consistent anyways, you'll get some plugins here and there I guess.

3fe9a03ccd14ca5 6y ago

Better yet, install vscode, then install either the vim or emacs plugin. The best of all worlds!

ahupp 6y ago
Kind of. I haven't found a VSCode emacs package that does more than superficially handle emacs keybindings; there's always mismatches that trip me up.
chipotle_coyote 6y ago
Eh. Sort of. Like the other person who replied about the Emacs plugin, I find myself running into issues with the Vim plugin -- usually not the keybindings as much as the ex-style commands. For instance, ":20,27m." will move a block of text in Vi/Vim to under the current location; that doesn't work in VSCode Vim. Worse for me personally, I've gotten really used to the ":find" command being the (rough) equivalent of a fuzzy file search: ":find App.php" will find that file no matter where it is in the current project, but again, not a VSCode Vim command. It's a good emulation, but it's not a great emulation.
- jgalentine007 6y ago
  Ctrl+p will let you search nicely for files in vscode. At least the VI integration is better than the extension I use with Visual Studio.
  - chipotle_coyote 6y ago
    Oh, yeah, I do use that (well, Cmd-P over here in Mac-world). It's just when I get into Vim mode I type ":find" reflexively and I get disappointed for a moment. :) (Ironically, there's a Vim plugin called CtrlP to do the same thing that I never use because I find it confusing and weird compared to everybody else's implementation of the same idea...)

quadrifoliate 6y ago

This view is obviously biased against Emacs, but I don't disagree completely with the premise. As an Emacs user, being "immediately productive" (whatever that means) is not your topmost priority. You mold your Emacs to a workflow unique to you, notice things you are doing often, add elisp functions to change it to make those things easier, and carry them with you from job to job. As your job evolves and changes, you maintain and grow your Emacs files over decades, and borrow from someone else's workflows. In a a much better way than I can put it, Emacs users are like Igors [1]. You can be a productive individual contributor writing Clojure inside Emacs, or a productive CEO managing todos in org-mode [2] – it works equally well once you figure out how you mold your editor. VSCode "plugins" and Emacs packages are just not the same, with Emacs you can be far more flexible about changing the behavior of the plugin in specific modes or activating things given specific conditions. You revel in the effectiveness of using one of the last remaining vestiges of the Lisp Machines of Old Valyria. Meanwhile company X will just slot in cookie cutter developer 1 and ask them to use VSCode because they are eager to get the developer to be "productive" on Day 1 for some reason. You would think that giving an employee a week for setting up and tuning their workflow should be totally normal if you want them be there for several years and be maximally productive over time. More power to them I guess. [1] https://chrisdone.com/posts/emacs-users-are-like-igor/ https://chrisdone.com/posts/emacs-users-are-like-igor/ [2] https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html

TheSpiceIsLife 6y ago
I’m not a programmer, just a tradesman who’s worn a few different hats over the eons, but I’ve noticed something as I’ve gotten older and lazier: I am equally as unproductive regardless of my setup. My productivity has way more to do with all the other factors at play than it does the fine-tuning of my setup.
- michaelmrose 6y ago
  In order to be more productive of 10s of thousands of hours one only needs to be slightly more productive to justify spending a handful of hours. 1% per 10k hours is worth 100 hours.

bachmeier 6y ago

> In a few years, VS Code has achieved better out of the box functionality for working professionals than emacs has in 40 years. That's not as clever as you seem to think it is. Emacs was created for a different world. Of course new tools have an easier time in the world for which they were created and with no legacy baggage.

ipv6ipv4 6y ago
You’re essentially saying that emacs has been stagnant and hasn’t changed with the world around it. Yes, absolutely. That’s why it’s not a surprise it is losing popularity. Clunkiness and baggage is not a foregone conclusion for software. Software can keep up with a changing world, discarding old baggage along the way. In the end it doesn’t matter. Whether it is old software that adapts and changes or new software that supplants stagnant, clunky software. The world uses whatever is easiest and most relevant and goes on.

jjoonathan 6y ago

That, and while emacs has a reputation as being the ur-editor from which all text editing innovation stems, the reality is quite the opposite. It's stagnant and hasn't been the center of text editing innovation for at least the last decade, and probably quite a bit longer before that. It was a particularly bad string of basic package incompatibilities that woke me from my emacs evangelist phase, but it was the realization that emacs was downstream from TextMate on several non-GUI-centric features that made me realize the entire "platform" value prop was bunk. While emacs might be excused for missing tectonic shifts (e.g. away from CLI and towards GUI), entirely text-centric features like multiple arbitrary simultaneous caret, Smith Waterman quick file/action search, powerful template substitution, parsing-based syntax highlighting, navigation, and refactor tools all developed and matured outside of emacs and then slowly and painfully found their way back in, not the other way around. Emacs was supposed to be a fertile platform for text editing innovation, but history didn't work out that way, even if you ignore the trend towards GUI innovation, which you shouldn't.

michaelmrose 6y ago
Emacs is a gui app. You can have if you like a tool bar. A menu-bar, tabs, split windows. If you want something slightly more like a traditional gui emacs application framework enables bidirectional communication with QT applications running in emacs frames. Personally I use it to render HTML mail inside emacs with what amounts to embedded chrome.
- pjmlp 6y ago
  As far as I am aware it still isn't as GUI oriented as ZWEI used to be.
  - michaelmrose 6y ago
    What gui elements do you find lacking I'm not familiar with ZWEI
    - pjmlp 6y ago

meddlepal 6y ago

I would expect an experienced emacs user to have a config already that more or less "works". Was this a junior developer that just decided to start using emacs one day? I'm not an emacs person myself, but every emacs person I have ever met already has it setup and customized and just brings their config. A new dev starting with emacs on a new job... just sounds like a bad recipe and misunderstood priorities.

jjoonathan 6y ago
> already has it setup and customized and just brings their config You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file. I've spent less total time configuring TextMate, Sublime, IntelliJ, Atom, Jupyter, VS Code, and PyCharm than I spent back in the day trying to learn emacs lisp and get the emacs plugins for ObjC syntax highlighting and fuzzy filename matching to play nicely with each other. Meanwhile, each of those GUI editors brought considerably more impactful unique day-to-day functionality to the table than emacs ever did.
- Scarbutt 6y ago
  You had to spend time learn a new set of keybindings for each one though, for editing and interacting with the interface.
  - jjoonathan 6y ago
    Not really. The most common keybindings of GUI text editing have largely converged, and those that haven't collectively account for similar total complexity to, say, basic file/buffer management and movement in emacs. Yes, the life of an editor nomad sometimes involves hitting the wrong key to build or occasionally forgetting which modifiers trigger block select, but those adjustment pains are typically overshadowed by the joys of high-priority platform integration that works straight out of the box, and they're downright tiny in comparison to the pain I used to experience getting half-assed platform support up and limping in emacs.
- josteink 6y ago

indogooner 6y ago

I don't contest that VSCode has achieved better out of the box functionality than emacs but it still needs a lot of configuration. My experience is only with C++ extension where intellisense update just goes on indefinitely. Navigation to a function takes ages. Then I exclude some source directories and restart VSCode. And not to talk of resource hog that it is. When it works it is pretty good and that's why I stick to it. May be other language extensions are better. I would say it is the best editor with the resource usage of a full blown IDE.

_bxg1 6y ago
The experience varies widely by language. TypeScript support is top-notch. Clojure support used to be bad and then got good. Rust support has been bad for a long time but the nascent rust-analyzer project makes it fantastic. Python support is decent but only if you get an optional, poorly-advertised extension on top of the default one. C# support is quite solid. Etc. Only a couple of languages get first-party support from MS. The rest depend on their respective communities to build extensions. VSCode has a great plugin architecture, but it's entirely possible to write a bad plugin for it, especially if it's simply not a popular enough editor in that community yet. Still, none of the above required dependency-juggling or stepped on each others' toes. Only a couple cases required a configuration step to get them fully working. My worst VSCode setup experiences haven't wasted as much time as the Emacs golden path did.
- mbeex 6y ago
  > Python support is decent but only if you get an optional, poorly-advertised extension on top of the default one. Which one?
  - _bxg1 6y ago
    This one: https://marketplace.visualstudio.com/items?itemName=ms-pyright.pyright https://marketplace.visualstudio.com/items?itemName=ms-pyrig... I only found out about it by asking here on HN

tiew9Vii 6y ago

Wouldn't class myself as an experienced Emacs user. Used it for 5 or so years. Learnt enough to get by and have my own config that works for me. Not got as far as writing my own elsip functions. When I set up a new computer 1) Check out my emacs config from git 2) Start emacs 3) Wait for emacs to automatically download all the packages declared in my config using use-package. If you never used Emacs before fair enough it's harder than VS Code. VS Code does let you get going knowing less by clicking buttons. It's the same as comparing any CLI app with a full blown point and click GUI. My take on getting a new user setup... "use what ever IDE you are comfortable with, I do not care. This is the IDE I use, here is how I have it set up if you want to use it also. Person C uses this IDE instead if you want to use that, ask them for there setup. No one here uses your IDE? You are on your own setting it up but can help with any project specific questions you need to know to get your IDE of choice running". As far as code searching goes I find myself often outside of any IDE using the silver searcher (ag) so use emacs projectile for the exact same functionality but within emacs. Sometimes the only feature I miss from a full blown IDE like InteliJ is find usages.

deleted 6y ago
[deleted]

danieldk 6y ago

I am not a passionate Emacs user and I strongly dislike the weird bugs that rear their heads sometimes. I was always a vim user, but switched to Emacs because it has better support for completion, etc. while having nearly perfect vi emulation. I would even go as far as saying that Evil is vi implemented in Emacs Lisp. I try VS Code every now and then, but I always stop because of two reasons: incomplete vi(m) emulation and the latency feels really bad compared to Emacs/vi. Would like to switch otherwise, but non-leaky vi support and good latency are essentials. Edit, forgot to add: something as good and keyboard-driven as magit.

thayne 6y ago
> but switched to Emacs because it has better support for completion, etc. while having nearly perfect vi emulation I switched to emacs for similar reasons (plus the fact that it supported embedded repls that actually worked). But eventually switched to neovim, because it could do things like completion and repls. vim 8 can now as well. > I try VS Code every now and then, but I always stop because of two reasons: incomplete vi(m) emulation and the latency feels really bad compared to Emacs/vi. > Would like to switch otherwise, but non-leaky vi support and good latency are essentials. Same. Also start-up time. I love typing `v <filename>` in a terminal and instantly getting an editor. Lower memory usage is also nice.
dmarchand90 6y ago
How long did it take you to switch? I tried spacemacs for a few months but got tired after I was always accidentally breaking things
- danieldk 6y ago
  Not too long. I also began using Emacs with spacemacs, but it was buggy and slow. Then I just started with a completely pristine Emacs configuration and just added through use-package: - evil for vi emulation - general/which-key so I could define spacemacs-like bindings that start with SPC. - ivy for quick search of buffers, files, etc Then I added things on a by-need basis. I would say that the most important additions were magit for Git, projectile for quickly switching between project files, and some Rust packages. This is now my emacs configuration: https://github.com/danieldk/nix-home/blob/master/cfg/emacs.nix https://github.com/danieldk/nix-home/blob/master/cfg/emacs.n... Rust configuration: https://github.com/danieldk/nix-home/blob/master/cfg/rust.nix https://github.com/danieldk/nix-home/blob/master/cfg/rust.ni... (Sorry for posting Nix files, but it's pretty close to what it would look like in a regular init.el.)

michaelmrose 6y ago

New employee 3 workflow at company X: 1. Install Emacs 2. Sync existing config via git 3. Work New employee 4 workflow at company X: 1. Install Emacs 2. Spend 2 hours learning default Emacs 3. Work New employee 5 workflow at company X: 1. Install Emacs 2. Spend 1 - 2 hours learning default Emacs 3. Spend 2 - 4 hours googling interesting Emacs packages, in each case going to their GitHub repo to read the directions, adding a use package form to your config with the settings that seem best from reading the directions and testing it to see if you like it until you have a useful set of functionality 4. Work You can probably spend plenty of additional time tweaking emacs to be everything from your mail client, your music player, your IRC client, insert task here but if you do this in the time you would be watching Netflix instead of the time you are supposed to be working you probably wont have trouble getting your work done. I literally have no idea what you are talking about insofar as TTY settings, themes, indexing bugs highlighting bugs, or constant workarounds. I installed Emacs the graphical application, opted to spend 2 hours reading a book wherein I learned how to use emacs and picked a theme by searching for the string emacs theme and picking one that looked cool. I ran package-install typed the name of the theme, hit enter and evaluated (load-theme 'theme) in my config. I have no idea why you would be running Emacs in a terminal in the first place.

yewenjie 6y ago
I second this so much. Emacs configs like Spacemacs, Doom, or M-Emacs provide an excellent out-of-the box experience.
- dmarchand90 6y ago
  Disclaimer: mostly vim guy. I agree that Emacs is super powerful for power users, don't agree that it's intuitive or easy for new users. Also I found spacemacs to be pretty brittle when I last tried it a year ago.
  - iimblack 6y ago
    Agreed on Spacemacs. Seems like a lot of stuff I had to switch to the Develop branch for it to work right. Supposedly the next release is coming out soon which will fix a lot. I’ve since switched to Doom which I like better anyways though.

fossuser 6y ago

I largely agree with this and I wasted a lot of time in school and earlier in my career on these tools because of how often they’re positively talked about in online communities and positively compared to what seem to be otherwise obviously better tools.

xf1cf 6y ago

I actually like this viewpoint because I have done both and generally I disagree with you. But here's my take. I use VSCode often because its "just easier". The extensions are at best (in my opinion) ok approximations to what I can get with emacs. Especially for a language I'm inexperienced with in emacs VSCode is a nice integration layer while I adjust my configuration. Emacs (and to that point vim) is vastly superior to any offering VSCode has. The problem is you have to be productive. Many nights I labored over my emacs configuration to tailor to my job. I've done this for the last 10 years. It takes effort. To that, you have a point. VSCode is effortless. On that, VScode doesnt feel like anything to me except a bridge layer. Emacs and vim offer a vastly better experience (without the git politics!) if you're willing to spend the time customizing it. But that is the difference - are you willing to spend the time? Many developers are not and that's fine. But for a marginal additional investment you can have something better. Something to think about at least. I can install my Emacs configuration in 30 seconds from my github.

random_cynic 6y ago
Everywhere in this thread I see vague and generic statements like this. Do you have concrete examples of specific things in your 10 year old Emacs configuration you "labored over" that can do something VSCode (and its extensions) can't and which makes Emacs "vastly superior"? If so please share, otherwise don't bother. We have already heard all this vague nonsense for years.
- nvarsj 6y ago
  There are loads of examples in the comments here. Have you read them?

holri 6y ago

In the long run (now 20 years) the switch from Microsoft products to Emacs was a giant net win for me. Since I am no longer at the mercy of volatile business, but enjoy stability und functionality at its best. The initial investment in configuration and learning had enormous dividends. Don think short term.

pjmlp 6y ago

Younger self used to Borland and Microsoft IDEs, when going into Xenix, DG/UX and frieds, "where is my IDE?!?". The TA on my 2nd year university pissed off with everyone of us using Emacs as Notepad, instead of spending one hour talking about Pascal, decided to teach us how to use Emacs properly. I was one of the few that kept with it, although I ended up moving into XEmacs, which had a much better experience. The large majority of my fellow students decided to adopt Joe, JED instead. After university and after a couple of years on the job market eventually all of us moved back into IDE land. So not sure what Emacs can really do to still cater to younger generations, if even for us it was seen as something to endure on university computer systems, back when options were quite limited.

robotwizard 6y ago

What are you guys talking about... 1. nano code.txt 2. ??? 3. Profit!

_pmf_ 6y ago

> In a few years, VS Code has achieved better out of the box functionality How many years will it take until stock vscode stops lagging randomly every 10 key strokes?

sterlind 6y ago
laughs in visual studio Remember that you can open the dev tools and profile VS Code itself. I've debugged a few weird issues that way.

m463 6y ago

I think the productivity graphs look like: | 22 | 22 | 1111121111 | 1 22 |1 22 |122 -------------

zelly 6y ago

> this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing Exactly, the bottleneck is thinking, so why do I need the slick point-and-click tools in an IDE?

enitihas 6y ago

Or even better New employee workflow at company Z 1. Install the Jetbtains toolbox 2. Have IDEs for several languages with consistent features and semantics. 3. Minimal to no configuration needed 4. Profit.

adrianN 6y ago
I can use 40% more cores when compiling than my CLion using colleagues because vim doesn't need 10GB of RAM. I tried using CLion, but it was just too slow. Maybe I was holding it wrong.
- enitihas 6y ago
  Off-course, if majority of your time is spent compiling gigantic C++ codebases, more power to you for using VIM. CPU load in code compilation hasn't been the bottleneck I ever faced and I think this applies to most folks. Plus CLion doesn't just arbitrarily start consuming CPU, if it is not doing indexing(and VIM simply can't do the kind of indexing that CLion does), it doesn't consume much CPU. In the idle state, it consumes very little CPU. Then again, some seconds of CPU might be a good tradeoff against productivity in some scenarios.
  - adrianN 6y ago
    I don't spend the majority of my time compiling (a decent chunk though!), but then again, I also don't spend a large part of my time doing the complex refactorings that an IDE would make much easier. I don't think either vim or clion has dramatic advantages over the other.
- erikbye 6y ago
  The last time I used a Jetbrains product, it took several seconds to simply open the IDEs Settings page. I'm not kidding, several seconds. Sometimes it would also completely freeze up for seconds when Java's GC kicked in. Great experience...
Grue3 6y ago
Lol, tell that to my coworkers who take days trying to fix some problem with their Pycharm, while I just keep coding on my trusty Emacs.

santamarias 6y ago

Hybris & Curiosity => Vim => Emacs => Evil Emacs => Spacemacs => Evil Emacs => Org-mode videos on Youtube => Silent Despair => VS Code + Vim keys (w/o Ctrl*) => Peace of mind.

h91wka 6y ago

In what sad, warped alternative reality did this happen?

fredmorcos 6y ago

I worked for a company where the founder thought everybody should use the same tools (meaning the tools he used: OpenSuse, KDE, VSCode, etc...) so that we can help each other and, like you propose, we wouldn't have to fiddle with anything since he would provide configuration for everything. I've had plenty of problems running this garbage, and everytime he wouldn't help and would just say something along the lines of "what did you do? I've never ever had a problem with it". If you think VSCode or any other tool doesn't need fiddling then you haven't pushed that tool beyond the basics. Use what you know and what you're comfortable with. Sometimes VSCode is lacking at things where Emacs shines and vice-versa.

scooble 6y ago
These kinds of discussions tend to overlook that using tools that you enjoy using and are familiar with can be a virtue in itself. I doubt that any of the editors/IDEs under discussion make it impossible to do the work we need to do. And I'm willing to bet that forcing an employee to use a tool they don't enjoy will have a much higher impact on their productivity than any marginal differences in functionality between that tool and their preferred option. I use vim because I enjoy using it and it is sufficient for the tasks I need to do. The idea that this reason is not enough and I need to justify my choice by proving it is a more productive option than all other editors/ides strikes me as deeply odd.
arvinsim 6y ago
> I worked for a company where the founder thought everybody should use the same tools (meaning the tools he used: OpenSuse, KDE, VSCode, etc...) so that we can help each other and, like you propose, we wouldn't have to fiddle with anything since he would provide configuration for everything. I will ask this question in my next job interview. This is a red flag for me. I wouldn't want to work in a company that forces the developers onto a specific editor/IDE.

diffeomorphism 6y ago

> The fact that everyone has to have a non-empty, non trivial .emacs file means it is maximally unsuitable - for everyone. The fact that you don't have one for VS Code shows that any modifications to make it better are too difficult and that you just have to make do with how it comes out of the box.

101404 6y ago
In reality, it is very easy in vscode. The difference is, that in vscode it is a easily readable json. Much, much! better than in both emacs and vim. Edit: downvoting doesn't change reality
- diffeomorphism 6y ago
  So which is it: VS Code is maximally unsuited for everyone or the previous argument was nonsense?
  - 101404 6y ago
    Your comment doesn't make sense. What are you trying to say?
    - diffeomorphism 6y ago
      ELI5: - Article: Non-trivial config is bad. Hence emacs is bad but VS is good. - My post: Not having non-trivial config is bad. - Your post: VS has non-trivial config and even more/better than emacs. - My reply: So do you agree with article and now VS is "maximally unsuitable for everyone" (the quote for "bad" from the article)? Or do you disagree with article?
      - 101404 6y ago
        You didn't read the comments correctly, hence your confused reply.
- 6y ago

z3phyr 6y ago

I use emacs, and I do not have much problem with configs. I mostly work vanilla, and all the configs I needed were done when I was starting out with emacs. Now emacs is ubiquitous to me and the last time I visited my init file was last year actually!

arexxbifs 6y ago

VS Code has its pros and I use it daily, but I have to spend quite a bit of time configuring a fresh install of it. Probably not as much as I would Emacs, had I used it, but it's not insignificant. And that includes changing the theme.

williamdclt 6y ago
There's a sync extension. I think it's making it into the core functionalities.
- arexxbifs 6y ago
  Good news!

indymike 6y ago

This is being replaced by: 1. New employee is added to cloud access management. 2. New employe logs into AWS Code, Apache CHE or Githubs new web editor. 3. ??? 4. Beer.

neutronicus 6y ago

This is exactly what the IDE people say about VSCode

erikbye 6y ago

> and this mode or that mode don’t matter because the slowest part of the creative process is the creativity and not your typing. This is like saying we should just throw out every helpful thing that helps us write code faster/better. On one hand you argue for VSCode's OOTB experience (extensions which are MODES), and on the other hand you're saying modes doesn't matter when it comes to Emacs. Why not rip out every helpful thing from VSCode, too, then? No refactoring, no completion, because that doesn't save time? Why even learn to type with more than 1 digit?

greenshackle2 6y ago

This was kind of my experience with vim. I like vim's UI but I work on multiple languages so I need a bunch of plugins and tweaks. I finally gave up on it after a plugin update broke it one too many times and I didn't have the heart to debug the wall of errors it barfed up on startup. I switched to Sublime Text with the Vintage plugin (vim keybindings). Package Control is just so painless to use, and in a few years of use I have to yet to have a plugin break anything.

jonnypotty 6y ago

Trying vscode even in comparison to eclipse made me want to kill myself especially when everyone was saying how great it was. Did exactly what you're describing here. 4 hours of fucking about to achieve nothing.

lunias 6y ago

In a few years, VS Code has achieved better out of the box functionality for [people who don't already know / don't want to learn emacs]. Emacs has a challenging learning curve. I don't think it's realistic to insist new employees use Emacs that haven't already chosen the path for themselves. Real scenario (for someone experienced with and asking to use Emacs): 1. Install Emacs 2. Clone config 3. Work