[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 15:32:40 +0900

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:

We're here to change that :)

reply via email to

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