What do you tells VSCode and Jetbrains naysayers

A friend at an old workplace told me this morning that his boss told him they were all switching to VSCode and it was going to be a company mandate. It's not the first time I've heard people be dismissive of long time Emacs/Vim users. My last personal experience was someone telling me flat out I was wasting company time playing around with Emacs rather than using Pycharm. I have also gotten into long arguments that devolve into "feature-offs" where I have to explain how a feature VSCode has is also in Emacs. I tried to explain that you can use GDB in Emacs, and someone literally laughed at me because GDB is "ancient" and VSCode's debugging is modern and actually gets stuff done. It seems like even if Emacs can do something it's also A. Not good enough B. Takes too long to configure instead of just getting the job done. So please give me some advice on how I should combat this encroachment on my peaceful Emacs pasture. Or should I just give up my goats and switch to VSCode?

What happens when M$ stops supporting vscode. I understand pushing vscode on new engineers with no other opinions, but long-time vim/emacs users are likely just as productive. You would simply waste time while they get back up to speed in vscode, but then there would be little further gain. I can't speak in the editing environment of Emacs in python, but I am just as productive in Emacs with C++ as my peers are with vscode. And I get GUI debugging facilitated by gdb, with clickable breakpoints, line stepping, etc. And the package maturity is at the point where it's literally a handful of lines of well documented emacs lisp config and a few packages and you're ready to go. Gdb is actively developed and used and works just fine. It's used by professionals. We developed software to land on the moon using punch cards. Nothing anyone is doing could be more complex than that. So it doesn't matter what editor you use, as long as you learn how to use it and how to improve it, just like any other tool. Edit: eglot takes a handful of lines to configure and suddenly you have this capability https://github.com/joaotavora/eglot I use this daily. And when I need to, I use gdb-many- windows. For that graphical experience. Extensibility is in the name. When the core of the software is powered by a fully featured programming language, the sky is the limit. You still have to build your own airplane though. I started in visual studio land and thought the same thing about gdb when I first started using it. Then you realize that people got shit done long before visual studio came about, had just as much complexity to deal with as now. Archaic implies outdated and incompatible with modern. But Emacs is just old as in mature, just like gdb, and both are alive and well and maintained. Archaic is the carriage. Emacs and gdb are dinosaurs. Dinosaurs that have evolved into birds. Edit: made the last sentence flow better

Software engineers are ridiculously passionate about their IDE. This sub is an example of this. Forcing them to use one in particular is just stupid. I could resign just for being forced to use a specific editor or a specific OS. It's such a red line that tells so bad how they see engineers in the company, it's like parenting management.

How will the company know if $dev1 isn't using VSCode? Plain text doesn't force devs to use the same tool; I look at code with my color theme and my keybindings and my editor, and you do the same with your editor. As long as a team can share code, who cares how each dev looks at files?

In a business environment, there's more to it than "but it can do X!"... Being able to pair up with a colleague and hand over your mouse and keyboard is a big plus in my book... Being able to review code without being completely weirded out by the unfamiliar look of the IDE is a benefit, too.. Confusing your pair by wildly jumping around 500 buffers doesn't really help that much.. It's a bit like driving a car on your own.. You can accelerate harshly, you can take tight corners and feel the Gs.. It might be fun for you, but as soon as you've got a passenger, you're risking them puking into your nice car. As much as I enjoy using emacs, I totally understand the desire for uniformity in a work environment. Should be a least resistance-decision by the developers, though.. Not a management decision.

I would quit in the spot if I was forced to use windows, and I'm in academia.

