17 ms·

This is somewhat oblique to the content of the post but "special" is about right. "Unnecessarily obtuse", particularly from a contemporary perspective, might be

This is somewhat oblique to the content of the post but "special" is about right. "Unnecessarily obtuse", particularly from a contemporary perspective, might be a less kind way to describe it. I could say the same about the documentation which, frankly, is not great at making you immediately productive. It's written like an academic treastise, not a tutorial for a piece of software that exists to help you get stuff done and where learning the software is not an end in itself. I've recently started making a relatively determined attempt to become proficient with emacs due to increasing frustration at poor performance from both VSCode and Sublime Text when working with larger projects and, I'm not going to lie, it's hard going. Take something as basic as working with multiple windows. Emacs has concepts of buffers, windows, and frames, but windows and frames are diametrically opposite in concept to windows and frames in client side web development. That's not too difficult to grasp but, say you're in dired, and you want to open a file in a new OS window (in emacs-speak this would be a frame). You'd think you could just move the caret over the filename and hit some key combination to open that file in another window (sorry, I mean frame). Possibly you can but the nearest I've managed to get so far is (from memory) C-x 5 f, which brings up the minibuffer prefilled with the pathname of the directory you're browsing in dired, and then you have to start typing the filename (which, granted, will autocomplete), which seems somewhat redundant, and only then can you open the file. It's also full of things to trip you up, like the key bindings for switching to another (emacs) window and killing a buffer - both fairly common operations - being far too similar and easy to confuse for a newbie. It just seems so deliberately contrary, but I'm hoping the investment will pay dividends given time and persistence (this is, however, approximately my fourth or fifth attempt in 20 years to learn emacs, so we'll see).

morelisp 6y ago
These are reasonable criticisms of Emacs’s interface, but the topic of the post is interfaces in Emacs, not Emacs’s interface. Sublime has no comparison point.
fennecfoxen 6y ago
As a long time emacs user, I can confirm that emacs is terrible... and everything else out there is deficient. I can write custom code (ew, elisp) to determine how to switch between buffers (test buffer and code under test) and I can run my tests and find operations and the like in a first class buffer and a dozen things like that which are just incredibly painful in other editors. Also I hit Cx-c by mistake thrice a week.
- deleted 6y ago
  [deleted]
