Can't learn emacs, can't use anything else (rant)

This is a rant and a maybe cry for help, I hope you don't take it the wrong way. Basically: I've been using emacs for 10 years, and still can't find my way around it. I've read "Mastering emacs" a couple of times plus a bunch of tutorials, but everything I learn I end up forgetting because there is so much and it is so complex. The usual advice, in this case, is: just learn what you need and use. That works elsewhere, but not with emacs. You see, the whole system is so complex, and everything so interrelated, that I feel that if I don't know everything about it, the things I do use will alway act differently from what I expect. To understand why I would have to know how plugins are loaded, how text is processed, all the subtleties of the undo ring and so on. Just today I was sorting an org file, and at the end of the process the items were less than at the start. I kept undoing until it didn't change anymore and counted the items again. They were still less than what I started with. I have no idea how that happened, and that's just a normal emacs session for me. Or maybe I have a problem looking for how something is done. Something that may sound very simple, and I feel it should be done with just a click of the mouse, like "How do I change font size?" (just an exaggerated example). I find the question on stackexchange, and EVERY SINGLE TIME the answers go something like this: \- "In emacs this is called varying the letter bigness, and it doesn't work the way you think" \- "I've written a script that does exactly this. Just put these lines in your init file, and these other lines at the start of every file you edit. Unfortunately, size can't be increased to more than 14 and it conflicts with org mode" \- "Why are you even trying to change font size? Emacs doesn't do that and for a good reason. This is a XY problem" I don't even know how to describe this problem. It seems that super simple things that are taken for granted by everyone, for some reason can't be done simply in emacs, but require messing with the configuration, installing plugins, writing elisp and using workarounds. Also, they keep telling me that emacs is powerful and efficient, but sometimes I have big files that simply slow emacs to an halt, while they open without a problem in any other editor, even the heavy, bloated ones. At this point you are probably wondering why I don't just do everyone a favor and switch to another editor more my speed. The problem is, there seem to be no editor like emacs, and what I want is emacs.... at least emacs on paper. I just need to understand why I can't get real emacs to act like emacs on paper.

