Clojurians Log v2

just say it in Spanish - el rep

https://onelook.com/?w=un*el&ssbp=2&ssbp=1 is good if you're searching for un*el words

that's useful!

speaking of which, where did OneLook's reverse dictionary search go?

http://reversedictionary.org/ seems to work ok though

e.g. to find a word for "using pretentious words": http://reversedictionary.org/wordsfor/using%20pretentious%20words

fun, spiral yields romanesco

In the past when I was wondering what to rename nrepl.el to I took a look at https://onelook.com/?w=*repl*&ssbp=1&ls=a

They I figured out how the vim-fireplace name came to be 😄

and how CIDER came to be?

I do think that stuffing REPL in the name of such project is not really a hard requirement.

haha

I was just about to mention this. Well, I really liked the name SLIME and what it stood for (Superior Lisp Interaction Mode Enhanced) and I wanted something that’s also five letter and it sounded cool by itself and could be expanded into something.

5 letters also meant I wouldn’t have to change the indentation in nrepl.el when doing the rename. 😄

The author of nREPL Chas Emerick proposed the name CIDER and I instantly liked it.

Ironically he was also the one suffering the most by the choice of the nrepl.el name as almost all the tickets he’d get were for the Emacs package, not for nREPL itself. For most people there was just one nREPL.

unrepl being 6 chars, let’s find a backronym for LAMBIC!

or SPIRAL 😉

yeah but out of theme with CIDER

Lean and Awesome Mode for Building Interactively on Clojure

You have a knack

we have found the winner

romanseco!

typo intended?

nope lol

romanesco

fingers crossed that @volrath likes cauliflower

Super Terrific REPL Orchestration Emacs Mode

I really struggled with the O here 😄

does melpa allow heavy metal umlauts aka röck döts?

I think so, but they are hard to type for users, so that makes those a bad idea.

or would it be Heavy Meta Umlauts?

😄

Splendid Pluripotent Interactive REPL for Another Lisp

.o0(somebody has used Reverse Dictionary Search)

No! I swear

It's not omnipotent, only pluripotent 🙂

> (of an immature or stem cell) capable of giving rise to several different cell types.

there’s the “upgrade” idea in there 😉

I lol-ed with all this conversation... particularly with "Splendid Pluripotent Interactive REPL for Another Lisp" 😄

the name CIDER is hard to top... it's so cool haha

right now I'm definitely between SPIRAL and STROEM, I like both.. but before making it official with a new name, I've been putting a lot of thought on the value proposition of another IDE, besides having UNREPL as the communication protocol.. basically related to this https://github.com/Unrepl/unrepl.el/issues/5

I do believe there's room for alternative approaches, and that's what's currently driving me into this. the other side of the coin is that I'm not entirely sure I'll be able to put the amount of work to make a reliable alternative to CIDER in the long run.. and I wouldn't like this work to just die out because of it

so for now... I'm taking a time on reflect on this, while I work on testing for all that's been built so far, which won't add more features to the mix

@volrath it would be helpful if you stated explicitly things that you’d like to do differently than CIDER does (hey I mistyped CIDER as CODER) beyond unrepl/nrepl

so far these are the things that weight the most in my mind:

unrepl.el can also be seen as a way to get experience with unrepl, make it matures until incumbents 😉 see it as the right choice

- Working buffer dev over REPL buffer dev: The IDE should encourage newcomers
     to try this workflow, without being too pushy.
   - Fewer buffers, fewer distractions
   - Fewer (unified) ways to interact with evaluation results
   - The REPL buffer is a great place to save history
   - The REPL buffer is a great place to explore things that are difficult to
     explore in the working buffer.
   - Emacs level intermediate representation (AST) is great! let's...
     - explore different types of data visualizations
     - take advantage of static analysis of the code, a la Cursive. (although
       this might fit better in something like clj-refactor)

those are more like broad strokes, I have some other more concrete ideas but I'm still sitting on them

In fact, if anyone has opinions on this matter, I think it'd be good to use the github issue instead of slack to discuss this.. anything would be welcomed 🙂

Brave souls can try to build lumo from https://github.com/cgrand/lumo/tree/suspension

on this branch the stock repl (both term & socket) is upgradable

The async nature of JS forces the upgrade to be a bit different

Example:

