emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Elisp LSP Server


From: Ag Ibragimov
Subject: Re: Elisp LSP Server
Date: Tue, 12 Oct 2021 22:42:31 -0500

Richard Stallman <rms@gnu.org> writes:

> Our work proceeds by replacing nonfree programs.  Why do that?
> Because each one is an injustice -- denies freedom to its users by
> giving its developer power over them.  A nonfree program is not an
> inferior solution; it is a problem.  We can fix that problem by
> replacing it with free software, so that it can't do wrong to people
> any more.
>
> When we can't supersede a particular nonfree program in the near
> future, we should be careful not to be led into enhancing its use.
> Thus, when someone says, "Let's implement XYZ; it will be convenient
> for users that want to do ABC," we must ask: What is ABC, and is
> making ABC more convenient a good thing?

> Popular nonfree programs have many users, and they will innocently
> suggest we direct our work to make their use of nonfree software more
> convenient.  I don't blame them for suggesting this, but it is not
> what we should do.
>
> We have to do careful thinking about what constitutes progress in this
> particular situation.  We have to find the various options --
> including mixtures of the obvious options -- and think about what good
> and bad effects they would have.  Finding the right choice may be
> subtle and complex.
>
> But we can't find the right choice if we don't evaluate it based on
> the right values and goals.  Facilitating the use of VS Code or GitHub
> is not a goal; encouraging people to stop using them is a goal.
>

I profoundly appreciate you for graciously explaining this all. I
understand the points, and I don't think I'm in complete disagreement
with them. My mistake was to speculate about an idea. Which, upon the
materialization (if ever happens), may or may not be efficacious and
valuable for Emacs users. But my greatest mistake was to suggest that it
could potentially bring convenience to users of nonfree
services and proprietary software.

To be clear, I wasn't suggesting that someone should work on it. I was
merely curious if anyone had attempted to build it. And the potential
technical challenges to watch for.

I still think that there's a significant utilitarian value of simply
consolidating and unifying numerous different dissimilarities existing
today for different programming languages in Emacs. Polyglot programming
has become a norm in the industry, and sadly, Emacs has earned quite an
infamous reputation for being difficult to learn. And programming
language books and tutorials, sometimes even after acknowledging the
incredible power of Emacs and recommending to learn it, often warn the
learners to avoid making the mistake of trying to learn both the
language and Emacs simultaneously.

And as I mentioned before, even experienced users of Emacs often have to
abandon it after fruitless attempts to make it work nicely with a
different language. Something simple as: "it keeps screwing up the
formatting" can become the source of enormous frustration.

But finally, eglot and lsp-mode started challenging this status-quo. And
I honestly think we should embrace these efforts and pave the way for
Emacs to become the ultimate, egalitarian programming environment for
everyone. I hate to bring this up again, but VSCode (if you haven't yet
noticed) is already ahead of us in this competition. No, I don't think
I'm exaggerating. I think it's an accurate assessment. Yes, Emacs still
has a few cards up the sleeve, but for how long?

You have had witnessed the rise and fall of legendary Lisp machines with
your own eyes. And I think Emacs, even though maybe not ideal, but
indeed the best "Lisp machine" that we have today. And I don't think
Emacs is guaranteed not to face a similar fate. 

I'm sure people would use classic counter-argumentation like: "it's not
a sprint, it's a marathon. Just wait another twenty years, and you'd
see...", and I have used the same argument many times myself. But the
pace of growth and expansion of VSCode, various plugins, and services
that support it come across as almost unprecedented.

Unfortunately, I cannot offer you sound, reasonable suggestions that are
guaranteed not to challenge to the slightest your firm beliefs and
uncompromising philosophy, and I wouldn't even try. But I plead you to
take this adversary seriously, and I am pretty sure I am not the first
one to do that. We probably need a better strategy. Better than just:
"encouraging people to stop using them is a goal".

Thank you.



reply via email to

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