portal 2023-03-31

I hadn’t noticed the metadata option in the UI before, is that new, too? nice 👏

It has been in Portal for a bit, but it's only available for the inspector viewer.

I guess I just hadn’t noticed then. 😅

Dustin Getz (Hyperfiddle) 2023-04-03T12:24:26.271999Z

wow nice job @djblue impressive !

Is there a way to extend the default shortcuts keymap? I would like to have a shortcut for the command palette, for instance…

It's not an answer to your question, but there is a shortcut for "Open Command Palette" by default. A bunch of them actually. "Ctrl+ShiftP" (or meta on Mac), ctrl+j, shift+:

👍 2

Not currently, but it is something I would like in Portal. Still need to think through some design decisions. Also, ideally extension users would be able to provide configuration through their editor keymap 👌

Quite. There are a number of shortcuts that I’d like to (re)map, like emacs familiar keys and a few others for dvorak ergonomics; extend a few other things perhaps. This is an amazing tool, by the way. I can’t wait to show it off to others, and to dig in more. 🫶

I'd love to be able to do multiselection from my editor.

❤️ 1

I think for multiselect to work with only keyboard, there would need to be a command to move to another selection. Currently, multi-select is only possible with mouse + keyboard.

How do other apps deal with keyboard only multiselect?

In portal I would expect moving with j/k/up arrow/down arrow and pressing SPC to select/deselect From the editor I would expect something like select-next select-child that I can call

> • https://cljdoc.org/d/djblue/portal/0.38.0/doc/editors/vs-code/clojure-notebooks#portalnreplwrap-notebook @djblue that looks wonderful. Assume I wish to extend the middleware behaviour on the (JVM) user side. For example, I with to preprocess certain kinds of values before they are handled by Portal. How would you recommend doing that?

👀 1

Currently no, the middleware simply exists to hand off the value to the portal runtime code.

However, I wonder if this code could be independently wired into Portal so it would work for non-notebook use cases 🤔

Thanks :) (I am interested in the notebook use case, just wish to adjust the way values are handled.)

I vaguely remember we had an idea of how to get kindly in there, but I managed to forget all about it…

I forgot too : )

Anyway, I think any entry point which allows the user to add middleware (or somehow change the existing middleware) would be great as a way to start experimenting.

I think the challenge for me here is that I want to keep the api surface area minimal, so having one extension point makes sense. However, in different contexts, middleware is a bit complicated 🤔 For example, what is the value that gets passed to the middleware?

I think you can do that already in a bit of a hacky manner. Portal runs all the notebook results through the ->value command it defines itself. You could register your own so that your code runs instead of portals.

I think for notebooks, perhaps the value the was returned would run through the middleware, but what about the tap list? Or for user provided values?

Yeah, it’s not a good full solution, but it should be easy to start playing around with it already without you having to provide something extra. The thing I’m talking about is here: https://github.com/djblue/portal/blob/10af532c5722bb4705f438e1c0e0ac26028fb4e4/src/portal/nrepl.clj#L187

We did have a decent full solution we talked about @djblue, I just can’t remember right now 😭

> ->value Thanks. I'll look. > For example, what is the value that gets passed to the middleware? Yes, there are some things to think about. I'll try to create a proof-of-concept that will maybe help us think.

(Redefining ->value does not seem to have any effect, so probably I do not understand something about the workflow. Anyway, I think I will come back to it only in a few days. Looking forward to learn more. 🙏 )