Re: "Why is emacs so square?"

[조성빈 <pcr910303@icloud.com>]

Po Lu <luangruo@yahoo.com> 작성:

> 조성빈 <pcr910303@icloud.com> 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.