Hello! I'm going to talk about what I would like to see
in GNU Emacs in the future,
and what I would prefer not to find there.
This is all within the context
of GNU Emacs and its purpose.
GNU Emacs is a part of the GNU operating system,
and the purpose of the GNU operating system
is not simply to do a good job technically,
not simply to be good to use.
Its main purpose, its overall purpose,
is to give people freedom,
and to help them value and defend that freedom.
A GNU package, by being a convenient, well-written program,
should contribute to that overall ethical and social goal,
and not only to the usefulness of our software.
This is true for GNU Emacs
as much as it is for any other free program we’ve developed.
In fact, GNU Emacs is the first GNU program that I released.
I had written some other things before that,
but didn't release them at that time.
There was no particular use in doing so.
So it was through GNU Emacs
that I learned about various things
such as software licenses and how to defend freedom.
You're of course familiar with what GNU Emacs is today,
thanks to the contributions of thousands of other people
who came after me.
What would I like?
What would other people like?
Lots of people come to Emacs familiar with VS Code,
and they say, "Please make Emacs more like VS Code.
Change everything that you did in the 1980s and 90s
to be like that other thing."
That wouldn't be feasible even if we wanted to.
Our goal is not to be... not resembling VS Code.
Any resemblance is coincidental.
But in particular,
we do not want to have extension languages other than Lisp.
Emacs Lisp is the variant of Lisp
that we've always supported,
which has evolved along with Emacs.
We can conceivably have Scheme as well,
if we can sufficiently solve the problems,
the technical problems of making Scheme
and Emacs Lisp interoperate.
We did some design work, I think that was with Tom Lord,
whom the community will greatly miss.
In the 1990s, there are challenges that remain;
maybe it can be done.
But a non-Lispy language would be a mistake.
It would divert our development focus into areas
that we don't need, languages that are less powerful,
less beautiful, and less desirable for the purpose.
However, the language that we above all shouldn't support
is JavaScript. That's not because of the language itself.
I don't know the JavaScript language,
I've heard people say it's rather clumsy
and not well designed, but I don't know this.
In any case, it's not what my views are based on.
There's something much worse about JavaScript,
which is not the language itself, but how people use it.
Namely, it's been adopted as a way for a network server
to send a program to your machine
without your even noticing, so that this program,
written by you don't know who, will run on your computer
and do you don't know what.
And you're supposed to just trust
all and sundry developers of software
for the sites you visit,
which very commonly do malicious things, often unknown
to the people who are running the server itself.
They paid someone else to design a website
and they probably said, oh,
make it fashionable and attractive.
And they didn't insist, don't snoop on the visitors,
even if they understood what the issue was.
So these sites snoop. It's a serious problem.
The problem comes not from the language JavaScript,
but from the fact that browsers, by default,
will pull in JavaScript code that gets sent to them
and run it to do anything at all.
Emacs is supposed to defend your freedom.
It's supposed to help you to defend your freedom,
and lead you to defend your freedom,
which means it shouldn't lead you
to throw your freedom away as soon as you visit a site
that tries to send you a non-free program
to run straight off of that other machine.
So it's important not to lead users
to do computing this way.
So what are some good things
that we would want instead of this?
One thing we want
is to update the "Introduction to Emacs Lisp Programming"
by the late Bob Chassell.
It's a book that makes it easy for even non-programmers
to learn to write simple programs in Emacs Lisp.
And from there, they can go on to do better.
We made a pretty big change in Emacs Lisp
a few years ago, implementing lexical scoping by default.
Originally, Emacs Lisp used to be entirely dynamic scoping,
like some of the earliest Lisp interpreters.
This is a change that should have a careful job
of updating for the introduction.
I'm sure we've made it clear in the reference manual,
but that's not what beginners read first.
We need something to teach them in lexical scoping.
Another thing we could use is to make it easier
to understand the facilities that we have.
For instance, I think every package
that you might load into your Emacs and run
should have a name that helps you remember what job it does.
It doesn't have to be super long to tell you
what job that package does.
You can read the description to learn that.
But once you've read the description,
it should be memorable. When you see that name again,
you should realize, oh, that's the package I could use
to do "less" and so. We've had a tendency
to give packages names for the sake of pure wordplay
or lack of obvious meaning,
and I think we should add on, to those packages,
names that people will remember.
Also, there are ways we can simplify the command interface
of Emacs. For instance, there are many different parameters
users can specify that can have several values,
and sometimes you do various kinds of editing
in one session. That's normal in Emacs,
and you might want different parameter settings
for different kinds of editing.
So you specify parameter value A, do some editing,
you specify parameter value B, and do some editing,
and you'd switch back and forth, so you want
to switch back and forth between these parameters.
I think we should aim ...
People have added various commands to switch
between the last two or n values of this parameter,
and another command to switch
between the last two or n values of this [other] parameter,
and then that parameter, you know, and that parameter.
I think we should be able to have
a switch between the last n values command
that works on various different parameters,
and thus makes it easy to remember
that there is this facility.
Because right now the commands to do that are all ad-hoc,
and if you don't use a toggling among the last n values
of a given parameter, you won't know how to do it.
It won't be obvious that there is a way,
so you'd have to go to a suitable manual
and study for a while to think of that.
We could make this easily discoverable.
There is another kind of modularity that's important,
and that is modularity at the level of maintenance.
This is something all programmers know about, of course,
but in Emacs, various parts interact with other parts,
and we've tried to make them modular in design
by using lots of hooks,
but we haven't gone as far as we could.
With some effort, we could find calls
from over here to over there
that could be replaced by use of hooks,
so that we could reduce the extent
to which you need to know about one part of Emacs
to maintain another part of Emacs,
and I think that as we keep adding more facilities to Emacs,
this kind of modularity will be an investment that pays off.
There’s one big area of features
that I would like to see in Emacs,
and that's the ability to edit
formatted documents in WYSIWYG, to be able to edit
a letter or a scientific mathematical paper with formulas
or a nicely laid out manual,
looking at what it's really going to look like.
Now we have free software to do this.
For instance, I use LibreOffice some of the time.
Sometimes it's faster than writing something
to be formatted with a text formatter
and then formatting it. But when I use LibreOffice,
I always miss the commands and facilities,
the editing facilities of Emacs.
I'd like to have them both together, something with
the text formatting capabilities of LibreOffice
or even better of TeX, but the editing commands
and facilities of Emacs. This would be a big job,
but it can be made up of a lot of medium-sized jobs.
If people start working on those medium-sized jobs,
then in a number of years
we'll have something absolutely amazing.
But one thing I think we really shouldn't have
is the equivalent of a modern web browser.
The World Wide Web started out in the 1990s
in a much simpler form,
where a web page described its contents,
and the web browser laid them out,
and the user could parameterize
how to lay out various kinds of situations.
This was not only convenient for users
who wanted to control things and understand things,
it was also freedom-respecting
because the layout was done by your browser.
If you had a free browser, you were in control,
even though the browser was complicated already.
But starting around two decades ago,
there was an explosion in the complexity of browsers
as companies wanted to have more and more control
over exactly what would appear on a user's screen.
So they invented lots of features to control that,
features where the user couldn't really customize
how something would actually appear
because the whole point was that
the company could control that.
And JavaScript was sort of the ultimate level
of "the company controls everything."
Because of this, going beyond the simple level
of web page formatting features in Emacs
is basically heading down a path that leads to subjugation.
It's a path that we need to stay away from.
It's a path to an unjust world of computing
that you can easily see around you.
Web browsers nowadays are designed to display ads
that you may not want to see.
They're designed for DRM.
They're designed for companies to snoop on you
in unobvious ways. And all of that
we should protect ourselves from,
protect our users from.
So I hope that some of you will be enthusiastic
about some of these changes,
especially towards editing formatted text.
If you want to get involved, we have
a development discussion list called emacs-devel@gnu.org.
You can join that. You can also,
if you get interested in working on a package
and you're not an experienced Emacs Lisp developer,
it's a very good idea to look for an experienced developer
to talk with.
Make sure you can write programs in Emacs Lisp first.
It's not useful to take up the expert’s time learning that.
You can still learn it from the introduction.
But after that, when it's a matter of how to design
your favorite package, do have a discussion with developers.
They'll give you design ideas
that will help you make a package that we put into Emacs.
Now it's time for questions.