diff options
Diffstat (limited to '2022/talks/fanfare.md')
| -rw-r--r-- | 2022/talks/fanfare.md | 179 |
1 files changed, 179 insertions, 0 deletions
diff --git a/2022/talks/fanfare.md b/2022/talks/fanfare.md new file mode 100644 index 00000000..24e2ed4b --- /dev/null +++ b/2022/talks/fanfare.md @@ -0,0 +1,179 @@ +[[!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"]] + + |