18 ms·

Emacs Modernization: Simple Changes Emacs Should Adopt (2006)

112 points by AJRF 5y ago

wiz21c 5y ago
been using emacs for several years... What could be improved is speed. Too many times it doesn't see some keys combinations I hit. Screen redraw should be faster too (I spend a lot of time in front of it so that kind of "detail" is actually important). Loading big files is slow. Editing long lines is slow. Of course it doesn't happen often but when it happens it's annoying. Emacs could also propose options to better align on common behaviors (for example C-left/right arrow) doesn't behave like in other editors. It could also be more "discoverable". There are hundreds of functions so that 100% of my needs are covered. But every now and then, when I want to find a command, I DuckDuckGo it... It'd be nicer if somehow there would be an assisted navigation in the commands (or a pointer to that assistance I've been sorely missing :-)) But I like it anyway. 'cos it's faithful, community grown, etc. And if I had time I would contribute. But emacs is an old platform so there are many choices buried in and reaching the level of knowledge necessary to contribute is probably very high...
- Tomte 5y ago
  > What could be improved is speed. Native compilation is coming in the next version and should help quite a bit.
  - wiz21c 5y ago
    I'm already on the 28.0 branch, makes no visible difference (my workflow is rather basic : editing lots of code, bits of org mode, bits of WL)
    - daptaq 5y ago
      Are you sure you have libgccjit installed and configure found it?
      - wiz21c 5y ago
        My configure's config.log says : #define HAVE_LIBGCCJIT 1 #define HAVE_LIBGCCJIT_H 1 So, yep it has it.
  - medo-bear 5y ago
    i think running as a server should be made default. i imagine that alot of people are opening alot of seperate instances
    - lloda 5y ago
      I don't run Emacs as a server because it freezes occasionally and it's very painful to have a couple dozen windows in eight workspaces go down. If I could rely on Emacs never freezing, I'd be happy to run it as a server.
      - lvass 5y ago
        I have init manage an emacs daemon but open separate emacs instances if it's doing something important, even though it practically never freezes for me. I think this works fine as long as you don't have server-start in your config.
- kryptiskt 5y ago
  "Buttery Smooth Emacs" contains some insight into what goes on under the surface of Emacs and is a great read: https://m.facebook.com/notes/daniel-colascione/buttery-smooth-emacs/10155313440066102/ https://m.facebook.com/notes/daniel-colascione/buttery-smoot...
- abdullahkhalids 5y ago
  > It could also be more "discoverable". I definitely agree that I want to type some string and it should show a fuzzy search from all available commands and their descriptions. That would be huge timesaver for functionality I know exist, but I forgot the exact commands.
  - uncletaco 5y ago
    This is literally what `M-x` does. You want to do the same for functions? `C-h f`. Variables? `C-h v`. Keybindings for the current mode? `C-h ?`. If I'm not mistaken when you install vanilla Emacs the screen even includes a tutorial and guided tour that both tell you these commands.
    - trey-jones 5y ago
      Yes, once you make the connection between every single keypress invoking an elisp function, and the various help combinations (variables, functions, keystrokes as you mention), I think Emacs is actually the most "discoverable" editor that I've used.
    - wiz21c 5y ago
      Except when the name of what you look for doesn't match your mental model (yep, I'm in the group of people who think software should adapt to human and not the other way around) Example : I want to change the encoding of a file when I load it... Good luck figuring that out without resorting to reading the documentation.
      - uncletaco 5y ago
        And here I would argue that, since the documentation is included with Emacs and can be pulled up in the editor, this is still a point towards its inherent discoverability. Again when you load emacs there's a link to the manual on its splash screen and as a guided tour. A lot of people rush to turn off this screen or suppress the menues on startup (which I get, the menu bar is pretty ugly) but they do have useful functionality for someone who doesn't know Emacs.
- yakubin 5y ago
  > been using emacs for several years... What could be improved is speed. Same here. Long lines are especially painful. And it's quite surprising what Emacs considers a "long line". I have a file in my project with tests, where I have an array, with each element of the array on a separate line, averaging at around 125 characters per line (some of them weird Unicode characters, so not just ASCII). There are 52 lines of it. And when I scroll down the file with C-v (Page Down basically) it scrolls quickly up until I get close to this place, then I get something like 1.5 seconds delay while it's hanging there. It's ridiculous. Another thing is how easy it is to freeze Emacs into being completely unusable when editing files over Tramp (with remote work it's the go-to solution), caused by an unreliable connection. Mostly it happens when the underlying VPN connection is dropped. When that happens, Emacs freezes with no explanation whatsoever. I can only guess what happened. C-g, Esc, nothing works, regardless whether the VPN connection is restored or not. The only solution at this point is killing this instance of Emacs. Specifically for this purpose I crafted a one-liner to kill the right instance of Emacs[1] (the one under the mouse pointer): kill $(xdotool getwindowpid $(xdotool getmouselocation | cut -d : -f 5)) Also, magit is painfully slow. When using it, I always wonder if Emacs is frozen again, or if it's just magit being magit. It's a shame Fork is not available for Linux. [1]: The other instance of Emacs is used for tracking in org-mode the time I spend on different tasks. I used to do it all in a single instance, but then I kept losing that data due to Emacs freezing like that, so I started using a separate instance for the time-tracking. I really think Emacs should be a multi-process application to prevent such situations.
  - lloda 5y ago
    xkill ? But I agree. Emacs should be faster.
    - yakubin 5y ago
      I didn't know of xkill. Thanks!
  - jpeloquin 5y ago
    > some of them weird Unicode characters, so not just ASCII This makes me suspicious that it's the font cache causing the slowdown (assuming Windows), not long lines. I saw similar symptoms a couple years ago and fixed it with (setq inhibit-compacting-font-caches t). You could also try increasing the garbage collection threshold on the theory that the lag is a gc pause. I've used: (setq gc-cons-threshold (* 511 1024 1024)) (setq gc-cons-percentage 0.5) (run-with-idle-timer 5 t #'garbage-collect)
- rightbyte 5y ago
  Have you tried "native Emacs", AoT compiled with libgccjit?
- shrimpx 5y ago
  > Too many times it doesn't see some keys combinations I hit. This caught my eye because I tend to think the opposite of this statement. Emacs doesn't skip a beat on text input -- unlike say VSCode which has perceivable input lag. In my experience, when Emacs gets slow it's a configuration problem, like flychecking on every keystroke, or a slow/poorly written third-party package. Raw emacs is blazing fast. Disclaimer: I use `emacs -nw` -- no GUI toolkits.
- BeetleB 5y ago
  > It could also be more "discoverable". There are hundreds of functions so that 100% of my needs are covered. But every now and then, when I want to find a command, I DuckDuckGo it Have you tried the apropos command? For me, often using helm/ido and trying to guess actually leads me to the correct command. I personally haven't even tried apropos, so I don't know how good it is.
medo-bear 5y ago
i initially hated emacs' non-CUA bindings. now my thoughts are opposite and because i spend so much time in emacs, when I need to go to CUA it's quite annoying. i agree that CUA should be made default, but with immediate option on start-up to use original emacs bindings. i think it will put off far fewer people
acomjean 5y ago
I used Aquaemacs on my work machine. It wasn’t perfect but it really did integrate well with macOS. the command key doesn’t overlap with and native emacs commands which helped. Im using IDEs more these days but still drop text into emacs if on a remote terminal or need to use it’s macro feature. Installing emacs plugins or extending the application always seems daunting and seems to always involve manual king editing a list config file….
roenxi 5y ago
Interesting commentary. I do think this is a little harsh on the poor Emacs undo system. I can't really push back on the idea that Emacs' undo system is excessively confusing, because I use Emacs and I don't understand it. I usually save text in a second buffer if I think I'll need it later. But the solution should be to improve the UI rather than remove functionality. Consider what magit did to a similar problem in git - git is powerful with a weirdly crippled CLI. Magit adds a great ... Emacs User Interface? EUI? and all is well. There is a probably a similar solution to the Emacs Undo problem.
- Guthur 5y ago
  Just add undo-tree and blow everyone's mind :)
- psychstudio 5y ago
  Given your current situation, undo-tree-visualize will change your life.
  - medo-bear 5y ago
    wow. is there something like this but for a whole project ?
    - blahgeek 5y ago
      I think that something is "git" :)
      - medo-bear 5y ago
        nope. what i mean is doing undo operations on a project as opposed to a buffer. lets say you have 3 buffers open and you edit buffer 1 (i), then you edit buffer 3 (ii), then you edit buffer 2 (iii), and then back to buffer 3 and you edit it some more (iv). finally you want to do project-undo from this point in buffer 3. the undo sequence then goes like this: (iv) - (iii) - (ii) - (i)
  - 5y ago
