Hacker News Reader

Hacker News

Comment by ipv6ipv4 | Hacker News Reader

Parent Full thread

ipv6ipv4

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.

View on HN

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.

Don't forget:

New employee 6 workflow at company X:

1. Install Spacemacs, don't bother fiddling with the config

2. Spend a few hours working through the tutorial or reviewing the excellent docs [1]

3. Work. Become a better developer [2].

[1]:https://www.spacemacs.org/doc/DOCUMENTATION.html

[2]:https://blog.osteele.com/2004/11/ides

1. Install Spacemacs.

2. Observe a flurry of errors every time you start emacs. Ignore and hope it works because no idea how to fix any of it.

3. Find, among a million others, the command that seems to do what exactly what you want. Command gives an error. Dunno how to debug.

4. Watch emacs features that should work ootb not work because spacemacs or evil or one of the three bazillion packages did something that broke it. Dunno how to debug.

5. Complain on HN, get told you need to be using the master/develop version of packages because upstream devs don't care about maintaining stable releases.

6. Use unstable packages. Observe new errors whenever you update or do anything. Hope it doesn't break more than it's already broken.

This.

While Spacemacs is an admirable effort, I think it misses the point: Emacs is an editor for power users from another era, so it requires huge effort by the user to become truly productive by todays standards. Trying to create layers upon layers of "friendlines" and eye candy is not going to solve the complexity.

I've always said that it's better to grasp Emacs with a vanilla config or a small starter kit and see if you can make it grow step by step in a journey that takes years.

vim is a similar rabbit hole, maybe less deep.

The real question is: can VS Code make you productive enough in less time?

Pretty much, yeah, from what I've seen. Against the shockingly low ambient baseline of "editors that aren't Vim or Emacs", VS Code's highly usable OOTB experience and broad extension ecosystem are enough of an improvement to constitute a real win despite being so poor by comparison with a thoroughly evolved configuration of either of the Two True Editors.

I stick with Emacs because, now having invested more than a decade in learning to get the most out of it, I can do a lot of things in seconds that take VS Code users minutes or hours. But the converse is also true, and I think will only become more so. Especially in the realm of remote collaboration and mentorship, which has never been more important than it is today, VS Code does things that Emacs simply can't, and almost certainly never will.

That's fine, of course. That different tools should specialize in different things is perfectly reasonable, and I don't have the kind of emotional attachment to Emacs that would give me cause to be upset with its dwindling user share or its lack of broad appeal. It serves me very well, but it's not something I advocate, although of course I mentor those who take an interest.

I am looking at picking up VS Code, with suitably Emacs-esque keybindings, for the mentoring-in-programming aspect of my role. That's where pretty much everyone else is, or is going. And in that context, its less fluent and less extensible user interface is probably a boon, once I get over being frustrated by it. In the context of teaching someone less experienced, acting with the speed of thought is really best avoided; if you don't explain why you're doing what you're doing, or offer the chance for questions and discussion, essentially the entire point is lost.

> I can do a lot of things in seconds that take VS Code users minutes or hours.

Out of curiosity could you provide some examples of some of these?

"Out of curiosity" = "I'm going to nitpick this to hell and back"

Ahh, that's not what I was going for. I'm actually just curious. I'm willing to give emacs a try, but it just seems like it has kind of a steep learning curve, so want some strong reasons to know if it's worthwhile. This was the best I could find googling: https://www.reddit.com/r/emacs/comments/8h1cxa/any_long_time...

I mean, a lot of it is just the kind of complex one-off text transformations that would normally require a throwaway script or program to express. (They do in Emacs too, but you can write it as inline Lisp forms in the replacement side of a PCRE find-and-replace, and not deal with any boilerplate.) Refactors and stuff like that all happen through LSP providers, just like in VS Code.

If you're looking for a strong reason to think Emacs is worthwhile as a totally new user, I'd point instead to Magit, an extremely powerful and comfortable git porcelain, and Org-mode, which is simply the most powerful and flexible single-user notetaking/outlining/live code notebook tool yet created. Those are the two Emacs features I see most often mentioned as the subject of sentences like "I don't use Emacs for anything else, but I do use it for X because nothing else comes close".

That said, as I mentioned above, I'm not really here to evangelize Emacs. It definitely does have a steep learning curve, enough so that unless you see a clear killer feature (in my case, TRAMP's transparent remote file editing, since I edited remote files a lot in those days), it's not likely to be worth the trouble.

This. After having fiddled around with Emacs over the weekend, having tried out Spacemacs and Doom and working through some tutorials, I concluded that I definitely won't replace VSCode with Emacs for coding any time soon. As a Git & PIM-Tool, it seems to be useful though.

Come now, that’s a bit harsh... he didn’t nitpick at all, just asked for some pointers!

> I've always said that it's better to grasp Emacs with a vanilla config or a small starter kit and see if you can make it grow step by step in a journey that takes years.

