[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 16:45:28 +0900

Po Lu <address@hidden> 작성:

조성빈 <address@hidden> writes:

Emacs Lisp as a language and the standard library (the Emacs API) is
different. For example, the fact that functions and variables have their
own namespaces is a part of the language, and the functions
self-insert-command or bury-buffer are parts of the API.

Do buffer-local variables count as part of the language, or part of the
API? What about text properties in strings? File-local variables?
Primitives like `record_unwind_protect_excursion`? Or how the bytecode
interpreter has a plethora of primitives that only make sense within

And I would consider `self-insert-command' part of Emacs Lisp the
language, since it is implemented as a subr in C code.

I was arguing that the surface area of Emacs is not smaller than VSCode,
which makes the exact classification unnecessary.

(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…)

You can call them as a whole Emacs Lisp, but that doesn’t mean that
it’s more easier/simple than VSCode. Yes, Emacs Lisp isn’t a complex
language like C++, but for outsiders that have never used Lisp, it’s
hard to approach.

It's not hard to approach at all.  The easy trick is to treat it as an
editor macro language, instead of a Lisp dialect.

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

Regardless, Emacs can’t stop using Emacs Lisp, so Emacs needs to be the
reason for users to use Emacs Lisp, not backwards. And that means that
Emacs should have a great onboarding experience (which is currently not true) with various packages for so many languages and productivity tools (which is
IMHO true considering all of the packages in GitHub).

Emacs Lisp (more precisely, the first-class extensiblity) is one of the
main reasons to choose Emacs, and the onboarding experience is exactly
what we're talking about.

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 experience
is really about Emacs Lisp - users don’t try to add keybindings or custom
functions on the first day of use.

I know, I should report it, but I find that macOS/Windows is considered a
second-platform here, and I didn't want to take my time writing reports just
to get no feedback. I’ll try to report some today.

macOS/Windows are considered second-class platforms, when it comes to
features: features not available on free operating systems will not be
available on non-free systems.  macOS/Windows are not second-class
platforms, when it comes to fixing bugs not present on free operating

(TBF, I remember trying to report them, searching for duplicates, and
I saw some
bug report on the exact same issue I was experiencing. I didn’t know how to
subscribe, so I just thought that it might get fixed.)

Hm, you can always M-x report-emacs-bug

reply via email to

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