Re: Brand new clojure support in Emacs ;-)

[Danny Freeman <danny@dfreeman.email>]

João Távora <joaotavora@gmail.com> writes:

> I think there is still a fair amount of exaggerated alarm over the
> simple issue of Emacs providing a major mode for Clojure in some future
> version.  Emacs traditionally provides major modes for every major
> programming language.  There is no shred of evidence of any inclination
> of the Emacs project to sow chaos in the workflows of Clojure
> programmers just for the heck of it.
>
> Of course the naming issue is real,

Yes, I'm glad to see you acknowledge this as an issue. The naming issue
is all I'm trying to speak to right now.

> but deciding on it is one of the
> very last things to address on and it depends on what the new mode would
> be able to do.  So don't put the bulls in front of the carriage.  Not to
> mention there is lots of prior-art for technical means to manage
> clashing names.  Not only in Emacs, but most everywhere.  For example:
> if I ask my system package manager to install "java" I get a number of
> possibilities.  None of these options is more "java" than the other.  I
> get to choose which one is fits my needs better.  Symlinks to
> executables and libraries get setup appropriately, etc.

Avoiding name collisions is a great and simple way to deal with this.

> So, there is no "hijacking" at stake because there isn't (or at least
> there shouldn't be) the concept of property or ownership of a name,
> especially something as generic as "Clojure mode".  Plus, what matters
> to Clojure programmers generally isn't the really the NonGNU provenance
> of their daily working tools.  If anything, I've seen evidence of the
> contrary, witnessing some users switch to Emacs's core facilities even
> if they are _less_ featureful than third-party alternatives, _precisely_
> because they trust the Emacs project's stability and longevity.  I've
> seen this with Flymake and most recently with Eglot.

I too have witnessed this recently with Eglot, but only with respect to
switching from lsp-mode, not using Eglot and flymake as a substitute for
CIDER, of which there is some overlap in functionality, but both have
features the other does not offer. CIDER is still the killer feature
that draws clojure programmers to Emacs.

> What _really_ matters to users is what they can do with their Clojure
> tools.
>
> With that in mind, and since you sincerely state you want to move this
> discussion in a productive direction, what are -- in your opinion -- the
> 5 most important features supported by the the NonGNU Clojure mode and
> the brand new NonGNU Clojure TreeSitter mode?

In no particular order:
- Clojure-mode has built in refactoring tools, not all of which exist in
  clojure-lsp (to the best of my knowledge).
- Clojure-mode provides an API for tools like CIDER and inf-clojure to
  interact with clojure buffers.
- Clojure-mode integrates with CIDER to allow clojure macros and
  functions to define indentation rules as part of their metadata. I'm
  not sure if it will even be possible for clojure-ts-mode to do this.

The rest would be run-of-the-mill major mode stuff. The real value of
clojure-mode lies in it's integration with CIDER and to a lesser extent
inf-clojure.

There is nothing very special about clojure-ts-mode that I develop right
now. It is a work in progress and far from finished. It's not even quite
to the point where I can dogfood it at work yet. A long term goal is to
provide everything clojure-mode provides for CIDER with clojure-ts-mode.

> As a Clojure programmer,
> do you personally use LSP?  What are the LSP and nonLSP commands you
> find yourself invoking most often.

Yes, I am a happy user of Eglot and clojure-lsp, a refugee from
lsp-mode that you spoke of above. I mainly use it for
- xref navigation
- eldoc integration
- flymake error reporting
- renaming symbols

It's a very nice experience and pairs well with CIDER, especially when I
don't feel like starting up a repl. As you may remember, I also wrote
the jarchive package to integrate with Eglot for navigating to sources
outside of an existing clojure project. I use jarchive every day.

Non LSP commands I find myself invoking a lot are

- A large array of CIDER repl evaluation commands.
- CIDER documentation commands, which have different contents than those
  provided by clojure-lsp. They are both useful in their own ways.
- The CIDER inspector, almost an application in and of itself which is
  used for examining clojure data.
- The CIDER debugger. It is hands down one of the best debuggers I have
  used. Better than the other de-factor clojure development experience
  offered by the proprietary intellij IDE.
- CIDER test commands (i.e. run tests that exercise the current function
  at point, or current namespace, or last failed test)
- Clojure error examination - clojure is notorious for it's hard to
  understand error messages, cider or clojure mode, not sure which,
  provides a mode for interacting with errors that makes them easier to
  reason about.

> Can you say if CIDER is prepared to
> work with major modes other than the NonGNU Clojure mode?

No I cannot, as I am not a CIDER developer. There is a large overlap
between clojure-mode and CIDER developers though. I can guess that using
the name "clojure-mode" for whatever you land on here will make them
less open to working with a built in mode. Again, I don't speak for
them, but I think this is a good guess.

--  
Danny Freeman