Back to the schedule
Previous: Bard Bivou(m)acs - Building a bandcamp-like page for an album of music
Next: Beyond Vim and Emacs: A Scalable UI Paradigm

Trivial Emacs Kits

Corwin Brust

Download video, 13:41, 114M
Download subtitles
Download compressed .webm video (12M)

Techniques to help new users bootstrap a more gentle introduction to Emacs, one (short) init.el file at a time.

Additional Materials

KindTargetSizeDescription
org, svgtar.gz25kNotes for all talks
demowebm26mCharacter Sheet
demowebm19m"Sketch" Map and Tile editor
demowebm16mBattleboard, damage tracking
demowebm9mGame Maps, controlling fog-of-war
demogif724mAll demos, no overlays
demojson274KOBS scenes
elispwww Corwin's init files

Transcription

Following is a somewhat hasty self-transcription of my talk. Please don't hesitate to mailto:corwin@bru.st or to add any clarifications you feel helpful back into the EmacsConf wiki.

There is a visual gimmick underlaying the initial remarks.  We are
looking at the first (first-slide ("Welcome") showing how the org
markdown looks on other editors, including cygwin emacs, Notepad++,
Sublime, VS Code, and cygwin vim.  As each is closed we see the next,
until we reveal GUI Emacs running org-mode in a full-both frame.

My name is Corwin Brust and I will be talking about getting started with Emacs Today. I have been an Emacs user for a long time-

First of all thanks and a huge welcome to the conference..(15s)

On behalf of and back to the other organizers. It has been cool to have a peek backstage.

So. I've used a lot of different editors in my time. That's about 25 years as a professional software engineer. And most of that time I've been using Emacs. (~54s_)

I'll talk a little bit in a minute (if I can ever find my slides) about how I got into Emacs, but if you've used Emacs and a lot of other editors for a long time, something that you notice right away is that you get good with it in a way that stays meaningful. You learn new things, those things stick with you. You learn how to- how to make it do new tricks and then keep doing those tricks. (~1m26s_)

I want to mention this conference isn't about (whoops: "this talk") how to adjust your configuration specifically. I don't have a bunch of good code samples in here. There are a bunch of other great talks, especially Andrew's that I think may be aimed more at that "hey, I'm just getting started with Emacs what are some things to try to make it more comfortable for me starting?" [subject/audience? cezb]. (~2m07s_)

This is about how to think about the problem space more. (2m10s)

Hopefully a good way to warm up as we start thinking about some of the lightning talks later on. (I'm going to bring up my IRC buffer [offscreen] in case I run into time- I didn't get my stopwatch started for this one.) (2m25s)

So, alright: let's dive in. (2m30s)

We assume that we want to install packages, and maybe configure some features. This is particularly from the perspective of where we're working with a bunch of others on a team and we want to get something done. (2m42s)

Some of us probably have mature Emacs workflows, others may be installing it for the first time. (2m50s)

So the first questions is, you know- in that context: what's the value proposition? Why should I mess with my machine, my mature Emacs configuration, impose my way of thinking and ideas over the way somebody else is learning Emacs? (3m09m)

It can be [laugh] I'm off my slides here a little bit.. (3m13s)

It can be a little tricky to learn Emacs. One thing that helps us a lot is if people that we are working with can tell us, kinda, keystroke-for-keystroke at times what to do and explain what everything is doing. (3m30s)

And using the same packages as others can really help us working together on a project. (3m36s)

Speaking from my personal experience, it took me decades to get to the point where I was excited to program in Emacs Lisp. (3m26s)

I've programed in a lot of programming languages, but Lisp wasn't on my list. I looked at my config, that I was copy-pasting around from generation after generation of .emacs file or re-crafting it by hand and from Internet searches, to get things that I needed when I would quickly go install Emacs to start some new job or contract, and quickly get though that work-flow that caused me to go install the program. (4m15s)

You know, just simple little one-liners that got committed to memory over decades eventually just lead [me] to a sort of "hey, what's going on here". (4m27s)

And I credit my good friend Jeff Goff who died earlier in 2020 for my lifelong love of Emacs. Perhaps Erik and I will talk a little more about that at another talk we have scheduled but Jeff was a huge influence on us in a number of ways and a huge contributer to the Raku programming language which is very cool. (4m52s)

So, understanding how to make a good decision about splitting up configuration in a way to share it with people with really different uses of Emacs. That's actually a complicated topic, and I want to off and stare at it for a second: (5m11s)

I think Emacs is about people, so that means it is about community. And community means we're going to invite disagreement. In fact that disagreement isn't necessarily a road-block to our project, in fact that some of the work our project can invite us to do is to get closer to each other by inviting those disagreements, by learning from people of different styles, and from how they argue, and thinking about why they have that perspective and what technical benefits that perhaps radical point of view might carry away. Some people are really aggressive arguers others are very passive and really couch their ideas in distancing terms, "well probably this is a good idea" or "please double check me". Those don't always indicate how certain a person is. Because we're different. We have different ways of communicating ideas such as certainty or excitement. (6m23s)

When we thinking about a bunch of really diverse programmers approaching Emacs probably one of our first really big challenges is just to pick what we're going to go after. There are a number of existing kit installs and things like this. My argument is that you can get pretty far just trading files around. And maybe the more value conversation to have is making the hard decisions, e.g. "should we have vertical completion", should that be out of the box and those that want the traditional splayed-out over a sing line such as the mode line will have to add a line to their configuration. (_7m26s)

The way to get there?

How do we find out what works?

We don't want to slow down the people who are super productive with Emacs, and ask them to completely break their workflows to make it easier for new folks, at the same time we do want to make sure those new people. (7m42s)

At the same time, we do want to make sure those new people arre excited by Emacs and not turned off by having to learn the entire jungle of Emacs history in the form of it's unique technical stylings in terms of frames, buffers, and other unique Emacs viewpoints on interface concepts, especially. (8m15s)

The encouragement here is to keep using the project team as a crucible. Rather than following the defaults of, um, finding the simplest customizations that generally work, what if we tried to look for fairly specific configuration that we'll expect basically all of our developers to be using, at least when the submit bug reports. (8m48s)

In particular with this, I think that degree of experimentation can drive back into the Emacs development process. In the development mailing list.. [] In the context of Emacs development as a greater entity, we see this struggle. We have the sense that some things can "never" be change. I think one thing that can help us get there is evidence that says "hey, my 30-40 person team is using this set of bindings and here is what we learned about new Emacs users coming in and trying that". (10m)

So let's just recap real quick: in theory Emacs works out of the box. That means we are free to throw it all away and start over. [trouble with slides, again]

Our goal is to enable users- to unlock our computers, to do as much with them as possible. My work of encouragement is experiment with it. And think really specifically about how the development users may be different from each other, as you are configuring the development environment of emacs for developing on a project.

That's my talk, etc, answer any questions.(12m09s)

Do you use Emacs as a Community Building Tool? (13m15s)

Do /i/ use Emacs a community building tool? Or how do I use Emacs as a community building tool. [amin: "it doesn't say"]

Yes, absolutely. I think Emacs is an ambassador to the gnu tool-chain. in the fullness of time we will see an Emacs that will make others, Android and iOS, dream. That's why that mock us and say that Emacs is an operating system. It's because it could be, if cared for it to be. It's quite a threatening product in terms of the number of problem spaces it can address, how many types of users it can satisfy. (13m01s)

And the things that we can do to make it robust in those environments. We're always thinking about the weak points but is Emacs a community building tool? Heck yeah. (13m13s)

[we agree that I'll write my answers to the remaining questions, I say thanks more, and we're done. ps, I'll get to your question or comments I can find a response to within the next week, I expect]

  • Actual start and end time (EST): Start: 2020-11-28T10.45.48; Q&A 2020-11-28T10.57.38; End: 2020-11-28T10.59.48

Questions

What makes the Emacs community unique (special/different?) from other communities (if anything)? And/or, are there other communities that are similar in your view?

Do you use Emacs as a community building tool?

  • Yes, Corwin uses Emacs as a community building tool.
  • Corwin: "Heck yeah, Emacs is a community building tool"

Are you suggesting there is value in "Emacs for scientists", "Emacs for programmers", "Emacs for writers" etc. – i.e. different defaults for different groups?

[Corwin] Implicitly, yes. My argument is that we should rethink the problem of building and maintaining Emacs configuration sets each time we assemble a team to work on something. That gives us a new chance, each time, to maybe produce new data that helps us make more informed decisions about how to make our own personal approaches more robust (and easier to read), but also to help "chip away" at the huge work of making Emacs more easily configurable for new users.

What is the background you are using? What is the tool you are using to present?

[Corwin] Wallpaper Engine on Steam is probably the thing that's grabbing attention. I haven't tried it under GNU/Linux. My family are (mostly) Windows users right now heavy sigh I don't want to get into my tool chain a huge amount, but I will talk about it some as/during the Welcome to the Dungeon talk tomorrow. For now I will say I'm using a mix of free (free and not-free but too easy to avoid tools on my one pretty good computer). I would love to have the time to invest to use more (only) free stuff but sometimes we can't afford the freedom, in terms of the learning curve. I think this is the most important problem space in free software, FWIW.

Notes

  • https://github.com/dungeon-mode/game co-founder
  • Initial "trolling" by showing presentation notes in different editors: vim, Notepad++, VS Code, Sublime Text.
  • LISP wasn't on the list.
  • Disagreement is not the barrier.
  • Emacs is threatening as something that addresses many different needs/use-cases.

Transcript

Following is a somewhat hasty self-transcription of my talk. Please don't hesitate to mailto:corwin@bru.st or to add any clarifications you feel helpful back into the EmacsConf wiki.

There is a visual gimmick underlaying the initial remarks.  We are
looking at the first (first-slide ("Welcome") showing how the org
markdown looks on other editors, including cygwin emacs, Notepad++,
Sublime, VS Code, and cygwin vim.  As each is closed we see the next,
until we reveal GUI Emacs running org-mode in a full-both frame.

My name is Corwin Brust and I will be talking about getting started with Emacs Today. I have been an Emacs user for a long time-

First of all thanks and a huge welcome to the conference..(15s)

On behalf of and back to the other organizers. It has been cool to have a peek backstage.

So. I've used a lot of different editors in my time. That's about 25 years as a professional software engineer. And most of that time I've been using Emacs. (~54s_)

I'll talk a little bit in a minute (if I can ever find my slides) about how I got into Emacs, but if you've used Emacs and a lot of other editors for a long time, something that you notice right away is that you get good with it in a way that stays meaningful. You learn new things, those things stick with you. You learn how to- how to make it do new tricks and then keep doing those tricks. (~1m26s_)

I want to mention this conference isn't about (whoops: "this talk") how to adjust your configuration specifically. I don't have a bunch of good code samples in here. There are a bunch of other great talks, especially Andrew's that I think may be aimed more at that "hey, I'm just getting started with Emacs what are some things to try to make it more comfortable for me starting?" [subject/audience? cezb]. (~2m07s_)

This is about how to think about the problem space more. (2m10s)

Hopefully a good way to warm up as we start thinking about some of the lightning talks later on. (I'm going to bring up my IRC buffer [offscreen] in case I run into time- I didn't get my stopwatch started for this one.) (2m25s)

So, alright: let's dive in. (2m30s)

We assume that we want to install packages, and maybe configure some features. This is particularly from the perspective of where we're working with a bunch of others on a team and we want to get something done. (2m42s)

Some of us probably have mature Emacs workflows, others may be installing it for the first time. (2m50s)

So the first questions is, you know- in that context: what's the value proposition? Why should I mess with my machine, my mature Emacs configuration, impose my way of thinking and ideas over the way somebody else is learning Emacs? (3m09m)

It can be [laugh] I'm off my slides here a little bit.. (3m13s)

It can be a little tricky to learn Emacs. One thing that helps us a lot is if people that we are working with can tell us, kinda, keystroke-for-keystroke at times what to do and explain what everything is doing. (3m30s)

And using the same packages as others can really help us working together on a project. (3m36s)

Speaking from my personal experience, it took me decades to get to the point where I was excited to program in Emacs Lisp. (3m26s)

I've programed in a lot of programming languages, but Lisp wasn't on my list. I looked at my config, that I was copy-pasting around from generation after generation of .emacs file or re-crafting it by hand and from Internet searches, to get things that I needed when I would quickly go install Emacs to start some new job or contract, and quickly get though that work-flow that caused me to go install the program. (4m15s)

You know, just simple little one-liners that got committed to memory over decades eventually just lead [me] to a sort of "hey, what's going on here". (4m27s)

And I credit my good friend Jeff Goff who died earlier in 2020 for my lifelong love of Emacs. Perhaps Erik and I will talk a little more about that at another talk we have scheduled but Jeff was a huge influence on us in a number of ways and a huge contributer to the Raku programming language which is very cool. (4m52s)

So, understanding how to make a good decision about splitting up configuration in a way to share it with people with really different uses of Emacs. That's actually a complicated topic, and I want to off and stare at it for a second: (5m11s)

I think Emacs is about people, so that means it is about community. And community means we're going to invite disagreement. In fact that disagreement isn't necessarily a road-block to our project, in fact that some of the work our project can invite us to do is to get closer to each other by inviting those disagreements, by learning from people of different styles, and from how they argue, and thinking about why they have that perspective and what technical benefits that perhaps radical point of view might carry away. Some people are really aggressive arguers others are very passive and really couch their ideas in distancing terms, "well probably this is a good idea" or "please double check me". Those don't always indicate how certain a person is. Because we're different. We have different ways of communicating ideas such as certainty or excitement. (6m23s)

When we thinking about a bunch of really diverse programmers approaching Emacs probably one of our first really big challenges is just to pick what we're going to go after. There are a number of existing kit installs and things like this. My argument is that you can get pretty far just trading files around. And maybe the more value conversation to have is making the hard decisions, e.g. "should we have vertical completion", should that be out of the box and those that want the traditional splayed-out over a sing line such as the mode line will have to add a line to their configuration. (_7m26s)

The way to get there?

How do we find out what works?

We don't want to slow down the people who are super productive with Emacs, and ask them to completely break their workflows to make it easier for new folks, at the same time we do want to make sure those new people. (7m42s)

At the same time, we do want to make sure those new people arre excited by Emacs and not turned off by having to learn the entire jungle of Emacs history in the form of it's unique technical stylings in terms of frames, buffers, and other unique Emacs viewpoints on interface concepts, especially. (8m15s)

The encouragement here is to keep using the project team as a crucible. Rather than following the defaults of, um, finding the simplest customizations that generally work, what if we tried to look for fairly specific configuration that we'll expect basically all of our developers to be using, at least when the submit bug reports. (8m48s)

In particular with this, I think that degree of experimentation can drive back into the Emacs development process. In the development mailing list.. [] In the context of Emacs development as a greater entity, we see this struggle. We have the sense that some things can "never" be change. I think one thing that can help us get there is evidence that says "hey, my 30-40 person team is using this set of bindings and here is what we learned about new Emacs users coming in and trying that". (10m)

So let's just recap real quick: in theory Emacs works out of the box. That means we are free to throw it all away and start over. [trouble with slides, again]

Our goal is to enable users- to unlock our computers, to do as much with them as possible. My work of encouragement is experiment with it. And think really specifically about how the development users may be different from each other, as you are configuring the development environment of emacs for developing on a project.

That's my talk, etc, answer any questions.(12m09s)

Do you use Emacs as a Community Building Tool? (13m15s)

Do /i/ use Emacs a community building tool? Or how do I use Emacs as a community building tool. [amin: "it doesn't say"]

Yes, absolutely. I think Emacs is an ambassador to the gnu tool-chain. in the fullness of time we will see an Emacs that will make others, Android and iOS, dream. That's why that mock us and say that Emacs is an operating system. It's because it could be, if cared for it to be. It's quite a threatening product in terms of the number of problem spaces it can address, how many types of users it can satisfy. (13m01s)

And the things that we can do to make it robust in those environments. We're always thinking about the weak points but is Emacs a community building tool? Heck yeah. (13m13s)

[we agree that I'll write my answers to the remaining questions, I say thanks more, and we're done. ps, I'll get to your question or comments I can find a response to within the next week, I expect]

Saturday, Nov 28 2020, ~10:48 AM - 10:58 AM EST
Saturday, Nov 28 2020, ~ 7:48 AM - 7:58 AM PST
Saturday, Nov 28 2020, ~ 3:48 PM - 3:58 PM UTC
Saturday, Nov 28 2020, ~ 4:48 PM - 4:58 PM CET
Saturday, Nov 28 2020, ~11:48 PM - 11:58 PM +08

Back to the schedule
Previous: Bard Bivou(m)acs - Building a bandcamp-like page for an album of music
Next: Beyond Vim and Emacs: A Scalable UI Paradigm