Fanfare for the Common Emacs User

John Cummings (IRC: jrootabega, john@rootabega.net)

The following image shows where the talk is in the schedule for Sun 2022-12-04. Solid lines show talks with Q&A via BigBlueButton. Dashed lines show talks with Q&A via IRC or Etherpad.

Format: 11-min talk followed by live Q&A (done)
Etherpad: https://pad.emacsconf.org/2022-fanfare
Discuss on IRC: #emacsconf-gen
Status: TO_INDEX_QA

Talk

Q&A

03:26.480 How would you suggest Emacs developers, including package developers, interface with non-developer users and get their insights to help in shaping future Emacs functionality?
04:38.480 Is the Emacs community getting smaller?
08:22.720 Do you think using one of the starter packages affects the learning process you mentioned?
10:41.040 Barrier to getting regular users on board
15:26.280 Changing your habits
19:28.240 Tip of the day, Emacs help discovery
21:47.020 Menus
32:18.040 In terms of your Emacs, how far down do you go? (Lisp functions, primitives, C)
43:52.400 Have we thought about how to use touchscreens?
47:39.560 Have you ever seen VisiData?
53:48.880 Low-code environments
59:32.200 Microsoft
01:04:53.840 Hyperbole and Org
01:12:07.720 EmacsConf behind the scenes
01:21:00.680 Theming
01:22:42.080 HyControl
01:26:25.880 Emacspeak
01:31:21.040 Recording
01:38:22.520 Losing and rediscovering knowledge
01:44:11.480 Emacs as a shared community knowledge base
01:53:46.560 Philosophy
02:03:49.800 Narrowing
02:05:40.800 First time on a new system
02:07:43.800 Bootstrapping
02:10:50.760 Richard Stallman
02:14:24.880 Other developers
02:15:54.880 Emacs and Org development
02:21:41.000 Closures, Lisp
02:42:12.480 Clog
02:54:23.960 Domain-specific languages, collaboration
03:02:39.280 Condensing things into a 10-minute talk

Description

Table of Contents

Emacs enables Emacs developers to produce some very impressive and useful things. It can also inspire examination and discussion of profound ideals. But what about the everyday user who may not always feel that they live up to these examples? What about the "dark matter" of the Emacs universe? There's a lot of us out there, and we have an important effect, but it may be hard to see it. What about life after the EmacsConf inspiration has started to fade, and we find ourselves working much the same way as we always have? In this not-very-technical short reflection (perhaps just a personal projection pep talk), I want to recognize and celebrate the experience of these users.

Colored by my personal unremarkable usage of Emacs, I'll describe some of the practices and "imperfections" that everyday Emacs users might experience – trying to create and remember keybindings, writing many quick hacky functions to solve miscellaneous problems, trying to learn more than we forget, half-implemented ideas, messy organic .emacs, etc. I'll frame these positively, as a great way to use Emacs for our own personal mundane needs, and a sign of our own dedication and pragmatism. I'll opine on how Emacs is, conversely, a perfect platform for this kind of usage in addition to highly-organized packages and modes.

Discussion

Notes

• What a wonderful talk.  You knocked it out of the park.  Thank you so much.
• "Psychic baggage" with emacs-- awareness of possibilities left behind and opportunity costs.
• Possibly related:
  • https://www.youtube.com/watch?v=yJDv-zdhzMY Mother of all demos
  • https://www.youtube.com/watch?v=oMpf0ilQ9Lk&list=PLomc4HLgvuCWuJVVwsT8pbLWYR-n3G8bH&index=17 EmacsConf 2019 - 18 - Object oriented spreadsheets with example applications - David O'Toole (dto)
  • https://agregore.mauve.moe/ peer to peer browser
  • https://emacspeak.sourceforge.net/
  • The Common Lisp Omnificent GUI Builder - Online Lisp Meeting #13, 11.01.2022 https://www.youtube.com/watch?v=pkQ-WlzQudw
  • https://gtoolkit.com/
  • https://janet-lang.org/

Questions and answers

