diff options
Diffstat (limited to '2022/talks/fanfare.md')
| -rw-r--r-- | 2022/talks/fanfare.md | 106 |
1 files changed, 106 insertions, 0 deletions
diff --git a/2022/talks/fanfare.md b/2022/talks/fanfare.md index a3dd3ad4..f855961b 100644 --- a/2022/talks/fanfare.md +++ b/2022/talks/fanfare.md @@ -41,6 +41,112 @@ 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. + +## 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"]] |