Might I pitch [emacs-groundup](https://gitlab.com/public-repositories/emacs-groundup) :D

This config uses straight.el over package.el so I would argue it is not suitable for novices or OP. We should encourage beginners to rely on the built-in functionality until they are comfortable using Emacs.

I was in a similar place ten or fifteen years ago.. I did not want to use emacs, I wanted to be as proficient as the people I knew who were using emacs for decades. Drop that idea, treat it like a text editor for a while, maybe just get used to using emacs client, but stop doing huge things with it for a while, learn to move around text easily and to search and replace... Then maybe edit a file or two with tramp's sudo or a remote file.. Start building from the basics and expand.. don't start from what you'd like to have as a final state and work yourself down to how it works.. Every time you hit something in BASIC usage that doesn't suit you, find out if you can reconfigure that in vanilla emacs or, if it's not possible, find ONE package that deals with that problem.. Over time, you'll grow more comfortable and tackle bigger things.

>the answers go something like this This amused me. :-) A few fairly high-level comments: * Yeah, the fact that GNU Emacs has been around since 1985 - the first Apple Macintosh came out in 1984 - means that it has a *lot* of baggage. (And there's at least one person on this sub who was using *an* Emacs before *GNU* Emacs existed.) Various (actual or de facto) standards didn't exist, or were still forming. The Common User Access (CUA) standard was first published in 1987. Windowing systems were by no means commonplace. (My first computer, an Amstrad PC1512 which i got at the end of 1987, had the GEM desktop, but i didn't have a machine with Win until around 1992. And in fact, the PC1512 didn't just come with GEM, it came with both MS-DOS 3.2 and *CP/M*, because CP/M's install base hadn't yet faded into insignificance.) GNU Emacs is software that has run / currently runs on a *wide* variety of platforms, so it's had to / has to support a *lot* of diversity, with all the resulting fun complexity that can entail. * Sometimes the issue might be that Emacs is handling use-cases that other editors don't. Emacs isn't only used for coding; many of us use it for natural-language stuff as well, and most of the world has a language other than English (and a script other than Latin) as its primary language. The first Unicode standard was published in 1991. UTF-8 wasn't as widespread an encoding as it is now; Microsoft bet on UTF-16. Given this, over time Emacs has developed a very sophisticated system of cross-platform stuff to try to handle these things (e.g. various input methods, rendering bidirectional text). * i don't have the sort of "normal Emacs session" you have, but i'm not sure why that is, sorry. It's certainly true that occasionally Emacs does behave in ways that make me go "wait, what?", but it's often the case i'm able to look into it and then understand what's happening. (One instance of that *not* happening is that when i'm doing package updates, Emacs constantly steals the focus as it output logs, such that i can't do anything else. This is with i3 on multiple Linux distros. i haven't been able to determine what it is in my config that causes this.)

There are a few things I think you should consider: First, take the advice everyone is giving you. You've tried learning everything all together for a while now and it's not working. So don't keep doing that. Learn one thing at a time, as you need it and accept that you'll have incomplete knowledge about certain things. That's ok. It's inevitable. Very few people have a deep understanding of the every component of emacs. And you don't need it to be a very effective emacs user or to write quite sophisticated personal packages. Secondly, how's your elisp? Can you write a function? Can you write a minor mode? Can you write a package? If you've been trying to learn emacs and it's just not landing, I'd suggest instead switching to try to learn elisp. Things will make a ton more sense. And, once you learn elisp to a reasonable degree, you can get a lot done even without understanding emacs itself. Write code to do what you want done. It doesn't really matter how emacs works: just if your code works. Last, you have to make your learning stick. Reading a book isn't going to help you unless you immediately apply what you read about, and then experiment with it. Not just copy what you read but try to extend it. Test your understanding. So don't read, don't study. Do stuff. Write a package or a mode and work on it regularly. Keep notes about what you learn. A learning journal is *incredibly* useful. You can even use emacs for this (for example, org-roam). When you write down your own thoughts about what you learn, it's more likely to stick with you. It will also force you to discover if you actually understand something. And you'll have it there as a resource for reference later. Seriously, for *any* hard thing you try to learn, keep a learning journal. Hell, turn it into a blog and become an influencer! Perhaps consider setting up your config as a literate config. Doing this was the single biggest thing that exploded the depth and quality of my understanding. I no longer have the experience of looking at some arcane thing in my config and thinking "what the hell is this here for?" because everything has a write up. Even if it's just "I don't really understand why I need this, but I copied it from <this line>." Now you have a reference point. You're not starting from scratch every time. But more than that, you may find like I did that writing up the reasons you've done something gives you better ideas about what you could be doing. Whenever I find and fix some weird thing in my config, I add a description of what I've done to a "troubleshooting" section at the end. That thing has saved my ass several times. No more frustration of knowing that I've dealt with this before, but having no memory of how. I've for some reason recently set my config to private on github (probably leaked some passwords or something) but if you'd like, DM me with your GH username and I'll give you access to it so you can see how the documentation in my literate config makes my life much much easier.

I don't think I agree. Straight provides so much organizational usefulness. The chaos in a beginner's config is one of the biggest challenges for getting a stable, working setup. I can't count the number of times problems in my config were due to things like changing the same variable in many places that I wasn't able to keep track of. Keeping everything related to a package contained in a single use-package sexp is a huge simplification and structural advantage.

I may have given advice that's more tailored to a different time in your journey. It might help if you can share a bit about what you currently use emacs for and what things you are comfortable with. Are the navigation keybindings second nature to you? Do you know how to set variables? Do you understand modes, windows, buffers, and frames? Do you know how to access and use the help features?

i have mixed feelings about this. Yes, i certainly think it's good to encourage people to learn about Emacs' extensive built-in functionality, and in particular about "learning how to learn Emacs" (e.g. the Emacs manual being available from within Emacs via `C-h r`, being able to search for documentation on something via `C-h d`, using `C-h ?` for a description of the various help options available). On the other hand, it can be a very frustrating experience to have to learn so many new things at once, when one is trying to get to a minimal level of functionality for one's use-case. This is why distros like Doom and Spacemacs, and starter kits, and things like an [Emacs configuration generator](https://emacs.amodernist.com/) are so important: at the very least, they show what Emacs *can* be like with a relative minimum of fuss.

Those imaginary stackexchange answers are spot-on, haha. I like what others are saying, and I'll add one thing from my personal experience. As I was learning, I ran into issues like the examples you're describing. I unconsciously added them to my mental list of annoyances and let my frustration build up over time. When I finally tried to take on these problems one-by-one, I realized there were a lot less than I'd been imagining. Maybe you'll find a similar thing. When I encounter something annoying now, I either try to find a solution I'm completely satisfied with right away, or I use it as an indicator that I should change my expectations. Either way, I try to move on from the issue before I let it become a sort of pet problem in the back of my mind. I'm not saying that the problems aren't indicative of deeper issues with Emacs, but Emacs really is quite a weird program. Certainly not ideal. Only other thing I could think to say is that if you run into something particularly unexpected, maybe try to talk to the mailing list about it. You might have to use a hacky solution for a little while, but you'll save others like you some trouble if you get the issue addressed upstream.

What do you want to do with Emacs? In my case, I had the same frustration at first, and the solution was to really understand what Emacs is (and isn't) and how it works at a conceptual level. To follow your exaggerated example… wanting to change the font size with the “MS Word mentality” is not going to work, because they are two different things. It would never occur to anyone using VS Code and editing an HTML document to select just a random word and look for a button to change its font, And no one finds it strange that it doesn't work like that, because… That's not how it works.

And replying to myself here: After a while, get used to emacs' packing system.. it doesn't have to be use-package or straight.el right from the start, but use the system, don't just install packages at random... To this day, I hardly understand enough elisp to make sense of my .emacs file, but I can browse github repositories of packages and read the documentation well.. that's something that has REALLY improved over the past decades(and I used to use xemacs, just for the package manager for a while).. Back in the day, you used to get some random elisp file that you placed in a magic folder and wrote down the incantation in your .emacs.. Nowadays, many, many packages just come as an elpa/melpa package that you can easily find and install from `M-x package-list-packages` and the github pages(mostly linked from the package info in the package list) usually include some valuable clues how to configure the package to your liking.. It's even gotten so good that I (the elisp illiterate) prefer to write down my own configuration over using `M-x customize-group`.

I know the basics of everything you listed, altough only the parts that I use constantly (e.g. I remember how to split a window horizontally or vertically and how to switch from one to the other, but not much else regarding windows). While following a tutorial (for example, for setting up a REPL environment) I can usually understand the logic of everything. However, every time I must do a new installation or reset my configuration (for example, because something doesn't work anymore and it's not clear why) I must relearn and redo everything from the start. I never got into elisp, but I will now, following your advice. At least it's something new I can try. As for my use, it's my general editor. I do everything in it, except when I must use Word for job stuff (but I use emacs a lot at work too). Thus, you can understand my frustration at still not getting it. Mostly it's programming and organizing my ideas. For the latter I use org-mode, and it is another source of frustration. People write about how they put their whole life in org mode and make it look extremely powerful and flexible. I use it, and I start wondering whether I've downloaded the wrong 'org-mode', because it looks like an undocumented mess that can't do anything besides a couple basic operations. For example, I like mixing spreadsheets/tables with text, but according to discussions I've found online (the manual doesn't go into detail in a lot of things) I can't even fold lines in org tables, I must use another kind of table that must be edited in a separated window. Sorry, still in rant mode :)

I switched to neovim and tmux a while ago and it’s a lot simpler. I still use emacs to read my org files though and I do still love it but it definitely feels like vim/neovim has the stronger community. I install things and rarely even need to configure it and it all just works, but when I want to get into the tweaking it’s all there. This is where I think emacs lacks a bit. You have to config things a lot just to get them to work properly and I just got tired of the time commitment. Also go tired of emacs shitting itself on large json.

I have similar experiences with not understanding simple things, like I don't know why my package for a js repl applies its custom color scheme when the line containing its color toggle is *explicitly specified* '*off'* but not when it's set to '*filter',* but *now* I know after tinkering with it that setting it to filter does what I want. Why do I have a saved, named, and bound macro to enter the letters h-t-o-p, press enter and then rename the buffer \*HTOP\*? Because I don't know if this is even the correct *phrasing* for what I want to do, but because I don't know how to pass commands to vterm in comint-mode, yet! That could be absolute gibberish. I hope it's not gibberish. *But,* in the meantime, my solution *works*, and it doesn't interfere with anything else in the system and structure of emacs. I'm relatively new to emacs, and I'm positive my init file and load path, especially my own hand-written desktop library for my functions, commands and keybindings to arrange emacs, would make any of the veterans and technicians either cry or cringe. I think the starting perspective, "this system is so complex and interrerlated that I need to understand its moving parts before I feel comfortable changing anything," is a *challenging* one to bring to emacs. Emacs has been around and developed for so long I'm not confident there's *anyone* who actually "understands" *all* its moving parts anymore, or at the very least not anyone who can *keep* all of it in mind at the same time. I fall into this same thought pattern in lots of places where it's counter-productive all the time, too. I think, however, approaching emacs from the *start* as, "the extensible, hackable..." and getting *right* into the extending and hacking, even if it's imperfect, even if it's almost certain there's a "better", even if the "solution" that ultimately "works", is absolutely ludicrous and probably *shouldn't* work, is how you get to "emacs on paper", where sure, you are "running emacs", but in reality you're running this hand-crafted and tuned *personal software suite* under the heading of "emacs". Also, because I don't know where else to fit it in, knowing even just the *smallest* bit of lisp, goes a *long, long* way in this process.

Org mode is great, but the tables aren't a good replacement for spreadsheets, unfortunately. My journey into having org mode take over my life was through using org-capture. Prot has a nice video on org-capture that you might enjoy. As per the rest, yeah, you should definitely learn elisp. It will help you to avoid things like having to declare config bankruptcy and start all over from scratch. You're trying to understand how to interpret a novel that's written in a language you don't speak. And, if you document what you've done (either directly in your config or just in notes in org mode) then you don't have to re-learn everything from scratch. You can refer to your own notes. The first block of my config is all documentation about how to set up a new installation: what environment variables need to be set, what other apps need to be installed, how directories need to be organized, how to install emacs itself. I would never just remember all that stuff off the top of my head. So I write down the steps I perform as I take them and then, next time, I have a lot less to worry about.

>the tables aren't a good replacement for spreadsheets If I learn some basic elisp, do you think I could realistically add the features I need (for example, wrapping the text and moving a particular cell, row or column in ways that aren't supported at the moment), or would it be too difficult / too much work? >And, if you document what you've done (either directly in your config or just in notes in org mode) then you don't have to re-learn everything from scratch. Wow, you are giving me a lot of good ideas. Together with the learning journal thing this could be a game changer. I'm going to try org-roam and org-capture. Do you have any other advice for using emacs as a thinking/planning tool? I like mixing paragraphs of text, lists, tables, mind maps, code, and so on. Maybe there is another org-mode addon that capitalizes on these features?

[deleted]

I said what I said as a straight user myself. But I still contend someone starting out should start with package.el. Straight is great when you want to modify a third party package and perhaps even contribute your changes upstream. It greatly simplifies that process. Someone starting out with Emacs should be encouraged - to use default Emacs, - realise something could be improved in their workflow - look to see what Emacs offers to resolve the sore point - if Emacs doesn't offer anything (rare) or what it offers is insufficient for their particular use case then they should look to a third party package via package.el for a solution Package.el serves its purpose well for an Emacs beginner. It allows them to install/remove packages with minimal fuss. That is not necessarily the case with straight on account of installing the source git repository so things can break easily when you add the extra complication of using git which new users aren't always familiar with. >Straight provides so much organizational usefulness. It may do so in some respects but it is not necessary for one to have an organised config. >The chaos in a beginner's config is one of the biggest challenges for getting a stable, working setup. I don't think I can agree with this statement. Without configuring anything Emacs already provides a stable, working setup. Any chaos that ensues is usually down to the user's configuration or misconfiguration. >I can't count the number of times problems in my config were due to things like changing the same variable in many places that I wasn't able to keep track of. I'm not sure I understand why you would be changing the same variable in many places. Do you mean have its value differ in different modes? >Keeping everything related to a package contained in a single use-package sexp is a huge simplification and structural advantage. I didn't comment on the use of use-package (which I also use) because it is unrelated to the straight.el/package.el point I was trying to make. In any case, use-package integrates with both straight.el and package.el. But I agree with your point here.

Yes, I agree that such distros have this going for them. But would they serve OP? Their complaint is feeling like they need to understand how all the different elements of Emacs work together. If they start with such distros then I presume they will want to understand how the various parts work together which is another layer of complexity atop of Emacs itself.

I see that you started your reddit account to post this, so I can't gather any insight into your background. In another comment suggest you do some programming. The key here is to realize that you haven't downloaded an editor, you've inherited a code-base. The problems you described - not knowing how to do things, complexity underlying surface-level descriptions, forgetting what you've already learned and modified - this is par for the course. It's not just you, it's our way of life. I've only been using Emacs for about 1.5 years. However I'm writing this comment to you in Emacs with all it's power, automatically synced to my browser, because the editor has become so customized to my brain that I fumble using an HTML Textbox without bindings. I have custom functions and modes, my entire life is modeled in org-mode and org-roam. But I still have the same problems as you. The difference is, these hurdles are a part of the way I approach all of my programming work, editor included. Learn the basic tools for exploring the documentation, the code and the config. From then on, you have one problem and one approach. You'll do it hundreds of times and it becomes second nature. Much of these have been recommended elsewhere, but these are the tools I use daily: **Literate config** - build an indexed, documented, collapsible, org-mode powered config. [Start here](https://gitlab.com/dwt1/dotfiles/-/blob/2a687641af1fa4e31e080960e0b6a5f3d21d759d/.emacs.d.gnu/config.org) using this [live-stream tutorial](https://www.youtube.com/watch?v=hoP4I9ounyQ) **Elisp** - if you don't understand *anything* in that config, brush up a little. `undo-tree` - have a way to navigate your mistakes. `view lossage` - use this to find out what you typed that *led* to the mistake. `C-h f` (`counsel-describe-function`) - Use this to find out what the function does. You can usually visit the source this way. Do you see a function call on the next line? Check the docs on that function too. You don't have to leave Emacs to do this. Just writing this comment I had to use these tools. I couldn't recall the name or binding for `evil-goto-definition`, even though I use it all the time. However my Emacs has grown to use `counsel` and `hydra` and `General` keybindings and `which-key`. So I typed a leader key and got a prompt listing keybindings that I personally set up. I typed `g`, which handles all of my `goto` short-cuts. From there the function was listed. If I had remembered the name of the function instead, I would have used `C-h f` to find the binding. From there I just have to open a single link to be in the source and it's clear as day what is happening under the scene. Build your editor for the task of learning/exploring your editor. Then you have a single process instead of many unrelated problems.

> (My first computer, an Amstrad PC1512 first computer we had in the house too ps: trying to undo this comment with C-/ made me learn firefox selects all textarea content :)

Your question is large, and my only advice is let your opinions be free. If emacs doesn't behave like you expect it, it's not necessarily you that needs to understand. And actually emacs is made to be molded into your needs. Maybe you need vim ? maybe sublime or vscode. Sometimes people really have different mindsets.

You're right. But when I read people explaining what they do with emacs, I think "that's precisely my dream, that's the editor I want", and the other editors don't even come close. So I can't shake the feeling that I'm simply using it wrong, and because some mistake from my part I'm not enjoying the real emacs.

I have a feeling that you have a lot of emotions regarding your use and understanding. Sometimes it's cool to take a step back and be patient, through use and talk you'll reach higher understanding and speed. Have you spend time on #emacs IRC channel ? people there are hyper friendly and knowledgeable, maybe a bit easier to find help on a live chat than on SO. Are you a programmer too ? it helps. Maybe you've seen them already but there's also http://emacsrocks.com/ videos, emacsconf too

> all the subtleties of the undo ring and so on. For this part I'd say that you've run into limitations of the undo-ring interface. It can be impossible from its interface to recover your original state depending on what manipulations you do (you might have also run into the [undo-limit](https://www.gnu.org/software/emacs/manual/html_node/emacs/Undo.html)). [undo-tree](https://git.savannah.gnu.org/cgit/emacs/elpa.git/tree/elpa-packages#n753) mitigates most of these issues. It can have performance implications though which depending on what you do means you might have to tune it. A number of your other issues have to do with finding documentation and understanding Elisp. To get the most out of Emacs, you ultimately need to learn Elisp (since at the end of the day it's a Lisp interpreter providing a text UI with some GUI support). It's certainly usable without, but you'll never get as much out of it. > Also, they keep telling me that emacs is powerful and efficient, but sometimes I have big files that simply slow emacs to an halt, while they open without a problem in any other editor, even the heavy, bloated ones. That is an issue both related to Emacs' internal representation of buffers and modes working in the background on the data in buffers of very large files, for which there are some workarounds like [vlf-mode](https://github.com/m00natic/vlfi). See for example [(info "(emacs) Long Lines")](https://www.gnu.org/software/emacs/manual/html_node/emacs/Long-Lines.html) for similar issues with long lines and a solution more similar to what all those other editors you mention are doing to mitigate the issue of large files and large lines. edit: [Vertical completion](https://github.com/emacs-tw/awesome-emacs#minibuffer) (there are many implementations of the idea) is *extremely* useful for finding help and documentation when you don't perfectly remember things. It's also useful for discovery.

Regarding JSON, things are starting to improve: https://github.com/iwahbe/jsonian/ is pretty good, better than both `javascript-mode` and `json-mode`, even without the speed improvements. Of course minified JSON will still have the long line(s) problem and you're better off doing `jq .` to reformat it before opening it.

> If I learn some basic elisp, do you think I could realistically add the features I need (for example, wrapping the text and moving a particular cell, row or column in ways that aren't supported at the moment), or would it be too difficult / too much work? Part of the issue is that Emacs buffers aren't the most efficient way to represent spreadsheets (there's a reason they're usually implemented in purpose-specific programs with specifically chosen datastructures) and Elisp is ultimately not the fastest language for the purpose either (this is improved by both byte-compilation and native-compilation of the involved functions, but even then there's a long way to go optimization-wise). Adding those features is certainly possible (as is improving Elisp compilation and execution), but depending on how intensive a use of spreadsheets you expect, you might still remain disappointed.

> Also, they keep telling me that emacs is powerful and efficient, but sometimes I have big files that simply slow emacs to an halt, while they open without a problem in any other editor, even the heavy, bloated ones. M-x find-file-literally

I might try Spacemacs or doom. I declared emacs bankruptcy a few times during my first decade with emacs and found these config kits to be a bit of fresh air. There’s a consistency to them that I like. That said, it may not be what you want at all if you’re trying to understand the onion since each kit essentially adds a new onion layer.

Yeah I seen some of this a while ago. I was just too fatigued at that point from various other things in my config. eMacs fatigue is real but who the hell wants to use spacemacs

I think that's only one possible approach. And it's an approach that I think is the main reason emacs is not more popular. Not everyone has the time/need/patience to go through a manual (a pretty terse and badly written one at that...) even before starting to use a text editor. The learnig-the-internals part should come later - when the user is sure they like the tool (emacs is a tool, not a religion...), and are ready to invest the time needed to play around with configurations. What you are suggesting is, in some sense, similar to asking users to go straight to a bare slackware install with no DE, and read the linux manual to configure their system. Don't you think it's much easier to convince people of the tool (linux in this case) when they can play around with friendly distros like Mint or Ubuntu. Once they are sure they want to stay, it is obvious they will create their own configurations and read the relevant parts of the manual. No need to rush them into the manual - it only scares users away. At least that is my approach behind creating this distro. It is a literate config with comments and refs so that when the time comes, the user can slowly start to modify parts of the config and create their own config. And if the user is completely sold (and has a lot of time to spare), they will probably create a new config from scratch - it's an inevitability.

It would be a substantial project to modify org tables to do some of these more complex spreadsheet features, unfortunately. There's a reason it doesn't exist already. As for other advice, I'd say, go back to my first comment and read about literate programming and a literate config. As for the journaling, org, and roam ecosystem, just start simple. Don't try to discover the best possible workflows. The "best" workflows will be the ones that are easy, that work for you. Most people only use about 10% of org mode, but *which* 10% varies from person to person based on their needs. org-babel is what you're looking for to incorporate org mode with other capabilities, side by side. This is literate programming. You have blocks of text intermixed with blocks of code in essentially any language. You can include also images, gifs, tables, and so on. You can add bable src blocks into any org document including org-roam nodes or org-journal entries.

A lot of people will tell you to double down on barebones Emacs and prescribe you several methods to become an Emacs Wizard. You can certainly go that route. If that is the case, more power to you. But I will not tell you that. I used Emacs for many years and, at one point, I was just too tired and needed a break. So I transferred all my settings to Doom Emacs. When people talk about Emacs distros, they sometimes give the impression that using one is the equivalent of switching from Linux to macOS, or worse, Windows, and that you'll become ultra-dependent on a bloated structure in which you cannot thrive. In the case of Doom Emacs, that is far from the truth. Doom Emacs removes the weight of managing every single thing, but I still can and do whatever the hell I want with it, with the benefit of a sensible configuration scheme and some very handy macros. If I found Doom to be too bloated or slow (which it is most certainly not), I could disable every single module and still benefit from its sane defaults. And if you're not an Evil user, you should know that using Doom without Evil is officially supported. So yeah, don't give in to peer pressure. There's absolutely nothing wrong with benefiting from the knowledge of others. Try Doom. Try another distribution, or someone else's init. Remove the weight so you can focus on the settings and tasks that really matter *to you*. That's my advice.

>Any chaos that ensues is usually down to the user's configuration or misconfiguration. That's exactly the chaos I mean. And I feel using ~~straight~~ use-package helps to avoid that. >I'm not sure I understand why you would be changing the same variable in many places. Because I was a beginner, and my configuration was chaos. As I got to your point about use package, I realized you're correct and I was commenting without sufficient coffee. The two packages are intimately tied in my mind and I was suggesting straight when I was thinking of use-package. So yeah, I agree with you. A beginner should definitely use use-package.

I am so confused by your "question". You say you've been using emacs for ten years, but what for? Programming in your free time? Your day job? Writing a novel? Taking notes on a Windows XP machine while text processing happens in Adobe Whatchacallit? There are a lot of helpful "newbie" answers in this thread already, but honestly, none of those contain anything you would not have found searching the internet during your *first* year with emacs, let alone ten. I fail to understand what could even make a person stick with a text editor for ten years when they have such a distaste for it. Maybe tell us what it is you actually *need* from a text editor, so we can suggest more than "generic emacs for noobs" advice?

Honestly, the default behavior in emacs is completely anti-human. The right way to use it is to lean elisp and customize it so the editor does what you want, rather than learning to do what it wants you to do. Unfortunately that means emacs is different for everyone so it is hard to get good help. I feel your pain. Plus elisp is weird.

Needs more `C-h [t,k,K,w,f,F,a,d,m,b,r,i,p]`.

> everything I learn I end up forgetting because there is so much and it is so complex. The usual advice, in this case, is: just learn what you need and use. That works elsewhere, but not with emacs. It does work with Emacs, which is exactly why it's "the usual advice". Trying to understand All Of The Things will inevitably be overwhelming, because there's too much. Familiarise yourself with the limited set of things which are *most* important to you, and reinforce them until they're second nature. If something less-important doesn't work how you want, and you don't find a solution quickly, my advice is to *ignore that thing* -- just accept that, for now at least (and possibly always) you'll have to trade off those less-important annoyances in order to achieve your more-important goals. > You see, the whole system is so complex, and everything so interrelated, that I feel that if I don't know everything about it, the things I do use will alway act differently from what I expect My take on your rant is that Emacs will probably *never* work exactly how you want/expect in all respects, so find a way to accept that. > It seems that super simple things that are taken for granted by everyone, for some reason can't be done simply in emacs, but require messing with the configuration, installing plugins, writing elisp and using workarounds. 1. Emacs probably pre-dates most of the things that "everyone" takes for granted. 2. Using or writing elisp is *how* you configure Emacs. It's the fundamental thing which makes Emacs flexible, and it's crucial. In another comment you said: > I never got into elisp, but I will now There's no chance (none whatsoever) of understanding "all of Emacs" without having strong Emacs Lisp skills. Emacs Lisp is the core around which most of Emacs is constructed. Knowledge and skills with elisp will give you the tools you're lacking for understanding how and why some feature works the way it does, and give you an ability to investigate and change many things. *However* you still need to accept that many changes may entail more effort than you're willing to expend, and you will not be able to have everything the way you want. Whether that's an acceptable trade-off will be up to you and your personal priorities.

It wasn't for me, but when I tried vscode it gave me an emacs-like feel and might be worth checking out for a similar kind of extensibility with less of the legacy aspect that you find frustrating about emacs. I had the impression using it that, if I hadn't already learned emacs and gotten it set up how I liked, I might have liked it instead.

>Just today I was sorting an org file, and at the end of the process the items were less than at the start. I kept undoing until it didn't change anymore and counted the items again. They were still less than what I started with. I have no idea how that happened, and that's just a normal emacs session for me. If this is true, ditch emacs. There's no shame in leaving an abusive relationship. I don't see things like this as a problem. The computer did exactly what I asked, I just asked the wrong thing. So I debug. Non-debuggers move up to management and live lovely lives.

No. Visual Studio Code is not extensible the way Emacs is extensible. Emacs is built to be extended, molded, and shaped the way you want as you use it. You can use prebuilt packages and even prebuilt configs, but it admits a higher level of customization because it's a live system you can program as it runs.

When I was in New York City, before 9/11, I would look up at the World Trade Center towers and make myself dizzy contemplating how tall they were. That's also how I felt opening up Emacs in my early days. This was the most powerful text editor, used by wizards to achieve wizardly feats. The "tower" of stuff yet above me, things I had to learn, was staggeringly huge. Emacs has a *profoundly* high skill ceiling. There is no way you are going to grok all of it. But it is one step beyond free software, because not only is its source available and modifiable, but it will happily tell you all about itself when queried. So avail yourself of that help system, and if there is a function (C-h f), variable (C-h v), keystroke (C-h w and C-h k), or concept (C-h a) you don't understand, ask Emacs help! If Emacs had a personality, it'd be akin to Richard Feynman: ridiculously, staggeringly, intimidatingly smart, but eager to tell you all about the stuff it knows. Also, don't turn off that pull-down menu! You may see wizards doing this, but... they're wizards. In general, take things one step at a time. If you can use Emacs as a basic text editor, great! That's more use you're getting out of Emacs than if you hadn't touched it. Each new thing you learn from it, however small, increases your ability with it. Don't be afraid to experiment.

I'm aware that it's not equal, but it's the closest I've seen in a modern editor and could make a good choice for somebody that isn't getting along well with the open-ended nature of emacs but wants something *similar* for flexibility. Which is what I was saying. If it were actually equal in power I'd have switched because it feels a lot less clunky in many ways, but it doesn't, so I'm still here. but OP isn't me and might prefer vsc, so I mentioned it because what's good for me (or you) isn't good for everyone.

First, this was a great question / conversation prompt / plea for help. Most of the things you wrote ring true for, I'm sure, virtually everyone here. Unfortunately, "The usual advice, in this case, is: just learn what you need and use. That works elsewhere, but not with emacs." is a real snag. I've used emacs for a couple decades, and I adore it, and I am not an expert at it in the way some of these prolific package authors are. The reason I adore it is that it is so flexible that usually someone somewhere has made something to help it do some quirky thing I -- purely as a user of the application -- would like (e.g. esoteric programming language support). I am a user first and foremost. But then, when I *do* set aside an hour or two to try to scratch some itch (I wish I could do some task in some easier way) it is always possible thanks to emacs being emacs. That's when it really wins me over. You so rarely hit situations where you have to accept emacs the way it is because under the surface it's some black box that you don't control. So, I appreciate that you feel like the usual advice isn't working for you, but it's certainly the advice that I'd offer anyone in your situation.

I used both, they are both really good, Doom is better. But if you’ve been at Emacs for over a decade I don’t think these frameworks are going to solve your problem. IMHO they muddle the waters, it’s hard to know whether the weird behavior you want to fix is because Emacs isn’t working how you want it to, or because the framework is modifying one of the installed packages in a way you don’t want it to. Basically it just increases the problem space from “how can I make Emacs do this” to “how can I make Emacs do this OR how can I make Doom/Spacemacs not do this”.

This. I’m blown away by the level of “question” here. If you’ve really used Emacs for a decade you’d know everything that has been said in the comments so far. Why keep using it if it’s not working for you?

I’m not sure that this is really related to OP’s question, but it’s interesting nonetheless. I don’t know what a “lacanian real mind” is, but I’m a Vim keybinds until I die kind of user. I do find it difficult to memorize arbitrary keybinds (which is how Emacs keybinds appear to me), but I’m confident that if I put in the time I could learn them. It’s not that memorization is difficult, it’s that using Mnemonics is significantly easier. I honestly thought this was a near universal truth and that people not using Vim keybinds just never put in the time necessary to grok it, you’re saying there’s a fundamental psychological difference?

> However, every time I must do a new installation or reset my configuration (for example, because something doesn't work anymore and it's not clear why) I must relearn and redo everything from the start. That sounds awful. An Emacs config should be something that you grow and maintain over the years, and take with you wherever you're using Emacs. Starting from scratch every time you do a new installation?! That's horrifying. Put your config somewhere which will be accessible to you any time you're installing Emacs, and copy it across at that time. I *highly* recommend using an online version-control repository for this (github is a popular choice, but there are many options out there). For the "something doesn't work anymore" case... well, you want to get to a point where you can fix any such issues. But even without such knowledge, I think the worst case should be removing or commenting out some parts of your config, not abandoning the entire thing!

FWIW there is active ongoing work which is intended to give Emacs 29 good performance OOTB when dealing with super-long lines. The current master branch includes the current work-in-progress.

Learn some elisp and learn the names of functions and call them with “M-x” (as in learn to search for the things you need) before committing them to keybind memory. Also once you start learning elisp, if a package has shitty documentation you can just go look at the source code.

>Secondly, how's your elisp? Can you write a function? Can you write a minor mode? Can you write a package? If you've been trying to learn emacs and it's just not landing, I'd suggest instead switching to try to learn elisp. I'm in this guy's shoes too. I'm stuck in perpetual newbie mode. What's the best way to learn elisp etc? I've seen a zillion tutorials over the many years I've been around emacs but none of them really clicked and out it all together for me.

Few considerations: - is Emacs really complex? I mean, yes, I know it is, but for instance in case of a weird bug in Linux did you know *really* how to debug? A strange graphic problem with a modern DE? You probably just not suffer there because the code is FAR MORE "tested" since it's run by many more people and things are hidden. Take let's say a desktop: for most it's a single machine. For some there are a small number of components. Almost no-one dig into them, if something goes wrong they just start over (drop a faulty component, not caring about it's fault, push a new one in place). The issue with Emacs is that starting over have a cost; - any large project need expansion and consolidation phases and at a certain point in time need to start over from the empty sheet. It's not different for civilizations: there are expansion and crisis periods and at some point in time they fall and new one born knowing good and bad parts of those came before, sometimes re-doing similar mistake and then re-discovering that something they cut from the ancient civilization have a reason to be. Modern OSes follow this VERY well. As the time pass they rediscover things already (and better) implemented decades ago, to reach the Emacs point ad actual speed you need probably seeing OSes from 150+ years in the future. Long story short: yes the same thing you describe happen to me as well, and yes it's frustrating... But there is no solution: probably it will be about time to think an EmacsOS incorporating a lispy kernel and bootloader and say "Emacs is a unix-compatible, but not unix, OS". With this perspective probably some users disgruntled by the actual crappy evolution of major OSes will give a try with a right mindset a push fresh air in the community causing 5+ years long troubles but provoking indirectly a cleanup and positive evolution. That's because IMO Emacs so far have simply lost focus, not really knowing it's identity...

for a new (or not elisp magician) person they provide sane defaults for the things you might actually use emacs to do, e.g. language layers, also a newer person might prefer spacemacs to doom (and i actually do even though I am neither new nor totally elisp ignorant (but not a magician) but I would bet my preferences are more similar to op's lol)

Keep in mind that those people suffer through some pain to get things to work often enough. Whatever anyone showcases is often the fruit of arduous labor but like the movies, we outline the part that is most interesting to others. Everyone uses it differently. I don't really believe there is a right or wrong here. Just "whatever you need" and then the other stuff. 🤷🏿‍♂️ The points regarding the literal config are good tips. Try making your setup more declarative as it will help you share with community members (IRC or some Discord space like SystemCrafters) to help you find out what may be broken. A lot of lovely and knowledgeable folks around that are happy to help. Also, engage with the community on concrete questions like "Org is slow on large files, this is the relevant part of my config, how to optimize?" and you'll probably end up receiving actionable tips to disable `display-line-numbers-mode` and to disable wrapping or something of that sort. I have such tweaks in my literate config https://github.com/vidbina/dotfiles/tree/reorg-for-lit-prog/emacs#hide-line-numbers-when-in-org-mode and the literal nature of the config saves my ass as there is no way I would recall what I was thinking by just looking at uncommented elisp code. Furthermore personalized tweaks are not universally applicable (not everyone uses Emacs and/or Org the same way) so this tuning problem will likely remain part of the Emacs experience for a while. Put the config in a repo and start sharing questions. I'd be happy to give a glance and help sleuth for root causes when you bump into an issue. No promises I'll be helpful though as I'm constantly roaming between despair of my lack of Emacs knowledge and elation because I got a tiny thing to partially work so I'd consider myself and Emacs noob myself. 😅

For a cases like these, being able to roll back is key. Use a version management system like git to track all the plaintext files that are important to you. This allows you to change things around with confidence as there is always a way back. I personally track everything over multiple git repos and sync between multiple machines with syncthing to minimize the blast radius of my elips noobness.

Can you pin deps with pure package.el? Starting off, I believe that straight.el allowed me to worry less about package compat as it allowed for some confidence regarding reproducibility in the sense that the right version of all straight-managed Emacs packages would be installed everytime I were to apply my config. Being a NixOS user, this was an important feature of straight that allowed me to focus more on the bits that are just relevant to my work as opposed to peripheral issues and this is why I would recommend straight to beginners too. Focus on the relevant parts of your config and worry less about updating things or reproducibility.

By the way, speaking of moldability, a bud of mine is working on Glamorous Toolkit and it seems to be in the Emacs category with less constraints from historic legacy. I haven't yet tried it because I could not manage to package it for my system (NixOS) but if extensibility is what you're looking for, gt may be a suitable contender.

To be clear I’m not knocking these frameworks. Both are great, literally a godsend to new users, I never would have given Emacs a chance if it weren’t for Spacemacs. I recently switched to Doom and am happy with it. With that said, I’m running into one of the same problems with Doom as I had with Spacemacs, which is that I don’t feel like I’m in full control of my configuration. So when something isn’t working how I expect I’m never sure who to blame. I’m not saying don’t use a framework (I’ve actually never used plain Emacs), I’m just saying if you’re going to go down that road beware that they may simplify a lot of things, but they add their own special flavor of complexities as well. I guess this is as good of an excuse as any to try building a config from scratch so I can better compare what kind of complexity is easier to deal with.

[deleted]

I guess you misunderstand the higher-level concept of emacs. Base on your post, I assume you see emacs as a regular text editor?! This is your mental model of emacs, so you want to use emacs as a regular text editor. But, the higher-level concept of an emacs is to be a virtual machine for automated text processing. The idea is to automate everything which is a repetitive task in text processing. For instance: Ctrl + a is a key combination which executes the function named `(beginning-of-visual-line &optional N)` Why? The keyboard is the user interface, and to move the cursor to the beginning of a line is a repetitive task for the user which wants to process text files, so it can be automated. Your goal to use emacs should be to automate tasks for text processing. And therefore, it is needed to learn emacs-lisp. This is the reason I am using emacs. I have to work with a bunch of information and I want to automate tasks to be more productive.

Replying to /u/LeonardMH too: you would be suprised to see what laziness and inertia can do. Basically, I've been using emacs like a notepad that happens to have hierarchical lists, windows, and interactive programming environments for basically every language. Just for this, I wouldn't know how to replace it.

Yup, I start to see this as a thread emerging from the replies I get. Basically, I was under the impression that I could use emacs like a regular text editor with a lot of cool stuff included, and learn something about the underlying system only when absolutely needed.

Perhaps Jupyter Notebooks? Not a direct replacement, but they’re pretty similar for a certain use case. Also if you’re basically only using Emacs for org-mode, your rant makes more sense. I’ve gathered that org-mode is a very “mature” and monolithic part of Emacs, which in a lot of subtle ways, doesn’t behave the way that the rest of Emacs behaves.

You CAN use emacs as a regular text editor, but you would miss a lot of opportunities. It is like using a smartphone just as a regular telephone. You CAN do this, but you would miss a lot of opportunities of the smartphone. For instance, if you are an author of screenplays, by using emacs and emacs-lisp, you could invent your own markup language for writing screenplays and automate some tasks, and be more productive. And you can do this all without having an degree in computer science from a university. This is the value proposition of emacs. If you want to be productive with emacs, it helps to have an long-term goal. For instance, I am working in the UX field. I have to do a lot of user interviews and to analyze the results to get insides. Some of my colleagues are using software like MaxQDA or similar. But I decided to develop my own qualitative data analysis with emacs.

For me, navigating the help menu and learning by doing have been best. There's no motivator quite like a specific need. I figured out what I wanted to do and what existing functions and variables I needed by using commands like lossage (C-h l) and apropos (C-h a), then I looked up Elisp syntax and code online to find out how to achieve it. If I wanted to know Emacs Lisp inside-out or contribute code or something I'd have to make a more formal study, but it's never been my goal to be a whiz. I just have a comfortable set of settings and functions that work for me and which I know well enough to debug when something breaks, for instance, on upgrades. And that's plenty enough for me, but YMMV of course.

May I suggest to use git when modifying important documents? It allows you to commit changes and it allows you to compare the differences between previous versions. Even a temporary git repository is useful for this. I use it all the time and it has saved the day so many times.

I wholeheartedly agree! (If my coworkers hear me say "If it's not in git it doesn't exist" one more time I think they're going to stage an intervention.) It seems though that the OP doesn't really like the reality of emacs. The -- admittedly humorous -- rant sounds a lot like someone who wants to be a musician but doesn't want to suffer through learning scales. You don't get the outcome without the practice and asking someone to "practice" using a text editor might be a bit much if it's not in their nature. I don't mean that to be judgmental, we all have things we don't want to dedicate time to. Alternative (though not more heartfelt) advice for the issue I quoted would be to recreate the problem in a test file then start digging into the source to find the root of the problem. In the context of the rest of the rant "RTFS" seems glib, unhelpful, and arduous even if it's the route that would lead to the emacs proficiency the OP desires.

Observation: your post's almost incoherent as it has numerous topics mixed together. 1. "Just be proficient with what you use" isn't a copout. It's good advice. I've used emacs for years and added keyboard macros for the first time a few months ago (I'll admit this makes me anomalous as I'd written numerous elisp things previously). 2. Files with performance issues. I've had this happen as well and it was caused by files with long lines. While I just lived with it, there appear to be several ways to handle this. 3. How to remember everything you learn? I stopped trying and started using small org-roam notes to keep track of nuggets of hard-won knowledge (e.g. `make-indirect-buffer`). Looking at the Graphviz representation of my notes, it's remarkable how many of my notes are about Emacs.

Genuinely curious, why do you think Emacs keys are the faster ones?

The other response is correct; pick some goal and try to accomplish it instead of just reading or watching videos. Use built-in emacs help as much as possible. Even drop into the source code of packages and see how they do things. It's not even important if there's already a package or a built-in function that does what you want. Write your own anyway. For example, I wanted to change the behavior of ctrl-a in org mode to cycle between the start of the line, the headline or list marker, or the first letter of text on the line with successive presses. It's similar to but not exactly like org-special-ctrl-a/e which comes with org-mode. I learned a lot writing that function. Then, I wrote a minor mode that highlights words in a document from a list of over-used or weak words so you can replace things like "really" and "very" with more interesting vocabulary. Turns out, there's already a few packages that include this capability, but writing a minor mode myself taught me a lot. I posted a link to it here and got some very helpful feedback. I wrote a function that looks up definitions and synonyms of words on [Dictionary.com](https://Dictionary.com) and provides an interactive list of options to select from to replace the given word with. Doing that helped me understand completions and completing-read. And that's how it goes. You learn by doing. When you get stuck on some specific part of whatever you're working on, ask questions on stackexchange or here. People will help you out.

Okay I'm impressed just based on the fact it's made with Pharo. That's awesome, Smalltalk is another amazing language that doesn't see enough use. I'll have to check it out in more detail later, seems interesting, thanks for mentioning it.

If I hadn't learned Scheme first, elisp would have been more difficult for me. Elisp is very powerful but a bit irregular. Now learning Common Lisp, my experience with Scheme helps me there as well. I have just written very short "glue" scripts for elisp, that made things work well enough for me.

It doesn't matter if it's 1, 5 or 15 years. You have to be actively using Emacs and learn it. It's one of its own kind and not like if you learn VSCode, there's a good chance things will be very similar with Sublime, Atom etc. On the contrary, everything you learn about Emacs is only Emacs related. Learning anything else gives 0 contribution to understand Emacs. You just need to use Emacs. Make notes and save thoughts about things you learn. Eventually, they'll pay off. My story is following. I have started using Emacs a month ago with LaTeX. To turn it into something I like took me about that period. It's now doing things I expect but had to learn lisp, spent hours and days on learning simple stupid things and basics. I also installed helpful packages like Ivy, perspective, projectile, counsel, doom-modeline, which key etc. I also had to learn how to use help. This is IMO one of the major things people miss or are not aware how powerful Emacs' help is! I used to use Atom but it has been discontinued because freaking Micro$oft bought GitHub and decided to eliminate one of its rivals for VScode. I'd feel uncomfortable to change to a product from the company which feels OK to remove something that's been used by community for years. Besides, I'm not comfortable with tracking and telemetry. So why Emacs? I pushed to learn Emacs because I know it's open-source, independent, free from shady things, and will be here always. I know once I turn it into something that works for me will be there. It's hard and frustrating but it's also rewarding; it's very good for everything, although there might still be editors superior for individual tasks. For instance, I might still come back to Atom for using regular expressions.

Well I’m always checking in so I’ll have a look. Compiled eMacs was the last cool thing I tried an it was amazing but the interface still hanged for me on a lot of stuff unfortunately.

I switched to Spacemacs (before Doom came out) after having used Emacs for like 7 or more years and I learned a ton from it. After a couple years, I moved off Spacemacs and back to my own config and it only took a few hours one weekend to make the switch. You're *definitely* not locked in to a distro if you try one out, and even experienced users can benefit from seeing a well-structured set of defaults and packages. Quite a few things in my personal config now are inspired by Spacemacs and Doom.

I'm weighing in late (as usual for me), with a certain sympathy. I've been using Emacs for about 30+ years, but never as an expert. For me, it's basically a LaTeX IDE, with AucTeX and RefTeX as major modes. The trouble with Emacs is that because it's so extensible, and so customizable, it's basically an OS in itself. You can use it for file management (Dired), remote access (Tramp), email (numerous front-ends), shells, IDE for numerous languages and systems (ESS for R is excellent), Git (Magit), and then there's org-mode, which seems to be all things to all people: I've used ox-hugo for managing my blog, and ox-reveal for presentations. ANd it does, as you say, has its own terminology (windows, frames, for example). But the point is that you don't have to use any of these. You can start simple - as I did with LaTeX and the original LaTeX-mode before I discovered AucTEX - and then keep adding things as you like. Even after all these years there are many standard things I can never remember, as I use them only infrequently: macros, for example, and the various editing commands for managing rectangles. And I've never got comfortable with elisp. Of course for whatever reason you may find that Emacs is simply not for you, but there are plenty of other editors, although on Linux Emacs still seems to me the best. (There also a number of Emacs-like editors, which provide a very cut-down editor-only app, but with much of the same key-codes as Emacs.)

[deleted]

"Just today I was sorting an org file, and at the end of the process the items were less than at the start. I kept undoing until it didn't change anymore and counted the items again. " I believe most people use git to back up the orginal file first. You problem is you need plan and build your own workflow, - write down existing workflow on a paper - pick up a mature 3rd party config distribution (doomemacs? spacemacs?) - figure out how to integrate your workflow into the distribution. If you have no clue, ask for help in distribution's channel There are also many good articles and tutorials to teach you how to build the workflow. For example, From vanilla Emacs to Bash IDE in 17 minutes by Skybert Hacks (https://www.youtube.com/watch?v=LTC6SP7R1hA) is pretty good.

I can confirm that learning to write elisp helped me tremendously. I still consider myself something of a newbie, but over many years, I cobbled together a system that let me set a bunch of compilations in action, queuing them up, displaying buttons, etc. I'm a (C++) programmer by trade, and there's really no magic to it: start with a goal, hack it together, go back, and refine it. Come here and post about your elisp problems. Start with the easiest, most basic constructs and build up. Someone will come along and tell you that something can be more easily accomplished with this or that other library or function, and you can roll that in. Make comments in your code that remind you what you were doing and what goal you were trying to accomplish at the time. (Indeed, this holds for just about any programming--write comments so in five years when you come back to your old code, you understand what was happening in your head.) I literally started by writing fizz-buzz. Then figuring out how to use the `compile` function to build my app so I didn't have to jump out to visual studio to hit that compile button manually. You almost certainly have a workflow that's multiple steps. Try to see if you can write code that ties that all together for you, so it's just one keystroke.

Wow! I didn't know C-h had that much stuff. Thanks! It only just now occurred to me to type C-h C-h.