Re: Is Elisp really that slow?

[Ergus <spacibba@aol.com>]

On Thu, May 16, 2019 at 05:12:22PM +0300, Eli Zaretskii wrote:
>> Date: Wed, 15 May 2019 23:09:24 +0200
>> From: Ergus <spacibba@aol.com>
>> Cc: help-gnu-emacs@gnu.org
>>

Hi Eli. Sorry, maybe this email sounds stronger than the intention.

>> We are far from becoming a toxic community, but new/different ideas are
>> not really very welcome and sometimes the arguments are like "it has
>> always been like that", "old users don't want that change".
>
>Really?  You've just went through a process of proposing and
>implementing a new feature -- did you feel your idea was "not really
>welcome"?
>
Actually fill-column-indicator was something that many people were using
(with the package) but it doesn't affect the global behavior at
all. Actually I think that most of the users won't even know that the
functionality will be there probably until emacs 30 when the
fill-column-indicator package just stop working or so. But also it was
an addition. Adding features to emacs is something easy from the mailing
list point of view. Actually we something is added that solves N
problems that nobody complained before (as fci) then automatically
appears some mails claiming that it must solve P other issues to no body
have complained either.

But when we mention (propose, suggest) to do any change in the defaults
or remove obsolete functionalities to promote new ones, or change old
features to add more modern ones... the mailing list starts becoming
crazy. Just give a look what happen when I just mention the C-c C-c
example. So at the end everything goes in and nothing goes out... that's
unmaintainable YKWIM.

>> The conservative attitude in emacs development group (apart from the
>> technical obstacles like the workflow and the paperwork and so on) gives
>> the idea of a closed environment (that actually it is from the
>> development point of view because we are like frozen in the past) where
>> only very experts are welcome (that's the vision people have from
>> outside) so very few melpa developers are really interested to face all
>> those issues to contribute.
>
>Is this your experience from implementing the fill-column indicator?
>If so, how do you explain that you, as a relative non-expert, were
>welcome in that case?
>
I put explicitly: that's the vision people have from outside.

Actually I was surprised that you were son kind, and patient with all
the emails and questions. But again fci does not affect anyone that does
not enable it, and actually the reddit post just received a couple of
comments. So actually it is a specific functionality that maybe
shouldn't have been added because there was not interest on it.

But any proposals that potentially change any default or break any
backward compatibility or even correct previous mistakes or update some
behavior are actually like a bomb in the mailing list.

Just give a look how long it took to enable delete-selection-mode or
transient-mark-mode since they were implemented and proposed the first
time. But also the new behaviors as they need to be optional, many
functions need to check a lot of conditional to work in all the
situations.

Just give a look how many good packages are in melpa, but not in elpa
in spite of they are totally free with no dependencies and their
maintainers are very active, and the communities too. (elpy, slime,
helm, company, swiper-avy-counsel...).