sullyj3 5y ago
Title could probably use a (2006)
- mcc1ane 5y ago
  or (2015)
Decabytes 5y ago
I posted a link here to a Reddit post that said “if you could change one thing about emacs what would it be?” It had almost 200 comments. Some answers definitely touched on these points. But for the most part, what Emacs users wanted was for the Gnu Emacs maintainers to do was… 1. Switch out Elisp for a Common Lisp or Scheme 2. Update the way Emacs Ui Core so it used standard GTK or something better. (The current implementation uses a lot of ugly hacks to support a subset of GTK) 3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off. 4. Improve threading so that things like TRAMP didn’t freeze when you were connecting 5. Fast/Arbitrary graphics support I think for most Emacs users it’s a performance thing. Though the improvements to the GUI code would go a long way to making it easier to make Emacs be more user friendly. In terms of this article. I think all of this is possible in a separate distribution of Emacs right now. Emacs will never turn on most of these things by default. But maybe if a version of Emacs that makes these changes becomes wildly popular, the current maintainers would be more amenable to it. https://old.reddit.com/r/emacs/comments/padv22/if_you_could_change_one_thing_about_emacs_what/ https://old.reddit.com/r/emacs/comments/padv22/if_you_could_...
- clircle 5y ago
  Hopefully pure-gtk branch will be merged prior to Emacs 28, addressing (2). On (1), I'm not much of a programmer, but Emacs-lisp fine, so I'm not sure what benefit changing languages could bring.
  - slightwinder 5y ago
    Is the pure-gtk-branch really working on switching the underlying UI-architecture? Or just removing the hacks for X11 and moving them to gtk?
    - clircle 5y ago
      pure-gtk doesn't decouple ui process from editor, if that's what you're asking about.
giancarlostoro 5y ago
I would love Emacs to get a facelift in the UI aspect. I like what Neovim is doing for UI stuff. Maybe Remacs can head a similar direction.
- smackeyacky 5y ago
  Given that emacs just needs a good editor, maybe get them to integrate neovim? ;-)
toolslive 5y ago
what a lot of people fail to realise is that emacs key bindings *are* consistent with other tools. Take a look at bash (or the korn shell): begin of line (C-a); end of line (C-e); kill rest of line (C-k). Emacs key bindings are the same. Not everybody grew up using windows.
- still_grokking 5y ago
  That's because GNU ReadLine uses Emacs key-bindings. It's not the other way around.
  - toolslive 5y ago
    I think these key bindings go (at least) back to csh.
    - ByteJockey 5y ago
      csh's initial release was 2 years after emacs.
- Veen 5y ago
  > Not everybody grew up using windows. No, but almost everybody did. Very few people grew up using korn, readline, and emacs.
  - G3rn0ti 5y ago
    But I’d argue learning basic Emacs key bindings gives you the benefit of becoming better on any Linux terminal. Going through the tutorial does not take much time. I think the author is right about the arcane terminology („meta key“, „buffer“, „window“, „frame“ etc) that should be changed and, too, configuring CUA Mode by default to help newbies a bit. I personally prefer using „control c“ and „control v“ for copy and pasting. Mind you if you like to use keyboard macros, you can’t use CUA mode copy/cut/paste bindings in them. That confused me quite a bit as beginner. However, I don’t think I ever got confused by Emacs undo system. It basically does the same thing as in other editors, just the key binding is different.
daly 5y ago
I've been using emacs for 35+ years. It does everything I need to do. If it doesn't, it has lisp. And then it does. I only use fundamental-mode. Emacs, like lisp, is "clay for the mind". You can adapt it to any task easily.
- Scarbutt 5y ago
  I only use fundamental-mode. Why? do you use emacs for programming (besides elisp)?
- greggman3 5y ago
  I've been using programmable editors for 35+ years. They all do everything emacs does and more and are just as adaptable.
  - BeetleB 5y ago
    Sorry, but which programmable editor lets me read/send email, create TODOs that link both to a relevant email, and a line of code in another file, and let's me autocreate flash cards?
    - pjmlp 5y ago
      I bet there is a VSCode or Sublime plugin for that. But if you prefer something more oldie, there are plenty of plugins for Ultraedit, Notepad++ and similar with scripting support.
- agumonkey 5y ago
  and emacs is already so packed.. even after rtfm 3 times thoroughly (or so I thought) I learn there's something else I didn't know about maybe the only thing I'd like to see more center, is a blend of crdt / live-notebook in simple buffers. This could be very benefitial to newcomers too.. you can pair tutor, enjoy things in teams right inside your window
mark_l_watson 5y ago
I bought the Emacs Manual from Richard Stallman and friends, so many years ago, and I still rely on it, especially with Mosh+tmux for working in remote servers. Off topic, but I have been trying to figure out why Emacs startup got faster and editing seems snappier on an M1 MacBook. The M1 is generally faster but not enough to account for the difference. Maybe some engineers at Apple in some way optimized the Emacs that ships with macOS? The speed up has increased my use of Emacs locally on my laptop. EDIT: I love Common Lisp, but probably it is not worth the effort to replace Emacs Lisp.
- agigao 5y ago
  Emacs did speed-up on M1? When/How? :D Which Emacs distribution are you using?
  - mark_l_watson 5y ago
    I just noticed that I am now running the Home Brew built for M1 install of Emacs: /opt/homebrew/bin/emacs It is really nice to be able to have Brew installs for Intel (Rossetta) and M1 side by side (in different root directories).
    - snazz 5y ago
      Emacs doesn't appear to be preinstalled in macOS anymore (I think the ancient version they were shipping was removed with Catalina).
