Re: "Why is emacs so square?"

[조성빈]

Po Lu <address@hidden> 작성:

> ndame <address@hidden> writes:
>
> > I agree that Emacs is easier to program once you learned it, but
> > other editors, like VSCode, has the advantage that you don't have to
> > learn a quirky and unfamiliar language first.
>
> > Many developers know Javascript and even if one doesn't it's more similar
> > to mainstream languages than lisp, so extension writers mostly has to
> > learn the VSCode API only.
>
> Here's the problem: You have to learn the VS Code API. I'd say learning
> that, and becoming reasonably proficient at it takes longer than
> skimming through the Emacs Lisp intro.

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.

> > VScode has a very nice out of the box experience. If you want support
> > for a language then it's one click to install it and it installs the
> > necessary scaffolding too, like a language server for the language.
>
> We have several starter packs, with similarly nice OOTB experiences.

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

> > And it has Electron for display support which has a mature browser
> > engine behind it, so it can support advanced graphics features out
> > of the box on all the supported platforms.
>
> Electron is not free software (https://labs.parabola.nu/issues/1167),
> and is definitely not as well suited to providing an integrated
> experience like Emacs.

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.

> For instance, even if you render raw HTML inside VS Code, you would not
> be able to grab the region using VSC APIs.  I'm not sure if the VSC API
> allows interacting with the DOM, but from what I can tell, it can't.
>
> There are also various other issues, with relying on a lower-level
> abstraction for "nice graphics features" (the DOM) that is outside the
> editors control.
>
> > Out of the box experience matters. Familiarity matters (e.g supporting
> > standard keys on the platfrom for cut and paste). Nice appearance matters.
>
> We have Cua mode.  No, you don't need to have it enabled by default,
> since it would result in unnecessary breakage for old users.  It would
> be nice if the startup screen informed users of features such as the
> (hypothetical) GTK theme previously mentioned, and Cua.
>
> I personally think that the Emacs bindings are better, and in the end
> work better with Emacs itself, but I do agree that newcomers should be
> allowed to familiarize themselves with Emacs before moving their
> workflow (and habits) to it entirely.
>
> > No wonder lot of developers choose VScode:
> > https://trends.google.com/trends/explore?geo=US&q=emacs%20editor,visual%20studio%20code
>
> We're here to change that :)