he he -- yes, for the moment, though i think it would be nice for the eventual merger too 🙂

I have written an email to the author or rewrite-clj, but no response yet.

yes, it seems difficult to reach him...may be we can find someone who can find him in person 🙂

hope he’s ok. life happens sometimes.

for deps.edn, I could ease into it with https://github.com/RickMoynihan/lein-tools-deps I suppose

indeed!

hadn't seen that -- will take a look

rewrite-clj's project.clj seems pretty straightforward

need to check rewrite-cljs' though

yep

I think deps are pretty straightforward…

let me put this on my todo list

I miss my old rewrite-cljs playground squirrel.

lol -- it's been playing around over here, hoping to end up in a native-image project 🙂

native image for what?

I’m slightly worried about the unreachability of the rewrite-clj author. I hope he’s doing OK.

ok, phew, his account is showing activity: https://github.com/futurice/entranceFE/pull/16 so I guess he’s fine 😉

good to hear xsc seems to be ok 🙂

@borkdude i'm working on a proof-of-concept editor extension to perform the inline-def transformation you blogged about. so iiuc, it's kind of the opposite of one of the things your clj-kondo does (clj-kondo detects and can remove(?) inline-defs).

clj-kondo only detects, it does no transformations

Good to see xsc is active. I wonder if there is a way we can get his attention.

@sogaiu what would your editor extension do? is there any ticket with a longer description?

@borkdude thanks for the clarfification on what clj-kondo does. i'm still finishing up an initial implementation so no description yet, but the idea is to be able to have your pointer / cursor somewhere in a defn, you invoke a command, and the result is that the defn surrounding the cursor is auto-detected and then the inline-def transformation is applied to it. does that make sense?

I’m not sure why an editor would have to do that for me? it’s usually only a temporary debugging thing for me

it's a proof of concept for making stand alone extensions that don't bloat other extensions. the design uses native image so that different editors can use the same native image piece.

@sogaiu that’s a cool idea 🙂 makes a lot of sense actually

but for inline def, I usually only want to define something little, not have the editor insert a lot of them for me automatically. but there are several other things that could be done

like removing them 😉

@borkdude just to clarify, the current code is meant to transforms one defn (the one that's automatically detected based on the cursor). on a side note, it also handles destructuring types of situations for the arguments of the function, so one ends up with a (do (def a a) (def b b) ...) inside the result if one started w/ something like (defn my-fn [{:keys [a b]}] (+ a b)). i think one minor benefit of programmatic inline defs is it's potentially less error-prone, but now that you mention removal, it seems that the programmatic process could be inserting information (e.g. metadata or special comments) that would make detection for the removal process easier. at any rate, i'm hoping to publish a sample before too long so folks can experiment with making things for emacs, atom, vscode, etc. that can work without interfering with existing clojure-related things like cider, chlorine, and calva (so they can all focus on their core features, possibly spinning stuff out to make them leaner and easier to maintain). (my original intent was to provide a command that would instrument functions with tap / trace expressions so i could quickly get code that would record execution information for diagnostic / debugging purposes, but i haven't worked out the piece for recording such information yet, so when i noticed your inline def blog post, i thought it might be a candidate for use in a proof-of-concept.) your work on clj-kondo, particularly the native-image portions has been great to reference, thanks for sharing your findings 🙂

cool idea, looking forward to it

@sogaiu I have updated my rewrtite-cljs playground with deps.edn https://github.com/lread/rewrite-cljs-playground/blob/cljc-spike-2/deps.edn

thanks! i appreciate it :)

It was even easier than I expected. Which I find myself often saying when working with clojure!

As usual am happy to hear about any issues you encounter.

he he -- just pulled the change, and performed the first test. working ok so far, now on to the second test (native-image building).

coolio!

looks good on the native-image building side, thanks!

@borkdude, I am wondering about open source etiquette and rewrite-clj author not responding. I think as I get closer to an alpha-ready release of my cljc version, if he hasn’t responded, I’ll raise a git issue over at rewrite-clj as maybe another way of getting his attention. I don’t want to be a pest, but I also would love to get a response.

that’s great @sogaiu!

@lee I think in case of non-responding authors, all we have is fallback on the open source license, which is MIT for rewrite-clj

but creating an issue might work.

right, good point, thanks