I moved to Spacemacs becaues I wanted to write clojure without maintaining my own Clojure IDE in vim+tmux (this was around 2014, maybe 2015). I was productive in Spacemacs in around 10 minutes. I went from never using Emacs to fixing bugs and writing extensions in Emacs in less than two weeks because Spacemacs pervasively uses which-key to provide discoverability and had vim-style shortcuts I could use for real work (rather than learning a new set of keybindings). The groupings of things into layers makes studying what ecosystem packages provide what functionality much easier than blindly googling "how to do X in emacs" and getting 3000 "unique" (read: half-baked if you're lucky) solutions.

This idea that you should suffer for hours/days/weeks building your init.el from scratch while adapting to terminology, keybindings, and a lack of familiarity with the ecosystem is absolutely insane. If you can use vi, you're better off with Spacemacs.

As a counterexample to that somewhat... I initially tried learning emacs with spacemacs, and the amount of customization in spacemacs’s config made it difficult for me to compare it to much of the emacs documentation out there. Whatever documentation spacemacs had at the time was confusing enough to me that it wasn’t quite enough.

I later ended up starting with a stock config, and I probably could pick up spacemacs now if I wanted to, but at this point I don’t feel the need.

> vim is a similar rabbit hole, maybe less deep.

Vim was for a long time and still pretty much is mostly a text editor. It is light, work well with large files and is installed on most Unix machines. I don't think trying to turn it into an IDE makes much sense but if you want to develop with it, installing a language server client takes two minutes and you don't need much more.

As a text editor, Vim is really nice. Modal editing can be very pleasant if it clicks with you.

If you install Spacemacs from develop branch, don't change the defaults and enable just the git plugin, it's pretty much always going to work just fine unless elpa is down or something.

I install Spacemacs in every machine for the sole reason of using Magit with vim bindings. It's so far beyond all other git clients it's even hard to explain to others sometimes. If Magit existed as a native standalone app, I would be happy to pay €50-100 for it, right away. But, but... :/

You can always donate the same funds to the development of magit.

I cannot recommend Spacemacs enough. I was a pretty dedicated Vim user for years but grew tired of the brittle tooling and subpar extensibility and decided to give Emacs a try. My first experience with Emacs was dreadful - the default keybinds were counter-intuitive and hard to use (no, I should not have to remap my control key to caps lock just to avoid carpal tunnel), basic features were absent yet included was a web browser, mail client, etc.

A month or two later I gave Spacemacs a try, and I've been using it ever since. Not only does it have sane defaults like evil-mode for Vim emulation, but a lot of terrific packages like Magit and Org-mode are builtin. I also use the Spacemacs docs as my first resort when I want to install something new or fiddle with settings, rather than the subpar GNU Emacs documentation which never quite tells me the exact information I'm looking for.

+1 I was really attached to my vim config but decided to try out SpaceVim [1] (the vim version of SpaceMacs) after a stint using VSCode and after reinstalling my OS (before pulling in my usual vim .git) and I was surprised it was almost the same as what I spent years perfecting but with a far better and logical key mapping scheme that fit neatly across plugins + a nice programming language extension/layer scheme.

It's the oh-my-zsh of vim/emacs.

After a year of SpaceVim, when I finally found time, I ended up switching back to my more lightweight and stripped down version of NeoVim but copied the keymapping approach and some of the individual configs. It was a great starting point.

If you're a) new to vim/emacs or b) tired of maintaining your own config for w/e reason, Space[x] is entirely usable in it's default state with good documentation. It also updates often and stays on the cutting edge of various plugins and progression in the community, but with the stability of a larger community.

It defeats a lot of the learning/config curve arguments again vim/emacs.

[1] https://spacevim.org/

Weird. I tried spacevim, via their docker container. First impressions were 100% CPU use after entering:

  int main(

I'll stick to tried and tested vim.

If one needs a docker container to run a text editor, I think that says all that needs to be said about it.

Well, sort of. Something like spacevim requires some dependencies I imaging. Docker is sort of a package manager, so it makes sense to run the 1.1G docker image to see what you're getting into.

Anyway, this way I saw an issue early on that stopped me from going any further, and saved me much time and heart ache.

Sticking to my plain old .vimrc for now.

Sorry, but that's not true anymore. The spacemacs project has kind of gone off the rails and it doesn't seem like they have any idea about what they really want to do.

The next release has been coming for several years and it's not yet there. This means that you can either choose between the master branch and get hopelessly outdated stuff or the development branch which is so chaotic that you better be ready for things to break constantly.

I used spacemacs for years, then I tried doom emacs and it took me all of 15 seconds to realize that I should switch.

While the most practical employee 7 installs Prelude[1]:

1. Install Prelude 2. Work

[1] http://batsov.com/prelude/

I tried spacemacs last month.

It didn't work. So I gave up.

PS: I am on windows.

New employees 4 and 5 are completely fictitious and only exist in your imagination/reality bubble. In the real world no mortal has ever learned how to use Emacs in 2 hours to be able to work effectively. And like the OC said the documentation for extra packages are horrible, full of bugs and may take additional week to understand how to use effectively.

It's a text editor. You can work when you know enough do common textual operations to add remove and modify text, search through existing text, jump around to different files in the project, and run whatever constitutes a build.

More sophisticated ide like features normally constitute reading the documentation for a particular project like cider for clojure.

I have no idea why you consider 4 and 5 fictitious. One can read the entirely of mastering emacs and the cider docs in a reasonable period of time for example.

> You can work when you know enough do common textual operations to add remove and modify text, search through existing text, jump around to different files in the project, and run whatever constitutes a build.

It is one thing to know enough and quite other to be proficient in using them effectively. With the horrible and unintuitive default keybindings it takes even longer to develop muscle memory.

> One can read the entirely of mastering emacs and the cider docs in a reasonable period of time for example.

Yes one can in theory. But again if everybody could become proficient in something just by reading manuals then we could shut down our expensive schools and colleges and any sort of practical training. Also, everyone could then program in `ed` or TECO.

Curious, have you actually met any other person who's not an emacs user in real life, like ever? Here's an experiment, go to any decent software company and ask 5 new hires who've never used Emacs, give them the manual and see how long it takes them to actually do something significant? Then give them VSCode and compare notes.

Did you mean to ask if I'd ever met an Emacs user? I'm pretty sure we both pass people who haven't heard of any text editor or IDE all the time.

I'm not likely to meet many Emacs users regularly as I don't work in tech I'm just interested in it. I've met Emacs and vim users at a clojure meet up but that isn't exactly shocking.

I second this so much. Emacs configs like Spacemacs, Doom, or M-Emacs provide an excellent out-of-the box experience.

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.

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.

You forgot new employee 0:

1. Install Emacs

2. Finds magit

3. Questions reality before swimming in new found joy

Magit is so good that it should be shipped by default into Emacs.

Alas the process of integrating any outside code into Emacs is tangled behind three layers of bulletproof glass.

I'm not against the glass, as it's a good defence against hostile thieves, but it sure kills any desire to merge outside code

magit is clearly a cosmic planet alignment, whatever happens is a choice from the universe I won't question

> if you do this in the time you would be watching Netflix instead of the time you are supposed to be working

And why would I be doing that? Configuring and learning your work tools is part of work, it should be done in work time.

Think they key here is you read a book whilst the prev op just assumed reading random guides on the Internet would be an appropriate way to learn a piece of software for professional use.

> I have no idea why you would be running Emacs in a terminal in the first place.

I don't see an advantage of using it outside of the terminal in the first place to be honest.

That's the good part about vim. Or if it's complicated for you, use nano. Done. Editing of files while you're in the terminal.

And yes vimscript is annoying, but it seems to be simple enough for most of the basic stuff.

Otherwise there are plenty of GUI editors that work fine.

https://blog.aaronbieber.com/2016/12/29/don-t-use-terminal-e...

Accepting the terminal version is accepting an inferior environment with no upside.

Interesting to know. Though calling the terminal only version an "inferior version" to me sounds like they are aware of its caveats.

TRAMP sounds nice but a lot of times I can't have emacs on the other side. And vim with screen/tmux works fine

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/

[2] https://www.fugue.co/blog/2015-11-11-guide-to-emacs.html

> 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.

I've been writing software for ~24 years, and I can understand the need for this in the past.

Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it?

I've found that JetBrains IDEs with a few plugins do 100% of what I want, including some really advanced refactoring and useful GUI integration with CLI hinters/linters. VS Code takes more setup, but it's similar.

The level of customization that emacs supports seems unnecessary to me. Can you talk about a few use cases where emacs is just better than an IDE could be?

> Can you talk about a few use cases where emacs is just better than an IDE could be?

I don't use Emacs at present (Neovim instead), but I find TTY based programs to be genuinely more productive and flexible once you make it past the initial learning curve. Using tmux and ssh to seamlessly float between devices with an ongoing complex editing session immediately comes to mind. I've also used both Eclipse and Visual Studio at different times and distinctly recall what I can only describe as lumbering startup times. Ranger via ssh is often much more straightforward to use (for basic operations and browsing) than trying to click through a bunch of menus and sort out network mounting issues.

Neovim does lack advanced refactoring tools out of the box, and I've never gone looking so I can't comment. I suspect Language Server Protocol may change that in the near future though.

Regarding the possibilities afforded by the sheer level of customization, vim-fugitive comes to mind though I'm sure there are better examples. (https://github.com/tpope/vim-fugitive)

A +1 here for your comment...

I have multiple machines, running Docker, running multiple tux sessions, for different projects. I can’t even begin to think how I’d pick up where I left off when switching between projects if I wasn’t using Vim

You can do one thing in JetBrains: edit code. That's it.

In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs. I write Confluence articles, so I don't have to deal with Confluence's shitty interface. I edit remote files, I edit files via sudo on my machine. I control git. Yes, JetBrains can do git, too. My colleagues sometimes use it. Actually, they use an unholy mix of JetBrains, GitKraken and the command line on Linux, and Tortoise, SourceTree, JetBrains and the command line on Windows. Not different people. Everybody individually! Why? Because they know how to do different things in different tools. Meanwhile, I just use magit. Magit is absolutely fantastic, there is no better git interface, and I've tried many. Even for our backend Kotlin code, which I have to use IntelliJ for, I jump back to Emacs to use git, and edit yaml/graphql/etc files.

I've probably forgotten a couple of things here. And the cool part is that Emacs now supports LSP very well, and LSP is starting to support a lot of languages very well. So I don't even miss IDE features, such as refactoring. Add to that block selection, the best undo mode, actually robust modal editing (evil!) fantastic documentation, great flexibility, keyboard macros (I use them ~2-3 a week, and they're great every time)

… the list goes on. I've been a dev for less time than you have by about 6-7 years, but I can honestly say that no other tool could even come close to replacing Emacs.

> You can do one thing in JetBrains: edit code. That's it.

You can also takes notes in markdown docs and/or code comments (it has a built-in TODO detector and organizer).

> they use an unholy mix of JetBrains, GitKraken and the command line on Linux, and Tortoise, SourceTree, JetBrains and the command line on Windows

I just use SmartGit for git. It's configurable with workflows (or custom commands), navigable with a keyboard, visual, clickable, and actually "smart" -- it warns you if it thinks you're about to do something stupid, like overwrite a repository's history.

> In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs. I write Confluence articles, so I don't have to deal with Confluence's shitty interface.

This is good info. These are all things I really, really don't want to do in my IDE. I want my IDE to be a good IDE, and I want my other tools to be purpose-built as well.

Switching apps is not painful to me at all. I often have a screen with a git GUI, IDE, browser, and DB GUI all open at the same time.

I get it, not everybody has the mindset of living in one tool — I didn't either, before I converted to Emacs, which is a relatively recent development. Maybe 3-4 years, though I did use it ~7 years ago once, and then even further back, probably around 12 or so years ago. I don't quite remember.

But I came back to it, and stayed for good, because Emacs is really an OS with a nice editor. So you can have the same approach of do one thing and do it well, but you have different packages instead of different programs. And they synergize nicely. So it's not only an IDE. Everything I use is purpose-built for that one task, including ledger (accounting), mu4e (mail), lsp (IDE-features), org (agenda, research, documentation) magit (git) etc. None of these things are "plugins". They're programs in their own right, just like ls and mutt, and git themselves.

> This is good info. These are all things I really, really don't want to do in my IDE

The point of Emacs is that it's a text-editor, and as someone editing text all day (code, documentation, etc) I want the best, most consistent text-editing and text-process possible, without having to jump from tool to tool.

With Emacs, you can mold everything you do to be consistent across all dimensions you can imagine. Once you get used to it, it is very weird (unthinkable?) to go back to other tools.

What are your favourite features about magit? I switch between Pycharm and Vs code and terminal for my git usage. I find Pycharm has a really great git blame ui that makes it easy to walk back in time and investigate changes. It lets you toggle "Annotations" next to the line number, that display the SHA. From there, you can right click > show diff, from which you can _also_ show annotations, and continue jumping back ad infinitum. Vs code has a plugin which does something similar, but I find the UX to be not as elegant (the annotations are way too wide; every option is hidden behind cryptic icons like "<<"; diffs open in new tabs, which makes things cluttered; and instead of right click menus they have really large hover menus which I find are super finicky to use). VS Code's conflict resolution is a little easier to use for me. Pycharm's approach is a little overly UI'd, whereas Vs code treats everything as text with helpful little overlays for quickly selecting one vs the other. Also when viewing local changes as a diff, Vs code's highlight change > right click > "stage selected lines" is more flexible then Pycharm which only shows a little checkmark near "chunks" of the diff for staging. Both editors also have a lovely feature that lets you highlight text and copy the GitHub link to the chunk or the entire file. Makes sharing really easy.

I use the git terminal for everything else; branching, checkouts, rebasing, pulling, pushing. Actually I use vim for interactive rebasing because it's fast/quick there.

> What are your favourite features about magit?

For a similarly complex task, there is no program with a better UI.

Magit manages to optimize for both, speed and discoverability: 99% of all actions are 2-3 keystrokes away, and at each stage of that process, magit will tell you your options. For example, invoke magit, press 'b' brings up the branching menu, basically a keymap for letter -> action. Pressing 'c' for checkout then starts a new branch creation. The default branchpoint is your current branch. If that is fine, press enter, otherwise type out the branch name (tab completion for all possibilities, local and remote). Finally, you name your branch. So in 99% of the cases, it is b>c>enter>my_cool_new_feature>enter, done.

Before magit, using version control was a necessary evil (for me). Nowadays, it is so effortless, so natural, that it hardly registers in my attention -- similar to the way that you automatically save the file that you are working on after a couple of lines of writing without noticing that you are doing it.

All cli tools should have a magit interface. World peace and happiness would ensue.

> All cli tools should have a magit interface. World peace and happiness would ensue.

:) Ahhhh, I think I understand! So magit is like an autocompleting wrapper/reorganization around the git cli. That does sound great! There are some git commands which would be super annoying to do via a UI (not to mention if you add _all_ of git's features to a UI, good luck making anything discoverable :P), but in the CLI they're kind of awkward cause unless it's something I use very frequently, I forget the syntax (looking at you git bisect). This sounds like it would make those significantly easier to use, _and_ help the developer discover new git commands they might not be aware of (looking at you, git bisect :P).

> Ahhhh, I think I understand! So magit is like an autocompleting wrapper/reorganization around the git cli

It's a complete git "porcelain", in that it provides more or less full access to all git offers.

I daily rewrite git history in my feature-branches, cleaning up my commits, to provide fully atomic and clean merges back into dev.

Using magit, it's just seamless and feels immensly rewarding wrt doing a good job. Without magit? I wouldn't even bother.

Magit is not "just" a wrapper around the git CLI. It's a complete replacement, enabling you to fully exploit all of Git's power without ever leaving your editor of choice, nor exposing you to complex internals.

It's an amazing product, and I've seen people ask for a Magit-only Emacs-distro, just to replace their existing Git client.

I think incremental commits are among my favorites in magit. It's so quick and easy to stage and commit selectively.

The other thing I love about it is discoverability of git features. Did you know that you can stash index and working tree separately? I only know because of magit. Now that I know, I have actually used it to great success.

Also, I've become my team's go-to rebase monkey. What takes my colleagues minutes of thinking what to rebase where, and how, and how to deal with the conflicts, I'm usually done in seconds. Also, conflict resolution with magit is really very streamlined. Conflicts still suck, but less so.

Pushing/pulling to/from different remotes is quick and easy (happens often with github forks and PRs), merging and branching is a breeze, and you've got splendid auto-completion on branch and tag names (I use ivy.)

The blame mode you described exists in magit, too. You can annotate a file and drill back into a certain commit's history. Actually, the default way magit does it is dissimilar from what you might be used to from other GUI tools. Magit doesn't annotate the left or right, but instead inserts header lines for a commit. That way it's easier to see coherent commits. I find this way of displaying history nicer if your code's commit history actually contains chunks of lines for the files, and it's not so fragmented that practically every line is from a different commit/author. It's possible to do the margin-annotation you're used to from other blame tools, too, though.

Thanks for the examples! The magit page is a little hard for me to grok why it might be worth switching to something else.

> Did you know that you can stash index and working tree separately?

What does this mean? Can you give an example?

> Also, I've become my team's go-to rebase monkey.

Haha, hello friend. I love rebasing; it always breaks my heart a little when I see "Merged master into branch X" commits :P My main git rebase flow is `git checkout master; git pull upstream master; git checkout X; git rebase -i master` + vim. Having multiple branches that depend on a shared branch does get a little messy though. How does magit make this flow better?

> Conflicts still suck, but less so.

Hahaha, that's all you can hope for with merge conflicts!

`git status` always shows you some of three things: files not tracked by git, tracked files with modifications that are not staged, and tracked files with modifications that are staged.

You can stash tracked files with modifications, or tracked files without modifications separately! Scenario: I've staged a couple files for a commit I'm preparing, but I see that there's an unrelated change in the unstaged files that I want to do in a commit that should come first. So I stash everything I've staged. I do not stash what I haven't staged! Now I can create that new commit, and pop the stash later to come back to the commit I wanted to originally write.

I agree with all of this, especially discoverability of git features. I think using magit really helped me build a mental model of what git’s doing and what it can do vs. just using the git CLI on it’s own.

And yeah, incremental committing, the rebase workflow, working with multiple remotes... they’re all a breeze. With the GitHub style PR workflow, I typically set the main repo for a project as the “upstream” remote and my fork as “origin.” With the settings I’m used to for a project, pulling down the latest changes from upstream is two keystrokes: “F u”, and pushing back up to my fork is two more: “P p”.

Really? There's a way to edit confluence pages in emacs? you've made me very happy!

EDIT: https://www.emacswiki.org/emacs/ConfluenceMode

Actually, I just use ox-confluence, which means I can export (narrowed) org-mode trees to confluence. It exports it to a buffer that I cut-and-paste into the web page.

I think confluence.el is no longer maintained, sadly. Maybe an interesting new side project :)

> You can do one thing in JetBrains: edit code. That's it.

No, you can do more, it's just usually people don't have the mindset to do more. And to be fair, JetBrains software is not meant to do that, so it's harder to do it, preventing the people from developing the mindset. It's a loop.

Thats just plan incorrect. JetBrains lets you do the following, out of the box:

- Edit Code - Debug Said Code - Run Said Code - Manage your repo via Git, SVN, or Perforce - Has GitHub integration built in - Has PlantUML integration for creating UML diagrams via their markdown editor (its pretty nifty and I believe now bundled by default) - Connect multiple SSH sessions - Connect multiple SFTP sessions (semantics right)

and so on and son on..I can even do remote editing as if its there, righ tin front of me. you can't even tell if the filesystem is remote because of how it populates in the IDE.

So please, what doe sit not actually do again?

and via plugins, (and a plugin ecosystem that tends to be well manicured/maintained, at that), you can add an LSP or many other languages that are supported. I've tried many many editors, and JetBrain IDE plugins are some of the highest quality i've ever worked with.

So please, tell me, what do they not do again?

>In Emacs, I read my mail, I organise my agenda, I write technical reports, blog posts, I wrote my entire thesis in org-mode. I collect research notes in Emacs, and a journal. I do my bookkeeping and accounting in Emacs.

No one cares (other than Emacs users). There are better tools designed for those purposes. There's a reason the UNIX philosophy of doing one thing well is still so popular and widely used. Rather than configuring and spending hours on buggy, poorly developed and indecipherable systems like Gnus, org-mode (it's like an Emacs with an Emacs, just ridiculous) etc people instead choose tools that are far better, more intuitive and works out of the box and everywhere.

> I edit remote files, I edit files via sudo on my machine.

Any decent editor or IDE can do that.

>I control git.

VSCode support for Git (and Github) blows everything else out there. And so also for languages like Python. Emacs support for any language which is not a Lisp dialect or C is horrible.

> I've been a dev for less time than you have by about 6-7 years, but I can honestly say that no other tool could even come close to replacing Emacs.

I very much doubt you actually tried to use anything else.

Which tool would you suggest for Org-mode? I have been reading up on it and it almost made me want to use emacs. But if there is a better tool designed for it's purpose..

you can try workflowy

> web-based

And that's already not a decent concurrent for org-mode. Not that I have a grudge against web tech, but no self-hosting of my most personal data and no offline abilities is a deal-breaker for me.

This comment is quite harsh and definitely doesn’t seem to assume good faith in the person you’re replying to

Emacs user here. I've been thinking about this lately since I switched to VSCode because Emacs doesn't have a good TypeScript React mode and to be honest, you're right.

The difference is I can make Emacs do things just the way I want it vs can it do what I need it to do? And I find that for most part I don't miss it that much (even I'm shocked) but I still open Emacs for Magit from time to time, because there's just nothing else like it, and boy is Magit slow when I have to merge big changes (probably exacerbated by Emacs Mac port's slow vfork).

