[[!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
[[!inline pages="internal(2022/info/fanfare-after)" raw="yes"]]
[[!inline pages="internal(2022/info/fanfare-nav)" raw="yes"]]