h2odragon 5y ago
Why should emacs have to adopt your changes (or mine)? Make a "Modern-Emacs" and make it what you want, make it something you and others can love. Maybe others will love it enough to contribute, maybe no one but you will ever use it. Either way is great, and you still have your ideal tool.
b5n 5y ago
Lately there's been a lot of talk about what Emacs needs, written mostly by people who don't understand Emacs. Emacs is more of a journey than an application. It's similar to a blacksmith forging their own tools - Emacs is the metaphorical ingot, waiting to be transformed and molded by the user. If you're happy with what you're using then you don't need Emacs, and Emacs doesn't need to appeal to that crowd. Emacs isn't a VSCode competitor, it's something entirely different, and it's waiting for those who desire transcendence - shedding the limits imposed by other tools. You can install and use Emacs as quickly as any other application, but to truly reap its benefit you must go deeper. I don't see the need to cater to people who clearly want something else, those tools already exist, please leave Emacs to those of us who appreciate it for what it is. I disagree with all the reccomendations made in this article, all these changes are easy to implement, and the user is encouraged to do so - one of the main selling points of Emacs. That doesn't mean there is not room for improvement, Emacs is still constantly improving. Additionally, I've encountered many instances where a colleague or friend introduces me to some new feature in their preferred application, the majority of the time it's a feature that's been available in Emacs for years if not decades. I'd prefer we continue to focus on the needs of Emacs users rather than the wants of non-emacs users. Emacs will still be waiting for them when they're ready.
- greggman3 5y ago
  Seems like you completely missed the point of the article. The article called out that none of the changes make emacs any less powerful nor do any of the changes remove any functionality. Users can still do everything they could always do with emacs. They can still take this "journey" you mention. All the changes do is let them get started quicker and jump in with at least some familiarity. Old emacs users such as yourself can keep on using your non-standard keys and old terminology. For you, nothing would change. For new users, they'd be productive quicker and still able to take advantage of all the things that keep fans of emacs using to emacs.
  - b5n 5y ago
    I can't help but feel that you missed the point of my comment. New users should be encouraged to make those changes themselves if they feel the need to. If that's not something they're interested in, why use Emacs? Anyone can publish a config and distribute it. For instance, the author of this article could create a 'new user friendly' config and distribute it just like doom, spacemacs, etc. If it's popular enough it will see a lot of use, but my guess is it would most likely wallow. Making those changes default would require existing users to update their configs, not necessarily a big deal, but for what? So a new user can download Emacs, play with it for a minute, and still conclude that Emacs is a dusty relic because they don't understand the philosophy? The whole idea of chasing new Emacs users is kind of silly, Emacs is more popular than it has ever been, and if a new user doesn't come to Emacs for what Emacs offers they were never going to stay. Out of the box solutions already exist, Emacs is in a different category, and need not compete in that arena - especially at the expense of current users. Appreciate the reply, cheers.
pjmlp 5y ago
Not sure what might still be missing, but I add the ones from XEmacs for graphical tooling integration, that might still be missing. By the way, Gosling now rather uses IDEs.
- vkazanov 5y ago
  He is THE Java guy, and java is pain without massive IDEs. What I find here funny is that Netbeans is dead, and nobody ever mentions it on HN. And we still talk about emacs.
  - bitwize 5y ago
    NetBeans is dead because JetBrains was a better NetBeans.
    - SeanLuke 5y ago
      NetBeans was killed by competition with Eclipse. IDEA had nothing to do with it.
    - pjmlp 5y ago
      The only thing JetBrains is better is turning my laptop into a grill.
  - pjmlp 5y ago
    All programming languages are a pain without IDEs, who thinks otherwise is masochistic. That guy did lots of stuff on his career, decades before Java was a thing, including XEmacs.
tsuujin 5y ago
I agree with basically everything in this article. Emacs needs new users, and to get them we need to reduce the barriers and user friction. In fact, increasing adoption through reducing user friction is a very well known topic in software design; this shouldn’t really be a topic for debate. But god help you if you suggest changing Emacs to conform with modern standards. I still maintain that the worst part of Emacs is the vocal minority of evangelicals in the community. I’ve been using Emacs as a daily driver for years, but it also took me years to adopt fully because the mental overhead of learning new terms for things I already knew drove me to ask for help from the community, and the community routinely made me not want to be any part of it. It sucks, because most of the community is fine, but the very loud voices of a minority group of purists who have built their identities around being “Emacs people” are incredibly aggravating.
- BeetleB 5y ago
  > Emacs needs new users Why do you think so? I've been hearing things like this for over a decade now. And compared to 10 years ago, the Emacs "ecosystem" has shown explosive growth. I can find much more useful help on Emacs on the Internet now. I can find an order more magnitude of tips/tricks than I could 10 years ago. There are many more packages easily accessible than 10 years ago. From within, it's clear that Emacs is doing quite well in terms of its user base. The fact that its percentage market share is dropping doesn't mean it's not growing - just that other things are growing faster. So I never understood why people imply that Emacs is somehow stagnating.
  - User23 5y ago
    The Emacs user community is absolutely fantastic. Lisp is an amazing language to work in, and Emacs gives it to you for free. VSCode is an excellent piece of software, but you have to jump through hoops to extend it. I can extend Emacs by switching to my scratch buffer and hacking until I get what I want inside of 15 minutes in most cases. And then I drop it in an .el file and go from there. And org-mode is absolutely fantastic when it's integrated into the editor you're writing your code in.
  - jolux 5y ago
titzer 5y ago
FTA: > Thus, every program had to be learned individually and its complete user interface memorized. It was a sign of expertise to have learned the UIs of dozens of applications, since a novice user facing a new program would find their existing knowledge of a similar application absolutely no use whatsoever. Hello, web, looking at you. Except that no UI is stable long enough that people ever bother mastering it.
cheezymoogle 5y ago
To makes Emacs popular again, the core team needs to realize that their actual competitors are desktop environments, window managers, and automation tools rather than text editors and IDEs at this point. Programmers know what they want in an editor--the general populace doesn't (beyond a bare minimum of having it work like Google Docs or Microsoft Word). Emacs doesn't need to change at all, it just needs tools that go a few levels deeper in its philosophy. That is to say, first make Emacs capable of controlling non-Emacs GUIs and piloting web browsers. Second, improve automation tooling that so that individuals can make and share no-code macros for simple tasks. EXWM, an Emacs-based window manager has already taken a great first step towards accomplishing this. Emacs is a keyboard macro editor stuck in a mouseless era where Lisp Enlightenment was still a thing. It's great, but it's niche. Most people don't actually want or need that (or to be more specific, they don't know that they need or want it). The way to directly grow the user-base is to get the general population on board Emacs first, then evangelize for the idea underlying open software afterwards. You do that by solving the problems that they already have more efficiently than their present solutions. Org-mode really nailed it in this department. I switched to Emacs for org-mode, but stayed for vanilla Emacs and EXWM. If Emacs were just Emacs, I'd probably be using a different editor. Without definitive hooks, Emacs is esoteric, opaque, and frightening to the general population, if they know about Emacs at all besides vim's evil rival. They just don't need Emacs in its current state. What they do need is something that makes it trivial to automate the dumb and repetitive tasks that they have to do every day on a computer using a browser. This is no longer shell or plaintext processing for the majority of non-IT users. It's interfacing with GUIs. They need middleware to automate interfacing with kludgy enterprise software. They need middleware to speed up internet browsing. If Emacs were a blank slate project today, fulfilling the same type of needs, I could see it being a mashup of EXWM, Selenium, and AutoIt. Its killer features would be a guarantee that the same controls (that the user selected from a common set e.g. Microsoft Word, Firefox, Vim, Emacs, etc.) worked functioned between applications. Having the ability to record mouse and keyboard macros without ever needing to see a line of code, but also providing the ability to drive using the DOM, OCR, or whatever niche smart interface is needed would be a second killer feature. These coupled with the already standard Emacs and EXWM features would attract a ton of new users that would actually have a compelling reason to learn how to use it and then later adopt to the Emacs paradigm. EXWM is already 70% of the way for a minimum viable product for something like this. It just needs to be bundled with more mature macro tooling beyond 90s relics like xdotool and xautomation along with a distro with sane defaults. Having a single abstraction layer to control everything from userland on through web platforms would be a dream for accessibility and returning a semblance of control to users.
ashton314 5y ago
Inspired in part by this article, I put together a quasi-Emacs distribution for my wife who is a writer. It turns on several of the suggestions in this article by default, such as CUA mode, etc. https://github.com/ashton314/amethyst https://github.com/ashton314/amethyst
mleonhard 5y ago
I've been using Emacs for 17 years. I want every change suggested in the article, especially 'redo'. A few additional ones: - After pressing Alt-X, show a list of recently used commands. Allow moving between them with the up/down keys. Show a docs pane which explains what the command does, how to use it, and has an example. For new users, pre-populate the recently-used commands list with common commands. This is like the auto-complete "intellisense" function that saves me so much time when using JetBrains & VSCode. - When opening/saving a file and typing the path, automatically show the directory contents and hi-light entries that match the path. Show recently opened files and directories in bold. Scroll the listing with PGUP/PGDN/mouse-wheel. I often use emacs to open log files which contain long unique prefixes which are error-prone to type. Allow using the mouse & arrows keys to select the file. - Auto-save and auto-format. I love this mode when editing Rust code with CLion. It gives me something I've wanted for a long time: to write code without thinking about formatting. There's probably already some complicated way to get this to work in Emacs. Ideally, emacs would check if appropriate tools (rustfmt) are installed and make it just work automatically. - Allow using ENTER to add newlines to a search-replace command. I can rarely remember whether it's CTRL-Q, CTRL-J, or both and frequently make mistakes. - Allow writing Emacs commands in popular languages like Python 3 or JavaScript. Include a tutorial for each supported language. The lisp bigots will be angry about this. - Create a public issue tracker for emacs, ideally on GitHub. This will let users help each other and participate in setting issue priorities. Include a code of conduct. Do not auto-lock old issues like Flutter Team does. Old issues are findable by search engines. Workarounds and error messages change over time. When issues are unlocked, users will add comments like "The fix now requires change X. Here's the new command that worked for me ..." Locking old issues saves the dev team some effort but destroys a lot of the utility for users.
- tgbugs 5y ago
  > especially 'redo' undo-redo is in emacs-28 now, though not the default behavior. > Allow writing Emacs commands in popular languages like Python 3 or JavaScript. For js see https://github.com/emacs-ng/emacs-ng https://github.com/emacs-ng/emacs-ng Integrating additional runtimes into the Emacs core, especially ones that also have a single main thread are likely to be a complete nightmare. There are already insane and undebugable performance issues with things that run on the main graphics event loop or on timers. If elisp can somehow be made multi-threaded there might be a chance. However, there is SO much elisp code that assumes synchronous ordered execution that will break in subtle and unexpected ways when that restriction is lifted I expect it will take even longer than the transition to lexical scoping (and that is just in the core). I would love to be wrong though. With respect to Python, the cpython runtime and semantics for redefinition are likely even more nighmareish because it is so easy for classes and instances to become out of sync and you wind up having to restart the whole environment just to clear out the bad state or risk creeping insanity. Also the churn in the Python ecosystem is likely far too high for Emacs to be able to maintain. So there are both technical and process mismatches. You could always run python in a separate process and use message passing though. Work to support LSP certainly paves the way for it, and elpy has fully interop with python as well, so you could use that machinery to operate on buffers in languages beyond python. So if all this is possible why isn't anyone doing it?