I was about to switch to VS for that reason and then I discovered Tide, which works grest as a React Typescript mode for me.

But to be honest I only use Emacs because 28 years of using it has made it feel like home, I don't usually recommend it to new people.

Tide + https://github.com/jscheid/prettier.el + projectile + helm work wonders. Been using this for +3 years now and its one of the bigger productivity improvements in my recent years of emacs and programming practice.

At work, I actually try to get ppl away from Jetbrains IDEs because they are slow and their typescript and prettier support seems pretty buggy to me.

Unfortunately, most developers I meet these times are not the kind of hacker types that want to understand and optimize their tools but rather just to get stuff done on the surface (which is totally fine). So emacs isn't just a good fit for them.

> prettier support

I use emacs/tide/prettier-js, but the prettier formatting only happens on save. Do you have settings that make emacs adhere to prettier formatting as it goes along?

Are there problems with typescript react on spacemacs or doom emacs?

As far as I know on the Vim side you can get feature parity.

1. Nothing I've found comes anywhere close to Emacs support for keyboard macros. Zero latency to record. Records every keystroke. Very very consistent behavior. Infinite undo. Kill Ring. Register support.

Despite being an expert Emacs user, I'm mostly in VS Code these days because it has syntax highlighting, git support, and linting out of the the box. But I always go back to Emacs when I need to transform a bit of text.

