emacs-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Brand new clojure support in Emacs ;-)


From: Philip Kaludercic
Subject: Re: Brand new clojure support in Emacs ;-)
Date: Sun, 03 Sep 2023 16:03:13 +0000

"Bozhidar Batsov" <bozhidar@batsov.dev> writes:

>> Of course, it would be even better if you and your co-maintainers could
>> be convinced to distribute clojure-mode along with Emacs (again, this
>> doesn't mean development must be moved away from GitHub), but just like
>> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
>> synchronised with the core.  But IIUC, your main issues is the copyright
>> assignment and the concern that it might limit who might contribute,
>> right?
>
> Other than the contributor agreement there's development overhead to consider:
>
> - where are issues reported? I don't want to use the Emacs issue
> tracker, but that'd be unavoidable for something built-in, so instead
> of having one issue tracker you end up with two (one of which I really
> dislike)
> - some patches will be submitted on GitHub, some on emacs-devel - I highly 
> doubt that all the clojure-mode maintainers would be willing to deal with this
> - discussions related to problems/ideas would be happening in different places

To my knowledge, this is not an issue with the packages I have
mentioned.  Of course there are exceptions, but to my knowledge
basically all conversation about org-mode happens on their mailing
lists, basically all conversation about the modus themes, happen on
Prot's mailing list/issue trackers.

> - there's also so overhead of keeping the GitHub repo and the code in Emacs 
> in sync

This is a minor point, IMO, and if it is relevant, it will usually be
because of a downstream change that should be upstreamed anyway
(e.g. someone replaced all occurrences of an inefficient construct, and
happens to do so in clojure-mode as well).

> I can go on and on about this - hybrid development models simply come
> with a lot of overhead. 

The mistake I want to emphasise here is that this is not a "hybrid
development model".  Development continues on your own terms, and just
gets copied over into emacs.git on a regular basis.

>                         I get that here many people think that GitHub
> is the root of all evil, but political preferences aside - it's the
> largest forge in the world by a huge margin and I think it provides
> unique benefits to projects that can't be replicated elsewhere. At
> least not today.

While I disagree, especially with GitHubs recent 2FA push, IIUC I just
want to clarify that this is not what is being discussed.

Other than these points, is the CA the only major issue.  Or to put it
differently, if you could state the conditions for clojure-mode to be
distributed with Emacs, what would your conditions be?  My point here is
just to clarify if there is a solution to this discussion -- in which
case I think it is worth continuing it -- of if you /want to not want
to/ have clojure-mode added to core Emacs?

>
> On Sun, Sep 3, 2023, at 5:19 PM, Philip Kaludercic wrote:
>> "Bozhidar Batsov" <bozhidar@batsov.dev> writes:
>> 
>> >> I would guess that anyone who is seriously interested in working with
>> >> Clojure, would install the proper major mode and the proper package
>> >
>> > That's one of the things that bother me the most in the conversations
>> > so far - lots of people tell us what the Clojure users need, but other
>> > than me and Danny, no one here has any real interest in Clojure. :-)
>> > Without an understanding of Clojure and its tooling ecosystem (and
>> > it's history) it's hard to make good suggestions about what makes
>> > sense and what doesn't.
>> 
>> This suggestion comes from a different point of view, namely that if I
>> open a clojure file, that I have anything else but fundamental mode to
>> structure the file.  And if it is true that LSP integration could
>> provide xref, imenu, capf, etc. support, one would come a long way for
>> modest needs with very little code.  Just like with the common-lisp
>> mode, the support is of course better if you install SLIME or Sly, but
>> having some basic OOTB support is already a good thing and all this
>> thread started out with.
>> 
>> Of course, it would be even better if you and your co-maintainers could
>> be convinced to distribute clojure-mode along with Emacs (again, this
>> doesn't mean development must be moved away from GitHub), but just like
>> with CC-mode, Org, cperl, Modus-Themes, releases would just have to be
>> synchronised with the core.  But IIUC, your main issues is the copyright
>> assignment and the concern that it might limit who might contribute,
>> right?
>> 
>> > I already wrote we tried the "thin layer on top of lisp-mode" and this
>> > didn't worked out great in the past. Of course, people are welcome to
>> > try and learn from experience themselves if they thing they can do
>> > things better/differently.
>> >
>> > On Wed, Aug 30, 2023, at 9:17 AM, Philip Kaludercic wrote:
>> >> João Távora <joaotavora@gmail.com> writes:
>> >> 
>> >> > On Fri, Aug 25, 2023 at 8:26 AM Philip Kaludercic <philipk@posteo.net> 
>> >> > wrote:
>> >> >>
>> >> >> Richard Stallman <rms@gnu.org> writes:
>> >> >>
>> >> >> > [[[ To any NSA and FBI agents reading my email: please consider    
>> >> >> > ]]]
>> >> >> > [[[ whether defending the US Constitution against all enemies,     
>> >> >> > ]]]
>> >> >> > [[[ foreign or domestic, requires you to follow Snowden's example. 
>> >> >> > ]]]
>> >> >> >
>> >> >> > It appears that there is no clojure-mode command in core Emacs.
>> >> >> > There is a Clojure mode package, but it is in NonGNU ELPA.
>> >> >> >
>> >> >> > I think that language is important enough that, notwithstanding not
>> >> >> > really being similar to Lisp, we ought to have a major mode to 
>> >> >> > support it.
>> >> >> > Would someone please work on that?
>> >> >>
>> >> >> I had brought this up in the recent clojure-ts-mode thread, that I
>> >> >> assume you are referring to.  Sadly, I have no experience with the
>> >> >> language, but one idea might be to extend lisp-data-mode by whatever 
>> >> >> the
>> >> >
>> >> > I don't know if this counts as "work on that" but here's two 
>> >> > interesting lines
>> >> > Elisp:
>> >> >
>> >> >   (define-derived-mode clojure-mode lisp-data-mode "Clojure"
>> >> > "Barebones Clojure")
>> >> >   (add-to-list 'auto-mode-alist '("\\.clj" . clojure-mode))
>> >> 
>> >> I suggested something along these lines up the thread, but didn't try it
>> >> out myself.  Nice to see that the idea works.  To avoid confusion, I
>> >> think it might be a good idea to not call this `clojure-mode' as well,
>> >> but something like "clojure-proto-mode" or "primitive-clojure-mode".
>> >> 
>> >> > Since it is a lisp dialect many things works here, like indentation,
>> >> > symbol recognition, parenthesis balancing, C-M navigation, and 
>> >> > thing-at-point.
>> >> >
>> >> > And then there's LSP, right?
>> >> >
>> >> > So I installed clojure-lsp from here:
>> >> > https://aur.archlinux.org/packages/clojure-lsp-bin
>> >> >
>> >> > I created a hello world project with the "lein" tool, git init, found 
>> >> > the
>> >> > src/helloworld/core.clj inside it, pressed M-x eglot and suddenly I had
>> >> > at-point-documentation, diagnostics, lots of refactorings, completion, 
>> >> > etc.
>> >> >
>> >> > The thing that's a bit minimal is the syntax highlighting, but it's
>> >> > not that bad either IMHO. Eglot doesn't yet support LSP-mandated syntax
>> >> > highlighting.  I have no idea what it takes to add TreeSitter support
>> >> > to such a bare-bones mode (but shouldn't it be really easy like mapping
>> >> > syntactic symbols to faces?)
>> >> >
>> >> > No idea if this works with the CIDER or SLIME backends for clojure.
>> >> > Don't ask me to test any more cause I've just uninstalled it all
>> >> > but any clojurians rading can have a go.
>> >> 
>> >> I would guess that anyone who is seriously interested in working with
>> >> Clojure, would install the proper major mode and the proper packages.
>> >> 
>> >> > João
>> >> 
>> >> 
>> 



reply via email to

[Prev in Thread] Current Thread [Next in Thread]