Who Needs Modern Emacs?

This argument is always active in some form. The easy way out is to make a recommended list of extensions that someone who needs things can use, instead of making it the emacs default, because more often than not the people to whom these things matter haven't ever used emacs. - ship by default “cool” themes like Solarized (it seems it’s very important to have some dark mode these days) Modus-vivendi is cool. - show line numbers in the gutter (or its general vicinity) by default Already in emacs, needs a toggle from the user. - use the keybindings that are common in most “modern” editors (think cua-mode) there's a vim mode (evil) that's very good; the rest isn't necessary IMO - if you forgo emacs bindings then it's likely you won't be using emacs' internals very intensively either, and you might as well not switch. - make Emacs more mouse-friendly (e.g. right clicking would open some context menus, there would be more tooltips on mouse hover and so on) No idea, never used a mouse much with emacs but selecting a region, switching windows, changing window dimensions and scrolling works, and that's pretty much what I need. The context menu on right click is also pretty helpful; the menu at the top is enabled by default. - display open buffers as tabs, so people can always see them and click through them (think tab-bar-mode and centaur-tabs) No comment, never used tabs. - make the modeline “sexy” (think Spacemacs) Many, many packages that can do this. Doom-modeline, minions, etc - replace Emacs Lisp with Scheme/Common Lisp/JavaScript They can make the first few commits :\^) I'll make the logo. - have a fancy configuration wizard to help with the initial setup of Emacs bundle some popular third-party packages by default (e.g. company-mode, lsp-mode, etc) to fix some perceived deficiency of vanilla Emacs Could be an org file with Hyperbole buttons that'd copy whatever sections you like into your init.el. - rewrite the entire UI layer to make Emacs look more “native” and “sexy” What would that look like?

Agreed, I just would have better defaults (imo) in the default configuration like `modus-themes` be the default, simplified yes-or-no (short-answers), a slightly larger fill-colum (80 instead of 70), backups in a default backup dir in `.emacs.d` instead of random loitering where a file is saved, etc. Maybe vertical icomplete by default (that one is a leap). So nothing fundamentally different but those seem to be low hanging fruits imo. Also, in terms of parsing I'd add more integration with `tree-sitter` (which is a branch in dev IIRC), instead of regex for most modes.

> ship by default “cool” themes like Solarized (it seems it’s very important to have some dark mode these days) I have been using the 'wheatgrass' theme that comes with default Emacs for ages now, and it's great.

> use the keybindings that are common in most “modern” editors (think cua-mode) I know this is what's turned off a lot of folks I've talked to about emacs.

This is such a weird discussion. The thing is that Emacs is obviously deficient in terms of the packaged defaults to meet the most common immediate needs of the average user. To use your first example, yes, obviously Emacs should ship with an easy 1-click solution to enable dark mode. This is one of the clearest and most obnoxious things that Emacs has neglected. The catch is that the average user and average Emacs user is not a strongly overlapping Venn diagram. While I do assert that it is obviously deficient to ship Emacs with a blinding, retina-searing black on white theme, I also immediately concede that there *are* dark themes available (either as distributed, or from external resources) and the process to switch themes isn't so complicated. But I do have to hunt down that process on a search engine, or remember how to navigate the Info system that I use for about 20 minutes a year (and new users have likely never, ever used, and probably never ever will). Emacs is like your handsome grandfather who aged like a barrel of fine whisky, but is still an acquired taste and goes down a little bit like fire. It's doing great for what it is. It's fine. But it hasn't let go of old habits in 40 years, and it'll be the same old pepaw in 20 more years. Your family loves him for who he is, but you don't introduce him to the new kids anymore because he's a little too old-fashioned and you can't tell those jokes these days, and it's a little bit too scary when he laughs about all the many ways a wooden spoon could be used for anything except cooking.

> But I do have to hunt down that process on a search engine, or remember how to navigate the Info system that I use for about 20 minutes a year (and new users have likely never, ever used, and probably never ever will). Options > Customize Emacs -> Custom Themes

Are toolbar menus supposed to be intuitive or feel natural? I’ve been using them since the 90s and every single time it’s awful even though I know exactly how they work and can infer how to get around them pretty well. I don’t have a better solution for exposing the mountains of options, I’m not that ingenious or clever. But I don’t think your reply addresses the problem I described.

I disagree on a few things. Emacs' bindings are effectively designed for ancient keyboards that are not produced for mass use anymore. It would be nice if they at least if they bundled a more modern binding set, and made the first run allow the user to chose. Much like spacemacs does with evil vs traditional (not to call evil mode more modern, but you get the idea). I also think a more modern emacs could include legitimate full multithreaded support. Overall though, I like emacs because of the legacy systems it has in place that allow it to do anything with a mild level of configuration (that essentially just points to or copies the work some other user has done). And I can make it pretty enough.

(You mean the menu bar.) Menu bars have been around since, I don't know... Xerox PARC? Apple II? I grew up with them on the Amiga, and on the Amiga you had to right-click to even get them to appear. I think they're... pretty easy to use for everyone of all age groups? And I think the menu bar's the first place people go looking for stuff. Including stuff like `cua-mode`. Seems pretty accessible to me.

Never mind dude.

One click is one click too many. Emacs needs to come **out of the box** with sane UI/UX defaults that take advantage of what everybody already knows about using computers. That includes not just cua-mode, but using standard terminology (e.g., "open file" instead of "buffer", "cut" and "paste" instead of "kill" and "yank", etc.) Also do what Autodesk did and deprecate Emacs Lisp, and expose Emacs internals through a COM-like FFI to support pluggable extension runtimes -- and ship a JavaScript runtime with the program so people can extend Emacs with JavaScript. I'd go so far as to recommend that Emacs remove its terminal interface -- legacy cruft at this point that interferes with implementing smooth GUI operation -- and other legacy UI layers (basically everything except Gtk4, Cocoa, and Win32). Go all in on being a graphical-only app. If you think that's too radical, requires too much to be rewritten, and is not what Emacs is about... now you know why a growing majority of developers use Visual Studio Code.

> remember how to navigate the Info system that I use for about 20 minutes a year (and new users have likely never, ever used, and probably never ever will) To me, the Info system is one of the best features of Emacs. Not just the system, but several of the main manuals are extremely well-written, exemplars of good computer documentation: Emacs, Emacs Lisp, Calc (especially), and Org Mode. I've recently learned to use the i key, which allows me to look up things in the index. Nothing like it in the world.

CUA mode comes bundled with Emacs and can be enabled via drop down menu. What's needed is for CUA mode to be the default. There's no reason why the default should be Stallman's pet keybindings from 1979, before everyone agreed that a single set of Mac-like keybindings would make all programs easier to use. Just use the damn keybindings that everybody else uses. Or be content being a niche editor for weirdos.

This argument (as I’ve seen it) usually starts from the question of how to get more users, and the response is “modernize defaults”, but personally the two things that really got me into emacs were: 1. Seeing what others could do with emacs, this was mostly through YouTube videos, blogs, and hearing anecdotes about why people use emacs (and seeing professors and professionals use it) 2. Opening vanilla emacs and disliking defaults. This forced me to immediately start hacking, finding new themes, learning how to remove the menu bar, etc. In my opinion, the learning curve is one of emacs’ greatest strengths, it encourages people to keep changing things until they create an editor that works for them, whether it’s perfect in 2 weeks or a decade