2. Comparing two text snippets, as opposed to files.

There are a small set of use cases where you want to look at every position where something has changed. You can open two buffers in Emacs and use compare-windows to walk through them. Since the IDEs are all file-oriented, they don't work for this case well.

What are some examples of keyboard macros you use? I read a lot about people loving keyboard macros, but I can honestly say I've never thought of a use-case for them. There's already a built-in IDE automation for everything I could think to do with a macro.

If you have, say, a list on consecutive lines with a blank line in between them, and you want to delete a character after the second word, add some text at the end, and delete the blank line - with keyboard macros you record these transformations once and then apply them to the rest of the items.

Somethings I find more convenient with Emacs than modern IDEs:

-Remote file editing with Tramp: This is much better even than using vi/pick over a terminal.

-Very flexible kill ring copy paste mechanism: can do complicated text manipulations with easy access to copy paste history.

-Easy macro recording and playback.

-Very flexible windowing: can show even multiple windows with the same file, even synchronized scrolling of required.

-Rectangular/column edits.

-Built in file manager.

-Built in shell, can run shell programs and capture their output.

You nailed it.

I'd also add:

- incredibly ergonomic file-system navigation (helm+projectile)

First thing I notice when I use VS Code is... Do I really have to click and click and click and click to navigate from one file to another? Why does VS Code show pop ups all over the place?

