Re: Brand new clojure support in Emacs ;-)

[Bozhidar Batsov]

Hi everyone!

I had decided at first to ignore this thread, given I'm on vacation this week, but its overall tone and directly really forced me to write something here. (I have to admit I'm extremely upset while writing this email)

1. I was accused of being "hostile" at some point, but if this thread is "friendly" and "constructive" I've been living in some fantasy world. Repeatedly it has been claimed that:

- The maintainers of the Clojure tooling for Emacs don't know what it's best for it (even if the end users have been happy with their work for a very long time and there's big structure already in place to support the existing tooling)

- The Emacs core team developers are the only people who know what's best for the Clojure tooling - everyone else is "short-sighted", "unreasonable", "aggressive", etc.

- It doesn't matter what name they chose for an alternative package, as the pains of the end users are probably not important. Yeah, if you install a mode named "clojure-mode" that doesn't happen to work with some other packages depending on "clojure-mode" that's perfectly fine in terms of user experience, right?

2. Suddenly people who have not touched Clojure have realized that Clojure is a very important language and it needs to be supported by Emacs OOTB. Where were you in the past 15 years? Would you have thought of Clojure at all if we haven't bothered to submit the Clojure packages to NonGNU ELPA? (which started all those conversations) Don't bother to answer here - I think that's quite obvious.

I'm still waiting to see a single actual Clojure user making the case that something will be gained by going in the direction that the Emacs developers have been pushing for for the past few weeks.

3. Why do you accuse me of having "my way or the highway" attitude when you repeated ignore me and Danny and just power on with whatever you believe to be right? Don't you think that dismissing other people's opinions in such a hostile way might be a bit counter-productive?

4. I also learned that 15 years of work don't amount to much (according to you) and we can easily get more or less the same experience with 20 lines of code and LSP.  From people who are not actually using Clojure in any capacity (at least to my knowledge)

I've been nothing but a champion of Emacs for 20 years now, yet I feel I'm being treated as an ignorant buffoon here, who wants to do (or not do) things out of sheer spite and stupidity. If that your idea of building a community - fine by me, but I don't want to be a part of this. Afterwards don't argue that people like me are "uncollaborative", "short-sighted", "combative" or whatever else you believe to be the case. 

Instead of having a civilized conversation here, I've felt that it's only "we know better" and to hell with how things used to happen. Sure, you can do whatever you want, but I think that no one will be better off if things in the community happen in this forceful manner.

I know all of you believe you're trying to solve a problem here, but from my perspective you're creating a problem when there was none. The road to hell is paved with good intentions indeed...

In Emacs We Trust! M-x forever!

On Sat, Sep 2, 2023, at 11:14 AM, João Távora wrote:

Danny Freeman <danny@dfreeman.email> writes:

> I don't think so. CIDER and clojure-mode are developed in lock-step,

> along side a couple other projects written in clojure to support CIDER

> from within the clojure repl process. The API is just the functions that

> CIDER calls from clojure-mode. If you want more information you will be

> best off reading the CIDER source.

OK.  So at some point, if you want your new clojure-ts-mode to be

integrated with CIDER, a more formalized API will have to emerge for

your new mode to adhere to.  It would be a good service to everybody to

take opportunity to document it and formalize it.

> I see your other message where you discovered some of my reasoning, and 

> I feel I've already explained my position. You will also see a later

> message where I said once clojure-ts-mode is in a more "done" state I

> will revisit the question of inclusion here with other clojure-mode

> devs. Until then I will continue to develop clojure-ts-mode in the

> clojure-emacs github organization with the intention of integrating it

> with the rest of the clojure-emacs tooling.

AFAIK, putting your clojure-ts-mode in GNU Elpa core GNU Emacs does

_not_ collide with the practice of developing in a GitHub organization

nor with your intention of integration with some specific tooling...

I've had a look at clojure-ts-mode and is seems very young indeed.  Is

there any reason you didn't derive from lisp-data-mode? I think you

should at least reuse lisp-data-mode-syntax-table instead of listing a

very large entry that essentially repeats it.

I am curious about the performance and capabilities of tree sitter in

Lisp modes.  Lisp modes are perhaps the easiest modes things to parse

and the ones Emacs has better support for.

João