bitwize 5y ago
Emacs has already been rewritten as a completely modern application in a modern programming language (JavaScript). It's called Visual Studio Code. We can now safely deprecate the original.
mlang23 5y ago
The title is rather strange considering Emacs is Free Software. Forks are fine. So why not UX forks. But demanding changes to the original without going through the dev process as everyone else would need to do is rather weird. "X should do Y" seems to be the new way of treating eachother... If you ask me, Emacs is fine as it is. In fact, I have been bitten by two changes over the time which come from the "better UI" camp. matching-paren-mode stopped to do the jumping cursor thing, which I totally rely on working with a braille display. I luckily caught this during the dev process and managed to submit a patch which adds a flag to force the "old" behaviour. And frankly, the guy who forced transient-mark mode on the world needs to hugs till he feels the pain. I am always bewildered when something I just marked suddenly vanishes just because I hit del. Move cursor a bit and DEL suddenly does something different again. IOW, I am a long-time Emacs user, and really, stop breaking the world just because you think something needs to be "modernized". Breaking the user experience of long-term users in order to cater to newbies is rather rude to those who have invested considerable time to learn the system so they can use it as effectively as possible.
- bjourne 5y ago
  Xah Lee and friends maintains a mode called ErgoEmacs that implements most of the changes he proposed: https://github.com/ergoemacs/ergoemacs-mode https://github.com/ergoemacs/ergoemacs-mode
ycstohley 5y ago
Do nothing. It's awesome.
erlkonig 5y ago
TL;DR * Don't change any of the naming, Emacs's naming is either better than what the article proposes, or cannot be changed everywhere it would need to be * Don't push for CUA copy/paste unless there's a plan for where to put both the C-x and C-c keymaps, and NOT on Alt (more info below) - if you have one, add a menu item to turn it and similar things on together, with help about it. * Add to the top of NEWS (C-h n) how to kill the NEWS buffer The article's point that Emacs's use of "frame" and "window" are quirky is true, but running it on a true terminal would mean the standard use of a the word "window" wouldn't even apply. However, since few people do that now, I agree that "window" to describe the view of Emacs overall on a terminal, or in a desktop window, and "pane" for the subsections (NOT "frame") sounds reasonable. EXCEPT that this would break the name usage in a staggeringly large amount of LISP code, and thereby add cognitive dissonance when reading code, documentation, function calls and so on. So sadly, I think being resigned to being consistent instead of having different terminology for a beginner vs advanced user is a better call. I've mapped keys for Alt, Meta, Super, and Hyper to my keyboard. Since Alt key (and AltGr) are, as far as I know, notionally for typing glyphs that aren't on the keyboard, it would be stupid to mix the Alt and Meta concepts - those need to be on different keys. All the article is doing by arguing that Alt should be hardwired in to the default emacs keymap is going down the same annoying path we did with backspace-vs-delete: Eternally confusing two different things over a keyboard layout peculiarity NOT shared by all users. Yes, the Scratch buffer should default to text mode. Experienced users who like the current default can configure for it. C-k and C-y are named mnemonically, so unless one wants to move copy to "Ctrl+c" and paste to "Ctrl+p" (which are both harder to read, btw, thana C-c and C-p), don't break one feature (mnemonic names) for another feature only some people prefer. Also, the kill-ring system does NOT work like copy+paste, and there are a number of complexities around X cut buffers the article author may not be aware of where something you kill/copy may not end up in the buffer the other app can yank/paste. There also nothing wrong with "buffers" - a editor with a concept lacking in the UX many other editors is certainly allowed to apply a single consistent name to it. It's unfortunate that this use of the word is unique to software (compare "buffer zone" in normal English)... "stash" at least had a concrete meaning to non-devs ("working copy" doesn't work since the in-RAM could be the original, "draft" doesn't work because it may have been saved to disk, etc, etc). "slate" would have been an amusing choice. As with the discussion on "window"/"frame", changing "buffer" consistently would be a nightmare. To the user complaining about copy/paste/etc not being all together, they are in contrast, bound to mnemonically reasonable keys. Also, Dvorak. Also, a huge number of PC users don't use the Ctrl+{C,V,X} anyway, and don't understand that complaint to begin with. "Keybind" is a pretty commonly used term in PC games, and is a superset of "Keyboard shortcut" since it's understood by PC gamers to include mouse buttons and so on as well. It's notionally hard to apply "keyboard shortcut" to the act of binding a function to a mouse key, so the "keyboard shortcut" falls short of the concept and will just cause confusion. Now saying a key is "bound" to an action may be confusing, sure, and what's funny is that saying a key is "tied" to an action would probably make sense to most users. Yet those are synonyms. Go figure. Having taught users how to use editors in Unix for years, my students only complained about one thing in Emacs - getting stuck in NEWS and not knowing how to get out. Usually this happened before they knew how to kill/switch buffers. Nothing else really bothered them, and they largely learned by using the in-editor tutorial. (those users were also taught vi, which is unquestionably harder to get started in, though vim today now points users at a tutorial)
brlewis 5y ago
I'd be interested to see an exhaustive list of computer programs that are as old as emacs that people still complain about today.