I really like how I can navigate the file system from emacs using fuzzy searches when I need them, and how the same fuzzy-search approach helps me also navigate all my buffers, works remotely over tramp, etc.

> emote file editing with Tramp: This is much better even than using vi/pick over a terminal.

You're probably aware, but VSCode has great support for editing over SSH.

For those who care about this (I do): that’s a proprietary Microsoft extension and doesn’t work in the free software versions.

https://github.com/VSCodium/vscodium/issues/240

Apart from remote file editing everything else exists in modern IDEs. When is the last time you looked at an IDE?

Remote file-editing is also available with other editors and IDEs. Everything KDE has it out if the box for example. Vim has IIRC some protocols. VS Code got some a bit ago as I heard.

I'd be surprised if a modern editor didn't support remote editing (SSH).

> Now, I just don't get it. What are emacs users customizing so intensely that no other environment can match it?

I thing it's a bit between exploring the possibilities of your tools, expressing yourself in some "divine art" and procrastinating under the guise of being productive. There is definitly a high amount of good customizing possible with emacs, but from my observation many end also in the trap of over-custimizing, to the point where it becomes harmful. Not to forgotten all the worthless oversmart solutions build in emacs, beacuse emacs gives them the means to do it.

> The level of customization that emacs supports seems unnecessary to me.

Emacs is a platform for textual and programatic interfaces. Similar to web-technologie. As such you can tweak little things, but also build whole apps dedicated to specific usecases with it.

> Can you talk about a few use cases where emacs is just better than an IDE could be?

It's not better than IDE, but similar level as IDE. Just that you are able to do it yourself. With an IDE, if you have a specific demand like integrating some new tool, or handling some specific filetype, you depend on the producer to build it into the IDE. Just recently IDEs have also learned to use plugins, to allow you build some stuff yourself. Ok, recently was 15-20 years ago, but emacs is 40 years old, predating them all.

I think VSCode is a very mouse-centric experience. Using Emacs I don't touch my mouse. It's a far more efficient and comfortable (less straining) experience, for me anyway. I use both Emacs and VSCode but vastly prefer the Emacs experience. I also use Emacs for much more than simply writing code.

Emacs is also more pleasant to use because it's simply faster. VSCode is slow compared. I'm not talking about application startup time, but just about every operation you do. VSCode stutters and hitches all over the place. Input latency might also be worse, but I don't know, that's just what it feels like. It also lacks many of Emacs' powerful features like helm swooping, which is of course customized just the way I like it. VSCode's "search in all files" just doesn't cut it. And symbol fuzzy search is just for symbols, not all text. Code navigation in Emacs is lightning fast, with the right setup. My Emacs config makes a distribution tailored for me.

A great advantage Emacs used to have over other IDEs and some editors was that you would use it for all/any language. Now with editors like VSCode, which has great support for many languages, it has lost this advantage.

Although the mouse centric experience thing makes sense when _writing_ code, I don't think it makes as much sense for reading/refactoring code. I'm not an Emacs user, but watching some of my colleagues navigating a codebase with Emacs looks not only slow, but also very mentally taxing. They often switch to grep searching, then select the results in order to iterate over them in Emacs. Or they have to remember full paths to files (with autocompletion, but still). Ctrl-shift-f in Vs code looks significantly faster since it displays the results in real time and let's you see the snippet and simply click on the one you want. Also ctrl-p for finding a file quickly by searching for any part of the path. Ctrl-clicking on a method name to jump to its definition. Right click > rename to rename a symbol across files. Or a feature I love in Pycharm, alt-enter to auto import a function--without having to try to remember where it's coming from (it gives a drop-down for multiple definitions). These things speed up flows enough that I think it outweighs the cost of having to remove your hands from the keyboard. And I think reading/refactoring code is as important as writing code in development.

These are exactly the things I find better and faster in Emacs. Watch video below and imagine searching that way but for all files in your project. Results in real-time, instantly taken to content when you highlight and browse results with arrow keys or further narrow down by typing.

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

IMO VSCode's ctrl-shift-f doesn't come close. And its symbol search is just for symbols, not all text.

Oh nice! That's pretty similar to the VS Code's search experience; I didn't know emacs had that built in! I have a colleague who uses emacs and he always uses grep for stuff like this and it makes my eyes bleed :P

Never used emacs, so can't compare. But:

> I think VSCode is a very mouse-centric experience

I never touch my mouse in VSCode. There's many many shortcuts that are configurable, and keyboard navigation isn't not a "second-class citizen"

> VSCode is slow compared

Yeah, probably true. Never felt like it slowed me down though

> And symbol fuzzy search is just for symbols, not all text

cmd-t on vscode. Probably not strictly equivalent to helm-swoop, but you could make your own extension in JS (which is a strong point for many people, I don't particularly want to learn a language that's specific to my editor).

