[Q] Why not use textobjects for everything?

[PowerUser64]

Hello! I just got started using Conjure, and I have a question: Why does Conjure have its own set of "textobjects" when neovim already has textobjects?

Conjure has so many variations on the "evaluate <this> and put it <here>" command, when most of them could be reasonably accomplished if there were just a single command that accepts a textobject - rather than having so many separate ones. Maybe it's here because it was just an early design decision?

Ignoring the <localleader> prefix on all keybinds from here on, these are some of the keybinds I'm talking about (+docs):

Default keybind	Keybind rewritten as a command and a textobject
ee	eie, where ie is a textobject that targets a form
ece	cie, where c is a command to evaluate to a form, and ie is the textobject from ee
er	ear, where ar is a textobject for a root form
ecr	car, ar is the same as above
ew	eiw, where iw is a "word" textobject, based on how ew defines a word
ecw	ciw, same as above, but with the c command
e!	Eie, replacing the current E command with one that evaluates and overwrites the target with the result
em[mark]	eM, where M is a textobject that matches the form around a mark
ef	this is one that might make sense as its own command, or as e%, where % is a textobject if that gets the contents of a file on disk (this may not be possible), or just as a :ConjureEval% command on the cmdline
eb	egG, where gG is a textobject targeting the entire buffer (like this one)

Written more directly, the current interface could be almost entirely written with these commands:

• e - "eval"
• E - "eval and replace"
• c - "eval to comment"

... and these textobjects:

• ar - "around root form"
• ie - "inside form"
• iw - "inside word"
• iM - "inside form at mark"

Wouldn't it be more flexible to define three commands and a few textobjects to replace the existing commands as a simpler and more flexible way to accomplish all this? The commands could even be made to accept a register (eg. "reie to eval and place the result in register "r), as a way of getting the result in a specific register, rather than having to configure a dedicated one. It might even be possible to make the upper-case registers map to special actions and not even have the c and E commands, like having "C redirect to a comment and "V redirect to overwriting the selected visual region or textobject. I don't know enough about making neovim keybinds to say whether this is possible, and it would probably not feel very "neovim-ey" at that, but I include it here to further accentuate the feeling I'm trying to convey - it seems like Conjure's core functionality (evaluating text in a repl and capturing the result) is abstracted in a somewhat non-composable way compared to how most other neovim commands work. Speaking as a new user, this has also made it a bit confusing to get in to using Conjure, since it has so much bespoke functionality that distracts from its primary feature.

I realize it's possible to remap these keys, so a composable e command can be made right now (although not a c comment command or a E "eval and overwrite" command), but how come this isn't the way it works by default?

[Olical]

This decision of how the keys work was inspired by fireplace and CIDER and was designed at a time that treesitter didn't exist. This meant that I was limited to walking the code and using regexes to find the right pairs of parens. That plus the desire for logic like "evaluate a (comment) block but ignore the comment and evaluate the first level of form below that your cursor is within" makes it easy (in my opinion) to justify implementing the code selection in the code itself.

This decision ended up being hugely beneficial because it meant I could migrate all clients and users gracefully onto tree sitter with added features with backwards compatible support for those that do not wish to use tree sitter at all (you can still get by without it in lisp-y languages).

I don't think I would do it differently, I like the control I have over the code selection, it's tightly integrated and coupled, but that has given me some nice control. What you're suggesting is decomplecting the selection of the code from the action, which I think is a noble effort, it's just a different approach with different tradeoffs.

All operations require more key presses for instance, something some people are fine with, others would hate (the sheer number of options we support shows how we try to accommodate a large number of tastes and opinions at once 😄 ). I could see this being good as an option though, maybe.

If you are decoupling code selection from evaluation though, I think Conjure shouldn't even define the text objects, at that point that's a plugin per language, like clojure-treesitter-text-objects, python-treesitter-text-objects etc all powered by something like https://github.com/nvim-treesitter/nvim-treesitter-textobjects (I have never dabbled with this, I have no idea how powerful it is).

Then on the Conjure side an option could turn off the built in mappings and swap to a "I require text objects" mode, but it won't care what those are, it's up to the user to compose. Maybe Conjure can provide some behind an option, but I think it'd be overstepping boundaries if it provided them by default, that would be very surprising for most users.

So in summary: I just took different design decisions back in the day, shaped by what Neovim features existed at the time and the original Conjure implementations (one was written in Clojure as a remote plugin). We could do this now, but it'd be an alternate control scheme you opt into with different tradeoffs.