112 points by AJRF 5y ago

been using emacs for several years... What could be improved is speed. Too many times it doesn't see some keys combinations I hit. Screen redraw should be faster too (I spend a lot of time in front of it so that kind of "detail" is actually important). Loading big files is slow. Editing long lines is slow. Of course it doesn't happen often but when it happens it's annoying. Emacs could also propose options to better align on common behaviors (for example C-left/right arrow) doesn't behave like in other editors. It could also be more "discoverable". There are hundreds of functions so that 100% of my needs are covered. But every now and then, when I want to find a command, I DuckDuckGo it... It'd be nicer if somehow there would be an assisted navigation in the commands (or a pointer to that assistance I've been sorely missing :-)) But I like it anyway. 'cos it's faithful, community grown, etc. And if I had time I would contribute. But emacs is an old platform so there are many choices buried in and reaching the level of knowledge necessary to contribute is probably very high...

Tomte 5y ago
> What could be improved is speed. Native compilation is coming in the next version and should help quite a bit.
- wiz21c 5y ago
  I'm already on the 28.0 branch, makes no visible difference (my workflow is rather basic : editing lots of code, bits of org mode, bits of WL)
  - daptaq 5y ago
    Are you sure you have libgccjit installed and configure found it?
    - wiz21c 5y ago
      My configure's config.log says : #define HAVE_LIBGCCJIT 1 #define HAVE_LIBGCCJIT_H 1 So, yep it has it.
- medo-bear 5y ago
  i think running as a server should be made default. i imagine that alot of people are opening alot of seperate instances
  - lloda 5y ago
    I don't run Emacs as a server because it freezes occasionally and it's very painful to have a couple dozen windows in eight workspaces go down. If I could rely on Emacs never freezing, I'd be happy to run it as a server.
    - lvass 5y ago
      I have init manage an emacs daemon but open separate emacs instances if it's doing something important, even though it practically never freezes for me. I think this works fine as long as you don't have server-start in your config.
kryptiskt 5y ago
"Buttery Smooth Emacs" contains some insight into what goes on under the surface of Emacs and is a great read: https://m.facebook.com/notes/daniel-colascione/buttery-smooth-emacs/10155313440066102/ https://m.facebook.com/notes/daniel-colascione/buttery-smoot...
abdullahkhalids 5y ago
> It could also be more "discoverable". I definitely agree that I want to type some string and it should show a fuzzy search from all available commands and their descriptions. That would be huge timesaver for functionality I know exist, but I forgot the exact commands.
- uncletaco 5y ago
  This is literally what `M-x` does. You want to do the same for functions? `C-h f`. Variables? `C-h v`. Keybindings for the current mode? `C-h ?`. If I'm not mistaken when you install vanilla Emacs the screen even includes a tutorial and guided tour that both tell you these commands.
  - trey-jones 5y ago
    Yes, once you make the connection between every single keypress invoking an elisp function, and the various help combinations (variables, functions, keystrokes as you mention), I think Emacs is actually the most "discoverable" editor that I've used.
  - wiz21c 5y ago
    Except when the name of what you look for doesn't match your mental model (yep, I'm in the group of people who think software should adapt to human and not the other way around) Example : I want to change the encoding of a file when I load it... Good luck figuring that out without resorting to reading the documentation.
    - uncletaco 5y ago
      And here I would argue that, since the documentation is included with Emacs and can be pulled up in the editor, this is still a point towards its inherent discoverability. Again when you load emacs there's a link to the manual on its splash screen and as a guided tour. A lot of people rush to turn off this screen or suppress the menues on startup (which I get, the menu bar is pretty ugly) but they do have useful functionality for someone who doesn't know Emacs.
yakubin 5y ago
> been using emacs for several years... What could be improved is speed. Same here. Long lines are especially painful. And it's quite surprising what Emacs considers a "long line". I have a file in my project with tests, where I have an array, with each element of the array on a separate line, averaging at around 125 characters per line (some of them weird Unicode characters, so not just ASCII). There are 52 lines of it. And when I scroll down the file with C-v (Page Down basically) it scrolls quickly up until I get close to this place, then I get something like 1.5 seconds delay while it's hanging there. It's ridiculous. Another thing is how easy it is to freeze Emacs into being completely unusable when editing files over Tramp (with remote work it's the go-to solution), caused by an unreliable connection. Mostly it happens when the underlying VPN connection is dropped. When that happens, Emacs freezes with no explanation whatsoever. I can only guess what happened. C-g, Esc, nothing works, regardless whether the VPN connection is restored or not. The only solution at this point is killing this instance of Emacs. Specifically for this purpose I crafted a one-liner to kill the right instance of Emacs[1] (the one under the mouse pointer): kill $(xdotool getwindowpid $(xdotool getmouselocation | cut -d : -f 5)) Also, magit is painfully slow. When using it, I always wonder if Emacs is frozen again, or if it's just magit being magit. It's a shame Fork is not available for Linux. [1]: The other instance of Emacs is used for tracking in org-mode the time I spend on different tasks. I used to do it all in a single instance, but then I kept losing that data due to Emacs freezing like that, so I started using a separate instance for the time-tracking. I really think Emacs should be a multi-process application to prevent such situations.
- lloda 5y ago
  xkill ? But I agree. Emacs should be faster.
  - yakubin 5y ago
    I didn't know of xkill. Thanks!
- jpeloquin 5y ago
  > some of them weird Unicode characters, so not just ASCII This makes me suspicious that it's the font cache causing the slowdown (assuming Windows), not long lines. I saw similar symptoms a couple years ago and fixed it with (setq inhibit-compacting-font-caches t). You could also try increasing the garbage collection threshold on the theory that the lag is a gc pause. I've used: (setq gc-cons-threshold (* 511 1024 1024)) (setq gc-cons-percentage 0.5) (run-with-idle-timer 5 t #'garbage-collect)
rightbyte 5y ago
Have you tried "native Emacs", AoT compiled with libgccjit?
shrimpx 5y ago
> Too many times it doesn't see some keys combinations I hit. This caught my eye because I tend to think the opposite of this statement. Emacs doesn't skip a beat on text input -- unlike say VSCode which has perceivable input lag. In my experience, when Emacs gets slow it's a configuration problem, like flychecking on every keystroke, or a slow/poorly written third-party package. Raw emacs is blazing fast. Disclaimer: I use `emacs -nw` -- no GUI toolkits.
BeetleB 5y ago
> It could also be more "discoverable". There are hundreds of functions so that 100% of my needs are covered. But every now and then, when I want to find a command, I DuckDuckGo it Have you tried the apropos command? For me, often using helm/ido and trying to guess actually leads me to the correct command. I personally haven't even tried apropos, so I don't know how good it is.

medo-bear 5y ago

i initially hated emacs' non-CUA bindings. now my thoughts are opposite and because i spend so much time in emacs, when I need to go to CUA it's quite annoying. i agree that CUA should be made default, but with immediate option on start-up to use original emacs bindings. i think it will put off far fewer people

acomjean 5y ago

I used Aquaemacs on my work machine. It wasn’t perfect but it really did integrate well with macOS. the command key doesn’t overlap with and native emacs commands which helped. Im using IDEs more these days but still drop text into emacs if on a remote terminal or need to use it’s macro feature. Installing emacs plugins or extending the application always seems daunting and seems to always involve manual king editing a list config file….

roenxi 5y ago

Interesting commentary. I do think this is a little harsh on the poor Emacs undo system. I can't really push back on the idea that Emacs' undo system is excessively confusing, because I use Emacs and I don't understand it. I usually save text in a second buffer if I think I'll need it later. But the solution should be to improve the UI rather than remove functionality. Consider what magit did to a similar problem in git - git is powerful with a weirdly crippled CLI. Magit adds a great ... Emacs User Interface? EUI? and all is well. There is a probably a similar solution to the Emacs Undo problem.

Guthur 5y ago
Just add undo-tree and blow everyone's mind :)
psychstudio 5y ago
Given your current situation, undo-tree-visualize will change your life.
- medo-bear 5y ago
  wow. is there something like this but for a whole project ?
  - blahgeek 5y ago
    I think that something is "git" :)
    - medo-bear 5y ago
      nope. what i mean is doing undo operations on a project as opposed to a buffer. lets say you have 3 buffers open and you edit buffer 1 (i), then you edit buffer 3 (ii), then you edit buffer 2 (iii), and then back to buffer 3 and you edit it some more (iv). finally you want to do project-undo from this point in buffer 3. the undo sequence then goes like this: (iv) - (iii) - (ii) - (i)