Yeah, info is pretty incredible for the time it came out. I don’t assert that there’s something wrong with it, just that I don’t remember how to use it year but year as I don’t ever really need to get into it often enough. It was also copied pretty much wholesale on windows back in the day, because it’s so good, but got a better layer of mouse navigation bolted on.

Replacing elisp with scheme would be kind of cool—maybe not worth rewriting all of emacs and all packages tho

Most software these days comes with a checkbox or yes/no question either during the installation or on the Home Screen splash page. It usually says “enable dark mode?” Sometimes it’s on by default, sometimes it’s not, but the main point is that it is presented to the user rather than tucked into a menu or dialog box hidden behind some mysterious keyboard invocation.

I wonder if there's any overlap between emacs users and people who drive cars with a manual transmission.

Using something something `tree-sitter` or any other real parser would be a nice improvement indeed (I hate dealing with regular expressions for font-locking), although I imagine it will take ages for this to actually be adopted by packages. Such changes are notoriously hard to execute. Some defaults can definitely be improved, but given how easy it is to change them today and the proliferation of many Emacs "distros", I don't think that'd move the needle much. I know that Emacs devs are making a few such small changes to defaults with every release, but when something has had such a long history as Emacs and is developed in a very democratic way, it's often hard to reach consensus even for the trivial stuff.

I doubt it - otherwise in Europe it'd be full of Emacs users. :D For the record - my car has manual transmission and I love it (except when stuck in traffic jams). :-)

Those happen to be the bindings in readline (e.g. bash), zsh and MacOS as well. They are hardly contained to Emacs and such defaults cannot be easily changed without generating massive backlash. Emacs's keybindings are often criticized (and are definitely inferior to vim's), but having used them for a very long time I definitely prefer them over CUA. Of course, that's very subjective.

Emacs is for tinkerers. :-)

Or you can have a runtime that supports both Scheme and Elisp - https://www.emacswiki.org/emacs/GuileEmacs I think the idea was good, but sadly it didn't make it to the finish line.

Oh my that’s cool

>I also think a more modern emacs could include legitimate full multithreaded support. Good luck. Every attempt down this path has fallen flat. It's very unlikely that this is anywhere in the near future for Emacs.

The issue is that emacs (at least vanilla emacs, other distros are often more plug and play) will never really be for people who aren’t willing to get past the learning curve, there are too many customization options, hooks, etc to pick up on. If you want a plug and play editor there are tons of them, VS Code is amazing, has good extensions and defaults such that you can install it and use it the same day, but if you want the absolute customization emacs offers, you need to learn how to customize it

Fair enough, but I think it'd reduce a bit of friction for first time users if they don't have to jump straight away in Emacs Lisp to configure Emacs and can get away with the defaults for a couple weeks, to get acquainted with the keybindings, modes, etc. W.r.t `tree-sitter` yeah, I've tried to write a major-mode for a language and once there are some pretty complicated statements or the language syntax is permissive, regex becomes a nightmare. Just looking at the code for `python-mode` is a tell, it's massive and somewhat difficult to understand because of the custom macros (and regex).

The reality is if you're gonna learn emacs mentally remapping C-c and C-v to C-k and C-y is very much the least of your worries. It's like complaining about wet socks during a tsunami.

\> So, I’m asking you this simple question - who needs “modern” Emacs? Who? those who might better off without Emacs whose needs can be met by "modern" editors. Emacs is on the splattered edge, where "some assembly is required." If you need training wheels or are put off by the idea that you're going to skin your knees dozens of times before you can ride without falling down then Emacs is not for you.

Dark themes are for noobs, why would emacs ship with dark themes? :)

The difficulty with posts like this and the responses is that it all comes from the same echo chamber of established, long time, respected Emacs users/devs who already have a vested interest in keeping the status quo and having others adapt rather than face adapting themselves. I'm not saying they're wrong necessarily, but I think it's worth seriously exploring the positive effects of modernizing aspects of Emacs. And I think to see how it can help all us grey beards, we need look no further than the effects that Doom had on the Emacs community. Doom (and before it Spacemacs) brought forth a ton of new (likely Vim) users willing to try out Emacs, and created a lot of momentum in new content that the whole Emacs community benefitted from. But before Doom existed, we had naysayers just like this post claiming that something like Doom wasn't necessary or needed. What we need is some visionary thinking that moves beyond this. We can continue to debate changing (or configuring) terms like buffer/kill/yank vs file/cut/paste or which themes are included or which keybindings - but in the end, to me it comes down to one thing - **how do we continue to see Emacs grow and increase adoption**? For my $.02, I'd love to see a bit more movement from the devs in this arena, but more importantly a ton more movement from the Emacs distro community in this arena, to create something that feels a bit more out-of-the-box like Sublime Text or VSCode. We have some good starts with NANO, but that's not quite enough. I think a lot more people would be willing to try and stick with Emacs with a stater kit geared toward those users that simply had a file browser and file tabs, more familiar keybindings, modern terminology, more sane behaviors (stop unselecting regions all the time!!!), and some better default options. Learning to configure from there with elisp isn't the issue to adoption - the issue is how much elisp you have to start with to get to something that feels familiar.

Modern? The first step is to get it to 1990. No offense to RMS. I'm sure his VT100 is still going strong.

If it doesn't happen, it doesn't happen. I'm still gonna use emacs. I do think it's an area where emacs can be improved though.

i don't know that CUA mode would be enough. Maybe something like including the which-key package by default, and allowing a prompt on first run with a non-customized config to choose whether to have it enabled (or the prompt could download and install it). Essentially, a lot of new user headaches could be included by having prompts at the beginning to enable more new user friendly niceties, rather than simply pointing to the tutorial (which is admittedly excellent, but imo expecting a 30 minute tutorial to cover the new user experience is unreasonable).

I'd argue that it IS at the finish line, but its just not worth the hassle of being mainlined unless some guy like Stallman himself makes it a priority.

Yeah I think that would be very cool, but unfortunately as usual it stumbles at the details like interoperability and different expectations around `nil` vs Scheme's `#f` etc. And there's also the danger that you end up with a more confusing ecosystem where different languages are used etc. In the end Emacs Lisp is probably a pretty good local maxima that can carry the platform forward.

More minds working on it is good for any editor. A percentage of users contribute code to the editor (new packages, improving existing ones, etc.), so more users mean more contributors. Making emacs less alien could make it more discoverable for the casual user.

Maybe we just need more advanced embedded tutorial that teaches how to better build your own config?

>... it will take ages for this to actually be adopted. `tree-sitter` decouples the font-lock task from major modes. No "adoption" necessary. And it won't take ages. You get it now in Commercial Emacs.