In my experience while Emacs is great in its own respects and basically unbeatable when it comes to configurability, file/code/text navigation, Linux terminal integration, file and note management etc Emacs is not so great when it comes to integration with modern software tooling. Consider for example Jetbrains IDE's. Each IDE varies in its power, I'm most comfortable with PHPStorm so I'll take that as an example. PHPStorm comes with integrations for basically every tool in the sun, the configuration is just "this tool is located here", PHPStorm usually auto-configures this when it can. That's all fine and dandy, when it comes to integration command-line tools and stuff, this is still possible in Emacs, it just requires tinkering or if you're lucky there's a package. Jetbrains is just more convenient in that respect. Where Emacs really falls short when compared to PHPStorm (jetbrains IDEs in general) is code understanding. PHPStorm comes with so, so incredibly many suggestions for your code. "Oh, you wrote this is_null($var) in php 5.4 10 years ago? That was fine then, but we use this now. Press enter to replace this code with the modernised version" There are 100s of these, it checks for weird boolean expressions, it can replace complicated expressions with shorter ones, it can find snippets of code that have been copy-pasted throughout your codebase with the option to automatically try to refactor it into a reusable function if you want, it has very reliable refactoring tools out of the box, it has project-wide symbol support, it has outlines, it has so, so, so much built-in. A lot of which is just not available to Emacs (nor VSCode!) What about LSP? LSP is cool, and I love the idea. You get the top 10% of the most important refactoring and code intelligence tooling through open-source language servers. They're easy to install, they're cross-platform, they're usable in practically every editor there is. This is really neat, it really helps many editors become more intelligent coding tools. Vim & Neovim, Sublime, Atom (for those who still use that :c), Emacs and many more. But.. LSP is not as intelligent as what Jetbrains IDEs provide most of the time. Not even close. So why is VSCode popular? VSCode only has LSP, right? Well, yeah. VSCode is also not as intelligent as any given Jetbrain IDE (nor as intelligent as Visual Studio!). But what it does have is: Approachability, speed, cool looks, great built-ins, it's modern, it's reliable, despite not being as customisable as Emacs, it's still very customisable. And, VSCode has possibly the most vibrant plugin community I've ever seen in any editor. Yes, Emacs has countless ancient and magical plugins (looking at you magit! 🤤), but VSCode lets people built plugins on top of the JS ecosystem. Everybody and their grandma knows JS! You have charts, you have bite-sized code intelligence tools, you have markdown, you have real-time inline code evaluation, you have people building businesses on top of this plug-in ecosystem. Lastly, I didn't really touch on this but... Emacs is still insanely powerful, it can do many things other editors can't. Org-mode, magit, evil-mode, e-lisps configurability and tramp are excellent examples of the best the Emacs ecosystem has to offer. No editor nor plugin really comes close. Those who want to become the absolute masters and owners of their computing stack will fall deeply in love with Emacs, I almost did. But it's ancient, it's old, it takes days to get to the point where you can _use_ it to the point where you're 10% as productive as in VSCode. It takes _years_ to become proficient. Emacs is for tinkerers and greybeards. Not for those who "just want to get shit done™". VSCode gets you just as much code intelligence, basically out-of-the box. All the customisability the average dev needs, and plugins for whatever's missing. When it comes to "heavier" coding, Jetbrains provides the power tools. The analysis, the refactoring. For what it's worth, I'm currently using these programs for my development: - I use vim emulation in basically every coding editor - Jetbrains IDE's for working on projects and my job. - Sublime Text for quick edits to small files, some python/js/html sometimes, large text files - Neovim/vim for anything in the terminal, server stuff, config stuff, some git stuff, sometimes just for fun. - Sublime merge. It's not Magit, but god is it good. Fast, _excellent_ search tools, intuitive UI. Not very customisable at all, but it really does 99% of what I need, I use git in the terminal for the rest - Obsidian MD. I love org-mode, but I feel like I need to _live in_ emacs to be able to switch to it. Obsidian is no org mode, but it's still fantastic for managing tasks, keeping track of stuff, taking notes etc.

Mandating repo tooling is smart. Expecting people to use editors that respect/use that repo tooling is smart. Writing PR gates to ensure that repo tooling is run, or has been run, is smart. Mandating editors is none of those, and is a bit dumb. If it should be mandated, it should be automated as a PR gate. If it can't or doesn't need to be automated as a PR gate, it isn't worth mandating - that's the basic SWE rule.

> Emacs can do something it's also A. Not good enough B. Takes too long to configure instead of just getting the job done. Sadly, that's literally been my experience at work (primarily SQL server related stuff). In my hobby forays (web front end, Rust/C++) as well, though I have more tolerance for configuration time there. Jetbrains IDEs have been the best most powerful experiences, but vscode is good enough and free as in money.

Mandating a certain editor and even (to be less specific) mandating *how* you reach a certain goal at your workplace is a red flag for me. Like you're employed, not a serf. I hope the "serf" wording above makes sense, had to use Google translate and guess since I'm not a native speaker. What I mean is that your services as a programmer is what is bought, not your autonomy as an individual.

I mean… if you use Emacs and not VSCode , what will they do about it? You get the work done in a timely manner and it passes the code review so what?

I think it's a good practise to be familiar with IntelliJ and/or VS Code, even if you can do everything you need in Emacs. There are a couple of ways it can be important: 1) the company relies on you using a specific tool because they invested in plugins or features of that tool and you need to be able to use them and 2) when pairing and screen sharing with others sometimes being in a "super editor" like Emacs can be too distracting. I've had people say open your editor when I am looking at code in Emacs because without the familiar visual anchors like the side bar or output pane they are lost. It is somewhat sad. If you don't pair with people though, and the first thing doesn't apply, then just leave any company that mandates editors for no good reason. (I know not everyone can easily leave their jobs but at least take it as a red flag).

Same, Installed linux on my lab's computer the day I started, even when my advisor wasn't happy about that. But now they understand I can work great with it and it's actually beneficial long term. I'd hate to work for someone who can't be accommodating.

Nothing, everybody has the right to use what they want/need. I find ridiculous to shame/frown upon somebody on editor preferences.

[deleted]

I agree with everything you said. I work with web apps in python and PyCharm is far and away the best editor for the job. I have an LSP + emacs setup for smaller scripts. But working on a big Django project in pycharm is a whole different world.

Exactly. I use Emacs for note taking with org-mode, as my git client, and as my default editor if I don't have a better specialized tool. For Python development, I really *want* to use Emacs, but I haven't managed to get it all the way there yet. lsp-mode + pyright is close, but pyright is really pedantic, not the easiest to configure, and basically is only a complaint factory. It doesn't offer solutions like PyCharm does. Also, for whatever reason, auto-imports break like 75% of the time. One of these days, I'll see if I can set up python-lsp-server instead.

