This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2020-12-21
Channels
- # adventofcode (60)
- # aleph (2)
- # announcements (3)
- # architecture (2)
- # babashka (12)
- # beginners (90)
- # calva (14)
- # cider (32)
- # clj-kondo (1)
- # clj-together (7)
- # cljsrn (4)
- # clojars (10)
- # clojure (161)
- # clojure-dev (110)
- # clojure-europe (58)
- # clojure-nl (3)
- # clojure-spec (35)
- # clojure-taiwan (1)
- # clojure-uk (24)
- # clojuredesign-podcast (3)
- # clojurescript (27)
- # conjure (47)
- # cursive (17)
- # data-science (1)
- # datomic (1)
- # depstar (6)
- # fulcro (20)
- # java (4)
- # jobs-rus (1)
- # luminus (4)
- # malli (10)
- # off-topic (8)
- # re-frame (4)
- # reagent (1)
- # reitit (9)
- # reveal (1)
- # rewrite-clj (8)
- # ring (3)
- # sci (44)
- # shadow-cljs (5)
- # spacemacs (6)
- # specter (8)
- # tools-deps (6)
- # vim (1)
- # xtdb (11)
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
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
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?
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
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.
What does that do when you already have a comment? Just keeps appending without adding more semi-colons?
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!
I would much prefer to see inline eval first, rather than inline eval and comment 🙂
I have to finish this fennel over stdio client today and document it then release this version