Thank you! ​ I definitely don't need nor want a 'modern' emacs. I try to stay away from distributions that try to mimic in some way visualcode. I don't want anything like vcode, because it sucks. And I also don't want to have to much contact with people who are thinking in these 'cool' terms. I would prefer to have conversations and discussions with the noncool people to whom I don't have to explain the benefits of emacs vs intellij and why emacs won't look by default so or so. Or why I think that not everything must be done in java. I got banned for life from the python subreddit for telling what I think python and it's userbase have become since it got so popular, so i know already that there is no place for people like me in such social environments ;) ​ Emacs being less popular is an advantage for emacs users who know what emacs is and who use emacs in a different way then the mainstream vscode folks. While the emacs community should be nice, helpful and friendly for cultural reasons I have absolutely nothing against the default emacs playing hard to get and hiding it's inner beauty behind the not so attractive default classic appearence and in comprehensible inner workings. This is the way to go to attract the right users. ​ Esthetics are important to me, but imitating the vscode style as is so popular now isn't sexy. It's some mainstream kitch. The fact that emacs is by default as it is made me rethink how my working environment should look like. Mine is minimal and distraction free. Also easy, simple and fast. If emacs would be by default bloated with heavy features i would have had a much harder time to configure mine to have these characteristics. ​ Culture really goes a long way. Every new emacs user is is welcomed not only with a quick startup, but some hints about emacs's history and gnu's philosophy. I am really so grateful for that. This gave me such a drastic new outlook on life and technology. ​ Emacs should never ever become vscodified!!! Emacs does not need mass adoption. If emacs will become mainstream I'm out. It wouldn't be the first fantastic and beautiful concept defiled by the masses

You must feel sooo cool

Ship treesitter and LSP into the core like what neovim is did. Non of the existing third party LSP packages has comparable performance to those editors where LSP is first-class. Keybindings isn’t something important, vim’s keybindings is even harder for newbie to use, but vim has higher popularity. But emacs’s keybindings are a bit ancient and learning it isn’t as rewarding as learning vim’s keybindings is learning indeed a thing. Mouse support and right key invoked popup is good, it is the subconscious behavior for people who used to use GUI to do something when they forget the keybindings/expect there should be something there but they don’t know what exactly it is. But after vscode’s prevalence, I think now people are/should accustomed to seek for a command palette (command/curl+shift+p) equivalent to M-x to to such things?

> I don’t assert that there’s something wrong with it, just that I don’t remember how to use it Seriously? * Can you remember `C-h m`? It'll help you with most, if not all, modes (major contexts). * Do you see the **Info** manual when you use `C-h i`? Can you open it? ...

While adding features for "adoption" is not a reasonable goal, some of those are still worthwhile quality of life features. We don't need to make Emacs "modern" to "attract users", we just need to make it better for existing users and not terrible for new users. - "ship by default “cool” themes like Solarized" More themes by default doesn't hurt; it doesn't help much, either. - "have a fancy configuration wizard to help with the initial setup of Emacs" A "configuration wizard", or a settings GUI, already exists: Customize. While a "initial set up wizard" is pointless, it does help if Customize can (a) stop ever contemplating touching the user unit file, and (b) act more like other packages, where you press buttons to get a prompt and enter values, instead of entering values directly into the buffer. - "rewrite the entire UI layer to make Emacs look more “native” and “sexy”" The Emacs GUI does need an overhaul --- not to look "native", and Emacs looks amazing already right now, but to (a) make it possible to display images without scrolling jumping around, (b) not fall over when encountering a moderately long line, and (c) maybe even display videos. This enables more capabilities to be coded into Emacs, rather than just appealing to what we might imagine a new user to be. - "use the keybindings that are common in most “modern” editors" New people seeing the apparent horror that looks like `C-x 5 2` end up thinking that Emacs keybinds are terrible and should be swapped out. They aren't and definitely shouldn't: very few applications, let alone editors, allow you to bind commands to arbitrary sequences of key combos, and Emacs takes advantage of that to be able to offer keybinds for way more commands by default. But that doesn't mean keybinding schemes that other editors use are bad. It is useful to offer good emulation of other editors. (IMO Viper should be moved into GNU ELPA instead of being available out of the box. It only serves to confuse new users as it just doesn't work as well as Evil if you're not already accustomed with it.) It also doesn't mean the key binding system in Emacs is perfect. The "disabled command" concept should be scrapped (if I don't know the command, how would I know if I want to use it or not? If I do, why would I want it disabled?). The "Key sequence starts with non-prefix key" error should never appear: If I bind "C-c a b" while "C-c a" is already bound to a command, just do the right thing and override it like `define-key` already does for nornal bindings. - "bundle some popular third-party packages by default (e.g. company-mode, lsp-mode, etc) to fix some perceived deficiency of vanilla Emacs" LSP is a nice feature that vanilla Emacs lacks. While it might be hard to bundle lsp-mode (copyright assignment), Eglot is already part of Emacs, please just ship it bundled just like org-mode. Bundling (then) third-party packages is something that has already happened multiple times: Org (I think?), transient.el in Emacs 28, and package.el in Emacs 24. It's not a magic bullet to attract users and achieve world domination, but it's not a fundamentally flawed idea either. - "make Emacs more mouse-friendly (e.g. right clicking would open some context menus, there would be more tooltips on mouse hover and so on)" It would still be really nice if there is a standard way to define context menus that are as keyboard friendly as M-x (right now there's the new context menu package, asking for key presses with transient or a keymap (or use read-char yourself like org-capture does), using completing-read and a incremental completion package so all candidates are displayed automatically, etc.). Of course, right click context menus already exist and already contain useful items. They're just not keyboard friendly enough. Overall, "modernizing" Emacs for the sake of being similar to other editors is a pointless goal, but thay doesn't mean some of what have been called "modernization" aren't good ideas. Who needs a modern Emacs? All of us, but we're already using it. I'd bet none of us would actually consider Emacs 23 to be better than Emacs 28. Will "modernization" efforts help? The term gets applied to so many different things, it's much more useful to just look at individual issues.

>make Emacs more mouse-friendly (e.g. right clicking would open some context menus, there would be more tooltips on mouse hover and so on) Now, It have been improved a lot on Emacs 29. For example, you can scroll screen the same way as in google chrome, just enable the `pixel-scroll-precision-mode` . And the right clicking aslo will get more useful context. Other two new features in Emacs 29: 1. Enable `dired-mouse-drag-files`, you can use the mouse to drag the file in dired, and drop it on any other program's window. 2. Enable `mouse-drag-and-drop-cross-program`and `mouse-drag-and-drop-region` at the same time to use the mouse to drag the text in region and drop it into any other program's window.

Again, I know it’s there and I know how to find the relevant help. The problem is that I have to refer to the help. The newbies don’t know where it is and when they find it, however naturally or intuitively they do, the result will still be confusion because you need a tutorial for the documentation. I shouldn’t need to clarify this.

Indeed. I just recently went through the hassle of converting the Django manual to Info format so I can access it in Emacs rather than always going to the web site.

I'm an heavy vi and vim user since almost 26 years, and I've recently switched to neovim. I'm not a spy :-P , I follow this community because I always wanted to switch to Emacs and become a real Grey Beard, but I have never found the pleasure to deep dive in your world. The two main reasons are: 1. I need an IDE built on my needs for my daily use This is what I've obtained in many years of vim customisation. 2. Lisp is the only language that I cannot stand. Sorry, it's like that. Maybe one day I will change, but all of those parentheses give me dizziness. That said, neovim is a superb example. By default is as vanilla as vim, in the beginning I was trolling it as an unnecessary effort. But now that I use it every day, I love how fast and flexible it is. Simple to hack and debug, easy documentation, an active community, many back-end languages, like Lua, Python, Ruby, etc. LSP Integration out of the box (almost). That is modernizing a software, cleaning and lifting it up, extending, documenting, and the most important thing, speaking about it. Communication. The website is sexier then vim, the code is on GitHub, etc. Modernizing something often is not even a technical matter. Honestly Emacs doesn't necessarily need a bunch of additional features that can be installed or configured by most users, it just need public relationship. Edit: typos

I think that there is a balance here — how many, and what kind of users would be attracted by those changed defaults? Would they be a net positive (submit good bug reports, write nice new packages, contribute to support channels in a positive way, contribute to Emacs itself), or a net negative (submit bad bug reports, not write packages or write packages that break other packages, clog support channels with “I’m too busy to Google”-type questions) to the existing community? Increased market share is not a definite benefit for existing users. Would those new users’ lives be improved by Emacs, or would they have been just as happy *or happier* in VSCodium / [Neo]Vim / …? I think that the impact of the various existing efforts (Doom, Spacemacs) for both the ecosystem and the new users is very positive. So there is still some space to go in the “more normal” direction that would still be good for everyone, and, I guess, we should all want a more “modern” Emacs (…onboarding experience) to exist. Without going too far, of course. Line numbers are icky, dark themes are objectively ugly, CUA mode is inefficient, mice necessitate pest control, one-tab-per-buffer is for people with too few buffers.

This, but also one that prioritizes the importance of prioritizing the important ;) By that I mean, sure install a custom theme and change your font size but don't spend 3 hours making an emacs useless for your workflow pretty. Instead make your critical workflows doable, note some ways emacs could improve them, then start using it and working on improvements as free or down time comes along.

