random_cynic

> loads instantaneously

I've never encountered a case where VLC did not load "instantaneously". Unless you're using a baked potato this should always be the case. If you have proper benchmarks for different video files and different hardware, cite them. "Instantaneously" doesn't mean a thing.

Your other points are equally subjective and meaningless. Especially vim bindings, really? That is now considered a feature? And I don't get how directly changing the configuration from the GUI where each option is explained in detail is simpler than a error-prone process of modifying a text configuration.

You completely missed the point about man pages. It doesn't matter what the man page was written in, it's still a man page, optimized for viewing in text terminal. It makes no sense to use this format for web browser. Vlc also had a man page, but the developers know the difference between a man page and proper documentation. It's completely unsuitable for new users using any sufficiently complex application like a video player.

> https://mpv.io/manual/ Linked from straight from the mpv homepage

That's just the manpage in html format, are you kidding? We're not in the era of text terminals, there are so many tools for writing good documentation that this is just inexcusable. Take a look at VLC documentation (https://wiki.videolan.org/Documentation:User_Guide/), that's a proper documentation with screenshots that looks like someone actually put some effort into writing that so that it is understandable to new users instead of plugging words into a troff file.

Except for the edge case of controlling a media player from another application you've put no convincing use case for using mpv over vlc. So it's a personal preference not that mpv is superior to vlc in anyway (actually far inferior for most use cases).

Like how? What can it do that vlc can't?

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.

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

> Does it need to be popular or need more users to become maintainers?

Yes.

> I use emacs because I can't imagine using anything else that has half the features and is harder to extend.

Maybe imagine harder or (just an idea) stop imagining and see the real world?

> It's a programming environment that happens to have a text editor built in.

Read the history of emacs again. It originated as a set of macros over TECO to make editing easier (hence the name emacs). Editing is always the primary function, the lisp interpreter was an afterthought.

> That appeals to some folks but I can't imagine why someone interested in writing for publication would choose it over Scrivener or a word processor and why it's desirable to attract such users.

Read the linked thread again. One "such user" is RMS. That pretty much has been his goal since the 90s to make Emacs a better word processor.

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.

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

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

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.

Except that the latter results in far less number of clicks and shares on social media. That's really the primary goal of most news outlets rather than an objective reporting of the story.

> you're literally agreeing that the current way scoring works is bad for finding up-to-date answers

No you're "literally" misinterpreting what I said. I said there should not be any scoring system at all and people should select an answer based on its own merit, usefulness and how recent they are as per their own judgment instead of relying on other people. In fact this should be true for anywhere on internet including this site.

No, that was perfectly clear. That's why I said people should not use reputation or upvotes to judge anything in the first place including how good an answer is. They should read all the answers (including the more recent ones) and if needed do further research to find out which one is more updated or relevant at present. I do it all the time particularly for questions on things like git and even programming languages like python which have lot of better way of doing things in last 2-3 years than say 10-15 years ago.

The first one is not really a dumb question. They may have setup their .ssh/config so that the user is automatically taken from that file and password being rejected may simply be due to some other reasons (such as disabling password based login at the server). This is why people should not assume something or make a judgment.

The second question is more because of a misunderstanding about the particular platform. These type of lead-in questions are common in tech support and even many forums where they expect someone will get back to them with more specific questions (they may not have an idea what sort of information will be relevant). A simple comment clarifying this will not only prevent confusion due to arbitrarily closing the question but will help them make a better question.

Yeah, I actually find the sister sites more helpful. The main problem is that there are far too many people on that site with their own opinions about how things should be done. There's less traffic on the sister sites like unix and linux, superuser, vi, emacs etc. They should break up the main site for different programming languages and platforms like git as well.