emacs-devel
[Top][All Lists]
Advanced

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

Re: Emacs contributions, C and Lisp


From: David Kastrup
Subject: Re: Emacs contributions, C and Lisp
Date: Fri, 09 Jan 2015 19:27:53 +0100
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/25.0.50 (gnu/linux)

Richard Stallman <address@hidden> writes:

> [[[ To any NSA and FBI agents reading my email: please consider    ]]]
> [[[ whether defending the US Constitution against all enemies,     ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
>   > There are refactorings that are impossible
>
> We were talking about completion -- you are changing the subject,
> taking my statements out of context to make a false attack.

I think that is an unfair characterization: the strictly limited idea of
completion in this thread has admittedly moved a bit to the background
in the course of the discussion, but I don't think that this has been
either a conscious strategy nor has it been Perry's "doing".

> 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.

I think the salient point here was that we currently have a problem with
implementing reliable and powerful versions of completion with awkwardly
complex languages like C++ that, for better or worse, are _supposed_ to
be well-supported by GNU.

However, the effort of tackling this problem is quite similar to a
number of other problems that _are_ being successfully addressed by IDEs
other than Emacs, and I think that if addressing them by GNU software is
to be an option, we need to provide the freedom for experimenting with
integration of GCC without close supervision.

Admittedly, the imminent project right now seems to be completion.  I am
somewhat afraid that by the time we have finished the spec books for
getting, more or less, the permission for implementing the technical
measures on track, there will be nobody bothering to pick them up.

> 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.

Shrug.  I don't see that the "axe to grind" here is one directed against
the goals of the GNU project.  Some people might not be interested in
the full view of all goals, and some might come to different conclusions
about them.  In the end, we can only implement one strategy, but that
does not make people making different proposals an enemy of the project.

> 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.

That might well be the case: you probably know yourself best.  It's
still another constraint that might not be easy to properly factor in
for some project members, and the facilities needed for that are
non-technical and not necessarily a strong skill of typical competent
hackers.

-- 
David Kastrup



reply via email to

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