> Commercial Emacs. What's that?

Nope, I'm dumb as paint -- even after close to 25 years using Emacs my config is a plumbers nightmare, but it mostly works for me. I like to use tools that can help challenge me to do better, no matter how much I suck.

I mean... ok. I'm just relating the feedback I got from developers who tried it and gave up.

> To me, the Info system is one of the best features of Emacs. Not just the system, but several of the main manuals are extremely well-written, exemplars of good computer documentation: I resisted it for 10 years and instead defaulted to the much worse life of alt-tabbing and googling from my browser, but this is 2000% true. However if you don't have nice fonts setup, it can be quite jarring.

Have you ever picked up tech, not understood it and put it down, only to come back years later and relearn the same tech and go 'oh it was easier this time'? It could be that you got better, or training content became better. Either way creating barriers to entry doesn't motivate the majority of the population, but I fully agree there are exceptions to that rule.

> The difficulty with posts like this and the responses is that it all comes from the same echo chamber of established, long time, respected Emacs users/devs who already have a vested interest in keeping the status quo and having others adapt rather than face adapting themselves. This is what bothers me the most about the emacs community. A lot of these discussions boil down to “emacs is just fine there’s no reason to change it, now let me go edit my 1500 line long config file I’ve been building for a decade to change the default behaviors”. Emacs is a great playground which lets you tailor it to your own needs fairly easily, so why are we so resistant to changing the out-of-the-box experience to be a bit friendlier? As an aside: I’d love to see how many long time emacs users just stick with the “good enough” current defaults and use them as-is.

> Again, I know it’s there and I know how to find the relevant help. The problem is that I have to refer to the help. The core issue is that: Why is having to refer to the help a problem? For bindings help, key translations taking 5 pagefuls of real estate is a big reason. Emacs 29 fixes this though. > The newbies don’t know where it is and when they find it, however naturally or intuitively they do, the result will still be confusion because you need a tutorial for the documentation. I shouldn’t need to clarify this. They should know how to use the help a little bit if they went through the tutorial right?

This is the point of the constant debate that the blog is retreading yet again. The newbies expect a gentler introduction, install the app and it’s comfy from the word go. Vs code feels like every other native app out of the box, and pops up hints and tips and “click here to automatically set up for this python file you just opened!” I don’t need the help being offered in this thread. I’m not the newbies that the debate is focused around. Stop talking at me about how to use emacs because the problem is neither that emacs is missing functionality or documentation nor that I struggle to use emacs. Stop missing the point of the example — so-called “modern” editors and dev environments include both the batteries and the guidance out of the box up front without the user needing to /seek/ out anything. Getting started on vs code is just a matter of opening almost any file and the app will nudge you along. This helps drive adoption numbers up and retain user attachment. It’s just like any video game, for example. If it’s too confusing or a bunch of manual labor to learn, most people tend to either revert back to the games they already know, or gravitate towards more simplified and basic games that don’t challenge the status quo by presenting an interface that follows all the traditional expectations. The A button is the confirm button. It just is. All the games confirm player input with the same A button, and even unify it across platforms. Emacs doesn’t have to join the ranks of the other software. It’s not necessary. But that’s what this is about. Stop being a Commodore 64 or an Atari jaguar.

to be frank I feel that emacs is waiting for modern me to catch up

> is that it all comes from the same echo chamber of established, long time, respected Emacs users/devs who already have a vested interest in keeping the status quo I don't think this is true. It is more like they don't have enough time or the resources to make everyone happy. My only problem with emacs developers is their resistance to a standardized FFI for interfacing with external libraries, which seems to ideologically rooted. Lem perhaps?

Link?

Personally, I think there is value in the midpoint of easy to get to and easy to parse help that you seek out. The automatic guidance has a tradeoff of being for very common cases and very opinionated which conflicts with extensibility. The middle ground option would be choices between approaches and a blurb about who they're right for I think. > Stop talking at me about how to use emacs Where did I do this?

