3 ms·

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 Emac

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.

agumonkey 3y ago
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).
- charcircuit 3y ago
  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
  - agumonkey 3y ago
    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.
    - charcircuit 3y ago
      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.
      - agumonkey 3y ago
        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.
  - Ferret7446 3y ago
    Magit performance has very little to do with Emacs. All operations are performed via git subprocesses.
    - charcircuit 3y ago
      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.
okasaki 3y ago
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)
- charcircuit 3y ago
  Treemacs is not built into the base Emacs distribution. Something so fundamental for a text editor should work perfectly out of the box.
  - okasaki 3y ago
    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.
    - charcircuit 3y ago
      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.
      - iLemming 3y ago
        > 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.
iLemming 3y ago
> 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".
mapreduce 3y ago
> 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.

agumonkey 3y ago

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

charcircuit 3y ago
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
- agumonkey 3y ago
  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.
  - charcircuit 3y ago
    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.
    - agumonkey 3y ago
      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.
- Ferret7446 3y ago
  Magit performance has very little to do with Emacs. All operations are performed via git subprocesses.
  - charcircuit 3y ago
    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.

okasaki 3y ago

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)

charcircuit 3y ago
Treemacs is not built into the base Emacs distribution. Something so fundamental for a text editor should work perfectly out of the box.
- okasaki 3y ago
  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.
  - charcircuit 3y ago
    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.
    - iLemming 3y ago
      > 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.

iLemming 3y ago

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

mapreduce 3y ago

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