summaryrefslogtreecommitdiffstats
path: root/2023/talks/core.md
blob: 77584a84c5fcfc2006279f768374d1a15dc8e2d5 (plain) (blame)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
88
89
90
91
92
93
94
95
96
97
98
99
100
101
102
103
104
105
106
107
108
109
110
111
112
113
114
115
116
117
118
119
120
121
122
123
124
125
126
127
128
129
130
131
132
133
134
135
136
137
138
139
140
141
142
143
144
145
146
147
148
149
150
151
152
153
154
155
156
157
158
159
160
161
162
163
164
165
166
167
168
169
170
171
[[!meta title="Emacs core development: how it works"]]
[[!meta copyright="Copyright © 2023 Stefan Kangas"]]
[[!inline pages="internal(2023/info/core-nav)" raw="yes"]]

<!-- Initially generated with emacsconf-publish-talk-page and then left alone for manual editing -->
<!-- You can manually edit this file to update the abstract, add links, etc. --->


# Emacs core development: how it works
Stefan Kangas

[[!inline pages="internal(2023/info/core-before)" raw="yes"]]

-   Why it is fun and exciting to contribute to Emacs
    -   We have easy bugs that anyone can fix, in random packages
    -   And extremely hard ones for experts in things like garbage
        collection, and compilers
-   We are not scary, in fact working to build a welcoming culture.
-   The nature of a public list
    -   Don't listen to random people being negative or hostile
    -   No response is not necessarily a bad thing
-   Cultural aspects of emacs-devel vs GitHub
-   How to behave (be polite, etc.)
-   Email vs forge, help wanted.
-   Why copyright assignment
-   Plans for Emacs 30 (maybe) - needs coordinating with Eli

If I have more time, I'd like to cover more things, for example:

-   GNU ELPA vs NonGNU ELPA - why and how
    -   Our plans for GNU ELPA going forward (bundle stuff in tarballs)
-   The future of Emacs: a vision

Basically, I want to do everything I can to inspire people to join core
development and to lower the barrier to participating.  In effect trying
to work on "bridging the gap" that we have identified exists between
emacs-devel and the community.

About the speaker:

Stefan Kangas is one of the Emacs core maintainers.


# Discussion

## Questions and answers

-   Q:Can you tell us some about your background with Emacs development
    and programming in general (your professional work possibly)?
    -   A: studied CompSci at university.  started programming on a
        Commodore 64, then C, Perl, and so on
-   Q: Do you think that one day, there will be a "native" graphical
    web browser in Emacs or is it kind of against its philosophy and
    architecture? So will we stick just with EWW and EAF or similar
    workaround tricks?
    -   A: Proper HTML rendering in Emacs is a dream right now
-   Q: Emacs development and communication still is very much focused on
    E-Mail mailing lists. I like this. But what do you think about
    introducing other channels for talking to users? E.g., the Emacs
    project/ community could set up a Mastodon instance of its own etc.
    -   A:
-   Q: What are some features or packages you'd like to see developed
    by the community?
    -   A: Some of the things that Stefan would like to see happen right
        now
        -   treesitter: improving and working on new modes
        -   refactoring capabilities in Emacs
-   Q: What is the hardest decision being made within Emacs-dev for last
    three years?
    -   A:
-   Q: Any plans to integrate EXWM into core? Emacs is a really good WM.
    -   A:
-   Q: Do you think it is a good idea to choose Org-mode for writing
    documentation instead of Texinfo?
    -   A
-   Q: What do you plan to work on in Emacs core in the future?
    -   A:
-   Q: What do you use Emacs for in your life, other than working on
    Emacs itself?
    -   A: Programming, obviously (Stefan works as a programmer). 
        org-mode (including to prepare this talk), for productivity, rss
        reader, emails.
-   Q: What could we do in order to make Emacs more attractive for
    younger users?
    -   A: 