> cmd-t on vscode.

Like I said earlier, that's just for symbols, so no, it's not the same.

So, I write a niche language server along with an adapter for VS Code. What are you frequently jumping to that isn't a symbol?

I can expose anything through the LSP api. Thinking about it, every single piece of text is covered by symbols and falling back to find all references.

The only thing that wouldn't work is trying to jump to syntax, but why would you do that?

I was going to say pong. Or fireplace. Or maybe the same experience on macos or linux or editing files on an embedded router remotely with tramp.

But really the customization is the use case.

just some examples:

I have written a few specialized diff functions. diff two directories, diff 20 files, diff what I have vs checked in. many different comment-out-a-region functions. remote compile. local compile, but build this part of a project or build it this way. every language I code in has customizations, for indent, for tabs, for colors, several "insert a debug printf".

They are all silly and redundant of no consequence. I frequently rewrite them or throw them away depending on the project I'm working on.

they are meta-silly even: f2 will rotate through editing my 3 startup files.

However - when the time gets tight and I have to do something on a schedule, I'm not grinding through some other person's decision of what is best, I'm just doing it. I also get better at it with time.

I just wrote a small function to convert Unix epoch timestamps to date-time strings. Just to be able to make sense of timestamps in some log files I was looking at.

I find this kind repetitive thing frequently comes up in the course of one's work. Not a big deal to copy and paste in a web site to convert the first few (or few hundred) times, or firing up the python interpreter. But once it becomes apparent that I will have to do this again and again it is great that Emacs gives me a way to add that small function to it.

I use an IDE for java development because the refactoring is just too useful. But Emacs macros are very useful and I haven’t found something like this in my IDE.

I wonder whether it’s possible to set up lsp-mode for my Java project.

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.

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.

Yeah, to some extent, maybe.

I appreciate what you’re saying, and I do hate being slowed down in the moment.

I’ve got a handcrafted AutoHotKey script and a 22 button gaming mouse fine tuned for 2D CAD / CAM software at work, so while I am definitely in to this sort of customisation...

If I’m honest with myself I don’t really get more work done because I end up using the time being unproductive elsewhere.

There’s definitely a certain intellectual curiosity-satisfaction to be had from customisation.

I’m just not convinced it’s a net time saver in the long run?

> because I end up using the time being unproductive elsewhere.

Isn't that literally the point? If you can do your task in 10% less time, and then end up spending that 10% procrastinating on HN, then you still win - the task gets done, and you also get to sneak in something nice. And if you find you'd rather spend that time on something else, or doing more work to finish everything faster, you can choose to do so. Optimizing work gives you choice what to do with the time saved; the default may be that you waste it, but now you have options.

> Isn't that literally the point?

Ah, yep, you might have a point there!

Dunno how I missed that. Seems obvious now.

> a certain intellectual curiosity-satisfaction

User interface design (UID) and user experience (UX) are interesting topics.

Have you ever conducted an oil change at your car or some other minor mechanical task? Wasn't it fun for a moment (at least that one time)?

Machines are interesting.

I think most emacs user are overestimating the gain they are having by mastering art of emacs. Sure, it sounds useful to copy every 5th character in all lines that fits a certain regular expression but how many times you actually need it on your active development time and how much time you lose by doing that manually or using more traditional tools?

The coding is mostly typing and debugging. Visual studio (most ides really) is good enough at that. And to be honest emacs/vim complicates the typing part.

> Visual studio (most ides really) is good enough at that.

No. It's not.

Emacs's electric-indent is so close to the Right Thing when you're coding it's incredible -- getting almost perfectly formatted code as you type. Other editors have autoindent, but it never seems to do the right thing. Other editors also see fit to insert closing brackets/parens/quotes, and then miss detecting when I typed the closing punctuation so now I have three brackets/parens/quotes. It throws me off. Just highlight the opening punctuation mark when I close it, the way Emacs (and vim) does.

I've given Visual Studio Code a chance. Lots of chances really. Each time I find myself struggling with it more than I should, and needing that Emacs flexibility much more than I anticipated going in. Initially I feel more productive, but the more I worked with it the more it gets in the way, inducing friction and slowing me down. And then I want Emacs back.

> 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.

In most jobs I worked for, taking files home from employer computers would be stealing from security point of view no matter what their contents are.

So it means that one has to create those configurations from scratch every single time in each new job.

It depends on the job. Certainly you can't add any company-specific tools to your overall init file.

However, most of the stuff I do isn't that specific so I have all my customisations in a git repo that I pull from github to whatever machine I'm working on.

>This view is obviously biased against Emacs,..

Yeah, no bias in your comment. This is the kind of gatekeeping that is keeping Emacs from being popular. All of what you said works great in a "blog" and social media to get upvotes and +1s, but not in real world.

> 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.

This is not only insulting but ignorant. Have you looked at how extensible VSCode is and how most of the users are using it before you made your comment? Just because it is great outside the box, does not mean it is not extensible or the users cannot "tune their workflow".

> 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.

I'm using emacs for 15 years, and it doesn't work for me. When I noticed things I'm doing often, I already have a habit of doing these things by this way. So if I wrote an elisp-function to automate things, I wouldn't use it, because my unique way doesn't include this function.

I'm trying to find a courage to migrate from emacs to some other IDE, where everything already configured, where I could create new habits relying on automation. You know, like use syntax-aware indexing software instead of "<f9> find . -name *.[ch] -exec grep -Hn something {} \; <enter>". I tried etags, but it doesn't work often enough. So my unique way is to simplify workflow and start with find/grep solution, which works in 100% of cases.

emacs is a subject of "lisp curse"[1]: it is too configurable for people to make it usable. People just hack around to make it work for them, and no one tries to make reasonable defaults, because when you set up text editor and ready to make reasonable defaults your editor already is configured and you personally doesn't need no defaults.

[1] http://www.winestockwebdesign.com/Essays/Lisp_Curse.html

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.

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.

Emacs is as much of an GUI-App as Window notepad is an editor. They both have the traits what justify to call them, but also are both on the absolute bottom-line in terms of ability.

The menubar is stuck in the 90s, the toolbar very very basic, even for the 90s. Window-Splitting is not even an GUI-feature and very basic. Only the tabs are somewhat modern, but also simple. COmpared to a modern GUI, emacs has barely anything that justify calling it GUI. Especially as most of those features are available in the terminal-version too AFAIK.

> If you want something slightly more like a traditional gui emacs application framework enables bidirectional communication with QT applications running in emacs frames.

Calling external apps doesn't make it a better GUI. And amount of connection between emacs and Qt is very limited. This is just a crutch to fill missing areas in emacs abilities.

> The menubar is stuck in the 90s, the toolbar very very basic, even for the 90s. Window-Splitting is not even an GUI-feature and very basic. Only the tabs are somewhat modern, but also simple