[Implementing Elisp support in emacsng](https://www.reddit.com/r/emacsng/comments/nk9hk3/can_the_software_mechanisms_used_by_emacsng_be/) would probably be better. Their repo hasn't seen much activity over the last month or so though.

I don't have it online anywhere. Basically, any manual written in Sphinx has a texinfo build target. So just clone the repo that has the docs, and tell Sphinx to build that target.

Oh 100%, in fact I picked up and put down emacs a couple of times before it really stuck with me. Vanilla emacs may not work for everyone’s needs initially, I think the difficulty is showing people why they should spend more time with it, and the answer probably lies in more introductory content, guides on commonly used packages, configs, and etc, not necessarily turning the editor itself into something will be adequate out of the box, there are distros for that. Even the frame/buffer/window/kill/yank terminology may be odd for people starting out, but the built-in tutorial does a great job explaining what everything is. Optimizing for people who don’t read that couple of paragraphs is (in my opinion) unnecessary, because that was never the target audience, they’ll get more value out of another editor that doesn’t require the same level of customization and constant reading of documentation

Okay. There’s value in every approach. People aren’t looking for value on approaches, they’re wondering when 40 year old design decisions can be revisited for a new computing era. I don’t disagree with you, or anyone on either side. Everyone is right. There is no wrong. That’s why my first comment opened with “this is such a weird discussion.” Both sides constantly craft scenarios and ideals in which their idea is better than the other. Emacs also backs off and just says we allow everyone to solve the problems they have by providing completely generalized solutions — a lisp machine. Every point made in every comment in this Reddit thread and the blog post have been said for decades.

While I agree it's good for emacs to get better defaults (which is already slowly being done each new release) and a better interface, I don't think this is what will bring in new users. It might help the initial curiosity of the newcomers but what makes people keep using emacs is everything it provides as a framework to create your own workflow. I kind of agree with your point about terminology even though there is a distinction between a buffer and file in emacs (a buffer doesn't always refer to an existing file) and since most of the terminology is historical, it would be jarring to change it for the existing user base. Deprecating emacs lisp would pretty much mean creating a whole new editor at this point. There isn't enough interest in emacs changing its core scripting language to warrant it. There are a few active projects that are interesting like Lem with commonlisp and emacs-ng which pretty much adds a JS runtime to emacs but I'm doubtful they will one day reach emacs' user base in size. Aside from these, most other attempts at this kind of thing has died out. Getting rid of the terminal interface isn't a solution. I still come across quite a few user who use terminal emacs and I was one of them not that long ago (I still use it on my phone). What would be nice would be to decouple the UI layer like Neovim did and allow developpers to create their own frontend. I'd argue that the reason people go for VS Code is not only because it sticks to the standards you'd expect as a windows user but also because it is backed by a huge corporation that has a wide recognition even to the general public and that has the means to promote and develop the editor constantly as it has a dedicated team of paid developpers. That said, there is also a steady increase in developpers moving from VS Code to Neovim so again, I don't think a standardized user interface is necessarily what's gonna make a dev stick to a tool but the power it provides them to achieve their tasks as efficiently as possible. That's why people use Code, Vim, Emacs, IntelliJ, whatever. They all have that power and it's their different strengths which cater to different types of individuals that make one chose to stick with one or the other. Different tools for different needs.

I made okayish use of the menubar when I was using VSCode. It was the first place I went to when I needed something... until I found C-`, or whatever that key is, which was a lot more convenient since it allowed to search for the options like completing-read.

Dark themes are for desktops, light themes are for laptops

Exactly this. Emacs is just fine not taking on all the extra users; there's no need to change the original vision that has worked for 40 years. If the user isn't willing to get some help in one way or another, they're not going to enjoy Emacs for what it is, really, so no need to try and convince them to stay.

> replace Emacs Lisp with Scheme/Common Lisp/JavaScript I, for one, specifically want JavaScript nowhere near Emacs.

Abacus users would be miffed if abaci designs added more noob-friendly features. Also impeding noob adoption: the only features fun to work on are features we core developers would actually use (I consider myself a core developer). Like abacus experts, emacs experts continue to leave the mousers in the dust. But we all know what became of abacus experts.

> That includes not just cua-mode, but using standard terminology (e.g., "open file" instead of "buffer", "cut" and "paste" instead of "kill" and "yank", etc.) Have fun doing that. It has the same problem as internationalising Emacs: too much work. Another annoyance with coexistence of multiple terms is when you have to find an option/variable/function/command. Using three different words for the mouse cursor (mouse, cursor, pointer) certainly did not help me find make-pointer-invisible easily. >(basically everything except Gtk4, Cocoa, and Win32) Think about what you wish for, especially Gtk4. The pgtk port already shows how much a pure UI toolkit can annoy Emacs users. Most of us demand absolute control over Emacs and Gtk doesn't seem to like that. And please for the love of god, don't remove the terminal UI. Once you're used to Emacs, it is very annoying to use any other editor in the terminal. Mg is bearable for simple edits.

I think you're absolutely right and I have problems with a lot of decisions of the emacs maintainers(it often seems to me that they are not open for discussions). But that's how they want emacs to be. They are doing a really great job and invest a lot of time. It's very hard to find people who are willing to do the work. I don't want to blame anybody(we all have responsibilities) but we also have serious issues with a lack of package maintainers and contributors in general and it seems to me it's getting worse. Many of the maintainers of old packages are now inactive and I don't see many new ones. Although I agree with you, I'm glad that they are doing what they do. Maybe they are also afraid that if they make emacs more user friendly, there will be more users who want something without giving something back ;)

I disagree. Light themes are for educated people who knows how eyes works, people who care about themselves. Dark themes are for wannabes, people who think they _are_ but has no proof. Either that or OLED laptop users.

> (c) maybe even display videos. https://lars.ingebrigtsen.no/2021/11/09/finally-videos-in-eww/ >Of course, right click context menus already exist and already contain useful items. They're just not keyboard friendly enough. Checkout https://www.emacswiki.org/emacs/LaCarte.

I strongly believe that the emacs contribution process is at least partly to blame for maintaining the fairly small group of contributors we have as static. The GNU rights attribution process and the no-longer common patch submission process together make for a large barrier to entry. I know I’ll be downvoted to oblivion for this, but refusing to adapt to current common practices is probably why we don’t see far more contribution; especially when the rhetoric is “this is how we do it and if you don’t like it you’re not fit to be one of us”. Also, reading the mailing list can be really disheartening. There is a tendency to abruptly dismiss submissions and stifle conversation—which a few high ranking people really buy into.

> to create something that feels a bit more out-of-the-box like Sublime Text or VSCode The problem is that this is an insane amount of work, and for what exactly? I doubt that people who can and are willing to put in the effort will actually use VSCode-Emacs. I'm far from a luddite, I'm very much pro-mouse, pro-GUI and all that, but Emacs and its packages just don't really work in a GUI-centric paradigm. You can't even move the screen without the point moving alongside it. Customization menu is a hacky mess that works, but from a UX perspective it's dreadful (or rather, just barely good enough). And even then, suppose someone did all that work. The pros of something like VSCode is that it both works out of the box with tons of features, and that it's very easy to customize. Emacs is not easy to customize. You don't edit a simple static JSON file. On the other hand, it's not like there's no room for improvement. Emacs has some pretty insane default out of the box, and the experience is delightfully 80s. I think a minimal distro with carefully curated settings might be a good idea to get the attention of "power users" who might just've been a bit too intimidated to delve into Emacs otherwise. The two really popular distros are Spacemacs and Doom, and neither is minimal, to put it mildly. Which means that on one hand you're either biting the bullet and configuring Emacs from scratch, or you'll be learning how to deal with Spacemacs and Doom, which isn't that great of a choice either.

> how do we continue to see Emacs grow and increase adoption? Does it matter? Judging by the number of new packages in the various ELPAs, Emacs *is* healthy and growing. It’s certainly not going away, so anyone who wants to use it can enjoy it for a long time. There’s plenty of room for improvement, of course, but pursuit of popularity for its own sake makes no sense to me.

People like Bill Joy’s pet keys from 1976 just fine. Or at least the lack of CUA doesn’t seem to hurt vi(m).

As someone who abandons and comes back to emacs on a semi-regular basis, I think the themes thing is semi-legit. Default colours in emacs could be easily tweaked to be more easy on the eyes: light grey instead of white, a bit more desaturated in general, etc. As for the rest I could care less. Maybe, if the vast majority of users are deactivating menu bars and such, id say to at least make that more easy and discoverable (although, Google exists so...). Maybe an effort on creating config tutorials would help newcomers... And I agree that NANOemacs is an extremely pleasant vanilla-esque config. But, should it be the default...? Anyway is emacs multithreaded yet? And I remember tramp hanging on python files for me for a few seconds every minute or so (although that was probably anaconda-mode), I don't know if that keeps being a problem because I don't have to edit files over ssh currently, but a couple years ago made me kinda disillusioned.

Well, I've eliminated all the rights attribution and patch submission arcana in Commercial Emacs, which mind you, does not lack for the latest GNU commits. But it's clear the lookie-loo's who claim "I'd contribute if GNU dropped their antiquated protocols" revel in the fly-by complaint (as do I), and generally lack the C proficiency and the interest to make meaningful contributions.

I'll be honest, I find your conclusion really funny coming from someone who's created and is responsible for a pretty popular Emacs distribution that does a fair bit to "modernize" Emacs.

I replied to your statement that there's nothing wrong with Info, and that the problem is just that *you can't remember how to use it*. `C-h m` in Info is a simple solution for that problem, I think -- it tells you how to use Info, in a simple, succinct way. It's at least a pretty good summary reminder. ---- I left open the possibility that you can't remember even `C-h m` -- I asked about that. And if you can't remember `C-h m`, can you perhaps remember just `C-h`? or `<f1>`? Or can you think of looking in the **Help** menu (under **Describe**)? If the answer is yes to any of those then, in Info, you can get to the helpful reminder that `C-h m` provides for how to use it. ---- But now, after saying that it's just that *you* can't remember etc., you seem to turn the table and say that you really meant that it's just that newbies -- not *you* -- can't easily know about or remember `C-h m`. Yes, that's a different problem from your knowing about Info and agreeing that it's good, but just not remembering how to use it. Leading newbies to the tutorial and to the `Info` manual can help. Maybe Emacs could do a better job of that, particularly the latter (the splash screen has a link to the tutorial). ---- You speak of newbie *"confusion because you need a tutorial for the documentation"*. I don't really agree that folks *need* the `Info` manual, to use Info. But it certainly helps, to make better use of it.

> The newbies expect a gentler introduction, install the app and it’s comfy from the word go. Why should there have to be a word "Go"? That's far too much trouble and confusing for newbies, no? Surely we can find something comfier and gentler than foisting that on them. And *installing*? Surely that's an immediate turnoff. Preinstalling Emacs -- I'm thinking maybe some creative use of CRISPR to implant it genetically -- should be on the front burner of any modernization campaign worth its salt. ;-)

Reply to https://old.reddit.com/r/emacs/comments/v2fjcd/who_needs_modern_emacs/iaslypt/ , since it looks like he's blocked me: Those are very vague goals that you've stated. What exactly should be changed? What do you like about the other editors? Why should emacs change radically when it has been working just fine all these years? > how do we continue to see Emacs grow and increase adoption? It's an open-source project, not a company or a product. Its main goal is to maintain the software as it is, all improvements and fixes stem from this. If the majority of contributors are veteran users, then a "veteran" editor it will stay (although it can do much more than any other editor). > there are a lot of naysayers bla bla How about the haters lay down a list of the things that they want, and then begin trying to suss out ways to implement them? The devs aren't lazy. The contributors aren't blind. Many of these things are MAJOR restructuring projects that go against what established users are used to. The once-and-done users can be the goal for corporate-backed projects like vscode that are building upon a decade of failed JS editors. A novel project like Emacs can't afford to be hasty. It can't afford to think short-term. Catering to transitory users is short-term.

It's all about equal lighting. Bright desktop 144hz has washed out blacks and is super bright, so I use a dark theme there, as it's also a similar darkness in the room. On my laptop I'm outside in the sun, so I crank the brightness up and choose a high contrast light theme.

> One click is one click too many. Hm, a bit dogmatic? Why does this remind me of McCarthy's "[One Communist Too Many](https://www.footagefile.com/stock-video/senator-joseph-mccarthy-one-communist-too-many-speech-at-the-republican-national-convention-usa-1952-2432.html)" speech...? ;-)

I am what we call a "power user" but since I never contributed a single line of code to emacs I will try to avoid judging what kind of work the emacs developer should do to make happy another set of people. i just can wish emacs beginners would start with elisp instead of just the trying to adapt other workflow, after learning elisp the customization to their taste is limitless....

> ship by default “cool” themes like Solarized (it seems it’s very important to have some dark mode these days) I don't care if the default theme is "cool", and I don't think you need dozens of themes available out-of-the-box if there's an easy way to install and add them, but let's be honest here: *Jesus Christ* the default Emacs theme is awful and needs an overhaul. Even if people go right for themes and install new ones, first impressions would improve just by having emacs not be an aesthetic abomination on first launch. > make the modeline “sexy” (think Spacemacs) Same as above. It doesn't need to be "sexy" but it can be made to look less shit than it does now. Why do we keep bringing up this insinuated false dichotomy of "if you don't like this butt-ugly decades-old default, you just want sexy new modern things like a *noob*"? > show line numbers in the gutter (or its general vicinity) by default > use the keybindings that are common in most “modern” editors (think cua-mode) > display open buffers as tabs, so people can always see them and click through them (think tab-bar-mode and centaur-tabs) Some programs, both text editors and otherwise, ask questions on first launch to tailor things like this to the user. Blender for example gives options to emulate other popular 3d tools, zsh has a first-launch configuration function, etc. A lot of program behaviour like this would make a lot more sense with that kind of setup. Suggest people put the effort into learning the emacs way for compatibility purposes, but offer an "easy mode" option for newcomers and provide a simple way to disable those features again as the user transitions from neophyte to intermediate or advanced user. Imagine having emacs launch and give a choice to enable evil mode for vim users instead of demanding they abandon their heathen modal ways. We might actually convert some of them to our side, or at least promote peace between the nations, instead of perpetuating endless warring between the emacs carpal tunnel tribes and the modal monks. > have a fancy configuration wizard to help with the initial setup of Emacs You don't need fancy, just let somebody pick if they want baby mode or not. You don't need your dialog to have 50 knobs in it just because 50 knobs worked on it. --- Look, I like emacs a lot, but it took a lot of work to get it there because out-of-the-box it *fucking sucks*, and refusing to improve that because you can customise it to your taste is just idiotic. Just because I invested countless hours into making it suck less doesn't mean we should continue to require new users to do that same thing. Good defaults are important in software because *the people using the defaults don't know how to change them yet*. Nobody's asking for emacs to lose features or neuter its extensibility, so better defaults don't hurt anybody. Deliberately keeping the defaults obtuse is just "I had to do the work so you should too" gatekeeping elitist bullshit that needs to fuck off. It's an excuse to keep people out and pat yourself on the back for the effort.

I believe that I'm in that group of Doom-user newcomers you've mentioned: I'm fond of vim bindings, but I'm past the point where I like to spend days learning elisp and configuring stuff from scratch. Currently it's the opposite for me: give me some nice defaults which are more or less easily extensible and then I get slowly more and more fascinated (magit! dired! org!) and at some point I start diving deeper in elisp and doing my own stuff. So I guess it's also a question of how configuration-enthusiastic a person currently is.

Yes, I offered my own example as a veteran where I see shortcomings year after year in that I have to overcome a barrier to entry that I already know the answers to. It is not relevant that this is about me, someone who knows what arcane key combinations can take me to the help pages. What is relevant is that everyone has to do this at first blush. If you still don’t get it after this final clarification, okay, suit yourself. I don’t need your help. Stop pointing your stick at me.

I do feel pretty cool when using emacs, thanks.

I used to think this way, but as I've gotten older light themes have started to hurt my eyes.

Calling emacs "building material" for tinkerers and DIY-minded users is I think at odds with the reality that emacs ships with a lot of packages preinstalled, and features built-in, and a lot of bells and whistles enabled. It's bloated as hell, though not necessarily in a bad way.

You recognize this in the post, but modern to me means novel. You can do novel things in emacs and I wish more discussion on modernity focused on that - instead of topics like defaults that, frankly, have been discussed to death already and are just plain uninteresting.

why you wrote this? did you just want some clicks? pretty much doesn't add anything, which i find kinda disappoint given your background. so i'll just link useful stuff instead - https://www.emacswiki.org/emacs/WhyDoesElispSuck - https://irreal.org/blog/?p=675 - https://www.emacswiki.org/emacs/EmacsLispLimitations - https://www.emacswiki.org/emacs/GuileEmacs - https://www.reddit.com/r/programming/comments/74p8v/why_elisp_sucks/ - http://dev.anagora.org/elisp-sucks - http://xahlee.info/emacs/misc/elisp_sucks_donkey_ass.html - https://www.reddit.com/r/emacs/comments/azc1u2/xah_talk_show_20190308_why_emacs_lisp_sucks_one/ - https://www.youtube.com/watch?v=KYcY7CcS7nc - https://old.reddit.com/r/emacs/comments/k2sceq/opinion_rms_does_not_see_the_future_of_emacs

Searching on Google I found this https://github.com/commercial-emacs/commercial-emacs I wasn't aware of such project.

I'm with you. Until a year or two ago, I just knew of emacs as an obscure development environment with difficult keybindings. Just within the last year or so I started to come across youtube videos and discussions on r/linux and other subs gushing about it's configurability and demonstrating its strengths. I finally dove in a couple weeks back with EXWM on a GUIX installation and I'm loving it so far, and only expect it to get better. I think it's a toolkit for tinkerers, more than an environment for users.

Here's a sneak peek of /r/linux using the [top posts](https://np.reddit.com/r/linux/top/?sort=top&t=year) of the year! \#1: [Firefox lost 50M users since 2019. Why are users switching to Chrome and clones? Is this because when you visit Google and MS properties from FF, they promote their browsers via ads?](https://data.firefox.com/dashboard/user-activity) | [2100 comments](https://np.reddit.com/r/linux/comments/ov8jsf/firefox_lost_50m_users_since_2019_why_are_users/) \#2: [Happy 30th Birthday Linux!!!](https://i.redd.it/g26too4bwbj71.jpg) | [245 comments](https://np.reddit.com/r/linux/comments/paq6ed/happy_30th_birthday_linux/) \#3: [30 years ago....on this day.....this is how Linux started. Rest is history! Happy bday #linux](https://i.redd.it/inso5hwqvij71.png) | [268 comments](https://np.reddit.com/r/linux/comments/pbdkh1/30_years_agoon_this_daythis_is_how_linux_started/) ---- ^^I'm ^^a ^^bot, ^^beep ^^boop ^^| ^^Downvote ^^to ^^remove ^^| ^^[Contact](https://www.reddit.com/message/compose/?to=sneakpeekbot) ^^| ^^[Info](https://np.reddit.com/r/sneakpeekbot/) ^^| ^^[Opt-out](https://np.reddit.com/r/sneakpeekbot/comments/o8wk1r/blacklist_ix/) ^^| ^^[GitHub](https://github.com/ghnr/sneakpeekbot)

> modern to me means novel. To you, perhaps. But: * https://www.merriam-webster.com/dictionary/modern * https://www.dictionary.com/browse/modern * https://www.wordwebonline.com/search.pl?w=modern

This.

Ok, do it. Show me the code and how to it works with the users (or die the first day).

Whoa, I'll have to try this out. I'm guessing some simplifications were made which might break compatibility in a way upstream doesn't approve of?

> Customization menu is a hacky mess that works, but from a UX perspective it's dreadful (or rather, just barely good enough). Can you expand on this? It's not that I disagree, but rather I think I've just used the customization menu enough that I'm blind to all but it's most obvious shortcomings. For instance, with a vscode style retheme if customization I'd struggle to tell the two apart.

It's a half baked attempt at a GUI interface that ends up crappy at both text mode interaction and at GUI interaction. Obviously, it works, it's functional, does the job, but the bar is set really low. The internal structure is pretty stupid too. Subgroups are at the end of the buffer. The most obvious group - packages, doesn't exist, it's basically under convenience for whatever reason. Plus it uses its own function and its own way of adding customization (custom-set-variables), I really don't understand why the devs went in favor of this approach as opposed to adding normal code (setq, set-face, etc). It also just craps those variables at the end of the init without any sorting. So if you have a bunch of customization, good luck untangling them. So on one hand - yes, it can be more convenient, especially for certain things like faces, but it's quirky as hell, and unless you're happy for all of this code to be buried in the custom-set-variables, you'll have to manually move it to your config files, which is a pain.

The only thing I would like fixed is Emacs being stuck while waiting for some task to finish. That would make EXWM a viable graphical environment for me. That is the only thing that would make me even happier as a user. Everything else is frills. The theming can be done by the community easily and we have projects like DOOM Emacs and Spacemacs. The users, who are not interested in an environment that allows them to shape their own experience, would be better off with whatever editor or IDE is 'modern' and cool at the moment. By its own nature Emacs requires a long term commitment. But the reward is endless, bounded only by the creativity of the user.

Did you really just post some dictionary links to me? This is a bad faith comment and I don't appreciate it. You don't see a parallel between "characteristic of present and recent time; contemporary; not antiquated or obsolete:" and novel?

Right, I am as well new to Emacs and just started my own config coming from Doom Emacs, but a lot of that process it's understanding how Doom uses and configures the packages that it uses and learning Elisp while doing so. I'm like 3 days into it, and I feel it's endless. But hell, I remember the same years ago when I started learning vim, you have to have a specific personality to want to waste so much time in configurations. haha

> It would still be really nice if there is a standard way to define context menus that are as keyboard friendly as M-x I developed Embark to fill this need. It's on GNU ELPA. The context menus are specified as plain keymaps.

No, it wasn't a bad faith comment. Tried to help. Sorry you didn't appreciate it. Suffice it to say I disagree that *"modern means novel"*. And the difference is relevant in these unremitting, misguided discussions about "modernizing Emacs". "Modern" is a particularly weaselly weasel word. And time hasn't been kind to it -- it's washed up and has little meaning by now. As old as the hills; as rehashed, flimsy, and phony as a soap commercial (BUT LOOK! NEW! IMPROVED!). Few words reek *less* novelty than "modern". What's merely more recent is of course newer in one sense (and OK, "novel" is derived from "nouvelle", new). But recentness doesn't imply innovation, which is what "novel" strongly and typically suggests. I thought you really did mean novel as in inventive, based on your plea for focusing on *"novel things in Emacs"*. And I happen to agree with that plea. By all means, let's focus on innovation and invention -- and not on trying to be or seem "modern". If for some reason by "novel" you really did mean only new vs old -- passage of time without inherent originality or invention ... then OK, call "modern" novel in that sense. But novelty's really more than that. I'll skip pointing to definitions of "novel". I expect you do agree about what it means, even if you don't agree that what's modern isn't necessarily particularly novel. *"Characteristic of present and recent time"* doesn't spell improvement. That's an old lesson that gets relearned over and over -- wash, rinse, repeat.

I'm not a programmer/coder, but I do enjoy tinkering. Doom is already 'modern' enough for me, in that I can tailor it to my needs without the learning curve constantly tripping me up.

This rant on the word modern is misplaced. And yes I do mean inventive - emacs encourages users to act on their imagination. I've always considered that special.

It *is* special. It's not modern. Emacs does that now, and it always has. I suspect we may in fact violently agree, except perhaps about the prescription that what Emacs needs is modernizing.

That Emacs still insists on "meta", "super" and "hyper" is a very bonkers. Such keyboards don't exist in quantities for 30+ years. It's almost like this non-innovative countries that after 100 years still didn't change to metric units.

I use Emacs not because of Lisp, but despite it. But I don't enjoy writing in it. It's a clusterfuck of an untangled mess. But having seen Vimscript I know that inferiour alternatives exist :-)

Neovim can now use Lua by default, instead of VimL. But my point it's not about comparing, really, it's about the oldish allure of Emacs. I don't think anything will change till there won't be a NEmacs fork. Vim started to improve only after the Neovim fork

> It also just craps those variables at the end of the init without any sorting. So if you have a bunch of customization, good luck untangling them. Is there a good GUI that also outputs acceptably sorted and structured data you know of?

No one is going to take that from you. Gatekeeping Emacs with ancient and artificial issues just to feel superior to people who are put off by them is stupid. Luckily things already improved a lot in the past years, and even people like you are reaping the benefits of the influx of new people and packages. I really hate the elitism that permeates coding. You're not special because you've been using Emacs for 25 years with your custom plumber nightmares config, you wasted countless hours fighting to make it and you don't want other people to have it easier than you.

Yes, Emacs is cool. You? I don't know, you sound pretty insecure since I wasn't even replying to you.

Emacs is very much a - If you aren't willing to work with me, you don't deserve to use me - kind If program. Emacs will never be mainstream, not even among developers

"!!!" Automatic disqualification, thank you for playing. "brought fourth a ton of new users". I see this claim often, but I haven't seen proof (because you can't, there are no statistics about Emacs users)

> It's a clusterfuck of an untangled mess. Lispy clusterfuck is still simpler and more powerful, than non-lispy one

> Emacs's keybindings are often criticized (and are definitely inferior to vim's) I wouldn't say that, Emacs bindings, while not being perfect, follow a great idea that mnemonics matters more, than anything else. Speaking of effectiveness, for a generic software engineer, I don't think productivity differs that much. But at the same time, vi-likes add more mental overhead because of permanent modes.

Kinda like insisting on calling it a "buffer" and not a "file" - what you say is absolutely and completely technically true, but completely misses the point. There are plenty of other proxy indicators that point toward this growth. The growth of subscribers of this subreddit being one (https://subredditstats.com/r/emacs), homebrew download stats, GitHub stars, growth in emacs.stackexchange.com, increase in YouTube and blog content, and numerous other stats if one cared to pull it all together. While most indicators could be said to point to interest rather than actual usage, and it's tough to point to any one cause for all the growth - claiming the growth in these areas doesn't logically lead to a corresponding growth in users would be a massive statistical anomaly that would require quite the proof.

> Kinda like insisting on calling it a "buffer" and not a "file" - what you say is absolutely and completely technically true, but completely misses the point. If you replaced buffer with file everywhere, what would you call the dired buffer or other buffers with no file location?

You can use circadian.el, set up your location and it will automatically change the theme.

Damn, I was skimming through the comments, and even before my mind could fully comprehend yours, I was like: "what the heck is Abacus? (in relation to Emacs)"; googled it, and of course, abacus-mode is a thing :)

Buffer is the most accurate term of course, but for pretty much every other text editing software package from Word to Sublime to VSCode to Google Docs - you'll rarely if ever see the word "buffer". It's just not widely understood. You could probably get away with referring to many of these types of things as an "unsaved file" or "message/output". Not saying Emacs should - just that combined with sticking to alternative meanings for terms like frame, window, tab, etc. for correctness sake is one big reason Emacs continues to feel more antiquated than it actually is.

I feel like this gets at something deeper which is that buffer isn't a precise term whose only use is being more technically correct but a precise term that guides the user to a place of deeper understanding where they can have more control over extending their software. It makes me wonder if throwing away the term buffer would be too great of a cost, does that make sense? I'm fine with doing away with antiquated terms or using more colloquial ones, but I'm wary of losing precision.

Fair points. Doing away with "buffer" wasn't the original point of this particular thread anyway - just used an example of favoring correctness at the expense of everything else.

Yeah but my point is, I doubt changing that one command to default would significantly change adoption rates. Because sure now you can copy paste but all the other commands are lurking in the shadows. In a sense by having it not as the norm it serves as a bit of a litmus test that if you're gonna not be interested due to that, you're likely gonna have a bad time in general. That's just my own bad take however. I bounced off of modal editing of vim in the way that many bounce off of emacs navigation or general use of ctrl.

My comment was not to be taken very seriously Although I do see many people blasting themselves with light when using dark themes thinking it's fine.

If dark themes was a thing when you were young you're not very old:)

Oh, the video example looks really nice. I really need to learn how to install xwidget support on Arch Linux… The scrolling is unfortunately still hardly usable though. I've tried LaCarte and found myself never using it despite having bound it to SPC SPC at the time. LaCarte makes the menu bar keyvoard-navigable, but when M-x is already a thing I find myself never getting to know the menu bar in the first place.

I already use Embark; thank you for developing it :) I don't think it's common for packages to use Embark to define their own menus though. Embark is the best way to define context menus *for the user*, but the primary way menus are defined seems to still be completing-read, which requires a bit of boilerplate to be used for this purpose.

You're right, of course, but I'd emphasize that packages don't need to _use_ Embark for it to be convenient for a user to get a context menu of operations provided by a given package! The key to this is that quite often packages define a keymap with several of their operations and as an Embark user you can just define a target finder and register that same keymap with Embark to use for actions.

In gnus, I use LaCarte a lot because I find it a lot easier to complete against English than symbol name. The same goes for unfamiliar modes.

Who cares if it will "never be mainstream?" It was never meant to be anyway. I have tweaked and configured Emacs over the years to fit my needs precisely. I use it for development in the many computer languages I know, and I also rely heavily on OrgMode and Org Agenda. I have even integrated OrgMode and LaTeX so that I can produce beautiful documentation with charts and equations, spitting them out to pdf. Name me one other IDE I can do all of that with. Emacs is in its own elite class. If you have run-of-the-mill needs, sure you can pick and chose among the many offerings out there -- Eclipse, VSCode, etc. But when you want to go beyond the mundane, Emacs is there.

I would very much like to see Elisp become multi-threaded. But that would require a major rewrite, so it will probably never happen. Maybe if it is possible for some transpiler to process the elisp and make it concurrent, it may be possible. But even that would take a lot of effort.

Idk why you are going off. Maybe read my comment and realise I said the same thing just in fewer words.

Except that Xorg and most of the kbd software still uses those terms, its windows that ditched them, and we sure as hell dont need to follow m$ examples

Well, it's also the Linux kernel that ditched them (e.g. at the input level subsystem you don't find "meta"). So really, operatings systems don't have this outdated cruft anymore for ... 30 years?

What does linix use for those?