Re: "Why is emacs so square?"

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

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

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