Personally, I would (in my usage) have the hud disabled and use the inline eval - then if I want to, I would open the log to view any results that need, or toggle the hud if I need

I would give perference to inline viewing, in terms of defaults, I think having it the way they are is fine, i.e., hud first, but allow it to be disabled and enable the linline, or have both viewing

yes, for large displays, that's where the hud comes in

I can always toggle the hud

Hmm a solid use case for sure. I'll give the defaults some thoughts, that's the easy bit code-wise.

or, perhaps there's an option to say "show inline, but if it goes over X characters (user configurable), to also open up the hud

(which would disappear on next cursor movement anyway)

I was thinking about something like that too 🙂 a hybrid approach, which may be a third style of configuration although it begins to get a little complex. And if was the default behavior I can already see the questions from confused users about why the HUD sometimes appears, the reason wouldn't be clear without explanation. Whatever UX I end up with, I want it to be obvious cause -> effect.

Not sure how long result virtual text sticks around for either... until the next eval? Time? Cursor moves?

What does emacs do?

As long as the results are always available at the log, the inline eval can be a bit gimped... I think until the next eval makes sense

Modelling the behaviour of the inline would help anyone who is trying it out?

Cider is super powerful and give you all of the above, but also cider (to my knowledge) doesn’t also have a log. So you rely on the inline results quite a bit.

spacemacs keeps the inline around until next cursor movement (just checked)

Wishful thinking too, but the option to add the result as a comment is really good

spc , ; inline evals and adds the result of that eval as a comment beside the form

that's useful when doing dev

Huh interesting idea

What does that do when you already have a comment? Just keeps appending without adding more semi-colons?

let me check

(+ 1 4);; => 3
;; => 5

adds to the bottom it seems

(+ 1 5);; => 3
;; => 6
;; => 5

as a stack

although, conjure doesn't have to do that...

Oh interesting

Why do that though :thinking_face: like, what's the use case. We have to bear in mind the different context, like the log buffer may overlap with why that exists in the first place. There's already <prefix>e! to eval and replace, the log buffer holds yankable editable results and we will probably have inline results soon too. What does the comment version add I wonder.

The use case, I believe, is that as you're developing and eval'ing and repl'ing, you can track the progress of your work along each side of the form, so you can keep track of the results.

you don't want to replace the form, you simply want to see the results of that particular evaluation

:thinking_face: I guess I need to think on it, I feel like that'd only get in my way and I'd end up performing a bunch of jumps to delete and clean them up, especially since that's what I would use the log for. I'll let it sit in my head for a bit, but yeah, I don't think I would ever use that as it stands right now. Could be wrong!

np

I would much prefer to see inline eval first, rather than inline eval and comment 🙂

heh same

I have to finish this fennel over stdio client today and document it then release this version

Then I can experiment with that part

The comment thing is nice when you actually want to commit the results for future viewers…

Like some adding documentation in a rich-comment block.

yes, that would be a nice use of it too

congrats on the new release!