• Q: I have not only One config, but multiple configs in different locations... .emacs/init.el and .emacs.d/init.el and different Python installs in different places. Is this something that I should take care of earlier rather than later? I need to pay someone to "consult" on my config. Is this an existing business? Is there a place to barter a screen share for something else of value in exchange? In any case, thank you for giving permission to have fun without the need for too much structure. 
  • A: Good quetion... I'm humbled and will give it some thought. The Buddy emacs system would be a good place to start. 
  • Now after having thought some more, I think it depends on your comfort level when the best time to reorganize your various environments and configs is. Separate configs and installs might be better separate if they are just doing different things or represent different mental contexts. If the separation starts causing stress or extra effort, at least you then know you have a good reason for merging them
  • and won't be doing it just for its own sake. I still think the Emacs Buddy Initiative sounds like a great way for people to trade eyeballs on stuff like this. And there's always the famous rule: just post it somewhere and say it's the best approach, and you'll get dozens of people giving you free advice on how to improve it!
• Q:How would you suggest Emacs developers (including package developers) interface with non-developer users and get their insights to help in shaping future Emacs functionality?  What sorts of things make new functionality more welcoming to non-technical users?
  • A: From what I can tell on the Emacs mailing lists, reaching out to all types of users is already seen as important and results in collaborations like the recent Emacs Survey. As far as going further than that, maybe a space for users of the package where all skill/comfort levels are welcomed and comfortable volunteering feedback? I wonder how many users might not even be interested in ever giving feedback just because they prefer to keep to themselves.
  • Side note.: sourchut allows multiple repos one one mailing list for smaller packages
• Q: It's my impression that many "common" Emacs users are migrating to other editors in past years. The reasons cited include configurations growing out of control, and the general rough-around-the-edges feel of Emacs that they've been putting up with for a while. (Maybe this isn't a new phenomenon) As a result, Emacs is becoming home to a smaller set of people who are ever more invested in it. Do you share this observation? If you do, what do you think of this trend?
  • A: My impression has been that there has been a large net increase in Emacs users in the last, let's say, 5-10 years, probably due to the popularity of tools including, but not limited to, org, starter kits, magit, others I can't remember due to a tired brain. One of the hypotheses that I couldn't fit in my talk was that I doubted that anyone ever really left Emacs.  Maybe they do some other tasks with other tools (I myself already don't use it for all my programming), but they always have some use for it. That could be wrong, of course. I agreee that there may be subpopulations of Emacs users whose proportions and philosophies change over time. I think the coming years will be about those groups finding common ground, but I think the overall population is doing OK at the moment. I could just be too committed to Emacs' utility to notice other things too much.
• Q:Do you consider that using one of the starter packages (doom emacs, spacemacs, etc.) affect that learning process that you mentioned? or is it a good thing from your perspective?
  • A: I don't have personal experience with a starter package, but I'm somewhat familiar with how those two at least work. I think any way is fine for getting started, and would just make your experience different when and if you started to outgrow it or get curious. Again, I'm technically ignorant about this, but my gut tells me that you could also learn and build a very advanced experience completely inside those kits, and that would still be a great thing, and comparing it to "standard" Emacs might be more of an academic distinction for those people. If they picked those up with the INTENTION of one day outgrowing them, that's also interesting. I think it would be a personal matter whether that was the right choice. I think at least SOME people would feel that they should have just went straight to standard Emacs, but I don't know/feel strongly enough to have a strong belief.
• Q: Would a "Tip of the Day" package or some elaboration on that idea in Emacs help discovery for lay users? Does that already exist?
  • A: I'm sure something like that exists, but at the time of the question I could not think of one. I think something like that could help if you got the tips that were appropriate for your situation at the time. I know in other applications, I often end up seeing "Tip of the Day" as something that gets in my way, even if I enabled it myself. Maybe a tip-on-demand? It might be hard to provide a stream of tips that can stay interesting and appropriate for a person's skill level for a long time, and be available when they were receptive to them. Now I'm having ideas about how to show context-sensitive animated tips. Perhaps one day I will have a better answer!
  • There is https://nitter.net/emacstips
  • https://github.com/emacs-dashboard/emacs-dashboard was also suggested by a listener  
• Q: what is a fanfare
  • A: it's based on an American piece of music "Fanfare for the Common Man" by Aaron Copland

Other discussions from IRC

• this is a GREAT talk!
• yes, really nice!
• Every single point I'm like "yes! THIS"
• This is as true of life as it is of emacs. Life imitates art imitates emacs...
• Resonates with me from having used emacs for a 5+ years
• Great talk!!
• Can't argue with this great reminder that a messy perennially-evolving Emacs setup/config is the norm rather than the exception!
• understanding source control is such a high bar for lay folk though, makes me think emacs by default setup version control for config files
• Hmmm, someone could experiment with detecting what version control is available locally then using vc to automatically source control changes to our conf..
• Also, over the last few years, some credit should go to Doom/Spacemacs for bringing new people into the fold that may otherwise not have given Emacs a second look with more the vanilla experience
  • The more I think about it, the more having use-case packages with virtual machines makes a lot of sense. A sort of all in one package that can be used "out of the box" with an included guide.
  • I like using starter packs with scratch init. It's a great way to know how far you can push emacs:)
  • agree, I started with Spacemacs, then moved to Doom Emacs, and I just love it, I agree that starting from scratch was too much challange to start, but now I am not sure if I should try that path or is not actually worth it (considering that I understand much more about the editor and the programming language)

