emacs-devel
[Top][All Lists]
Advanced

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

Re: Proposal for an Emacs User Survey


From: Marcel Ventosa
Subject: Re: Proposal for an Emacs User Survey
Date: Sat, 17 Oct 2020 18:40:36 +0700

On Fri, 16 Oct 2020 22:08:01 +0300
Dmitry Gutov <dgutov@yandex.ru> wrote:

> >> You can't be effective at affecting change anyway, if you don't
> >> know what's going on outside.  
> > 
> > Indeed. As I recall, RMS suggested open questions instead of
> > multiple choice questions that "shape their behavior". With open
> > questions, there is no need to mention MELPA at all in fact. With
> > open questions, the insights that could be derived would be much
> > more interesting.  
> 
> So we won't suggest ELPA as an option either? What about the users
> who don't know the difference? MELPA is also an ELPA, after all (as
> in "Emacs Lisp Package Archive").

Is it a survey then or is it an opportunity to "educate/advertise?"

> > I
> > would think it should be guided, for the most part, by what the people
> > putting their time into it want to create, within the principles of the
> > philosophy of the project and its goals.  

> It's not a painting or a novel. It's a software project, with certain 
> expectations of practicality.

Are you claiming Emacs is not practical?

> > If they are not, Emacs makes it quite simple to implement changes for
> > personal "improvements". I have written functions that serve me
> > personally and change the behavior of Emacs to suit my needs. There are
> > limits to what I can do, which could be pushed if I dedicated a greater
> > effort to do so. How is that unfair?  

> You're veering the discussion off to the side for some reason.

I'm explaining how easy it is to modify Emacs to suit particular needs,
and listing the possibilities that already exist for doing so.

> But if we're talking of "unfair", releasing Emacs under GPL, enabling 
> such excellent extensibility that multiple communities spring up over 
> years, ones brimming with creativity and people dedicating years of 
> their spare time to the extensions, and then badmouthing them from afar 
> as though they violated some existing contract (social or legal), *that* 
> is unfair.

It is GNU policy not to promote or encourage proprietary software. To
the extent that any community does so, GNU must not promote or encourage
that community. You mentioned it's a matter of 2 or 3 packages that
recommend proprietary software, so the current impasse should be very
easy to fix. I fail to see what injustice has been perpetrated on the
MELPA maintainers here, or how they have been badmouthed.



reply via email to

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