-   Q: How are we going to make sure that the cool idea is going to pass
    it through for the next generation, let's say 20 years later, that
    generation still have the good knowledge we have today.
    -   A:
-   Q: If you're willing to discuss it, what do you think about the
    recent controversy about use of cl-lib in Emacs core code?
    -   A: Stefan's opinion is on emacs-devel.
-   Q: When we find a bug, in our emacs.... do we need to try to
    replicate it on the sid version (debian/sid=1:29.1+1-5 at ehe time
    of writing), then update all the usual lisp package we use... and
    if we succeed to replicate the bug in this version, only then go to
    the development version 30 and do the same ? Then only, ask for
    assistance in reporting the bug we found ("M-x report-emacs-bug" 
    will be sufficient ) ?
    -   A: (Answering for Stefan, because information about how to
        report Emacs bugs is widely available, including in Emacs's own
        documentation: You should try to reproduce it on the latest
        released version of Emacs, with a clean Emacs configuration
        (i.e. "emacs -q"), before reporting.  And you should look for
        existing bug reports on the tracker.  If you have extra time,
        consider trying to reproduce it on the master branch or the
        branch for the next release as well.  And if you're sure
        you've found a bug, be sure to report it using "M-x
        report-emacs-bug" rather than just emailing emacs-devel about
        it.)
-   Q: On branching off sub-threads. I note that they are less visible
    compared to starting a new thread in practice. I am wondering if it
    is just my impression or something devs also observe.
    -   A:
-   Q: What about rewriting emacs in Rust? Use guile instead of elisp?
    Multi-threaded emacs? Make emacs prettier and shiny? And of course,
    sane defaults! Just kidding. We are spoiled children because you and
    Eli, Lars, etc. do an impressive work. I live in Emacs since 2001.
    Thanks!
    -   A:
-   Q: The only downside I see with copyright assignment is that one has
    to disclose their real identity. Would it be a possibility to assign
    copyright under a nickname?
    -   A: (not the speaker) FSF said they can publish a pseudonym but
        need the actual identity in their paperwork, which will be
        presumably protected, but it's not totally anonymous.
        -   (AFAIK from Bastien) The actual FSF assignee list is not
            public - I know that it is available to maintainers, but
            must not be shared.
-   Q:Do you think it is possible to reach an agreement on sane defaults
    for better out of the box experience?
    -   A: It's more of a social problem than a technical problem (my
        sane defaults might not be yours).
-   Q:Will xwidgets have a future? Seeing the new bugs popping up in the
    latest xwidget dev.
    -   A:
-   Q: Have you voted for Emacs as the software of the year on the
    Tuxies by Jupiter Broadcasting? I did, because Emacs 29 is great!
    Thank you! :-)

## Notes

-   Cambrian explosion of packages (5000 packages in MELPA)
    -   GNU ELPA <- generally better if someday it might be good to
        ship it with Emacs
    -   João Távora (Eglot author): haven't seen a problem with
        copyright assignment
        -   To be fair, it does happen in certain cases. But
            infrequently.
    -   New package archive NonGNU ELPA is now enabled by default, no
        copyright assignment needed
-   Emacs is hackable. I think that's a blessing and a curse. The types
    of choices you can make when you implement... Different choices
    between things like Common Lisp and Scheme. I think we have that
    kind of tensions within Emacs. These are good discussions to have. I
    think what will never change is that Emacs is hackable. Emacs is
    customizable. This is what's bringing you that amazing user
    experience. The flip side is that it's easy to hack around bugs
    instead of fixing them. Or we accept limitations in Emacs core. I
    think we could get better at taking those few extra steps to make
    Emacs better for all users.
- Thank you Stefan! That was all really cool! :D
- thank you you guys it's fantastic
- thank you guys to say you amazing is to not give you enough


[[!inline pages="internal(2023/info/core-after)" raw="yes"]]

[[!inline pages="internal(2023/info/core-nav)" raw="yes"]]