[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Emacs contributions, C and Lisp
From: |
Karl Fogel |
Subject: |
Re: Emacs contributions, C and Lisp |
Date: |
Fri, 09 Jan 2015 16:34:31 -0600 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux) |
Richard Stallman <address@hidden> writes:
>We were talking about completion -- you are changing the subject,
>taking my statements out of context to make a false attack.
>
>This is an example of your general approach. You (this means several
>people) are not trying to help me make the right decision. Rather you
>are trying to pressure me to do what you want, at the expense of
>something I consider important.
>
>The result of this is that I don't trust your judgment about anything
>related to this issue.
>
>I will try to find out more about these refactoring practices --
>privately, with people I have confidence in, that have no axe to
>grind.
>
>To approach the issue without prejudice, I will need to prevent
>resentment for your pressure campaign from influencing me. To help me
>overcome it, you would do well to drop the issue right now.
Richard, this is a very unfair characterization of what Perry has been saying.
He's not changing the subject by talking about features other than completion.
For quite a while now this thread's topic has been about all the features that
modern IDEs provide, and that Emacs currently has trouble providing (with the
data handed to it by GCC). Perry's points are made in that context. If you're
having trouble tracking the context, that's okay, just say so -- people will be
glad to help. But please don't make these kinds of accusations against Perry.
Perry has very patiently explained how he *does* understand your goals and
shares them, and he has explained why he thinks his proposed course of action
serves those goals better. He's actually gone into much more detail than
really should be needed, since for some reason you have not been willing to
acknowledge that at least *in principle* his point might have merit.
But not just in principle. I think he is actually right: the cause of freedom
would be better served by the course he and others here are advocating.
Everyone here understands the tradeoff: there is an inherent tension between
promoting freedom by building a protective wall around our city, and promoting
freedom by interoperating with non-free environments so that people in those
environments have a chance to experience freedom. Historically, the FSF has
used both strategies -- so you, too, understand this tradeoff.
For some reason you refuse to acknowledge that others are cognizant of this
tradeoff. They have been very patiently making a detailed argument for why, in
this particular case, you are choosing the wrong side of that tradeoff -- the
side that will be *less* effective at accomplishing our shared goal. They make
this argument, with impressive clarity, and then you accuse them of bad faith.
This would be poor behavior even if those people were wrong. I think they're
actually right, though, which makes it even worse, because now our goal is
being damaged too.
In a later message, Perry wrote one thing I disagree with:
> Dare I say there is a freedom issue here? Many people -- you have
> heard from the in this thread -- would very much like to have
> information that the compiler has available inside their editor. You,
> as the software vendor, for purposes that I will admit are well
> intentioned, wish to prohibit that. Naturally, people find this
> frustrating, for the same reason you might yourself find it
> frustrating.
There is no "freedom issue" in the sense he meant. GCC is still Free Software,
and anyone is free to fork it -- by which I mean, any one is free to try to
create a socially and technically credible copy of the GCC project, one that
attracts a majority of GCC developers as contributors, and is not restricted by
your decisions.
We know it's possible; after all, it's happened before. But the fact that no
one has yet stepped up to do it in this case is their problem, not yours.
You're not denying anyone's freedom. However, you're making such a fork more
likely, and for poor reasons. If you took Perry's advice, freedom would be
better served.
-Karl
- Re: Emacs contributions, C and Lisp, (continued)
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2015/01/09
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/09
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2015/01/10
- Re: Emacs contributions, C and Lisp, Daniel Colascione, 2015/01/10
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2015/01/12
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/10
- Re: Emacs contributions, C and Lisp, David Kastrup, 2015/01/10
- Re: Emacs contributions, C and Lisp, Thien-Thi Nguyen, 2015/01/11
- Re: Emacs contributions, C and Lisp, David Kastrup, 2015/01/09
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/09
- Re: Emacs contributions, C and Lisp,
Karl Fogel <=
- Re: Emacs contributions, C and Lisp, Richard Stallman, 2015/01/10
- Re: Emacs contributions, C and Lisp, Dmitry Gutov, 2015/01/10
- Re: Emacs contributions, C and Lisp, Eric Ludlam, 2015/01/10
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/09
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/08
- Re: Emacs contributions, C and Lisp, Stefan Monnier, 2015/01/08
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/08
- Re: Emacs contributions, C and Lisp, David Kastrup, 2015/01/08
- Re: Emacs contributions, C and Lisp, Eli Zaretskii, 2015/01/08
- Re: Emacs contributions, C and Lisp, Perry E. Metzger, 2015/01/08