Re: Brand new clojure support in Emacs ;-)

[Yuan Fu]

> On Sep 1, 2023, at 8:53 AM, Danny Freeman <danny@dfreeman.email> wrote:
> 
> 
> 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.

From a nontechnical side, taking over a package name that has been around for 
15 years, is very popular, is depended by thousands of Emacs users, would leave 
a bad taste is the mouth for clojure-mode developers and users. And it 
certainly wouldn’t help with the reputation of Emacs developers being hard to 
approach.

I don’t get the technical advantage of taking over the name either. For a basic 
better-than-nothing default mode, the user probably won’t even notice its 
name—the major mode just starts when one opens a Clojure file. And serious 
Clojure developers will just install Clojure-mode and CIDER instead.

> 
>> 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
>