You're confusing GUI with Windows GUI API. That's like complaining that a game like Stellaris barely has any GUI, because if you force it to run in windowed mode, then maybe you'll get a context menu dropping down from the application icon in the top left corner of the window.

Emacs absolutely has a GUI. It happens to be drawn almost entirely from characters, but it's a GUI. It uses the language, can display pixel graphics (in GUI-app mode), and even supports pointer devices. The fact that 99% of that GUI is a TUI is actually a benefit (you can also use it from terminal). And with third-party plugins, it has all the sophisticated GUI controls you could dream of, except unlike in traditional GUIs, they're fully interoperable.

A good comparison may be that Emacs is the OS that ships with a tiling WM, and most people unaware of that just use it to tile notepad windows.

> Emacs absolutely has a GUI. It happens to be drawn almost entirely from characters,

That's a TUI, not a GUI. GUI means Graphic, not text, even if it's spatial.

> And with third-party plugins, it has all the sophisticated GUI controls you could dream of

No, it has not. I've tried enough of them to know how poor they work.

Windows splitting is actually quite sophisticated you can split horizontally or vertically and split successive sections of the screen. You can balance windows in one dimension or by area. You can do this automatically as you create or destroy windows if you like.

You can have new splits inherit the file you are already editing or show a blank buffer. Further closing a split doesn't kill the buffer or make you decide at that point whether to save a buffer it just destroys the view not the thing.

Native tabs interact with splits in one of two ways. Either as an array of window arrangements at top of window or an array of buffers within a particular split.

You can manually resize a split with the mouse and in fact you can create them via the file menu which also shows the key binding to activate the functionality beside the option ensuring that the 2nd through 10 millionth time you need the functionality you can just press a few buttons.

It's not opening external apps like clicking a link in your email and having your regular web browser open the url its creating a pyqt app within the space of your emacs/tab/split that you can interact with via elisp

https://github.com/manateelazycat/emacs-application-framewor...

As far as I am aware it still isn't as GUI oriented as ZWEI used to be.

What gui elements do you find lacking I'm not familiar with ZWEI

Basically think of using Emacs like a Jupyter Netbook, including the visualizations.

Back when I was still into Emacs (2004) this wasn't possible.

That's possible now, you can render images inside buffers.

Render images alone is too basic, that was already possible in XEmacs.

I really meant like Jupyter Notebooks, interactive images and data structures, that you can click on and change to your pleasure and plug into Elisp code to be called back.

Org-babel does this, and is less limited in language choice than Jupyter; you can use any language for which a binding exists (there are many, including Python) in any code block, irrespective of what you use in any other. The interfaces are pretty clean, and you can have inline images, although I think not interactive ones. Data structures are expressible in code or in tables.

I don't use it much these days, having less need for that sort of highly interactive exploratory analysis, but I did find Jupyter highly limiting by comparison.

Thanks, I will have a look into it, if anything at least not to spread misinformation.

You can integrate jupyter notebooks into emacs so in particular everything "like jupyter" and more.

That is not the same as it doesn't work with Elisp, and hardly brings any value from Emacs itself.

Oh I see. Ya fair. Though honestly even in Jupyter notebooks I don't often see many people making use of anything more then static renders.

Completely agree. There hasn't been any innovation from Emacs since the 90s. Instead more and more effort has gone into adding useless capabilities into emacs such as mail/news readers, organization systems and even window managers. There's some truth to the statement that "Emacs is an operating system lacking a decent text editor" except that even as an operating system it sucks.

Have you tried spacemacs?

> 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.

There is an integrated settings/extensions sync feature (not yet available on the main release, probably next month). [1]

Or there is a popular extension that does exactly the same thing. [2]

Or you can also do it manually, import/export your settings in JSON and generate a list of `code --install-extension x` that you run on your other machines. [3]

[1] https://code.visualstudio.com/docs/editor/settings-sync

[2] https://marketplace.visualstudio.com/items?itemName=Shan.cod...

[3] https://stackoverflow.com/a/49398449/652669

> 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.

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.

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.

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.

I've never needed more than 2-3 VSCode packages for a given workflow. They're usually easy to find and at the top of the list when I search for a language. Settings live in a settings.json file in your home directory and/or workspace (the latter is so that shared settings can be committed to version-control). You can have both and they get merged, with the project settings overriding user-level settings.

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.

No. It doesn’t. You still need to install and configure plenty of 3rd party packages and tools that are completely outside of emacs. For C++, things like cscope, ctags (or maybe etags or gtags), clang autocomplete tooling, etc.

These, their dependencies and layouts, typically change from machine to machine, OS to OS, distribution to distribution and version to version. So placing it in your emacs config isn’t really portable.

Same for vscode? ex: if you want eslint, you install it from npm.

My experience with VS code has been a couple clicks for C++, Python (2 & 3), and a smattering of other languages and configuration files (YAML, cmake, etc.) on a fairly large (~1MLoC) enterprise code base.

Another click for remote editing over ssh.

No pain and most importantly no constant tinkering.

VS Code started very humbly a few years back and was useless to me because it only supported JavaScript and a couple other things with no plugins to speak of. It has since grown into a seriously powerful tool.

The 'one file' installs the other tools for you. At least mine does. I move between machines regularly, and when I do I just install emacs according to the recommended method for the particular OS and copy my init.el file to the new machine. All the packages I depend on are installed the first time I run emacs. And my init.el would be considered pretty basic by the standards of an advanced user.

You install something like spacemacs or doom emacs for vs code parity. And then it lazy loads packages based on the file type.

You enable features in config by uncommenting, and it auto installs.

The "Emacs file" can contain that yes. Since .emacs is written in Lisp (Emacs Lisp) you can basically tell it to do anything om start up.

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.

> 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.

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

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.n...

Rust configuration:

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.)

How does emacs have better support for completion than vim?

https://www.emacswiki.org/emacs/CategoryCompletion

Is this language specific? For typescript at least Vim can use the same completion server as VS code (and so can emacs for that matter).

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.

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.

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.

> 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.

> You might not have seen it happen, but if my experience was any indication, they spent a lot of time crafting that config file.

Yes. I've spent 10 years crafting this file I'm using now. One bit at a time, every time I found something which could improve my productivity and editing experience.

And I can now bring that with me anywhere at literally zero cost.

I'm not sure why anyone would frame that as a bad thing?

You had to spend time learn a new set of keybindings for each one though, for editing and interacting with the interface.

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.

While I think you're right on the whole here about "Emacs people," but you did an interesting thing in the first sentence: you contrasted experienced Emacs user with junior developer. And I think that actually points to a problem: people who are experienced developers but not experienced Emacs users are going to be in much the same position as the OP's description.

While I know the basics of Emacs, every time I try to get serious with it and make it my One True Editor, I end up spending days screwing around with packages and configuration files to try to figure out how to have similar functionality to what I get either out of the box or with fairly minimal effort in arguably lesser editors. I'm sure Emacs can do all of what I need and nearly all of what I want, but most of the time I'm damned if I can figure out how to get there from where I'm starting.