An interesting idea though!

[PowerUser64]

Thanks for your reply! I do agree, regular expressions are nicer than tree-sitter parsers in a lot of cases. Both because of the reasons you mentioned, but also I like them because they can often easier to predict than a fancy tree-sitter parser, even if they can't be generalized to all languages in the same way.

On how to support this, if at all, I think adding an option for a textobject-only mode might be a bit excessive for a base-case. All that would be needed to get 80% of the way with this is commands that accept textobject for the features that don't currently have them. Being able to rely on muscle memory for things like this without losing functionality would be really nice.

Also, I think having a layout more like this would make it more obvious what all Conjure does and how to use it, for those who are shopping around for REPL plugins. Connecting with potential users through things they already know makes it easier for them to imagine using it and more likely it'll stick with them.

If I wanted to try separating some of these things (maybe by making these missing commands), where would you recommend I start in the code base? I have not written fennel (or lisp) before, but I've seen it around a bit, and it's something I'd like to learn. Would you be open to accepting a PR that adds a couple of textobject-oriented commands if it was made up to your standard?

[Olical]

Thanks for your reply! I do agree, regular expressions are nicer than tree-sitter parsers in a lot of cases. Both because of the reasons you mentioned, but also I like them because they can often easier to predict than a fancy tree-sitter parser, even if they can't be generalized to all languages in the same way.

Sorry to cause confusion! I actually massively prefer tree sitter to regexes for parsing code. I see three tiers and I think your thoughts here could progress us onto the third one:

• Imperative regex / character pair matching based (old Conjure, highly discouraged but still supported for some Lisps)
• Imperative tree sitter walking (current state, works great for my use cases, highly specific to Conjure, not composable)
• Declarative composable tree sitter text objects (a potential future alongside the other two, different mapping scheme entirely, can combine with other plugins and gains power through decomplection, allowing future composition in unforeseen ways)

If this ended up happening I'd also move to shift the current form selection code out into a sub-module that would (like all of Conjure's source code modules) only be lazy loaded when it was used. Allowing us to support radically different ideas without just growing the loaded system in memory every step of the way.

If I wanted to try separating some of these things (maybe by making these missing commands), where would you recommend I start in the code base? I have not written fennel (or lisp) before, but I've seen it around a bit, and it's something I'd like to learn. Would you be open to accepting a PR that adds a couple of textobject-oriented commands if it was made up to your standard?

The only essential thing you need to work on it is nfnl which will handle all of the compiling for you as you write .fnl files, no other compile step or tooling is required. It should Just Work.

I think the existing eval motion mapping (<prefix>E if I recall correctly) is what you want to use to experiment if you don't want to change much of Conjure's code yet. I would then use that tree sitter text object plugin I linked to define text objects for a language of your choice, make it practical with good mnemonics that make sense to you within your context. You should be able to use them with the existing Conjure mapping mentioned previously.

If that experiment works well, then I think we can talk about options that disable some default mappings and replace them with mappings that expect some sort of motion or text object (I think those are entirely interchangeable?).

[PowerUser64]

I think the existing eval motion mapping (<prefix>E if I recall correctly) is what you want to use

Thanks! I just rebound it to <localleader>e and made the other keybinds upper-case so I can test out relying on just the motion keybind more easily. I'll let you know how it goes with writing julia and fennel+lua for a bit. (fennel if I can figure out how to make it part of my config cleanly, but it seems like nfnl is the right tool.)

I think [the terms textobject and motion] are entirely interchangeable?

They basically are. The way I understand it is that they're both ways of addressing regions of text, but textobjects are specifically for when you don't want the starting point of the text region to be tied to where your cursor is. Motions can be used in normal mode for navigation, whereas textobjects require "operator pending" mode. Additionally, textobjects almost always start with i or a for addressing "inside" or "around" a block (all built-in textobjects are like this).

I actually massively prefer tree sitter to regexes for parsing code.

Thanks for the clarification! I actually use the treesitter-textobjects plugin you pointed to, so I can already say it should work pretty well for this. It's quite useful for a lot of things. My favorite textobjects it provides are the function and conditional ones. I tried the comment one, but it didn't really work how I wanted.

I couldn't say how well it works with lisp languages because I haven't written them before, but it should probably work. If you want to try it, you would probably get a lot done with the "parameter" textobject that it provides (I bind this to im/am), as I think it would probably target something like a "word" in a form, as you define it. The "block" one is probably worth trying too (I think it will target a form). You can run :InspectTree in neovim to get an idea of what objects you might be able to use.

