emacs-devel
[Top][All Lists]
Advanced

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

Re: New maintainer


From: John Wiegley
Subject: Re: New maintainer
Date: Sun, 04 Oct 2015 14:41:11 -0700
User-agent: Gnus/5.13 (Gnus v5.13) Emacs/24.5 (darwin)

>>>>> Richard Stallman <address@hidden> writes:

> We have a deep disagreement, and neither of us is likely to change position
> on the issue. However, that disagreement does not necessarily mean you can't
> be a maintainer, because all the GNU Project really needs from a maintainer
> is to engage to carry out the maintainer's responsibility. So it is comes
> down to your decision about that.

> In practice, the parts of the responsibility that you'd need to reconcile
> with your views are (1) accepting changes that work only on GNU or GNU-like
> systems without reluctance, so as not to hold back the advance of Emacs on
> those systems with contributions from people who may not use or care about
> Windows or MacOS, and (2) and cooperating with the things we do to present
> the GNU Project's positions in the Emacs distribution itself (for instance,
> some material in etc and doc).

Thanks, Richard, that's really quite reasonable.

There is one technical matter that's been brought to my attention that I would
like to get your thoughts on:

In Emacs' future, I'd like to improve the way that external processes are used
to inform Emacs about the syntax and semantics of buffer contents. For
example, building completion lists, indexing code locations, looking up or
rendering documentation, etc.

I would like to achieve this in a general way, such that both GPL and non-GPL
software can be freely chosen by the Emacs user. For example, in C++ mode, one
could use either GCC or Clang (or both) to determine type information. It's
fine with me if only GCC support is actively endorsed, so long as the Clang
solution is equally feasible -- provided volunteers want to contribute to it,
and without detracting from the GCC support.

Some have told me off-list that you might be reluctant to allow even the
possibility of Clang being used in this scenario, since it might encourage use
of non-GNU software should its support prove superior. Since that doesn't seem
quite in keeping with the rational tone I read in your e-mail, I wanted to
check with you directly.

I can appreciate wanting Emacs to be a flagship GNU project, and to ensure
that GNU-favored technologies are not in any way damaged by supporting non-GNU
solutions. What I wonder is, if support for either option can be made purely a
matter of the user's choosing, without affecting Emacs' ability to make use of
GNU solutions, would this be opposed?

John



reply via email to

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