- joosters 6y ago
  ;;; Make it more difficult to kill emacs accidentally (defun my-kill-emacs () "Confirm before 'save-buffers-kill-emacs'." (interactive) (if (y-or-n-p "Really kill Emacs? ") (save-buffers-kill-emacs) (message "Aborted") ) ) (global-set-key "\C-x\C-c" 'my-kill-emacs)
  - jimmyvalmer 6y ago
    Dude, `M-x custom-set-variable RET confirm-kill-emacs RET TAB`
    - morelisp 6y ago
      Or just unbind it, you won't typo `M-x kill-emacs`...
      - fennecfoxen 6y ago
        TBH it actually helps me a little. I seldom lose any work at all, and I have to remember to commit editor config changes somewhere persistent. :P
- MarcScott 6y ago
  Run Emacs as a server. You can kill the client accidentally, then just load another client instantly and carry on from where you left off.
  - momentoftop 6y ago
    Exactly. My emacs uptimes (M-x emacs-uptime) are generally the same as my machine's uptime, which is typically months. Emacs is one of the most rock-solid pieces of software I have running. It's also great for remote. I have emacs daemons running continuously on my remote boxes. To start work on those machines, I log in and start my emacs client. I've never had a need for things like "screen".
agumonkey 6y ago
It might be the right timing for an ergonomic revamp. As much as I like the old habits, I agree that some parts really need to be rebalanced. And emacs is moving faster these days so maybe a mutation can happen A slightly nicer embedded docs. They were great for 80s way of life, but it could use a slightly more reply (to stay in the context of a live editor / lisp machine). Maybe a text demo system.. after all you could script a demo of workflows in elisp for newcomers to see rapidly. - hydras could be extremely useful for newcomers for instance (and I'm no fan, but it cuts the chase by a factor of 1000) - ace-jump I don't know, I'm just suggesting
- pmoriarty 6y ago
  I'm a huge, huge, huuuge fan of hydras. They're a big part of what make Emacs useable for me. I have set up hydras for pretty much every major mode I use (except magit, which kind of has its own hydra-like menu system). Because of hydras, I don't have to remember all the arcane keyboard shortcuts these modes have bound by default, and don't have to look up how to run a function that's not bound at all. All I have to remember is one keyboard shortcut which I have configured to bring up a hydra in every mode, and it'll show me a menu of everything I can do in that mode. This is really fantastic, has revolutionized the way I use Emacs, and has made it 10 times as useable for me as it was before I used hydra.
  - mercer 6y ago
    Whether it's 'hydras' or something similar, the single thing that got me into properly using Emacs was this feature in Spacemacs. For almost any situation, I can either pull up the spacebar 'global' menu, or a context-specific quick-menu. Discoverability has been insanely good, and I keep finding new tricks just by exploring the various menus that pop up. I wish 'UI autocomplete' like this was a standard feature of operating systems. GUI's aside, how nice would it be to run a CLI command with some flag that allows you to explore the various options and string them together, rather than reading the manpage and searching for whatever flag you might want to use?
  - agumonkey 6y ago
    more generally auto-completion helps users go combinatorial on new territory
jimmyvalmer 6y ago
> like the key bindings for switching ... being far too similar and easy to confuse for a newbie. You must be referring to `C-x b` vs. `C-x C-b`. I remember getting apoplectic over this in 1995. I remain aggrieved to this day.
- morelisp 6y ago
  I suspect this is actually `C-x k` vs. `C-x o`. My recommendation would be to bind `C-x C-k` to `kill-this-buffer` and unbind `C-x k`, or bind `C-x C-o` to a hydra that lets you repeat `C-o` i.e. hold down ctrl and repeat `o`, to cycle windows. Or both. Alternate, try out `ace-window`. I'm not sure about "too easy to confuse for a newbie." These kind of mistakes only happen when you are switching buffers rapidly without checking prompts, and newbies won't be doing that. And the default mnemonics are (unlike much of Emacs) good for these tasks. So rebinding doesn't feel like a big ask. (Agreed `C-x b` should be removed imo.)
rthomas6 6y ago
That sounds like something you could add to dired mode and bind to a key without too much trouble. It's my understanding that you sort of have to start molding emacs to your particular style, and that the defaults are kind of bad. I have switching windows bound to ctrl+direction. Super easy and convenient. Also some of the plugins augment Emacs so much that some people see them as part of emacs rather than an add-on. I don't use dired; I use helm/ivy. I am having good luck with Doom Emacs. You may want to check it out, especially if you are used to the Vim keybindings. It provides a lot of extra functionality out of the box.
tzs 6y ago
I think that tools like Emacs and Vim are aimed at people who recognize that very often over the next few decades of their careers they are going to have a need for powerful, complex, flexible text editing, and so even if they have no interest in learning the software for its own sake its worth putting in the up front effort because it will pay off later. For a lot of tools, both in software and other fields, there are three different classes of user. 1. Those with fairly straightforward tasks that they just want to get done. 2. Those who mostly have staightforward tasks, but occasionally have something a bit more complex but not too complex. 3. Those that need to handle everything from simple to ridiculously complicated. Take electrical testing tools for example. For a lot of people a simple battery tester is all they need (class #1). If you want to test a battery and have never used a battery tester before, it will either be obvious what to do, or a glance at the instructions will tell you. Some people need a bit more on occasion, and for them we have a class #2 tool, the multimeter [1]. You can still pretty easily test a battery with one, but the first time you probably will have to spend a minute or two in the manual, learning what voltage setting you want (the V with the ~ over it, or the V with the dashed and non-dashed line over it?) and which holes to plug the probes into. Some people need a lot more. They have a class #3 tool, the oscilloscope [2]. You can check a battery with an oscilloscope, but if it is your first time you are going to spend a lot of time in the manual before you get there. Emacs and Vim are class #3 tools. [1] https://en.wikipedia.org/wiki/Multimeter#/media/File:Fluke87-V_Multimeter.jpg https://en.wikipedia.org/wiki/Multimeter#/media/File:Fluke87... [2] https://www.tequipment.net/Rigol/MSO1104Z-KIT/Mixed-Signal-Oscilloscopes-(MSO)/?v=7403 https://www.tequipment.net/Rigol/MSO1104Z-KIT/Mixed-Signal-O...
- oblio 6y ago
  The thing is, you need AutoCAD (or equivalent) to be a productive engineer in certain fields. You don't need Emacs or Vim to be an incredibly successful software engineer. It's actually the opposite, Emacs and Vim users are a minority among successful software engineers. So they are only a specific kind of power tool. More than that, they can't even handle the "ridiculously complicated". Common examples are trying to use them with projects containing millions of lines of Java or C# code.
  - 6y ago
II2II 6y ago
Emacs is an old piece of software that has historical baggage. I would imagine that the window and frame terminology is a product of their time: the use of window would have made sense prior to X. Another term had to be introduced when X support came along. It is also a piece of software where changing the terminology is very difficult. While a non-scriptable program could simply change the documentation and be done with it, Emacs would either have to change the names of exposed functions (breaking compatibility) or have one set of terminology for scripting and another while discussing the user interface. Perhaps better choices could have been made, but the issue is non-trivial.
pmoriarty 6y ago
Yes, the Emacs defaults tend to be pretty awful, but you can configure it your liking, given enough time and effort. I've put in a ton of time and effort configuring Emacs (after spending about 25 years on vim and vi), and though it took a long time, the results have been well worth it for me. There's no way I would give that up and go to something with more reasonable defaults but which is much more limited in customization capabilities and which lacks a Lisp ecosystem which has been improved by thousands of people for many decades.
- oblio 6y ago
  > There's no way I would give that up and go to something with more reasonable defaults but which is much more limited in customization capabilities and which lacks a Lisp ecosystem which has been improved by thousands of people for many decades. You do know that there is a middle ground, right? Emacs itself could come with reasonable defaults. You'd still be able to customize it (after all, you probably did) and all the newbies wouldn't have to read about 80's computing arcana to figure out how to split a window.
  - pmoriarty 6y ago
    Oh, I fully agree, and some people have done just this with packages like Spacemacs, Doom, Prelude, and probably some others. I've never tried any of them myself, because I already have Emacs configured to my liking, but reasonable defaults is what these packages aim at.
  - morelisp 6y ago
    > You do know that there is a middle ground, right? Emacs itself could come with reasonable defaults... That's the rub though. Emacs could change its defaults, plan large deprecation and rename, rewrite all its documentation and write even more to help migrate. And 20 years from now someone will be whining about the 2010 "web arcana" embedded in some interface and command set. > newbies wouldn't have to read about 80's computing arcana Because here's the perfect example. Emacs isn't 80s computing arcana, it's 60s computing arcana largely encoded into it in the 70s. In the early 90s when I first picked it up there was a similar push to encode the arcana from the 80s instead. "Pick the standard keybinds that make sense!" they said. Like Shift-Delete for cut and Shift-Insert for paste! ... oh, that's probably not what you want today either, is it? So here's your options: - Churn the defaults and everyone's configs every 15ish years - Document as best you can the defaults and how to change them, and make the best UIs you can at the time, in fashion or not. (Kill rings are still better than cut buffers!) Universal "reasonable defaults" don't exist in a tool meant to last 50 years in an ecosystem of fads.
taeric 6y ago
Your complaint on the documentation reads oddly. You do know there is a tutorial included, right? And, it mostly does what you are asking. You can even try to speed run through it occasionally to make sure you still remember everything. The straight documentation on the parts? I'm curious how you would want those to be otherwise. They mostly read like the user's manual of a car. Fairly technical, but at a very high level. With occasional tips on how to use the part you are reading about.
- bartread 6y ago
  > Your complaint on the documentation reads oddly. You do know there is a tutorial included, right? And, it mostly does what you are asking. You can even try to speed run through it occasionally to make sure you still remember everything. But that's the point: it doesn't. Maybe it does if you want to invest a few hours getting up and running, but I don't have that kind of time: I need to get stuff done now. I'm not saying I'm too important, or my time is too valuable, or any nonsense like that: I just don't have time to invest in spending a day or even half a day learning what are in contemporary times the basics of using a text editor. And that's the problem with the tutorial: it doesn't start with a quick two page summary of what, in contemporary times, are considered the basics of using a text editor. It's long-winded and academic and takes way too long to get to the point on any and all relevant topics. The result is that I have to (and not just me: anybody used to non-emacs - or perhaps vim - editors) invest non-insignificant amounts of time learning basic functionality that works in a common way across most other editors and IDEs (IDEA, Visual Studio, Rider, VS Code, Sublime, TextPad, XCode - heck, even Microsoft Word) and learn completely different paradigms for all of it just because emacs is "special". It's pretty frustrating because for me the editor is not the point. I'm only looking at emacs at all because a lot of editors, once you get to a project of any size, become absolute CPU hogs and it starts to get in the way. But given the grief I may come to the conclusion that a better investment is just to buy a faster laptop. I'm totally happy to be proven, or to prove myself, wrong, but right now the whole emacs ecosystem seems unnecessarily, contrarily alien simply for the sake of it. There also seems to be a strong lack of empathy for users. Few influential people seem to have given any consideration as to how to make the software accessible for newcomers. In this day and age that's almost laughable.
BeetleB 6y ago
Agree on the referenciness of the manuals. They are not the best way to learn when new to it (or to a package). C-x 4 is a prefix for "other window". C-x 5 is a prefix for "other frame" (It's OK if you did not know this. I was a heavy Emacs user for a decade before I learned this). For your particular problem, you may want to look into Hydra. Setting up your own Hydra for dired-mode will involve some basic Elisp, but not much - you can just copy/paste from elsewhere. However, you may need to write an Elisp function for your particular situation, and then have the Hydra call that function. Similar to another commenter, once I learned hydra, I create my own menus for every new mode I want to use. Much easier than memorizing keybindings, and you can put your own custom stuff there. Also, I rebound F6 to switching windows. C-x o would drive me nuts. F6 is the standard in Windows/DOS, so that's what I was used to (I still use it in Outlook for work to avoid the mouse).
tiborsaas 6y ago
At what project size did you notice performance issues? I use VSCode as my daily workhorse and I can believe without a doubt that it can get into trouble if I forget to gitignore node_modules :) But putting ST on the same page got me curious. I'm on the other end of the spectrum, I'm betting that computers will become fast enough with time to run these bloated editors that were designed to be usable.

morelisp 6y ago

These are reasonable criticisms of Emacs’s interface, but the topic of the post is interfaces in Emacs, not Emacs’s interface. Sublime has no comparison point.

fennecfoxen 6y ago

As a long time emacs user, I can confirm that emacs is terrible... and everything else out there is deficient. I can write custom code (ew, elisp) to determine how to switch between buffers (test buffer and code under test) and I can run my tests and find operations and the like in a first class buffer and a dozen things like that which are just incredibly painful in other editors. Also I hit Cx-c by mistake thrice a week.

deleted 6y ago
[deleted]
joosters 6y ago
;;; Make it more difficult to kill emacs accidentally (defun my-kill-emacs () "Confirm before 'save-buffers-kill-emacs'." (interactive) (if (y-or-n-p "Really kill Emacs? ") (save-buffers-kill-emacs) (message "Aborted") ) ) (global-set-key "\C-x\C-c" 'my-kill-emacs)
- jimmyvalmer 6y ago
  Dude, `M-x custom-set-variable RET confirm-kill-emacs RET TAB`
  - morelisp 6y ago
    Or just unbind it, you won't typo `M-x kill-emacs`...
    - fennecfoxen 6y ago
      TBH it actually helps me a little. I seldom lose any work at all, and I have to remember to commit editor config changes somewhere persistent. :P
MarcScott 6y ago
Run Emacs as a server. You can kill the client accidentally, then just load another client instantly and carry on from where you left off.
- momentoftop 6y ago
  Exactly. My emacs uptimes (M-x emacs-uptime) are generally the same as my machine's uptime, which is typically months. Emacs is one of the most rock-solid pieces of software I have running. It's also great for remote. I have emacs daemons running continuously on my remote boxes. To start work on those machines, I log in and start my emacs client. I've never had a need for things like "screen".

agumonkey 6y ago

It might be the right timing for an ergonomic revamp. As much as I like the old habits, I agree that some parts really need to be rebalanced. And emacs is moving faster these days so maybe a mutation can happen A slightly nicer embedded docs. They were great for 80s way of life, but it could use a slightly more reply (to stay in the context of a live editor / lisp machine). Maybe a text demo system.. after all you could script a demo of workflows in elisp for newcomers to see rapidly. - hydras could be extremely useful for newcomers for instance (and I'm no fan, but it cuts the chase by a factor of 1000) - ace-jump I don't know, I'm just suggesting

pmoriarty 6y ago
I'm a huge, huge, huuuge fan of hydras. They're a big part of what make Emacs useable for me. I have set up hydras for pretty much every major mode I use (except magit, which kind of has its own hydra-like menu system). Because of hydras, I don't have to remember all the arcane keyboard shortcuts these modes have bound by default, and don't have to look up how to run a function that's not bound at all. All I have to remember is one keyboard shortcut which I have configured to bring up a hydra in every mode, and it'll show me a menu of everything I can do in that mode. This is really fantastic, has revolutionized the way I use Emacs, and has made it 10 times as useable for me as it was before I used hydra.
- mercer 6y ago
  Whether it's 'hydras' or something similar, the single thing that got me into properly using Emacs was this feature in Spacemacs. For almost any situation, I can either pull up the spacebar 'global' menu, or a context-specific quick-menu. Discoverability has been insanely good, and I keep finding new tricks just by exploring the various menus that pop up. I wish 'UI autocomplete' like this was a standard feature of operating systems. GUI's aside, how nice would it be to run a CLI command with some flag that allows you to explore the various options and string them together, rather than reading the manpage and searching for whatever flag you might want to use?
- agumonkey 6y ago
  more generally auto-completion helps users go combinatorial on new territory

jimmyvalmer 6y ago

> like the key bindings for switching ... being far too similar and easy to confuse for a newbie. You must be referring to `C-x b` vs. `C-x C-b`. I remember getting apoplectic over this in 1995. I remain aggrieved to this day.

morelisp 6y ago
I suspect this is actually `C-x k` vs. `C-x o`. My recommendation would be to bind `C-x C-k` to `kill-this-buffer` and unbind `C-x k`, or bind `C-x C-o` to a hydra that lets you repeat `C-o` i.e. hold down ctrl and repeat `o`, to cycle windows. Or both. Alternate, try out `ace-window`. I'm not sure about "too easy to confuse for a newbie." These kind of mistakes only happen when you are switching buffers rapidly without checking prompts, and newbies won't be doing that. And the default mnemonics are (unlike much of Emacs) good for these tasks. So rebinding doesn't feel like a big ask. (Agreed `C-x b` should be removed imo.)

rthomas6 6y ago

That sounds like something you could add to dired mode and bind to a key without too much trouble. It's my understanding that you sort of have to start molding emacs to your particular style, and that the defaults are kind of bad. I have switching windows bound to ctrl+direction. Super easy and convenient. Also some of the plugins augment Emacs so much that some people see them as part of emacs rather than an add-on. I don't use dired; I use helm/ivy. I am having good luck with Doom Emacs. You may want to check it out, especially if you are used to the Vim keybindings. It provides a lot of extra functionality out of the box.

tzs 6y ago

I think that tools like Emacs and Vim are aimed at people who recognize that very often over the next few decades of their careers they are going to have a need for powerful, complex, flexible text editing, and so even if they have no interest in learning the software for its own sake its worth putting in the up front effort because it will pay off later. For a lot of tools, both in software and other fields, there are three different classes of user. 1. Those with fairly straightforward tasks that they just want to get done. 2. Those who mostly have staightforward tasks, but occasionally have something a bit more complex but not too complex. 3. Those that need to handle everything from simple to ridiculously complicated. Take electrical testing tools for example. For a lot of people a simple battery tester is all they need (class #1). If you want to test a battery and have never used a battery tester before, it will either be obvious what to do, or a glance at the instructions will tell you. Some people need a bit more on occasion, and for them we have a class #2 tool, the multimeter [1]. You can still pretty easily test a battery with one, but the first time you probably will have to spend a minute or two in the manual, learning what voltage setting you want (the V with the ~ over it, or the V with the dashed and non-dashed line over it?) and which holes to plug the probes into. Some people need a lot more. They have a class #3 tool, the oscilloscope [2]. You can check a battery with an oscilloscope, but if it is your first time you are going to spend a lot of time in the manual before you get there. Emacs and Vim are class #3 tools. [1] https://en.wikipedia.org/wiki/Multimeter#/media/File:Fluke87-V_Multimeter.jpg https://en.wikipedia.org/wiki/Multimeter#/media/File:Fluke87... [2] https://www.tequipment.net/Rigol/MSO1104Z-KIT/Mixed-Signal-Oscilloscopes-(MSO)/?v=7403 https://www.tequipment.net/Rigol/MSO1104Z-KIT/Mixed-Signal-O...

oblio 6y ago
The thing is, you need AutoCAD (or equivalent) to be a productive engineer in certain fields. You don't need Emacs or Vim to be an incredibly successful software engineer. It's actually the opposite, Emacs and Vim users are a minority among successful software engineers. So they are only a specific kind of power tool. More than that, they can't even handle the "ridiculously complicated". Common examples are trying to use them with projects containing millions of lines of Java or C# code.
- 6y ago

II2II 6y ago

Emacs is an old piece of software that has historical baggage. I would imagine that the window and frame terminology is a product of their time: the use of window would have made sense prior to X. Another term had to be introduced when X support came along. It is also a piece of software where changing the terminology is very difficult. While a non-scriptable program could simply change the documentation and be done with it, Emacs would either have to change the names of exposed functions (breaking compatibility) or have one set of terminology for scripting and another while discussing the user interface. Perhaps better choices could have been made, but the issue is non-trivial.

pmoriarty 6y ago

Yes, the Emacs defaults tend to be pretty awful, but you can configure it your liking, given enough time and effort. I've put in a ton of time and effort configuring Emacs (after spending about 25 years on vim and vi), and though it took a long time, the results have been well worth it for me. There's no way I would give that up and go to something with more reasonable defaults but which is much more limited in customization capabilities and which lacks a Lisp ecosystem which has been improved by thousands of people for many decades.

oblio 6y ago
> There's no way I would give that up and go to something with more reasonable defaults but which is much more limited in customization capabilities and which lacks a Lisp ecosystem which has been improved by thousands of people for many decades. You do know that there is a middle ground, right? Emacs itself could come with reasonable defaults. You'd still be able to customize it (after all, you probably did) and all the newbies wouldn't have to read about 80's computing arcana to figure out how to split a window.
- pmoriarty 6y ago
  Oh, I fully agree, and some people have done just this with packages like Spacemacs, Doom, Prelude, and probably some others. I've never tried any of them myself, because I already have Emacs configured to my liking, but reasonable defaults is what these packages aim at.
- morelisp 6y ago
  > You do know that there is a middle ground, right? Emacs itself could come with reasonable defaults... That's the rub though. Emacs could change its defaults, plan large deprecation and rename, rewrite all its documentation and write even more to help migrate. And 20 years from now someone will be whining about the 2010 "web arcana" embedded in some interface and command set. > newbies wouldn't have to read about 80's computing arcana Because here's the perfect example. Emacs isn't 80s computing arcana, it's 60s computing arcana largely encoded into it in the 70s. In the early 90s when I first picked it up there was a similar push to encode the arcana from the 80s instead. "Pick the standard keybinds that make sense!" they said. Like Shift-Delete for cut and Shift-Insert for paste! ... oh, that's probably not what you want today either, is it? So here's your options: - Churn the defaults and everyone's configs every 15ish years - Document as best you can the defaults and how to change them, and make the best UIs you can at the time, in fashion or not. (Kill rings are still better than cut buffers!) Universal "reasonable defaults" don't exist in a tool meant to last 50 years in an ecosystem of fads.

taeric 6y ago

Your complaint on the documentation reads oddly. You do know there is a tutorial included, right? And, it mostly does what you are asking. You can even try to speed run through it occasionally to make sure you still remember everything. The straight documentation on the parts? I'm curious how you would want those to be otherwise. They mostly read like the user's manual of a car. Fairly technical, but at a very high level. With occasional tips on how to use the part you are reading about.

bartread 6y ago
> Your complaint on the documentation reads oddly. You do know there is a tutorial included, right? And, it mostly does what you are asking. You can even try to speed run through it occasionally to make sure you still remember everything. But that's the point: it doesn't. Maybe it does if you want to invest a few hours getting up and running, but I don't have that kind of time: I need to get stuff done now. I'm not saying I'm too important, or my time is too valuable, or any nonsense like that: I just don't have time to invest in spending a day or even half a day learning what are in contemporary times the basics of using a text editor. And that's the problem with the tutorial: it doesn't start with a quick two page summary of what, in contemporary times, are considered the basics of using a text editor. It's long-winded and academic and takes way too long to get to the point on any and all relevant topics. The result is that I have to (and not just me: anybody used to non-emacs - or perhaps vim - editors) invest non-insignificant amounts of time learning basic functionality that works in a common way across most other editors and IDEs (IDEA, Visual Studio, Rider, VS Code, Sublime, TextPad, XCode - heck, even Microsoft Word) and learn completely different paradigms for all of it just because emacs is "special". It's pretty frustrating because for me the editor is not the point. I'm only looking at emacs at all because a lot of editors, once you get to a project of any size, become absolute CPU hogs and it starts to get in the way. But given the grief I may come to the conclusion that a better investment is just to buy a faster laptop. I'm totally happy to be proven, or to prove myself, wrong, but right now the whole emacs ecosystem seems unnecessarily, contrarily alien simply for the sake of it. There also seems to be a strong lack of empathy for users. Few influential people seem to have given any consideration as to how to make the software accessible for newcomers. In this day and age that's almost laughable.

BeetleB 6y ago

Agree on the referenciness of the manuals. They are not the best way to learn when new to it (or to a package). C-x 4 is a prefix for "other window". C-x 5 is a prefix for "other frame" (It's OK if you did not know this. I was a heavy Emacs user for a decade before I learned this). For your particular problem, you may want to look into Hydra. Setting up your own Hydra for dired-mode will involve some basic Elisp, but not much - you can just copy/paste from elsewhere. However, you may need to write an Elisp function for your particular situation, and then have the Hydra call that function. Similar to another commenter, once I learned hydra, I create my own menus for every new mode I want to use. Much easier than memorizing keybindings, and you can put your own custom stuff there. Also, I rebound F6 to switching windows. C-x o would drive me nuts. F6 is the standard in Windows/DOS, so that's what I was used to (I still use it in Outlook for work to avoid the mouse).

tiborsaas 6y ago

At what project size did you notice performance issues? I use VSCode as my daily workhorse and I can believe without a doubt that it can get into trouble if I forget to gitignore node_modules :) But putting ST on the same page got me curious. I'm on the other end of the spectrum, I'm betting that computers will become fast enough with time to run these bloated editors that were designed to be usable.