- 5y ago

sullyj3 5y ago

Title could probably use a (2006)

mcc1ane 5y ago
or (2015)

Decabytes 5y ago

I posted a link here to a Reddit post that said “if you could change one thing about emacs what would it be?” It had almost 200 comments. Some answers definitely touched on these points. But for the most part, what Emacs users wanted was for the Gnu Emacs maintainers to do was… 1. Switch out Elisp for a Common Lisp or Scheme 2. Update the way Emacs Ui Core so it used standard GTK or something better. (The current implementation uses a lot of ugly hacks to support a subset of GTK) 3. Ability to scroll without bringing point along with me so I can quickly check something off screen then just continue typing where I left off. 4. Improve threading so that things like TRAMP didn’t freeze when you were connecting 5. Fast/Arbitrary graphics support I think for most Emacs users it’s a performance thing. Though the improvements to the GUI code would go a long way to making it easier to make Emacs be more user friendly. In terms of this article. I think all of this is possible in a separate distribution of Emacs right now. Emacs will never turn on most of these things by default. But maybe if a version of Emacs that makes these changes becomes wildly popular, the current maintainers would be more amenable to it. https://old.reddit.com/r/emacs/comments/padv22/if_you_could_change_one_thing_about_emacs_what/ https://old.reddit.com/r/emacs/comments/padv22/if_you_could_...

clircle 5y ago
Hopefully pure-gtk branch will be merged prior to Emacs 28, addressing (2). On (1), I'm not much of a programmer, but Emacs-lisp fine, so I'm not sure what benefit changing languages could bring.
- slightwinder 5y ago
  Is the pure-gtk-branch really working on switching the underlying UI-architecture? Or just removing the hacks for X11 and moving them to gtk?
  - clircle 5y ago
    pure-gtk doesn't decouple ui process from editor, if that's what you're asking about.

giancarlostoro 5y ago

I would love Emacs to get a facelift in the UI aspect. I like what Neovim is doing for UI stuff. Maybe Remacs can head a similar direction.

smackeyacky 5y ago
Given that emacs just needs a good editor, maybe get them to integrate neovim? ;-)

toolslive 5y ago

what a lot of people fail to realise is that emacs key bindings *are* consistent with other tools. Take a look at bash (or the korn shell): begin of line (C-a); end of line (C-e); kill rest of line (C-k). Emacs key bindings are the same. Not everybody grew up using windows.

still_grokking 5y ago
That's because GNU ReadLine uses Emacs key-bindings. It's not the other way around.
- toolslive 5y ago
  I think these key bindings go (at least) back to csh.
  - ByteJockey 5y ago
    csh's initial release was 2 years after emacs.
Veen 5y ago
> Not everybody grew up using windows. No, but almost everybody did. Very few people grew up using korn, readline, and emacs.
- G3rn0ti 5y ago
  But I’d argue learning basic Emacs key bindings gives you the benefit of becoming better on any Linux terminal. Going through the tutorial does not take much time. I think the author is right about the arcane terminology („meta key“, „buffer“, „window“, „frame“ etc) that should be changed and, too, configuring CUA Mode by default to help newbies a bit. I personally prefer using „control c“ and „control v“ for copy and pasting. Mind you if you like to use keyboard macros, you can’t use CUA mode copy/cut/paste bindings in them. That confused me quite a bit as beginner. However, I don’t think I ever got confused by Emacs undo system. It basically does the same thing as in other editors, just the key binding is different.

daly 5y ago

I've been using emacs for 35+ years. It does everything I need to do. If it doesn't, it has lisp. And then it does. I only use fundamental-mode. Emacs, like lisp, is "clay for the mind". You can adapt it to any task easily.

Scarbutt 5y ago
I only use fundamental-mode. Why? do you use emacs for programming (besides elisp)?
greggman3 5y ago
I've been using programmable editors for 35+ years. They all do everything emacs does and more and are just as adaptable.
- BeetleB 5y ago
  Sorry, but which programmable editor lets me read/send email, create TODOs that link both to a relevant email, and a line of code in another file, and let's me autocreate flash cards?
  - pjmlp 5y ago
    I bet there is a VSCode or Sublime plugin for that. But if you prefer something more oldie, there are plenty of plugins for Ultraedit, Notepad++ and similar with scripting support.
agumonkey 5y ago
and emacs is already so packed.. even after rtfm 3 times thoroughly (or so I thought) I learn there's something else I didn't know about maybe the only thing I'd like to see more center, is a blend of crdt / live-notebook in simple buffers. This could be very benefitial to newcomers too.. you can pair tutor, enjoy things in teams right inside your window

mark_l_watson 5y ago

I bought the Emacs Manual from Richard Stallman and friends, so many years ago, and I still rely on it, especially with Mosh+tmux for working in remote servers. Off topic, but I have been trying to figure out why Emacs startup got faster and editing seems snappier on an M1 MacBook. The M1 is generally faster but not enough to account for the difference. Maybe some engineers at Apple in some way optimized the Emacs that ships with macOS? The speed up has increased my use of Emacs locally on my laptop. EDIT: I love Common Lisp, but probably it is not worth the effort to replace Emacs Lisp.

agigao 5y ago
Emacs did speed-up on M1? When/How? :D Which Emacs distribution are you using?
- mark_l_watson 5y ago
  I just noticed that I am now running the Home Brew built for M1 install of Emacs: /opt/homebrew/bin/emacs It is really nice to be able to have Brew installs for Intel (Rossetta) and M1 side by side (in different root directories).
  - snazz 5y ago
    Emacs doesn't appear to be preinstalled in macOS anymore (I think the ancient version they were shipping was removed with Catalina).

h2odragon 5y ago

Why should emacs have to adopt your changes (or mine)? Make a "Modern-Emacs" and make it what you want, make it something you and others can love. Maybe others will love it enough to contribute, maybe no one but you will ever use it. Either way is great, and you still have your ideal tool.

b5n 5y ago

Lately there's been a lot of talk about what Emacs needs, written mostly by people who don't understand Emacs. Emacs is more of a journey than an application. It's similar to a blacksmith forging their own tools - Emacs is the metaphorical ingot, waiting to be transformed and molded by the user. If you're happy with what you're using then you don't need Emacs, and Emacs doesn't need to appeal to that crowd. Emacs isn't a VSCode competitor, it's something entirely different, and it's waiting for those who desire transcendence - shedding the limits imposed by other tools. You can install and use Emacs as quickly as any other application, but to truly reap its benefit you must go deeper. I don't see the need to cater to people who clearly want something else, those tools already exist, please leave Emacs to those of us who appreciate it for what it is. I disagree with all the reccomendations made in this article, all these changes are easy to implement, and the user is encouraged to do so - one of the main selling points of Emacs. That doesn't mean there is not room for improvement, Emacs is still constantly improving. Additionally, I've encountered many instances where a colleague or friend introduces me to some new feature in their preferred application, the majority of the time it's a feature that's been available in Emacs for years if not decades. I'd prefer we continue to focus on the needs of Emacs users rather than the wants of non-emacs users. Emacs will still be waiting for them when they're ready.