>How will the company know if $dev1 isn't using VSCode? I wonder if the company plans on using vscode's pair coding thing (not sure the name) to do code review? Might be worth just having vscode ready if you needed it.

A previous VPEng tried that, and I eventually told him to fuck off and stop distracting me from getting my work done. If an employee is using any reasonably sane tool (like, ruling out Word or TextEdit), and they’re meeting their deadlines, then leave well enough alone.

My school couldn't afford anything other than Linux and I attribute those early experiences to me landing an early job at FAANG.

Your usage is both correct and conjures up a certain scene in a Monty Python film

I have a ton of Emacs-centric workflows that have evolved over the years. If I was forced to stop using Emacs, I would lose all of those things, and have to either (a) spend time trying to find out if there was a useful equivalent in IDE(tm), or (b) become frustrated and lose those seamless efficiencies entirely, or (c) spend even more time learning how to extend IDE(tm) to reimplement the things I used to already have. Switching to IDE(tm) may very well provide some new benefits, but it's also *losing* you some (maybe a *lot*) of the beneficial functionality that you *already have* in Emacs, and which may not exist at all in IDE(tm). If you need to argue the case, make sure that this is clear, as the other person may be under the misapprehension that IDE(tm) is effectively a super-set of Emacs. Part of the problem is that the people trying to tell Emacs users not to use Emacs very likely don't actually know what Emacs *is* -- as evidenced by the enthusiastic posts we see here occasionally from people who have finally given Emacs a try after years of ignoring it, and *only then* started to comprehend what it was they'd been ignoring.

While I agree with a lot of what you said, LSP servers capacities varies wildly from server to sever and language to language. Prime examples I’ve noticed is Solargraph for ruby will change something like `if !true` to `unless true` or change a multi line `if` into an inline one. This fits a lot with what you you were saying of what php storm can do. But it’s documentation support isn’t that great especially for newer version of ruby (3.x). On the other end you’ve got `gopls` that won’t change code like this but has a pretty deep understanding of what you are writing and will suggest very good actions (the lightbulb in a Jetbrain product). Makes me a lot more productive. LSP as a protocol has the capabilities to do what Jetbrain’s product does but it’s up to the server to implement all of them which is pretty rare so far. It’s getting much more common with some built it to the language like deno with `deno lsp`, nothing to install!

My job is to deliver plain text files full of working code. If someone wants to tell me what tools to use to accomplish that, they need to justify why it matters to anyone but me. At this point, the only emacs feature that matters to me is that I'm productive in it. That trumps any feature of any other IDE.

