Re: Brand new clojure support in Emacs ;-)

[Lynn Winebarger]

On Sun, Sep 3, 2023 at 1:27 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > From: Lynn Winebarger <owinebar@gmail.com>
> > Date: Sun, 3 Sep 2023 13:16:40 -0400
> > Cc: casouri@gmail.com, danny@dfreeman.email, joaotavora@gmail.com,
> >       dmitry@gutov.dev, rms@gnu.org, emacs-devel@gnu.org
> >
> > On Sun, Sep 3, 2023 at 1:02 PM Eli Zaretskii <eliz@gnu.org> wrote:
> > > > From: Lynn Winebarger <owinebar@gmail.com>
> > > > Date: Sun, 3 Sep 2023 12:53:11 -0400
> > > >
> > > > > No one who speaks for the project suggested anything like that.  It's
> > > > > a non-issue.
> > > > >
> > > > So, does RMS not speak for the project?
> > >
> > > Sometimes he does, sometimes he doesn't.  Like all of us: sometimes we
> > > just express a non-obligatory opinions, sometimes we describe a
> > > decision made for the project as a whole.  There's no one answer; you
> > > need to read the fine print.
> > >
> > > > Am I misreading his message:
> > > > https://lists.gnu.org/archive/html/emacs-devel/2023-08/msg01063.html ?
> > >
> > > If you think he was saying we will necessarily call our mode
> > > clojure-mode, then yes, I believe you are misreading it.  From where I
> > > stand, Richard was describing a way to avoid a name conflict.
> >
> > I was rebutting the phrase "suggested anything like that" above.
>
> Why would you?  What good would it make?

In a discussion, attempts  to deny observable reality, intentional or
not, demean the ability of the other participants to observe that
reality and make decisions based on that observable reality.  In this
case, discussion participants were (and remain) justifiably confused
about whether the emacs project would or will develop a
library/built-in-package "clojure-mode" independently of the extant
third-party package.
I might be able to write a dissertation on why living by and promotion
of decision-making based on observable reality is a virtue (the
classical term for a "good" as you term it).  A consensus that cannot
withstand the weight of observable reality is no consensus at all.

> Please let Stefan and myself decide the policy in these matters here.
> It's what we are here for.  If we happen to disagree with Richard, we
> will work with him to solve the disagreement.

I fail to see how I am obstructing you from doing so.  You might have
made these assurances in private, worked out the policy disagreement
with Richard in private, then announced the resolution once you had
agreement.  I have no objection to your doing so.  I am not advocating
for one policy, or decision versus any other.  What I am advocating,
and defending, is the right of the rest of us to develop our own
viewpoints based on observable reality.  I don't view attempts to
manage feelings by denying observable facts as virtuous.

Believe me when I say that I am happy you and Stefan and whoever are
doing the work of maintaining the overall project and development
goals.  I am happy to defer to you in these matters.  I certainly have
no interest in doing that work.  But that is the extent of my
deference.

Maybe there is some confusion on my part as to the nature of this
mailing list.  The description says it is for "emacs developers".  It
is not restricted even to "GNU Emacs developers", much less "GNU Emacs
contributors".  My understanding of an "emacs developer" is one who
works on emacs code, whether the C source code or programs written in
emacs lisp.  That makes this mailing list a natural place to look for
advice or feedback from experts in emacs development, or make
announcements, recruit assistance, etc from the pool of people
interested in doing emacs development, whether that work will
ultimately be contributed to the GNU emacs project or not (since I
have seen little evidence that statement can be resolved before the
work is in fact in a contributable state, if for no other reason).
>From what I have observed, the meat and potatoes work involved in
coordinating maintenance efforts is done via the bugs email-list and
managed by the bug tracker, so these discussions on emacs-devel are
not in fact disruptive to such activities.

Lynn