Furthering the tree-sitter vs regex discussion, I do think there are still cases where regexes are a better option than tree-sitter parsers. I have a good example that shows when using regex is better which I could share, but including it here is a bit too tangential. That said, Conjure's use is definitely much better-suited for using tree-sitter than regex.

---

I'll keep going with Conjure and treesitter-textobjects. I suspect the combo to work quite well for the languages I use. I encourage you to try it too, since you'll be able to better assess how well it works for the lisp-y languages, which seems to be a fairly large audience for this plugin.

Also, feel free to reach out on Discord. My username is PowerUser, and I'm in the Conjure server as of a few days ago.

[russtoku]

Could you share what programming language you are working with when using Conjure? It could help to understand your workflow; what your pain points are; and how things might be composed to help you get things done with minimal friction.

The Fennel tutorial and reference should help you on your fennel-lang journey.

You should also be aware of the built-in functions that Neovim has and the functions that nfnl provides (see the api docs). You can ignore the Aniseed stuff because nfnl can replace most things that it provides. Most of the Aniseed functions have been upgraded to nfnl but you may see a few that haven't been.

To create mappings, you would use the Neovim functions. The help docs detail the Lua functions and their parameters but you'll need to convert that to Fennel syntax. There is a Lua <-> Fennel converter available to help this mental transition. Why Fennel? should also help with the differences between Fennel and Lua.

An example of the current imperative tree sitter walking code selection can be seen in the Python client. It defines the form-node? function so that it grabs pieces of code that are appropriate for Python.

[PowerUser64]

Thanks for the resources! Being able to convert both ways from lua to fennel and back to lua is really nice.

The language I'm using with Conjure right now is Julia, but I'd also like to use it with Clang-Repl (a c++ repl), although it's not supported right now. I have only used Conjure for a few days now. I noticed this as something that seemed like somewhat of a vim anti-pattern while I was trying to understand how to use this plugin. I was curious to ask about it since it didn't look like anyone had brought it up before.

I might try writing part of my nvim config in fennel, just to get the hang of it. Is it possible to call lua from fennel and vice-versa? I might be able to try it in a few places.

[russtoku]

Is it possible to call lua from fennel and vice-versa?

Yes, from Fennel, you would call a Lua function using the Lua function name. However, be aware of the naming convention differences. For example, a Fennel function named parse-prompt would end up named parse_prompt in the compiled Lua file. Peek inside the Lua file that is generated by compiling the Fennel file to check for name-mangling.

You can look at the Conjure source code in the fnl/conjure/ directory of the repo and compare the Fennel files there to their counterparts in the lua/conjure/ directory. Neovim functions show up as something like vim.fn.expand (:help function-list) or vim.api.nvim_create_autocmd (:help api).

[PowerUser64]

Okay, cool! So, it sounds like for writing a small part of my lua config in fennel, I would probably

• Write some file in fennel (in an equivalent directory under fnl/ in my config)
• Compile to lua (compiled output gets put in the lua directory)
• Call from my lua code with require

Do you think this is an alright way to do this? Or is there a way that's significantly better?

PS: If you'd like to message about this on Discord, I joined the Conjure server as of a couple days ago.

[russtoku]

I'm still a newbie at Fennel, Lua, and writing plugins for Neovim but what you've outlined should be workable.

BTW, @EkiM in the #help channel of the Conjure Discord asked about a Conjure client for Clang-Repl. @Olical suggested using the Conjure Rust client as a starting point. See his post. The Conjure Julia client would be another look at interacting with a REPL via stdio. Both clients use the conjure.remote.stdio module. But the Rust client might be a bit more straight-forward to understand.

Should you accept the mission to create a Clang-Repl client, copy fnl/conjure/client/rust/evcxr.fnl to fnl/conjure/client/clang-repl/stdio.fnl (create fnl/conjure/client/clang-repl/ first). Then, change it to work with the Clang-Repl. The form-node? function should be changed to respond with true if the surrounding context of the cursor's current position represents a C++ code object (rough equivalent to a Lisp form). The buf-suffix, comment-prefix, command, and prompt_pattern should be changed to what's appropriate for Clang-Repl. You can do it!

I have a post on my blog that gives an introduction to creating a Neovim plugin using Fennel. I hope you find it useful.