Re: "Why is emacs so square?"

[조성빈]

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
> Emacs.
>
> 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
> systems.
>
> > (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