Emacs' user base is probably larger than any time before.

Granted, market share dropped because many people are never exposed to Emacs (or vim), directly start with PyCharm, VSCode, etc.

The question is: Can emacs increase its market share by becoming more approachable? Probably yes, on the other hand since Emacs is so different to the User Interface expectations of 2021, it will always have a hard time.

I myself have been a hardcore vim user for now 20 years, in the last 2 years I have made an effort to learn Emacs and like it quite a bit. I am also a VS Code user at work.

> Why waste time on fiddling with configs?

Config fiddling is not specific to emacs. The time I spent fiddling with VSCode configs and plugins, or IntelliJ config. The difference is that with emacs I see the result of my fiddling in the form of emacs lisp code that I can store and easily transfer from computer to computer and for the IntelliJ stuff I had to take notes on what I changed where so I could reproduce it.

I just find it a little saddening although very understandable that at this point Emacs just simply isn't better for writing code than any Jetbrains product.

Yes I'm very aware that there are plugins, stand-alone terminal tools to integrate, language-server-protocol and all that... But it's just that Jetbrains tools have far deeper intelligence about your code. By default.

I tried hard to like Emacs, and I did end up liking it, I just don't know for what workflow.

Knowledge work? Obsidian

Working on large coding projects? Jetbrains IDEs

Working on scripts or quick edits? Sublime Text or sometimes vscode

Need to make a change to bla.config from the terminal? (n)vim

I think the only advantage Emacs really still has to offer nowadays is that it's general enough to be able to do all of the above very well to quite well. None of those tools comes close enough to be able to do all of those workflows. Yes you can force sublime or vim into becoming a workstation for all of the above, but then it will become very bloated and slow.

It also doesn't help that Emacs is very archaic. I can teach you Obsidian, Sublime and vs code in a day, I can teach you jetbrains IDEs in a month, but it will take me years to teach you to use emacs effectively.

> Working on large coding projects? Jetbrains IDEs

IME language support and a desire for intellisense type features is a bigger factor. JetBrains generally has excellent support for that across the board, and it's sometimes lacking for some languages with Emacs

but size of the codebase doesn't really matter. At work we have a sizeable PHP codebase, and it's just as fast, if not faster, to navigable with ripgrep and fzf or editor plugins based on them as with a JetBrains IDE

> for the IntelliJ stuff I had to take notes on what I changed where so I could reproduce it.

IntelliJ (and all other variants), stores setting in code (xml) too. It's not as exposed or clean as a single .vimrc or .emacs.d/init file but it does the job. You can easily export the settings or have them auto sync via your jetbrain account.

Exactly that, plus it doesn't really serve well as platform. I mean VSCode renders Markdown previews correctly, not some ASCII based approximation. It renders images if I happen to click on one. Extensions can actually provide decent UI, thank's to that CSVs never looked better in my text editors.

I use Emacs's markdown mode for syntax highlighting.

I have never used live export, but looked for it in its dropdown menu, found it, and clicked it: https://i.imgur.com/0LG6nnS.png

It renders images and doesn't rely on ASCII for its rendering.

I agree Emacs could benefit from some polish, on the whole.

I compared it two what I see in my VSCode (https://imgur.com/a/u9naqVi) and fair enough, it got way better since I tried it last time.

Both the examples you give seem kind of arguable; I'd almost say they demonstrate the opposite.

The problem with VSCode's built-in Markdown previews is that they're not extensible, so there are a variety of alternate Markdown renderer plugins, for example to better work with the various wiki-like Markdown plugins. Emacs also has Markdown previewing, but it is extensible by design.

I'm not an expert in either VSCode or Emacs (I use both off and on), but inline image handling seems like it works better in Emacs. I've never figured out how to show Markdown images inline in the actual text editor part of VSCode (as opposed to the preview), whereas that's super easy in Emacs.

your argument that a text editor is not going to be popular because you need to install a dozen plugins to match what would be considered "modern" doesn't add up. I can see a thousand reasons why emacs is not popular but having to install plugins is not one of them. VSCode itself needs a bunch of plugins for certain languages, and even if you used it for the out the box languages (e.g. JavaScript) there's a couple of things missing that and IDE would have out the box (I agree that emacs would need much more plugins compared to VSCode).

Also, look at vim/neovim. They are still one of the most popular text editors (much more popular than emacs for example), look at the stackoverflow developer survey, in the last one neovim was ranked the most loved text editor and vim is ALWAYS ranked between on of the most used editors. You need a dozen plugins if you want anything close to a modern IDE, yet they are still very popular and used.

Agreed about plugins. The main nice thing about VSCode is that it installs and reasonably-configures needed plugins as needed (though Spacemacs does this, too).

> each theme needs to be implemented separately for every mode

I am not sure whether you're trolling or just completely clueless about Emacs (despite your claims of using it for many years).