[[!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 &#x2013; 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"]]