If I was really going to try to give advice on how to make Emacs more popular, it'd center around the package/extension system. It's great that it has package repositories and a built-in management system now, and the documentation for the core editor is terrific... but the documentation for packages is wildly variable, and what's worse, packages interact with one another, depend on one another, and/or conflict with one another in ways that are just utterly mystifying to a newbie.

I don't care about making Emacs "pretty," and while it'd be nice if it used less weird terminology by today's standards, I can deal with it. What I want is sane defaults and good guidance. Spacemacs' concept of layers -- where I can just say "I would like you to install and enable all the crap that lets me smartly edit PHP files, please" -- is absolutely onto something, although I would still argue that it might need to offer a little less choice by default. Don't make me choose whether I want Helm or Ivy because I have no idea, and for God's sake, enable sensible layers/packages by default: assume that yes, I do want autocompletion and git integration and such. If you must, let me click a button to choose between "batteries included" and "advanced" configuration. This is stuff that mainline Emacs should be doing.

And, actually, that's one other thing Emacs could stand to do better: learn from VS Code's configuration system that lets you use dropdowns and checkboxes and simple text fields for nearly everything, and has a button to go into the configuration files when you need it. Yes, I know Emacs has a text-based UI for configuration, too. I've used it. It's bad. Okay? It's just bad. The controls are non-standard and weird, the organization is utterly mystifying to someone who doesn't already understand Emacsology, just... no. Start over.

As for me, well, when Spacemacs moves the LSP layer to its non-development branch, I'll probably give it a try again. Until then, I'm probably gonna keep doing my technical writing in BBEdit and my coding in Visual Code. (I'm probably gonna keep doing my technical writing in BBEdit until I die, but that's a different post.)

> Yes, I know Emacs has a text-based UI for configuration, too. I've used it. It's bad. Okay? It's just bad. The controls are non-standard and weird, the organization is utterly mystifying to someone who doesn't already understand Emacsology, just... no. Start over.

I’ve used GNU Emacs for twenty years and totally agree. I avoid the customization menus wherever I can.

> As for me, well, when Spacemacs moves the LSP layer to its non-development branch, I'll probably give it a try again

You're doing yourself a discervice for not just using Spacemacs develop branch. It's actually more stable than the master branch.

I use and love Spacemacs, but their branch handling is a major PR fuckup. The last stable version should be phased out now. The develop branch works way better. They should rethink their release model.

True, just think they need to embrace the fast development cadence of develop and just make that master.

Interesting. I switched to the develop branch the other day (yes, just to try to get LSP working!) and ran into some glitch that I didn't have the time to investigate -- a complaint about the .spacemacs file missing a variable or something. I'll probably try again this weekend.

You need to run SPC f e D to do a 3-way merge of your .spacemacs everytime after you upgrade Spacemacs.

As changes to Spacemacs are made, there might need more or less things in the .spacemacs file. So you always need to do a manual merge of the changes.

Thanks for the tip. I had no idea that was a thing -- although it absolutely makes sense, thinking about it!

> I'm probably gonna keep doing my technical writing in BBEdit until I die, but that's a different post.

Please produce that post. Also, why not developing in BBEdit?

BBEdit's indenting and completion engines just aren't as smart as other editors -- I suspect in the latter case they'll have to add LSP support on their own (right now I don't think it can even be added externally because their API doesn't expose the right event hooks), and in the former case, I have a suspicion Bare Bones Software just has a philosophical objection to context-aware indenting. With those objections aside, BBEdit is still pretty good for development.

For the technical writing, I actually wrote a comment here somewhere about that in another post; I'll have to dig it up and turn it into a blog post at some point. But I called it a "fast Swiss army knife for text." Its "open file by name via fuzzy searching" command lets you enter multiple files, its multi-file search window lets you save file filters with meaningful names (and you can save grep patterns the same way, and in BBEdit 13 there's even a "Pattern Playground" that lets you nondestructively test out complex regexes on your current document). Projects get their own persistent scratchpads and Unix worksheets. And, a bit relevant to an Emacs thread, BBEdit has a bit of Emacs-ish keybinding support over and what Mac editors normally do, although it's decidedly not an Emacs emulation layer.

> I have a suspicion Bare Bones Software just has a philosophical objection to context-aware indenting

Yeah, either that or they are procrastinating on some quirk deep in their engine they should rewrite already.

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.

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.

> 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.

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.

I think the productivity graphs look like:

  |          22
  |        22
  |  1111121111
  | 1   22
  |1  22
  |122
  -------------

> 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.

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

In vim, configuration is either through running commands you could run in normal mode in vim, or through vimscript functions. I assume emacs is similar in that regard.

JSON isn't really that easy to read unless it's pretty formatted, and it's somewhat difficult to write (making sure you have every double-quote, every comma, every closing and opening bracket/brace, etc. I always have to run a JSON linter to make sure I didn't miss anything when writing JSON by hand.

In Emacs it’s easily readable ELisp. Much, much better than JSON.

Well, more versatile, anyway.

So which is it: VS Code is maximally unsuited for everyone or the previous argument was nonsense?

Your comment doesn't make sense. What are you trying to say?

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?

You didn't read the comments correctly, hence your confused reply.

I use VS Code sparsely but this is what has worked for me https://marketplace.visualstudio.com/items?itemName=Shan.cod...

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.

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.

> Python support is decent but only if you get an optional, poorly-advertised extension on top of the default one.

Which one?

This one: https://marketplace.visualstudio.com/items?itemName=ms-pyrig...

I only found out about it by asking here on HN

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.

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

> 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.

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.

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.

> 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?

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.

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.

What are you guys talking about...

1. nano code.txt 2. ??? 3. Profit!

> 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?

> 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?

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.

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.

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.

There's a sync extension. I think it's making it into the core functionalities.

Good news!

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!

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.

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.

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.

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.

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...

My progression in editors was something like Sublime -> GVim -> Spacemacs -> VSCode -> Jetbrains.

After all those years, there are 2 main takeaways for me.

1. I love modal editing, not necessarily Vim

2. My time is better spent doing actual work or enjoying my hobbies than fiddling around with configurations.

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.

What is the problem that take days to fix with Pycharm. Just curious. I have been using Jetbrains products for 5-6 years now, and have never faced a problem which took days to fix. Sure, there were some bugs here and there, but no showstoppers, and all were already filed in their bug tracker before I could file them.

Also, Pycharm does far more than even a heavily customized .emacs can do (I used to have one very custom emacs setup). There is simply no comparison feature wise. Not to mention, things that emacs can do, Pycharm should be doing in even a very problematic bug ridden state.

In what sad, warped alternative reality did this happen?

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.

This is exactly what the IDE people say about VSCode

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.

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.

There are loads of examples in the comments here. Have you read them?

I use vi.

Never had to install anything across thousands of servers.

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.

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

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.

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.

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...)

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.

Reply on news.ycombinator.com