You are trying really hard to not use Emacs(and that's fine), but I mean, you could just keep Jetbrains,vim,emacs and discard sublime text/merge/obsidian. Personal preference of course, but for me, the less programs I have to wrangle with the better. Like why can't you just treat emacs/magit or emacs/org-mode as different programs? start them as different processes? Just a suggestion since you find magit and org-mode to be really good. I have use webstorm, reported two bugs more than a year ago (it gives warnings when it shouldn't) and they still haven't fix it. It's annoying you can't do anything about it. I guess for Java they are more polished. Here's a recent one I found: https://youtrack.jetbrains.com/issue/WEB-57184/wrong-warning-about-unused-definition-in-javascript?s=wrong-warning-about-unused-definition-in-javascript

I find this kind of comment interesting because, like with Java, I always wondered how people can manage large Python projects. Maybe it is these IDEs providing the needed assistance.

Well to me the main thing that stops me from VScode, PyCharm, Jetbrains and countless others is exactly that. Other editors have come and gone. I realize these days most of the editors have plugins to support various languages. But they come and go (see Atom editor) and I don't just write code in a some language during my day. But I write emails (same workflow/keybindings). I write notes (same workflow/keybindings). I organize my tasks (same workflow/keybindings). I connect to remote machines, kubernetes clusters and edit files there (same workflow/keybindings). And more... That consistency across things I do is worth its weight in gold. So yes, perhaps editor doesn't have as many refactoring tools and similar as Jetbrains or VScode for some languages. But writing code is not where most of my time is spent usually even though I have been software engineer for well over 10 years. It's dealing with all the other stuff and knowing that my workflow won't be disrupted by some change in the tooling without me being able to fix it myself by changing a variable or writing a few lines of lisp.

As an immediately relevant anecdote, I've been working on a vue project and the lsp-integration has what feels like a memory leak that I can't be assed to hunt down and fix, so it's off to VScode to actually get things done. > I have also gotten into long arguments that devolve into "feature-offs" where I have to explain how a feature VSCode has is also in Emacs. I feel like the feature-offs are a lose-lose situation because sometimes feature parity is not the same as how effective a tool is. I've yet to find a git interface that I gel with more than magit. Of course VSCode has gitlens and integrations, but I just don't vibe with it as much. Lina has coded an entire GPU driver in Kate in what felt like a few weeks so what is even anyone's argument for or against a particular IDE? > laughed at me because GDB is "ancient" and VSCode's debugging is modern and actually gets stuff done I like the idea of discussing pros and cons and learning from the perspective of my coworkers, but it's pretty rude to ridicule anyone for their choice of tooling. > It seems like even if Emacs can do something it's also A. Not good enough B. Takes too long to configure instead of just getting the job done. At the end of the day they're just tools to accomplish a goal. I feel it's always worth trying out something new to see if it can't be faster or more effective at the task at hand. There's no council that will call the wrath of the machine gods upon those that use both. > So please give me some advice on how I should combat this encroachment on my peaceful Emacs pasture. Or should I just give up my goats and switch to VSCode? If someone comes with a recommendation and reasoning, I'd give it a fair shake. If people are telling me to use X because X is better and Y is bad, I tell them to kindly fuck right off. Plus, no reason you can't use both for different things - sometimes I need Krita, sometimes I need MS paint.

we still need to know why OP management wants to switch, tho. I was fired once for not "reading the room" over this, the "last straw" for the CTO. But other than that experience, I've had more understanding bosses and coworkers over my tech choices.

Damn, beautiful comment. Kinda teared up a bit.

An IDE makes larger python projects much easier to deal with. I think well defined coding standards and docs go a long way, type hinting has been a massive boon. I don’t do anything in python these days without type hints, love them. Python really benefits from a full IDE. Where as newer, compiled, typed languages like Rust have very good LSP support where the compiler can do most of the heavy lifting. In those cases emacs + LSP is a better experience for me.

Yes. The static code analysis of JetBrains products is unbeatable. This reduces foolish programming errors, and at the end of the day is all that matters. I use EMACS all day and love it, probably more than it deserves. But as IDE I prefer to use JetBrains products.

I totally agree with you. I still use emacs, because I'm one of those graybeards who has used it for decades. But I don't recommend it to anyone else.

You cant convince people of things they don't want to believe. Did you get vaccinated? Why? Can I convince you that you made a mistake?

Hahaha! ❤️

>Everybody and their grandma knows JS! ​ And oh god it shows.

Just the other day I replied on HN to the comment that was: "> I can just use VS Code.", and I wrote the following: - So how many VS Code extensions have you written? How many workarounds have you invented to make your workflow more productive? - Do you use VS Code for automation? Does it run any tasks for you? - Can you for example, open a page in your browser, send it to VS Code instance and let it collect all the links on that page and show them? - Can VS Code work as a window manager? Email client? Maybe RSS reader? - Do you read PDFs in VS Code and make notes and annotations? What about epubs? djvu maybe? I read PDFs in Emacs, because e.g., I can toggle "the night mode", and the colors in PDF would match my current color theme, I can then comfortably make my notes and annotations. - Do you do project management in VS Code? Is there a way to calculate the number of days between the two dates? Convert that to hours? - Do you test HTTP requests in VS Code? Can you send a request, then feed the results to a Python script, then based on that - create a SQL query and send it to a DB, then transform the data with Clojure and finally create a table with the final results? Can you do that in VS Code? Because I do something like that in Emacs almost every day. - Do you plot sequence diagrams in VS Code? Or do you write math formulas? Do you work with research papers? Does VS Code have support for scientific citations? - What about prose? Do you write plain text in VS Code? I'm typing this in Emacs. I have syntax and spell checkers; integration with Grammarly (I know VS Code can do that one); I have Google translate integration; I have dictionaries and thesauri. - What about some advanced version control? Can you change the editor settings depending on what git worktree you're in? Can you select several files in the directory tree (including sub-folders) and see the git log pertaining only those files? Can you edit the directory tree using regexp-replace or multiple cursors, or do something like "find all the files larger than 3Mbs that were created between March and June, and rename them all using regexp pattern?" > I was wasting company time playing around with Emacs rather than using Pycharm. It doesn't matter what tool(s) you use if that makes you productive. If I can do something cool in Emacs in a better fashion than someone using VSCode or IntelliJ, it's not because their tools are deficient, but because **I know my tool**. If you want to win arguments, then you'd have to know your instrument to the point of being able to shut down skeptics. Choose whatever tool makes you feel empowered and learn it until you gain powers. Finally, if my boss tells me what keyboard I should use, or mouse, or IDE - that would be the last time they've spoken to me as my manager. Don't work with such people. Life is too short, don't waste yours on idiots.

I'd probably change jobs if someone forced VS Code on me. Might be easier to set up, but that can never compensate for such an inferior workflow

Hear, hear! Interestingly, my coworkers have generally treated my Emacs use with great respect, and even a little fear. But I secretly have the theory that I would gain a productivity bump if I switched to Jetbrains for my Python development, simply because of the refracturing tools if nothing else. I simply have not had the two weeks to be unproductive in. I hasten to add that I will never ever give up emacs in general.

I rarely worked with others but the few times I've seen them use IDEs or VSCode I would have been laughing on the ground if it wasn't for keeping my job. It was a all rants and sluggish struggle to understand anything. Not including the regular freeze. I actually had to show many how to use git, or code scan or simple edit tricks to avoid wasting time. I don't promote emacs much anymore, but now that I've used it on company desk and time .. I'm now confident emacs gives me enough to work fast (even with my subpar / borked emacs setup). I'm sure jetbrains or other IDEs have solid piece of work in them, but not enough for me to switch. And I really appreciate the ability to script stuff.

> We developed software to land on the moon using punch cards. I started developing with punch cards, eight years after the moon landing. If you had any idea how incredibly slowly we developed software back in the day you would never ever ever ever ever ever say what you said. :-) I can accomplish in a day what used to take me a week, or even a month. I can accomplish things I could never have thought of when I first started coding.

> At the end of the day they're just tools to accomplish a goal. A spade and a backhoe are both tools. But one of them will let you move earth hundreds of times faster than the other.

> I have use webstorm, reported two bugs more than a year ago I used IntelliJ family tools - Webstorm, Pycharm, Rubymine for over seven years. I loved those. I have found numerous tricks and used some obscure undocumented features. I've participated in plugin development. I have discovered, reported and discussed plenty of bugs. That was seven years ago. Then I switched to Emacs. I still sometimes get email notifications from YouTrack when someone comments on the bugs I've reported. Some of them go back to 2009. Still not fixed. Well, someone would say, Emacs also has old, long-standing bugs. The difference here is that most of the time there's a workaround. In IntelliJ - you just have to "get used to not having things if they are not there".

Ask in team who is already very familiar with VSCode, ask them for tour. Chances are, VSCode have some nice stuff, so copy that into Emacs and call it a day BUUUUUT do have VSCode installed and configured on your machine. Tell your boss that anyone can immediately switch to VSCode when they come by your PC. Check with your boss if that is enough.

A good workplace lets the craftsman use his favourite tools. Ideally every programmer uses the editor they are most familiar with so they spend less time wrestling with text and more time expressing themselves and thinking about the problem at hand.

What is repo tooling? You mean CLI commands that manage all the git hosting capabilities used by team in project? ​ Why isn't that CLI already? Why are we back in crazy land of GUI-or-go-\*\*\*\*-yourself? :(

> Emacs is for tinkerers and greybeards. Not for those who "just want to get shit done™" I disagree. I've used all the tools you listed. I am also a die-hard Vimmer. I use vim-integration wherever it's possible. And I use Emacs specifically because I want to get shit done instead of wasting my time, clicking around, trying to get one [incompatible] app "to talk" to another. It takes time to gain efficiency and become a proficient and capable software developer, regardless of your path. You may choose to hop from one tool to another, juggling between them, getting used to idiosyncratic, specific features, keybindings, differences in their UIs, etc. There is a plethora of awesome tools out there to choose from. However, there's another path. Of all the different things in computing, there's still no software in existence with the extensibility of Emacs. And you can learn Emacs to the degree where it can be used as a binding "glue", that can work with multiple tools "talking" to them. It feels extremely liberating and empowering when you gain complete control over things on your computer. I chose Emacs not because "I have to live in it" now, but because I learned it to the point where I don't have to leave it. I can control things in my browser from Emacs. I can edit text in any input box, in any app using Emacs. Whenever I need to automate something, small or big, often, there's no better tool for the job. So, please don't call me a graybeard who wastes time. The time that "I have wasted" learning Emacs paid dividends many times over. And still does.

That can't be further from the truth. Modern Javascript is extremely confusing. Even when compared to Clojurescript (which works on top of Javascript). ECMAScript specification is about over 800 pages long. It's slightly shorter than "The Lord of the Rings". It's okay when people don't know all the details of a fiction book. But it's disconcerting when people claim to know one of the most popular programming languages, but if you put them to a test, they'd get lots of things wrong. And it's understandable, and not surprising at all. As I said: modern Javascript can be very confusing. It's just wrong thing to say that "everybody knows JS". The days when javascript was a simple and small language are well in the past. It would be correct to say: "most programmers don't know Javascript", and that would be true.

What you described above, and what your argument is mostly revolving around, is the self code introspection that JetBrains ides have. This is not magic, that can be implemented by the community the same way it was implemented in a proprietary tool like any of the JetBrains ides. The difference here is that - it's a company with bigger resources, thus the result you are seeing. I am at the moment for example using neovim for java development (and it still gets the job done 99% of the time) the code introspection in JetBrains can be replaced by other tools like SonarQube for example which does the same - actually, no its much better than what Intellij has for example. So yes i see your argument, what i am saying is that it is not some sort of magic that can not be replicated - it exists purely because that product has had more resources (money, time, man hours etc) to spare developing and polishing their tools. Off the top of my head, emacs or neovim can piggyback on local instance of sonar to do the same probably for example (crude, but you get my idea i hope)

I was just making the point that it's not always the best thing to be the odd one out, because it makes teaming up with others difficult :) Questioning the reason why the change for a very specific IDE is another, albeit also valid, point :)

>I tried to explain that you can use GDB in Emacs, and someone literally laughed at me because GDB is "ancient" and VSCode's debugging is modern and actually gets stuff done. What does this troglodyte think that VSCode uses under the hood for debugging C and C++? Let's check: > Linux: GDB macOS: LLDB or GDB Windows: the Visual Studio Windows Debugger or GDB (using Cygwin or MinGW) https://code.visualstudio.com/docs/cpp/cpp-debug

Im saying its poorly written js mate. I agree with you.

Yeah, totally agreed. LSP varies wildly. In the comments I see that newer languages/developments (rust, deno) tend to have better LSP integrations and that makes me happy. LSP totally does have the power to displace the intelligence Jetbrains products provide if communities come together. I just haven't seen it happen for the languages I use most unfortunately. I do think that the future here is bright. With LSP and treesitter, the open-source community has all the tools needed to make our editors as intelligent as we want. It's only a matter of doing it!

Oh yeah, Emacs and Vim are generally respected and for good reason. I think a lot of the value in Emacs comes from being able to customize your editor to _your_ workflows. IDEs are intelligent, but they're not very adaptable. Obsidian does most of this for me, but it doesn't integrate with my coding environment. I loved being able to just yank a commit from magit and paste it as a link in a .org file, "I think this commit is related to ..." and then link to a file in another branch etc etc... It's how I work best, given my ADHD I benefit so much from externalizing work context onto text. Nothing does that better than Emacs, no contest.

I didn't intend to give off a negative connotation with what I wrote. Emacs is great. What I meant is, there are many developers who when they get to their desk at work just want to sit down and work on tickets and code. They don't really care what editor is in front of them as long as it doesn't freeze, provides ctrl-z and ctrl-y, ctrl-c, ctrl-v and ctrl-x, and just generally "works".

> telling me flat out I was wasting company time I'm confused, is customizing Emacs a waste of time, or is it explaining how and why you want to use Emacs at work that is a waste of time? > So please give me some advice on how I should combat this encroachment The easy answer is to just go work elsewhere, if that's an option to you

Corporate control over the machines their employees use? If they decide that you get only a particular IDE and you can't install any other software and you *certainly* can't exfiltrate proprietary source code to another machine... Well, you're out of luck. Best to quit if it's a deal-breaker.

Honestly at this point I think I'd just accept somebody writing code in Word. It sounds abominable but hey, it's just a glorified typewriter either way.

[deleted]

Leave. Find a place that respects you and your workflow, nothing beats the above strategy.

The biggest benefit to my new job, aside from the money, is not having to use a locked down soul sucking POS windoze laptop.

Even on small Django projects, `lsp-mode` can't understand/find some objects methods or attributes and the completion if kinda slow. I'm using Emacs 29 (from the master branch) will all the optimizations on. It's not as good as Pycharm with Emacs keybindings, I'm missing Magit though.

Big corps have a list of "acceptable" software that can be installed on their windoze laptops and emacs isnt going to be on that list. Visual Studio, VSCode or notepad++ are your choices.

I'd just show them the window splitting, switching, and nav. For me, that's such a big part of the value-add of emacs. Indirect buffers and window narrowing is cool too. Send them some Emacs Rocks! videos.

I'm curious what exactly is missing in an emacs/pyright setup. For years it was missing auto import, but I feel like that's now on par with pycharm. The only things I can think of are: - Template debugging - Template autocomplete (somehow?) - Autocomplete of related fields e.g. `Pizza.objects.filter(topping__...`

As long as they don't force me to follow suit, I don't care to be honest. I know for a fact that I'm a lot more productive with Emacs (I used to use IDEs/VSCode before)

Programmers are craftspeople, and craftspeople are passionate about their tools. You wouldn't tell a blacksmith her hammer is wrong because you prefer a different style, right? So why should we change our tools because management dislikes them? The relationship between a craftspreson and the tools of their trade is a personal one, as we tend to put a lot of time into building and tweaking them to be *just right*.

This is my workplace (except you need special permission to use notepad++, no joke). It's frustrating because there are so many workflows I'm used to in emacs that don't exist in VScode, even through plugins, or are multistep things that involve clicking around.

It's probably some guy who spends a lot time refactoring old code and less time trying to think about wtf their algorithm is doing. Also, I was under the impression that the programmer gets stuff done. Not the debugger

Emacs and gdb (and vim) are machine guns. Machine guns evolved into the Gau 8 avenger 30mm brrrrrt machine.

This was my thought also. It's the only reasonable explanation. But even still, use Emacs day by day and fire. up VSCode for those pairing sessions.

Well it depends. If a machinist has a favorite lathe but goes to work at a different company he has to adjust. But in this case there's zero effective cost to let a guy use his favorite tool. It's like telling a writer to use a pencil when he has a trusty old fountain pen. No reason to stick to one or the other. Why not use both? They're good for different cases after all.

That's fair. I kinda lost the plot there for a bit.

[removed]

[deleted]

[deleted]

This is a little tangential to this post but I feel this 1000%. I’m a lawyer, and my programming hobby has filled me at such rage over the tools we are forced to live in (Word and Outlook). There is so much time that lawyers waste doing such insanely basic shit like making sure defined terms are used consistently or plugging in exhibit numbers manually into long documents that any sane tool for the job would take care of automatically. Or even though we have clients that need task by task billing, our software doesn’t track that, so I have to manually add (0.8)s and (2.5)s to my time entries and mentally make sure they all add up. My frustration at the tooling alone makes me want to quit my job sometimes. And I wouldn’t have known to be as frustrated as I am if I didnt get a taste of something better in Emacs

> An IDE makes larger python projects much easier to deal with. Do you have any specific things your Python IDE has that you'd miss from an Emacs+LSP setup? I ask from a place of ignorance. I have never used an IDE productively. All my career I've spent in the command line and in Emacs using, as you say, strongly typed compiled languages. My use of more dynamic languages is limited to smaller scripts. The advent of LSP has been great for my C and C++ work, but I wonder what am missing. Actually, I forgot about the year I spent programming Java using a combination of IntelliJ and Emacs. I would use IntelliJ to run tests, drill down to specific errors, debug, explore code, and do light coding. I would use Emacs for "heavy" editing and editing any file in the project that wasn't Java code. Are these the kinds of things you find a Python IDE does better than Emacs?

Your job environment or coworkers seem to be toxic and to have some kind of dictatorship approach to tooling. If my employer tried this with me, I would probably look for a new job and let them work with their dumped-down tools, however they want. When I see how painfully slow people do things in VSCode in screensharing sessions, it takes some effort to restrain myself from taking over. If they really cannot see, how me using Emacs saves time (because I am already proficient!), then they apparently do not have a clue what they are talking about or are blind or whatever. It would be silly to throw a wrench into smoothly running gears and would be wasting my time.

I find it interesting that so many people think that PyCharm is superior, while nothing I used did satisfy my needs for Python better than Emacs so far. Sure it needs time to configure but when it works it rocks.

I do recommend it, but only if they want to invest in their future.

Emacs/pyright (using Doom Emacs with minimal customization) has been unreliable at best for me. Autoimport works like 25% of the time. It will often fail to see packages that I *definitely* have installed in the project's venv and complain. It frequently complains that the workspace has too many files to track, even though 90% of them aren't Python files and shouldn't be tracked anyway. SQLAlchemy is a nightmare of type errors, and installing `sqlalchemy-stubs` into the venv doesn't help.

Why not just keep Emacs open in a separate window for Magit?

I'd be fine with someone using something like Word or Notepad as long as I never, ever, **ever** had to watch them work. I would be screaming internally loud enough to rupture my eardrums from the inside.

I mean I could but it's just easier to have everything in the same place.

>This is my workplace (except you need special permission to use notepad++, no joke). It's frustrating because there are so many workflows I'm used to in emacs that don't exist in VScode, even through plugins, or are multistep things that involve clicking around. How do they 'stop you' ?

The IT team sets up Windows group policies that prohibit execution of unwhitelisted binaries.

Oh wow, that must be depressing. I'm going to guess that renaming emacs.exe to explorer.exe and things work ?

I would search another job. Picking your own tools is one of the rights every developer should have. I don't care what is your favorite tool. As long as you are comfortable and proficient in it you should be free to use it. Period.

No. Also they've recently installed "Windows Defender Smartscan" so you get two separate error messages if you try to do that.

That bites, I guess emacs in the browser it is then !

> Apple is a disgustingly bigoted company Please come down to my genius bar in Queens. There's a wokester genius there who I wouldn't mind being disabused of his fanboy snobbishness regarding his employer. *Disclaimer*: I avoid Apple not for any other reason other than my cheapness. I also don't see how a multinational consumer products company could be racially prejudiced, much less "disgustingly" so.

I mean build tooling, test tooling, linting and style tooling - all of which have editor integration, and can be done with standalone CLI tools.

I'm not the most seasoned Emacs user, but I will say I don't blame anyone for not using Emacs. I'm still getting Emacs up to a point to where it surpasses VSCode before I start using it everyday at work. There are features that people forget about in Emacs that can speed up the development process a little bit. One thing that everyone seems to forget about skeletons, abbrevs and auto-insert. Skeletons can give you an interactive way to insert text, but you can opt out of a prompt: (define-skeleton hello-world-skeleton "Write a greeting" "Type name of user: " ; <- this the prompt "hello, " str "!") (define-skeleton hello-world-skeleton2 "Write a greeting" nil ; <- no prompt here "hello, " str "!") You can also bind skeletons to abbrevs. I won't go into detail, [but here's what's in my config](https://privatebin.net/?a0b69b12addeefc2#7JX7TmB1EHesi53oeCdc9nS9VhpdLuAmEaGTv2CV4mxj) and I'd suggest looking through `Autotype` in the info docs (`C-h i`). `Forms` is another thing people don't seem to really know about. But all of the above to say that Emacs *can* have the ability to some of if not more than VSCode. As others have said, the Jetbrains IDEs are a different story. They're built to actually understand the code you're writing. It's quite possible, with features like auto-insert and skeletons, to replicate some of the functionality that, say, IntelliJ does. For example, say you `find-file` into a new file for some Java project. When you first enter the buffer, you could setup a prompt to create a class, enum, interface etc. and then upon a selection, you have the basic relevant code for whatever the selection was made auto-inserted. Or you could just quit the prompt with `C-g`. Granted that takes some time to set up as well as recreating other smaller features that IntelliJ has. [JDTLS](https://github.com/eclipse/eclipse.jdt.ls) can do *some* of this, but at the end of the day it's not a replacement for IntelliJ and I don't think JDTLS intends to be such. Speaking of LSP servers: For me, they can be such a coin toss of whether or not they're even worth installing outside of having basic completions and code linting and that of course transfers to VSCode, not just Emacs. Maybe they'll get closer to what Jetbrains's IDEs do, but I don't think that'll happen in the next couple of months or really even the next year. So that's...not really a point in Emacs's court, but it's not one in VSCode's either. However, just as of note, Emacs does do well with Common Lisp development. The only thing that *might* beat it is the LispWorks IDE. I'm going to guess, though, that you aren't doing Common Lisp development at work. So to give you advice, you're going to have to showcase some of Emacs's capabilities and how it benefits you to use it over VSCode. It's definitely possible, but it requires some setup.

A couple things that come to mind, these could probably be done with some tinkering in other environments, but I haven’t spent the time to look too hard. I mostly work with Django. And most of the things I like are around completion since I think a lot of project admin stuff is doable just as easily on the cli. * I find the debugger to be easier to use than gdb. It’s nice to run the server in debug mode and walk through a request in the gui. * completion for Django templates is very good. It will find static files, custom tags, etc. * Autocompletion of related fields in Django models is very helpful. * multi language support without any config. I can work with JavaScript, html, and css all embedded in a Django template and completion, highlighting, etc all just works.

[deleted]

"Help, Help I'm being repressed!" https://www.youtube.com/watch?v=ZtYU87QNjPw

I have found that discussing editors/IDEs with non-emacs people (or even with less experienced emacs users) is usually hard because we have very different values when it comes to our workflows. IDE people tend to value features while new emacs users (and also vim users by the way) seem to value frugality. Both focused on productivity. In my opinion the point is not productivity but rather ad-hoc abstraction. The way I see it is that emacs is (by 2022 standards) generally a crappy editor built on a kinda-crappy dialect of common lisp. The value proposition is neither the features nor the stability, it's the radical flexibility of allowing *you* to write exactly the right tool for the particular job you are doing. To a user unwilling (or otherwise unable) to write elisp as an integral part of their workflow I would recommend a different tool than emacs. It is true that it is common for me to spend more time automating something that would take to do manually. I think it is almost always still worth it because once I automate it because I am not smart enough to simultaneously think about the problem I am trying to solve and do repetitive tasks that break my train of thought. Again, it is not about time, it's about abstraction.

> IDE people tend to value features while emacs users value frugality. Perhaps you meant "parsimony," as in a parsimonious statistical model with fewer explanatory features. But I'm positive certain sure frugality (cheapness) is a strong predictor as well.

As a multi-decade user of Emacs, I'm confused about the "crappy editor" part of your assertion.

Vanilla emacs is not great. Since you have been working with it for a bit you probably can atest to how frustrating it can be to find yourself having to work with vanilla emacs for more than a few minutes. It's unintuitive and it can do little more than the basics. I have also been working with emacs for a minute (around 15y) and I have wound up changing nearly every aspect of it over this time. I find that emacs is more like a framework for building an editor bundled with some default application that nobody uses or cares about. Contrast this to vim where a vim user will be fairly happy to work on a michine that just has vim installed. Some colleagues can roughly reporoduce the relevant parts of their config in little more than a few minutes and approach normal productivity levels. This is just not feasible for the average (experienced) emacs user.

But I'm *not* frustrated with it, and I spend hours coding and writing text in Emacs. I've used GNU Emacs and XEmacs since the late 80s. Evidently "the basics" with very few additions satisfy my editing needs. Perhaps you should be more specific about the things you find deficient.

It's hard to switch between files/buffers without some 3rd party fuzzy matching framework, out of the box support for even basic stuff like markdown is absent or lacking, up until recently even integration with the os clipboard was an arcane art. Even common lisp editing is wanting without external packages. This doesn't even touch on more high level stuff like terminal emulation, lsp, version control, etc for which we have excuses of features out of the box. And I understand that for programs like vim that go full Unix in their approach. But emacs seems to have a crappy solution for everything out of the box. I think that the most frustrating part of is that there are great and mature options for everythkng I mention but due to some puritan conception of "freedom" everyone is (for all intents and purposes) forced to trust their security separately to magit, lsp-mode, straight, ivy, vterm, etc. (Sorry about the random rant)

it is however true that GDB IS ancient, and unless you learn how to work without IDE features, you will be potentially less productive

So your complaint is really about FSF policy, and you don't like the work-arounds.

I used vs code for a while, it was ugly at first, then I made it nice. Then it got slow both in processing and input lag (all electron stuff suffers this). Intellij is great, minimal input lag comparable to stock Emacs. But their (java's) font rendering make me dizzy and it's quite heavy on the CPU. I use passive cooled computers, so I have to look out for my temperatures. Otherwise use whichever makes you happy. Emacs is an experience, vs code and intellij are tools.

Yes, my grievances with vanilla emacs are in a big part caused by fsf policy.

They are right a specific tool is always more streamlined than a general one and homogeneity of IDEs improves interoperability. That said, the converse is also true, that specific tools cannot solve problems outside their domain and homogeneity in mediocrity worsens performance. Exploit that.

[removed]

I tell them to learn their tools. I work with a lot of other people who think I’m a grandpa because I use emacs. I think they’re childish for running around in VsCode and saying it’s amazing because it has features like, gasp, backtab, or extensions (because nobody ever had that idea before) I tell them whatever editor they work best in is best for them. And I make sure I always have more features, and better performance. :)

>windoze windows\*

That comment is not valid for Jetbrains and VSCode, VSCode has been out for 7 years and there's no sign of microsoft stopping giving it any support given how useful it is and jetbrains has been out for 22 YEARS (and they have the BEST IDEs ever made).

I use beacon, hl-line-mode, and teach them how to read any information they need in emacs when pairing.