Transcript

Hello, my name is John Cummings, and I'm here today to play a Fanfare for the Common Emacs User. By "common", I mean the types of Emacs usage and comfort that are simpler, more mundane, and yes, even imperfect, that some may identify with more than others, or more at certain times. It's hard to use Emacs and not be aware of the impressive and interesting accomplishments of its community. And here at emacsconf we also get pumped up about those things, amplified by the energy of the other attendees. But this energy fades as we return focus to our day-to-day work. And in these circumstances, we may unfairly judge our own Emacs usage against the community highlights. So I want to identify and celebrate the ways that we common Emacs users use it, the reasons why it's a good fit for those ways, and some ways we could take advantage of that. What is Emacs to us common users? Well, we're consumers. We use whatever was available - whatever our OS gave us, or whatever we found when we searched the web. We're not even necessarily aware of what the latest version is, or what changes it has. We may not ever think about upgrading. We have what we have, and we use what we have. But I think, with this simple act, many of us achieve a very significant Emacs milestone: we've committed to having it in our toolkit and our skillset. We'll probably install it on every system that we can, eventually. We know it has a use for us today, and that it will solve some problems that we don't even know about yet. It will not just be one tool; it will be many. And we know that it will be more than just useful; it will also be challenging, puzzling, and frustrating. But we still keep it as a permanent part of our toolkit, and we should be proud of that. And regardless of what exactly we've installed, it was a good choice. It will almost certainly do what we need it to do. Old versions are not inert dead-ends; they're still functional tools. And that's a key aspect of Emacs - it's a tool to get our work done. That sounds obvious, but it's easy to get distracted by the great things that it can accomplish, and think that it requires the same accomplishments from us. But it requires no advanced state of mind, no level of expertise to start using it, or use it correctly. It just requires that we have it, and use it. And with a little effort, we can get results early on, and those results are not just preparations for better things to come later; they have value for us today, and we're already using it right. And when we do need to tweak whatever we installed, we might again be consumers, finding some snippets out on the web, pasting them in, and moving on. We don't necessarily understand what we did, but we got some value out of it. Over time, we may participate more, take it day by day, and one day we may find that our config has become a disorganized pile. Maybe it's mixed haphazardly with some output from the "customize" feature, and eventually we start to feel like it's a shameful mess. It's hard to manage; we may think of it as append-only or read-only. We can't deny there are problems here, but it happened for a good reason. It was quick, easy, and effective for us to enhance our experience this way, and then move on. We were using Emacs as it was designed here. It just wasn't sustainable indefinitely. We may continue doing things this way even though we realize it's not a good idea. But I think there are some ways to mitigate the downsides, that let us embrace our tendencies, and continue to benefit from them. If we allow and encourage ourselves to capture our thoughts and circumstances along with the work that we do on our config, and do so without judgment, or the responsibility to "do it right", we give ourselves the context to understand and manage it later. This should be done however works for us, whether it's rambling inline comments, keeping a separate journal or notes, or even a more advanced literate programming technique, if we want to make an investment like that. Or putting our config into source control, even if it's nothing more than a simple, daily record of changes along with our contextual notes, will make things a lot easier for our future selves. But regardless of how well, or sloppy, we manage it, we should also realize that our messy config is a personal artifact with inherent value, even if it's amusement value, or sentimental value. Emacs is not only a tool to get our work done, it can also be a very personalized experience. And if so, then our Emacs config is our experience in written form. You can see it as a log of your journey through Emacs, and the mark that you made on it along the way, mistakes and all. We may see our config as a record of failure, of things that we did wrong, the things that we repeated, or never finished. But it's important to realize that a record of failure is a record of persistence. In that sense, it's kind of like our genome: a set of unique, disorganized, somewhat accidental properties, that, on the whole, makes us fit to survive in our Emacs usage. It's also interesting to think of it as an archaeological record. Where we can sometimes get some insight into our "ancient times". Just being able to see what we were doing years ago is interesting -- to see how things changed, and hopefully grew over time. And sometimes we find some buried treasures that we forgot were there. And of course it's interesting to realize that when we start Emacs, this pile of config also executes in roughly the same order that we created it in. Our journey through Emacs happens again and again every time we start it up. And it's ready for us to keep working on it. And when it comes to packages, we may not make extensive use of them, if any at all. We probably have different reasons for this. We may feel like we need to reach some level of mastery before we start using them. We may not have the mental room to think about packages, or may not want to take on the administrative burden required to keep track of which packages we have, the dependencies and versions, and their compatibility. Some of us may just be uncomfortable letting new third-party code run in our environments. It could also just be the case that our needs haven't driven us to need a package yet. We're already doing what we need, and doing it efficiently enough. And here we find more alignment between Emacs the tool, and our common mindset: They work well when they stay needs-driven. We're not obligated to use as much of Emacs' functionality as we can, or every package that we're aware of if we don't have a need to. And in fact, that's a great way to stay overwhelmed. But if we stay aware of our needs, and then find that there is a package that might address them, then we can deal with it. And a need to explore, and a need to be curious, is a valid need. And if we do need extra confidence for that exploration, then the things we talked about before, like keeping good notes of our experiences and needs, or version controlling our config, will help us keep that connection to our needs, that gives us the freedom to experiment in the wide world of packages. And if we really do just need what's built in to Emacs, the vanilla out-of-the-box experience, then we can also be proud that we're making use of all the work that went into that experience, because a lot did. And when we report any problems that we find, we're also working to keep that experience smooth for future users. Of course, some of us may find this intimidating, and if so, feel free to reach out to me, and probably anyone in the community, that can help you navigate that process. So how do we use our Emacs installation? We often use it very simply: we get simple results in simple ways. Often we do things the same simple way for a very long time, and this is of course great, since we're getting done what we need to get done. There's no result or method too simple for Emacs. And we're not oblivious to the alternative. Many of us are at least aware that there are ways we could iterate on what we do, or some polish that we could apply, and we may even quite enjoy reading about more advanced Emacs possibilities, and thinking about how they could apply to our own workflow, but at the end of the day, we still keep our own usage the same, and basic. And this is another fundamental aspect of using Emacs. You can work simply and successfully, but you'll always be conscious of the possibility for far more complexity. And many of us do try to iterate on our ways, and sometimes succeed, but often we run into trouble and we stop or defer. A lot of times we're intimidated by the scope of things - we're not sure how to make measurable progress. We may find that the first ways we learned are so ingrained in us, that learning even a second way is many times harder. And sometimes we do make sudden progress after years of sameness, and wonder why we waited so long. And these are universal pains that everyone has to feel who wants to improve. But this is again where we can benefit from letting our needs drive us. Sometimes they'll tell us that it's OK keeping things the way they are, and sometimes they'll tell us that it's good to keep pushing, because there's a reason for it, and we'll be glad that we did. And what are the ways that we do learn, and grow, and create within Emacs? One constant is that we forget a lot. We learn something and then remember that we already learned and forgot it once before. Sometimes we just hope to learn more than we forget. And staying driven by our needs can also help here, because it's easier to learn something when we have a reason to, and an application for it. In Emacs, it can be tempting to do this backwards, and want to learn all there is about Emacs first, and then apply it. But again that's a surefire way to stay overwhelmed. And when we code and build things, we tend to create many small, quick things, but never really integrate them deeply into our environment or workflow. We leave things half-finished once we get bored, or find ourselves in over our head. And this is natural, because we're curious and creative, and Emacs makes it relatively easy, and actually fun, to experiment and get these quick results. But it's less clear how to see them through, and inherently less fun to do the follow-up gruntwork. But if we embrace our ways here, and structure our workflow to support them, we might find ourselves more satisfied. So let's give ourselves permission, and a logical place to put all our fun little quick experiments, without having to worry about integrating or polishing them, unless we find a need to later. Let's use source control wisely to give ourselves a place to experiment, and a place for stability. Let's stay needs-driven so that we know what we really do need to follow up on, and what's OK to drop. And let's remember that there is someone who will always appreciate any notes about our thought process we can take, no matter how rough or rambling they are: our future selves. And so I hope that some people can identify with at least some of what I've shared today. And I hope that we realize that, no matter how we see ourselves as Emacs users, and no matter what we see other people building, we're proud of the fact that we have built an experience that fits us. Thank you to everyone.

Questions or comments? Please e-mail emacsconf-org-private@gnu.org