(lumo.repl/suspension-request
  (fn [r resume]
    (let [print-fn *print-fn*]
      (lumo.repl/read-chars r
        (fn loop [s]
          (if (re-find #“bye” s)
            (resume {:value :ok})
            (binding [*print-fn* print-fn]
              (println “you said: ” s)
              (lumo.repl/read-chars r loop))))))))

the equivalent Clojure is

(loop []
  (let [s (.readLine *in*)]
    (if (re-find #“bye” s)
      :ok
      (do
        (println “you said: ” s)
        (recur)))))

wow that is nice indeed

> right now I’m definitely between SPIRAL and STROEM, I like both.. but before making it official with a new name, I’ve been putting a lot of thought on the value proposition of another IDE, besides having UNREPL as the communication protocol.. basically related to this https://github.com/Unrepl/unrepl.el/issues/5 Yeah, I’ve meant to respond this, but I’ve been pretty busy at work these days. In the end of the day it really comes down to the fact that every Lisp IDE for Emacs has between 0 and 1 maintainer and eventually this impedes their development significantly. I’m all for innovation and healthy competition, but I know sooner or later everyone gets into a point where they can’t allocate a lot of time for OSS and generally stagnation begins there (even for popular projects like SLIME, SLY, Geiser and CIDER). I recall how sky was the limit when I had a lot of time for it, and how things are going now. Segmenting a tiny community might be detrimental in the long run.

I can't see this as critical segregation, this most important component of standardized clojure development in emacs clojure-mode is not being replaced. I'm already codeing entirely inf-clojure, wish that project had more maintainers and better vision, the userbase I think is pretty big (not obvious from Tickets and PR's). Adding yet another configureable feature to cider, sounds not so attractive to me no matter how good it may be. I doubt that old-schoolers will be changeing away from cider anytime soon. I've not looked at unrepl.el as I'm only programming in cljs these days. I think cider rocks, use it when (rarely) I do vanilla clojure. My opinion is maybe that unrepl.el can be added as a feature into cider, but also potentially a standalone.

haha

@hlolli I guess you don’t know I’m also the maintainer of both clojure-mode and inf-clojure 🙂

In comparison to CIDER they are trivial projects - they were both quickly derived from lisp-mode and inferior-lisp originally. I recall I hacked together the first version of inf-clojure in 1 day day. 🙂

The amount of work that went into CIDER is of completely different magnitude.

I can see an antitrust lawsuit coming :-)

😂 😂 😂

Anyways, this just serves to illustrate how few people are working on the Emacs tooling. It seems Emacs Lisp scares most people away, as most project don’t get many outside contributions.

I don't think it's fair to blame elisp or lack of interest of other people for lack of PR's. I've had 2 merges into inf-clojure, somehow when the maintainer are very busy doing other things, projects end their life. But that's a diversion of my point, the lightweight is what attracts me to inf-clojure. Been thinking myself to actually make a new clojure mode for emacs, so I'm glad to hear that someone is trying to create a new emacs package for clojure.

> I don’t think it’s fair to blame elisp or lack of interest of other people for lack of PR’s. I’m not blaming anything or anyone. I’m just stating personal observations that stretch way beyond Clojure-related projects. 🙂 I appreciate everyone’s contributions and I welcome new projects and ideas. I’m just ware of fragmentation . I really don’t think there’s anything foundational in clojure-mode, except the fact that everyone uses. Realistically this can be rewritten from scratch in something like a week. It took us something like 3-4 years to “rewrite” SLIME and that’s a vicious cycle. In the mean time there was little innovation, just a lot of catching up to do. But @volrath really has some great ideas in the UI department and that’s pretty awesome.

But I may want to add to what I wrote, I don't think there's any need for a new mode, given that what already exists can be improved and maintained well. I'm actually also not in favour of segregateing ad infinitum. @richiardiandrea has been doing very nice commits lately to inf-clojure and I have good faith that project can grow.

agree @bozhidar

thanks btw 😄

having contributed to clojure-mode, cider, nrepl and inf-clojure I really really like to contribute on inf-clojure 🙂

To be bit politically bromantic, @richiardiandrea should at this point have merge rights so that there's an active maintainer and that will automatically motivate it's users to interact and vibrate, prompting more PR's as a consequence.

🙂

I appreciate everything @richiardiandrea is doing for inf-clojure and I wouldn’t mind giving him commit right eventually. The main reason I haven’t done this so far is that he’s not very familiar with Emacs practices and could use some guidance and help here and there. CIDER and clojure-mode have many people with commit rights there, but alas - all of them have been inactive for a while.

I’m not a great maintainer of my projects for sure, and I wouldn’t mind nothing depending on me, but so far has been hard to achieve. 🙂

I am not familiar with those things for sure and I actually totally like the fact that you screen my code..and come on you are a good maintainer :)

🙇