[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Brand new clojure support in Emacs ;-)
From: |
Eli Zaretskii |
Subject: |
Re: Brand new clojure support in Emacs ;-) |
Date: |
Wed, 06 Sep 2023 19:27:46 +0300 |
> From: Lynn Winebarger <owinebar@gmail.com>
> Date: Wed, 6 Sep 2023 09:11:23 -0400
> Cc: casouri@gmail.com, danny@dfreeman.email, joaotavora@gmail.com,
> dmitry@gutov.dev, rms@gnu.org, emacs-devel@gnu.org
>
> > > > > 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.
That is completely off the mark. My point was that you are in effect
"rebutting" _my_ interpretation of what Richard wrote. That cannot
possibly be useful.
> 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.
You've heard 3 opinions which are almost identical. Where there are
some differences (which, together with the heated debate, where not
everyone reads everything and understands completely what is being
said, are probably the source of confusion), they don't yet need to be
reconciled because the decision is not on the table yet. If and when
it will be, the differences, such as they are, will be resolved, and
there will be no place for any confusion.
> > 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.
Your post could be interpreted as hinting on some contradictions
between the views of the 3 involved individuals, and even as an
attempt to exaggerate those contradictions, for whatever reasons.
That is once again not useful and doesn't contribute to kinder, calmer
discussions. I don't know whether you meant that -- I sincerely hope
you didn't -- but such an interpretation is definitely possible. So I
hope you will try in the future to avoid saying things that could be
interpreted that way.
> What I am advocating, and defending, is the right of the rest of us
> to develop our own viewpoints based on observable reality.
You and others have every right to your viewpoints, but I urge you to
think hard before you divulge each and every one of these viewpoints
in public. Where neither Richard nor Stefan nor myself see any
conflict of opinions that needs to be resolved, why would you insist
in public that such a conflict exists (or may exist)?
> 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.
That is completely unrelated to the point I was trying to make. No
one said that your posts were off-topic, and no one said that you
shouldn't be allowed to post here. It's a non-issue. The official
purpose of this list is "for communications between Emacs developers".
- Re: Brand new clojure support in Emacs ;-), (continued)
- Re: Brand new clojure support in Emacs ;-), Lynn Winebarger, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), João Távora, 2023/09/01
- Re: Brand new clojure support in Emacs ;-), Danny Freeman, 2023/09/01
- Re: Brand new clojure support in Emacs ;-), Yuan Fu, 2023/09/01
- Re: Brand new clojure support in Emacs ;-), Eli Zaretskii, 2023/09/01
- Re: Brand new clojure support in Emacs ;-), Lynn Winebarger, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), Eli Zaretskii, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), Lynn Winebarger, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), Eli Zaretskii, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), Lynn Winebarger, 2023/09/06
- Re: Brand new clojure support in Emacs ;-),
Eli Zaretskii <=
- Re: Brand new clojure support in Emacs ;-), Richard Stallman, 2023/09/04
- Re: Brand new clojure support in Emacs ;-), João Távora, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), João Távora, 2023/09/01
- Re: Brand new clojure support in Emacs ;-), João Távora, 2023/09/01
- Re: Brand new clojure support in Emacs ;-), Bozhidar Batsov, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), João Távora, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), Bozhidar Batsov, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), João Távora, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), Bozhidar Batsov, 2023/09/03
- Re: Brand new clojure support in Emacs ;-), João Távora, 2023/09/03