[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:04:01 +0900

Po Lu <address@hidden> 작성:

조성빈 <address@hidden> writes:

Skimming the Emacs Lisp intro doesn’t make one reasonably proficient in
programming Emacs packages though. For one to understand how Emacs works
(with it’s obscure naming scheme like windows), one has to jump a lot of
hoops, and I can guarantee that one who is familiar with Algol-family
languages can pick up the VSCode API much faster than picking up Lisp,
Emacs, and the Emacs API.

This is what gets interesting: Emacs Lisp is a language in it's own
right, and the "Emacs API" is the Emacs Lisp language.  Emacs Lisp is
also a rather small and simple language.

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.

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.

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).

You don't have to pick up "Lisp", or the Emacs "API", you only
pick up Emacs Lisp.

But the default Emacs doesn’t have that, and that’s the problem.
Which means that, for one to have nice OOTB experiences, one has to have
a really good reason to use Emacs (like learning Common Lisp), then google
how to configure Emacs, then encounter Spacemacs without knowing anything
about evil or helm or ivy. And proficient Emacs users usually recommend
not using a starter kit in the internet. (That’s my experience on trying
to use Emacs.)

We could put a link to them somewhere, but that's probably something for
RMS to decide.

Yes, it would be very useful if we can include some links to the starter kits. Also, it would be great if Emacs can have a default init.el that gets generated
when there is no one, so that first time users don’t get a bad impression.

I don’t think OP was saying that we should use Electron for Emacs, but more that due to using Electron, it gives the stability that Emacs doesn’t give. Maybe you’ve only used Emacs on Linux, but at least on macOS, Emacs glitches,
locks, and crashes very frequently, and that’s a non-starter for a lot
of people.

If it "glitches, crashes, locks", that's a bug, and instead of treating
it as a fact, report it.

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.

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

Plus, I know a lot of people who use Emacs on
macOS, and I even had to use Emacs on Windows a long time back, and
Emacs has always been rather solid.  The starter packs are also supposed
to work well, and it might also be a problem with your own config.

OTOH, Lisp code shouldn't be able to make Emacs crash (unless you're
doing stuff like running invalid bytecode, or overflowing the GC stack),
and if it does, it's also a bug that should be fixed.

reply via email to

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