[Top][All Lists]

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: "Why is emacs so square?"

From: 조성빈
Subject: Re: "Why is emacs so square?"
Date: Sun, 19 Apr 2020 21:07:37 +0900

Po Lu <address@hidden> 작성:

조성빈 <address@hidden> writes:

(FYI, I count buffer-local vars as a property of the runtime, text
properties are definitely an Emacs API, and `record_unwind_protect_excursion`
or other primitives, subrs like `self-insert-command` written in C are all
Emacs APIs. The language are things like if-expressions, macros,
symbols, etc…)

Here's the problem: primitives like buffer-local variables, text
properties, and record_unwind_protect_excursion, and self-insert-command
all depend on Emacs concepts such as "buffers", "windows", "frames" and
on and on.  All of these are implemented as language primitives (and in
many cases, 'properties of the runtime', et cetera).  The Lisp
interpreter itself intermingles with "editor" code in a highly haphazard
and ad-hoc way, with many "APIs" being implemented as core language

My view is: if the language still makes sense when X construct is
removed, X construct is considered outside the language.  If it doesn't,
X is part of the language.

I personally think that various Emacs APIs regarding buffers, etc… is not
part of the language, but that’s just my opinion.

I spread Emacs to my friends. Unless ones who already know Common Lisp,
almost everyone feels that Emacs Lisp is a big hoop.

You're not spreading it right, then :)
The Eintr teaches Emacs Lisp to non-programmers very well.  It also
teaches them how to extend the editor, in a straight-forward and
easy-to-understand way.

No, people shouldn't need to learn a new language to use an editor.
In the ideal world, normal people should be able to use package.el and
custom.el to use Emacs without much fuss, and some people that is
interested in can develop packages.

It’s just that Emacs practically needs configuration to be usable - which
means that one must learn Emacs lisp.

Yes, Eintr teaches Emacs Lisp well, but that step should be optional.

First class extensibility is probably one of the big reason to use Emacs, but
that’s orthogonal to Emacs Lisp. And I can’t say that the onboarding
is really about Emacs Lisp - users don’t try to add keybindings or custom
functions on the first day of use.

The reason Emacs extensiblity is so first-class is because functionality
for extending Emacs are implemented as primitives in the editor, and are
not "APIs" grafted on top of other languages, such as VS Code or

reply via email to

[Prev in Thread] Current Thread [Next in Thread]