greggman3 5y ago
Seems like you completely missed the point of the article. The article called out that none of the changes make emacs any less powerful nor do any of the changes remove any functionality. Users can still do everything they could always do with emacs. They can still take this "journey" you mention. All the changes do is let them get started quicker and jump in with at least some familiarity. Old emacs users such as yourself can keep on using your non-standard keys and old terminology. For you, nothing would change. For new users, they'd be productive quicker and still able to take advantage of all the things that keep fans of emacs using to emacs.
- b5n 5y ago
  I can't help but feel that you missed the point of my comment. New users should be encouraged to make those changes themselves if they feel the need to. If that's not something they're interested in, why use Emacs? Anyone can publish a config and distribute it. For instance, the author of this article could create a 'new user friendly' config and distribute it just like doom, spacemacs, etc. If it's popular enough it will see a lot of use, but my guess is it would most likely wallow. Making those changes default would require existing users to update their configs, not necessarily a big deal, but for what? So a new user can download Emacs, play with it for a minute, and still conclude that Emacs is a dusty relic because they don't understand the philosophy? The whole idea of chasing new Emacs users is kind of silly, Emacs is more popular than it has ever been, and if a new user doesn't come to Emacs for what Emacs offers they were never going to stay. Out of the box solutions already exist, Emacs is in a different category, and need not compete in that arena - especially at the expense of current users. Appreciate the reply, cheers.

pjmlp 5y ago

Not sure what might still be missing, but I add the ones from XEmacs for graphical tooling integration, that might still be missing. By the way, Gosling now rather uses IDEs.

vkazanov 5y ago
He is THE Java guy, and java is pain without massive IDEs. What I find here funny is that Netbeans is dead, and nobody ever mentions it on HN. And we still talk about emacs.
- bitwize 5y ago
  NetBeans is dead because JetBrains was a better NetBeans.
  - SeanLuke 5y ago
    NetBeans was killed by competition with Eclipse. IDEA had nothing to do with it.
  - pjmlp 5y ago
    The only thing JetBrains is better is turning my laptop into a grill.
- pjmlp 5y ago
  All programming languages are a pain without IDEs, who thinks otherwise is masochistic. That guy did lots of stuff on his career, decades before Java was a thing, including XEmacs.

tsuujin 5y ago

I agree with basically everything in this article. Emacs needs new users, and to get them we need to reduce the barriers and user friction. In fact, increasing adoption through reducing user friction is a very well known topic in software design; this shouldn’t really be a topic for debate. But god help you if you suggest changing Emacs to conform with modern standards. I still maintain that the worst part of Emacs is the vocal minority of evangelicals in the community. I’ve been using Emacs as a daily driver for years, but it also took me years to adopt fully because the mental overhead of learning new terms for things I already knew drove me to ask for help from the community, and the community routinely made me not want to be any part of it. It sucks, because most of the community is fine, but the very loud voices of a minority group of purists who have built their identities around being “Emacs people” are incredibly aggravating.

BeetleB 5y ago
> Emacs needs new users Why do you think so? I've been hearing things like this for over a decade now. And compared to 10 years ago, the Emacs "ecosystem" has shown explosive growth. I can find much more useful help on Emacs on the Internet now. I can find an order more magnitude of tips/tricks than I could 10 years ago. There are many more packages easily accessible than 10 years ago. From within, it's clear that Emacs is doing quite well in terms of its user base. The fact that its percentage market share is dropping doesn't mean it's not growing - just that other things are growing faster. So I never understood why people imply that Emacs is somehow stagnating.
- User23 5y ago
  The Emacs user community is absolutely fantastic. Lisp is an amazing language to work in, and Emacs gives it to you for free. VSCode is an excellent piece of software, but you have to jump through hoops to extend it. I can extend Emacs by switching to my scratch buffer and hacking until I get what I want inside of 15 minutes in most cases. And then I drop it in an .el file and go from there. And org-mode is absolutely fantastic when it's integrated into the editor you're writing your code in.
- jolux 5y ago

titzer 5y ago

FTA: > Thus, every program had to be learned individually and its complete user interface memorized. It was a sign of expertise to have learned the UIs of dozens of applications, since a novice user facing a new program would find their existing knowledge of a similar application absolutely no use whatsoever. Hello, web, looking at you. Except that no UI is stable long enough that people ever bother mastering it.

cheezymoogle 5y ago

To makes Emacs popular again, the core team needs to realize that their actual competitors are desktop environments, window managers, and automation tools rather than text editors and IDEs at this point. Programmers know what they want in an editor--the general populace doesn't (beyond a bare minimum of having it work like Google Docs or Microsoft Word). Emacs doesn't need to change at all, it just needs tools that go a few levels deeper in its philosophy. That is to say, first make Emacs capable of controlling non-Emacs GUIs and piloting web browsers. Second, improve automation tooling that so that individuals can make and share no-code macros for simple tasks. EXWM, an Emacs-based window manager has already taken a great first step towards accomplishing this. Emacs is a keyboard macro editor stuck in a mouseless era where Lisp Enlightenment was still a thing. It's great, but it's niche. Most people don't actually want or need that (or to be more specific, they don't know that they need or want it). The way to directly grow the user-base is to get the general population on board Emacs first, then evangelize for the idea underlying open software afterwards. You do that by solving the problems that they already have more efficiently than their present solutions. Org-mode really nailed it in this department. I switched to Emacs for org-mode, but stayed for vanilla Emacs and EXWM. If Emacs were just Emacs, I'd probably be using a different editor. Without definitive hooks, Emacs is esoteric, opaque, and frightening to the general population, if they know about Emacs at all besides vim's evil rival. They just don't need Emacs in its current state. What they do need is something that makes it trivial to automate the dumb and repetitive tasks that they have to do every day on a computer using a browser. This is no longer shell or plaintext processing for the majority of non-IT users. It's interfacing with GUIs. They need middleware to automate interfacing with kludgy enterprise software. They need middleware to speed up internet browsing. If Emacs were a blank slate project today, fulfilling the same type of needs, I could see it being a mashup of EXWM, Selenium, and AutoIt. Its killer features would be a guarantee that the same controls (that the user selected from a common set e.g. Microsoft Word, Firefox, Vim, Emacs, etc.) worked functioned between applications. Having the ability to record mouse and keyboard macros without ever needing to see a line of code, but also providing the ability to drive using the DOM, OCR, or whatever niche smart interface is needed would be a second killer feature. These coupled with the already standard Emacs and EXWM features would attract a ton of new users that would actually have a compelling reason to learn how to use it and then later adopt to the Emacs paradigm. EXWM is already 70% of the way for a minimum viable product for something like this. It just needs to be bundled with more mature macro tooling beyond 90s relics like xdotool and xautomation along with a distro with sane defaults. Having a single abstraction layer to control everything from userland on through web platforms would be a dream for accessibility and returning a semblance of control to users.

ashton314 5y ago

Inspired in part by this article, I put together a quasi-Emacs distribution for my wife who is a writer. It turns on several of the suggestions in this article by default, such as CUA mode, etc. https://github.com/ashton314/amethyst https://github.com/ashton314/amethyst

mleonhard 5y ago

