[[!sidebar content=""]] [[!meta title="Fanfare for the Common Emacs User"]] [[!meta copyright="Copyright © 2022 John Cummings"]] [[!inline pages="internal(2022/info/fanfare-nav)" raw="yes"]] <!-- Initially generated with emacsconf-generate-talk-page and then left alone for manual editing --> <!-- You can manually edit this file to update the abstract, add links, etc. ---> # Fanfare for the Common Emacs User John Cummings (IRC: jrootabega, <mailto:john@rootabega.net>) [[!inline pages="internal(2022/info/fanfare-before)" raw="yes"]] # 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) [[!inline pages="internal(2022/info/fanfare-after)" raw="yes"]] [[!inline pages="internal(2022/info/fanfare-nav)" raw="yes"]]