-
-
Notifications
You must be signed in to change notification settings - Fork 114
Frequently asked questions
Since the HUD is just a regular floating window you can alter the colours with the NormalFloat
group. Conjure doesn’t pick the colours for you, so some themes may use hard to read contrasts, especially when it comes to comments.
:highlight NormalFloat ctermbg=<colour> guibg=<colour>
I used to suggest setting the
Pmenu
group but I thinkNormalFloat
is more specific.
Yes! By design Conjure supports language modules from inside this repository or in your own plugins. All a language client needs to be is a Lua module with a set of values and functions exposed, you can read all about that in :help conjure-clients
.
You can learn a lot by having a read through the existing clients in fnl/conjure/client. Your client doesn’t have to be written in Fennel if it’s in your own repository but I’d highly recommend it. You’ll just have to get to grips with Aniseed.
Feel free to have a chat with me (Olical) about what you’d like to add and how you want to go about doing it. We can work out if it should be a 3rd party plugin or a fork of this repository until it’s time for wider release.
Yep! Although what’s available isn’t documented right now so you’ll just have to read through Conjure’s source code and have a play. Some modules you may be interested in are conjure.eval
, conjure.client
and conjure.extract
for example, you can require them from any Fennel or Lua file within Neovim if Conjure is installed.
Have a look through fnl/conjure/**.fnl
for what’s available, not an awful lot is private so you’re more than welcome to hook into function calls at your own risk. There’s a chance they could change until I have some sort of stable proxy API.
I’m not a huge fan of VimL despite spending years trying to get semi-decent and it and I think it adds a huge amount of overhead to any Vim based project. I have never felt that I could attempt something ambitious with it because I’ll get tangled up in my own code in no time. The syntax and semantics are just not good enough to build complex software, in my opinion.
As you may be aware, I’m obsessed with Lisps (mostly Clojure, but still), and there’s a myriad of ways to compile nice Lispy languages to Lua. Neovim has wholeheartedly embraced Lua by embedding LuaJIT (an incredibly fast runtime) and gone down the path of turning VimL into a compatibility layer from a bygone era. The goal is to make Lua the first class language in Neovim while automatically compiling VimL to Lua for you.
This means Lua support and tooling in Neovim will only get better, I feel that Conjure is ahead of the Lua plugin curve and you’ll start to see more Lua than VimL plugins in the near future.
So that’s the main reason and why I won’t be able to support Vim 8+, they just haven’t embraced Lua and the the subsequent APIs in the same way making porting almost impossible at this point. The other key reason is that Neovim will embrace tree-sitter at some point soon which will allow me to simplify my form extraction logic immensely and supply Conjure support to non-Lisp languages such as Python and JavaScript.
One more reason: Floating windows. Although I think Vim has an answer to that, I really like the Neovim approach.
TL;DR:
-
Embracing Lua as 1st class over VimL.
-
Deep tree-sitter integration.
-
Floating windows and other neat UI innovations.
This means the REPL doesn’t know which language we’re in when Conjure asked it via reader conditionals, so it sends #?(:clj :clj :cljs :cljs…)
and then uses that information to display what kind of REPL it is.
Sometimes that results in a nil
or error which usually means the nREPL is a little non-standard. This can also be cause when the nREPL is just busy when we ask, rather than waiting around for this optional information we move on since we can always check it later by listing the sessions.