I've been using Emacs for 17 years. I want every change suggested in the article, especially 'redo'. A few additional ones: - After pressing Alt-X, show a list of recently used commands. Allow moving between them with the up/down keys. Show a docs pane which explains what the command does, how to use it, and has an example. For new users, pre-populate the recently-used commands list with common commands. This is like the auto-complete "intellisense" function that saves me so much time when using JetBrains & VSCode. - When opening/saving a file and typing the path, automatically show the directory contents and hi-light entries that match the path. Show recently opened files and directories in bold. Scroll the listing with PGUP/PGDN/mouse-wheel. I often use emacs to open log files which contain long unique prefixes which are error-prone to type. Allow using the mouse & arrows keys to select the file. - Auto-save and auto-format. I love this mode when editing Rust code with CLion. It gives me something I've wanted for a long time: to write code without thinking about formatting. There's probably already some complicated way to get this to work in Emacs. Ideally, emacs would check if appropriate tools (rustfmt) are installed and make it just work automatically. - Allow using ENTER to add newlines to a search-replace command. I can rarely remember whether it's CTRL-Q, CTRL-J, or both and frequently make mistakes. - Allow writing Emacs commands in popular languages like Python 3 or JavaScript. Include a tutorial for each supported language. The lisp bigots will be angry about this. - Create a public issue tracker for emacs, ideally on GitHub. This will let users help each other and participate in setting issue priorities. Include a code of conduct. Do not auto-lock old issues like Flutter Team does. Old issues are findable by search engines. Workarounds and error messages change over time. When issues are unlocked, users will add comments like "The fix now requires change X. Here's the new command that worked for me ..." Locking old issues saves the dev team some effort but destroys a lot of the utility for users.

tgbugs 5y ago
> especially 'redo' undo-redo is in emacs-28 now, though not the default behavior. > Allow writing Emacs commands in popular languages like Python 3 or JavaScript. For js see https://github.com/emacs-ng/emacs-ng https://github.com/emacs-ng/emacs-ng Integrating additional runtimes into the Emacs core, especially ones that also have a single main thread are likely to be a complete nightmare. There are already insane and undebugable performance issues with things that run on the main graphics event loop or on timers. If elisp can somehow be made multi-threaded there might be a chance. However, there is SO much elisp code that assumes synchronous ordered execution that will break in subtle and unexpected ways when that restriction is lifted I expect it will take even longer than the transition to lexical scoping (and that is just in the core). I would love to be wrong though. With respect to Python, the cpython runtime and semantics for redefinition are likely even more nighmareish because it is so easy for classes and instances to become out of sync and you wind up having to restart the whole environment just to clear out the bad state or risk creeping insanity. Also the churn in the Python ecosystem is likely far too high for Emacs to be able to maintain. So there are both technical and process mismatches. You could always run python in a separate process and use message passing though. Work to support LSP certainly paves the way for it, and elpy has fully interop with python as well, so you could use that machinery to operate on buffers in languages beyond python. So if all this is possible why isn't anyone doing it?

bitwize 5y ago

Emacs has already been rewritten as a completely modern application in a modern programming language (JavaScript). It's called Visual Studio Code. We can now safely deprecate the original.

mlang23 5y ago

The title is rather strange considering Emacs is Free Software. Forks are fine. So why not UX forks. But demanding changes to the original without going through the dev process as everyone else would need to do is rather weird. "X should do Y" seems to be the new way of treating eachother... If you ask me, Emacs is fine as it is. In fact, I have been bitten by two changes over the time which come from the "better UI" camp. matching-paren-mode stopped to do the jumping cursor thing, which I totally rely on working with a braille display. I luckily caught this during the dev process and managed to submit a patch which adds a flag to force the "old" behaviour. And frankly, the guy who forced transient-mark mode on the world needs to hugs till he feels the pain. I am always bewildered when something I just marked suddenly vanishes just because I hit del. Move cursor a bit and DEL suddenly does something different again. IOW, I am a long-time Emacs user, and really, stop breaking the world just because you think something needs to be "modernized". Breaking the user experience of long-term users in order to cater to newbies is rather rude to those who have invested considerable time to learn the system so they can use it as effectively as possible.

bjourne 5y ago
Xah Lee and friends maintains a mode called ErgoEmacs that implements most of the changes he proposed: https://github.com/ergoemacs/ergoemacs-mode https://github.com/ergoemacs/ergoemacs-mode

ycstohley 5y ago

Do nothing. It's awesome.

erlkonig 5y ago

TL;DR * Don't change any of the naming, Emacs's naming is either better than what the article proposes, or cannot be changed everywhere it would need to be * Don't push for CUA copy/paste unless there's a plan for where to put both the C-x and C-c keymaps, and NOT on Alt (more info below) - if you have one, add a menu item to turn it and similar things on together, with help about it. * Add to the top of NEWS (C-h n) how to kill the NEWS buffer The article's point that Emacs's use of "frame" and "window" are quirky is true, but running it on a true terminal would mean the standard use of a the word "window" wouldn't even apply. However, since few people do that now, I agree that "window" to describe the view of Emacs overall on a terminal, or in a desktop window, and "pane" for the subsections (NOT "frame") sounds reasonable. EXCEPT that this would break the name usage in a staggeringly large amount of LISP code, and thereby add cognitive dissonance when reading code, documentation, function calls and so on. So sadly, I think being resigned to being consistent instead of having different terminology for a beginner vs advanced user is a better call. I've mapped keys for Alt, Meta, Super, and Hyper to my keyboard. Since Alt key (and AltGr) are, as far as I know, notionally for typing glyphs that aren't on the keyboard, it would be stupid to mix the Alt and Meta concepts - those need to be on different keys. All the article is doing by arguing that Alt should be hardwired in to the default emacs keymap is going down the same annoying path we did with backspace-vs-delete: Eternally confusing two different things over a keyboard layout peculiarity NOT shared by all users. Yes, the Scratch buffer should default to text mode. Experienced users who like the current default can configure for it. C-k and C-y are named mnemonically, so unless one wants to move copy to "Ctrl+c" and paste to "Ctrl+p" (which are both harder to read, btw, thana C-c and C-p), don't break one feature (mnemonic names) for another feature only some people prefer. Also, the kill-ring system does NOT work like copy+paste, and there are a number of complexities around X cut buffers the article author may not be aware of where something you kill/copy may not end up in the buffer the other app can yank/paste. There also nothing wrong with "buffers" - a editor with a concept lacking in the UX many other editors is certainly allowed to apply a single consistent name to it. It's unfortunate that this use of the word is unique to software (compare "buffer zone" in normal English)... "stash" at least had a concrete meaning to non-devs ("working copy" doesn't work since the in-RAM could be the original, "draft" doesn't work because it may have been saved to disk, etc, etc). "slate" would have been an amusing choice. As with the discussion on "window"/"frame", changing "buffer" consistently would be a nightmare. To the user complaining about copy/paste/etc not being all together, they are in contrast, bound to mnemonically reasonable keys. Also, Dvorak. Also, a huge number of PC users don't use the Ctrl+{C,V,X} anyway, and don't understand that complaint to begin with. "Keybind" is a pretty commonly used term in PC games, and is a superset of "Keyboard shortcut" since it's understood by PC gamers to include mouse buttons and so on as well. It's notionally hard to apply "keyboard shortcut" to the act of binding a function to a mouse key, so the "keyboard shortcut" falls short of the concept and will just cause confusion. Now saying a key is "bound" to an action may be confusing, sure, and what's funny is that saying a key is "tied" to an action would probably make sense to most users. Yet those are synonyms. Go figure. Having taught users how to use editors in Unix for years, my students only complained about one thing in Emacs - getting stuck in NEWS and not knowing how to get out. Usually this happened before they knew how to kill/switch buffers. Nothing else really bothered them, and they largely learned by using the in-editor tutorial. (those users were also taught vi, which is unquestionably harder to get started in, though vim today now points users at a tutorial)

brlewis 5y ago

I'd be interested to see an exhaustive list of computer programs that are as old as emacs that people still complain about today.