Olical

I've been writing my config and plugins in it for years :) https://github.com/Olical/conjure https://github.com/Olical/nfnl

<3

I'm the author, I think both. I'm working on DAP (https://microsoft.github.io/debug-adapter-protocol/) support for Clojure to use alongside Conjure connected to the same running Clojure program.

I can get by without a debugger but I think both have their strengths and I want both. Actually I want all three: REPL, LSP, DAP. The REPL layer gets to be super small and simple when LSP and DAP are handling the other harder parts of IDE-ish features.

Don't pick one, have your cake and eat it :) future post I'm planning talks about this sort of trifecta and all of my favourite editor things coming together alongside fast auto-running unit tests.

I'm trying to make the neovim lisp world a little more pleasant with Conjure :) just for those that absolutely can not switch to emacs long term (like me)

https://github.com/Olical/conjure

It's written in a lisp, runs as lua and supports: Clojure, Fennel, Racket and Janet with a bunch more to come.

Glad I could be of assistance :D (sorry in advance for any time lost to Lisp fun times)

Oh does it? Nice! I am a 100% Neovim user so I focus on that but if this works in Vim 8+ with minimal changes I'm totally open to pull requests to support / document it!

I'm the author, I've been in love with Lisp for years now (I'm a recovering JavaScript programmer) but refuse to leave Vim, Vim Script is absolutely awful for anything more than simple option setting in my opinion. Hence this massive detour into writing a plugin / library / framework to allow me to write better plugins.

I just wanted best of all worlds: My favourite editor with my favourite syntax without sacrificing any performance. If anything, my dotfiles should be faster now since there's less VimL which is damn slow to execute. I haven't benchmarked it though.

The Clojure world in Vim is getting better and better too thanks to various projects. My attempt at that is https://github.com/Olical/conjure

We also have really good s-expression editing plugins! Come on in, the water is full of parens :D

The p in prepl stands for programmable or programs, as in, for programs. If you open up a socket REPL you can connect to it and send code + receive results but they're printed without any structure. String goes in and string comes out.

The prepl wraps all responses in a predictable EDN data structure tools can consume with ease. This is what Conjure is built on. The source and doc for the Clojure prepl is really informative: https://github.com/clojure/clojure/blob/8e7213781a1a45db9668...

Already there :) K will look up docs for the symbol under the cursor. Pretty sure fireplace has this though...

Example of the doc output: https://imgur.com/vSB5Fv5.png

Yep, sure thing, good idea. I was going to do an asciinema video or something, I only got around to writing the README as it stands yesterday, it's the first time I'm showing it off really.

Hi, I'm the author and that means a lot to read! It's been a labour of love going back and forth on rewrites and ideas for about six months so it'll mean the world to me if it ends up being something people enjoy using some day.

The tool is, like all tools, designed around my preferences and opinions, it definitely won't align with everyone but I hope there's some good ideas in there.

There's no traditional REPL, there's a log buffer that has results appended to it. You can edit that buffer (which happens to be a .cljc file) and evaluate anything in there like you would in any buffer.

The log buffer appears, expands and hides when required. I've tried to keep it out of the way when you're not using it but persistent and accessible when you need it. I definitely want to experiment with Neovim's floating window API and the "virtual text" API too.

Streamlined, removed the insanity, tested and documented. Any better? https://github.com/Wolfy87/tuple

Huh, I never knew that. Thanks! As long as you're in a decent environment that kind of definition becomes a lot smoother. I like it.

The problem with that being that you redefine the unpack function every time a tuple is created. The this._NAME = VALUE; may look awful but it's more efficient.

You are just relying on your users to not abuse _ prefixed variables. It's far from ideal.

So what if I made immutable. You can only set once and unpack to a function that can name the values. I could also drop the valueOf usage.

Does that sound saner? It is definitely simpler and a lot closer to an actual tuple implementation.

I want to turn this into a small repository so maybe I will take the little good bits and drop anything unnecessary.

Okay, that isn't integral though. This could easily be left out if desired. It's not coercing to a number either, it's simply concatenating. This would work with strings too or any other type that supports valueOf.

You have valid points though. I just didn't like to think of this as something that could never be used in the real world. Or at least contain little ideas that could be used in the real world. It has at least some relevance.

It fills the array backwards because that is the most efficient loop possible within JavaScript when the order does not matter.

I added a pack method to enforce some weak limiting on the size of the array. This will only allow you to set an amount of values equal to the initial values that were set.

I know you can do it with `slice` etc, but the point was to make something a little different to an array or object inspired by the things I have been learning about functional programming.

Please, by all means, treat it as a cute demonstration. That's fine. I personally could see myself using something like this in some situations as a base type to extend from for example. Maybe as a generic coordinate storage system as I have shown in the post.

It has many flaws and might not fit in with your opinions or views, but saying "don't use anything like this code" seems a bit heavy handed to me. I think it has a time and a place, no matter how minute that time or place may be.