Hacker News Reader

Comment by charcircuit | Hacker News Reader

Even if it's not dying no one there cares about the user experience so stagnation is inevitable. Just compare the out of box experience for both VSCode and Emacs and it is no surprise why VSCode is more popular. Take a simple feature like showing different files that are open in tabs. Emacs' solution to switching between buffers is harder to use if you want to go between different files you have open. How many years do you think it will take before Emacs has tabs for different files open by default? A ubiquitous feature of text editors. This is what leads people to think Emacs is dead. It's stuck in a design from decades ago and the project is unable to evolve. It is only able to slowly iterate upon itself.

View on HN

> Just compare the out of box experience for both VSCode and Emacs

One thing I learned after using, designing, and building tons of different software products - there's often a strong correlation between something that is seemingly complex and difficult to start with and then gained simplicity later. Conversely, something that is very easy to get into often becomes extremely difficult to use later, slowing you down with a bunch of arbitrary drawbacks simply because it was never designed for "advanced power users" to begin with. Road to simplicity is rarely a straightforward and effortless journey.

For many people, the most - it's just easier to choose "fast food" of features, instead of painstakingly figuring out how to "make your own burger". And they never build a mental model of "being a cook", they just learn to consume what they've given. There's nothing wrong with that. Except that they often confuse the "there's no other way" with the illusion of "it just works".

Applying to the concrete example you're using, it would take me maybe just 10-15 minutes to whip up an Elisp function that would open each file in its own tab. I don't do that because there are many more empowering and productive ways than having each file in its own tab. Like Einstein one said: "What is right is not always popular and what is popular is not always right".

User experience is highly relative. To me magit is peak UX, above many many tools.. but to some it's utter sh8t and they want vscode (even though they are the one sweating and ranting everytime they get confused).

I agree that magit has relatively good UX compared to the rest of Emacs, but it is held back by Emacs' abhorrent performance. Magit however is not bundled with Emacs so I can not attribute its UX quality to the base Emacs editor.

I do think of you did an actual user study you would find that it should be using more GUI elements to expose operations instead of keybindings

Except on windows I don't recall any performance issues that were not due to repo size.

Magit is an extension of the old emacs outline mode, it inherits all the ergonomics culture around it (tab to fold, C-n/C-p for skipping, C-c C-c to validate..., k to kill). User studies don't apply here, it's too complex (due to the inheritance mentionned above). As I said, I have colleagues using other tools, they're slower and angrier, even with more buttons, which is somehow part of emacs culture.. don't create more widgets than necessary. And I'd argue it's irrelevant to good HCI for non mainstream duties.

I have had the editor grind to a halt when doing some combination of having a ton of changes, showing hunks, and trying to scroll.

>User studies don't apply here, it's too complex

User studies always apply. And doing basic everyday source control operations should not be complex.

You can't compare fairly since people will cluster around what they consider right. Even though, as I can witness daily, they suffer more, take more time than the 'obscure emacs thing'. So many git interfaces add more weight, lag, random iconography and terminology. But it taps into people love for shiny, it seems an exciting new tool with all bells and whistles when in fact, it disrupt your flow more, adds layers of confusion and costs more ultimately.

Fair point about massive hunk set causing lag, it's plausible.

Magit performance has very little to do with Emacs. All operations are performed via git subprocesses.

My expectation as a user is that the editor should never freeze. It should render at my monitor's refresh rate. What I experienced sometimes with magit is the editor freezing rendering 0 frames for 10s of seconds. It does have to do with Emacs.

Emacs has by far the best the best 'file switching experience' I've ever seen with treemacs, which is a sidebar with multiple projects, each with its file tree. Projects are part of workspaces which you can switch between. The whole thing can be configured with right click menus, or by editing an org file.

Additionally it has not one but two tab modes built-in (tab-line-mode, tab-bar-mode)

Treemacs is not built into the base Emacs distribution. Something so fundamental for a text editor should work perfectly out of the box.

Eh, if you're going to be using it as a text editor for 8 hours a day, you can take 2 minutes to install a package, surely.

Defaults matter and this is just one problem of many that needs to be fixed. It's not okay to ship a bad product because a user can fix it themselves if they really wanted to. Products that work well out of the box will have an advantage over those that don't.

> It's not okay to ship a bad product because a user can fix it themselves

I think you are confused about the definition of Emacs as a product. As stated in its documentation: "Emacs is the advanced, extensible, customizable, self-documenting editor." It is designed for advanced power users who are willing to extend and customize it. What you consider to be "must-have defaults" is as arbitrary and controversial as having an option to use vim keybindings or some popular dark theme out of the box. If you're saying that someone can't use Emacs because it doesn't open each file on a dedicated tab, maybe that's not Emacs's target audience?

Anyway, I do remember my younger self. I, too, was raging about this specific thing. I didn't understand "the philosophy of buffers," and people kept telling me "trust me, you don't need the tabs..." and I hated that. But I promise you, and please trust me, you really do not need the tabs. I've been there, I tried disproving everyone who told me that, and I admit that I was wrong.

>It is designed for advanced power users who are willing to extend and customize it.

That doesn't mean the default experience should be bad. Why not start with a good experience and let users build on top of that.

>What you consider to be "must-have defaults" is as arbitrary and controversial as having an option to use vim keybindings or some popular dark theme out of the box.

Which is why it is important to get feedback from real users. Get a random person off the street to use Emacs and see if they have an easier time with tabs. Repeat with intermediate and advanced Emacs users. See what works and what doesn't.

>If you're saying that someone can't use Emacs because it doesn't open each file on a dedicated tab, maybe that's not Emacs's target audience?

It's not that it's impossible it would be that users have a harder time to accomplish what they want.

>maybe that's not Emacs's target audience?

This is the kind of needless gatekeeping that will lead to Emacs death.

> This is the kind of needless gatekeeping that will lead to Emacs death.

This isn't "gatekeeping". What are you talking about? I expressed my personal opinion about one aspect of the default interface. I'm not an Emacs maintainer, RMS' cousin, Zaretskii's dog sitter, or director of FSF, I don't "call the shots".

Emacs is completely free to use, distribute and contribute to. Go ahead then, come up with convincing arguments, compose a proposal and write to the emacs-devel mailing list. Maybe, after all you are truly a bright-minded visionary and those dorks that been maintaining Emacs for over 45 years just don't know anything?

> it is important to get feedback from real users

Nobody is stopping you from giving such feedback. I don't think there were many cases in history where technological breakthroughs happened due to random people arguing about a subject on a forum like HN or Reddit. You have complete freedom to do something about it if you passionately believe in it.

> Emacs' solution to switching between buffers is harder to use if you want to go between different files you have open.

Are you sure?

If I am on foo.rs and I want to go to bar.rs all I type is C-x b bar and type Enter and done! I find this way easier than hunting and pecking for my tab in VSCode.

Reply on news.ycombinator.com