From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Danny Freeman Newsgroups: gmane.emacs.devel Subject: Re: Brand new clojure support in Emacs ;-) Date: Fri, 01 Sep 2023 11:53:13 -0400 Message-ID: <87v8cthmzl.fsf@dfreeman.email> References: <87il9kksqz.fsf@dfreeman.email> <87a5uw9ivs.fsf@posteo.net> <87ttt42gna.fsf@dfreeman.email> <87wmy080kn.fsf@posteo.net> <83v8djcydl.fsf@gnu.org> <87350ndquw.fsf@dfreeman.email> <83350ncbns.fsf@gnu.org> <87cyzrjbd8.fsf@dfreeman.email> <83zg2vav46.fsf@gnu.org> <87o7j99304.fsf@dfreeman.email> <87zg2hsyrd.fsf@dfreeman.email> <87h6ontwfv.fsf@posteo.net> <835y4ucrz3.fsf@gnu.org> <831qficgin.fsf@gnu.org> <87ttsehwab.fsf@dfreeman.email> <87fs3x6ge7.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20336"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Dmitry Gutov , rms@gnu.org, emacs-devel@gnu.org To: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Sep 01 18:34:45 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1qc76b-000531-Ej for ged-emacs-devel@m.gmane-mx.org; Fri, 01 Sep 2023 18:34:45 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qc75q-0003S7-D9; Fri, 01 Sep 2023 12:33:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qc75e-0003QT-Um for emacs-devel@gnu.org; Fri, 01 Sep 2023 12:33:48 -0400 Original-Received: from out-236.mta1.migadu.com ([95.215.58.236]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qc75Z-0000oK-2H for emacs-devel@gnu.org; Fri, 01 Sep 2023 12:33:46 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=dfreeman.email; s=key1; t=1693586018; h=from:from:reply-to:subject:subject:date:date:message-id:message-id: to:to:cc:cc:mime-version:mime-version:content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references; bh=0Pt637BV2KpjQl4JxtTnLGyXlpy+DV4+At5BD6/l93U=; b=G2NTwcjYPvv5SriXUiFtguPIV/0neBLFqjPNTEss2RxEXnEHRZhnXfTcKagPKjgQ5bPqUq Pcfs3FN1HMcADV6AQZlDaKY8y58YoeKsoNvvyNPA5FBxNfCT0Y3j+s8gAgUm1pyM/7I8Ks vlgLs1qMmvN0t3HFh3sxI8YIqYiTM4k= X-Report-Abuse: Please report any abuse attempt to abuse@migadu.com and include these headers. In-reply-to: <87fs3x6ge7.fsf@gmail.com> X-Migadu-Flow: FLOW_OUT Received-SPF: pass client-ip=95.215.58.236; envelope-from=danny@dfreeman.email; helo=out-236.mta1.migadu.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:309818 Archived-At: Jo=C3=A3o T=C3=A1vora 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. --=20=20 Danny Freeman