cursive 2023-04-13 | Slack Archive

tobias09:04:47

Any chance that in the future we could get static analysis support for the for-by macro used in Electric Clojure? • e/for-by: a reactive map operator, stabilized to bind each child branch state (e.g. DOM element) to an entity in the collection by id (provided by userland fn - similar to React.js key). See example https://electric-examples-app.fly.dev/user.demo-system-properties!SystemProperties

cfleming22:04:03

I can add support for things if needed, but @U09K620SG uses (or used) Cursive, so he might know how to resolve it.

tobias10:04:08

I did ask @U09K620SG and he suggested making a feature request here 😁

Dustin Getz10:04:44

i do use cursive, but i don’t know how to extend the static analysis, for-by is different than for

Dustin Getz10:04:40

colin iirc you said it wasn’t possible yet, the best we can do today is disable intellisense entirely inside the for-by body

cfleming22:04:08

Yes, user customisation isn’t possible yet, but I’ll try to get support for electric added to the next release.

Dustin Getz01:04:22

appreciate that, thank you!

Henrique Prange16:04:39

> Previously, selecting a history item would cause it to be copied to the REPL editor, and you had to use shift to execute the form immediately. Since I added this feature, it has become clear that the workflow preferred by most people is executing forms directly from an editor rather than typing into the REPL editor. In that spirit, the default action is now to execute immediately, and you have to use shift if you want to copy the form to the editor. I recently updated to the latest version of Cursive and noticed this change in the behavior of the search history feature. I’m wondering if there’s any way to revert to the previous behavior or if there’s a configuration or key-mapping option I’m unaware of. As a user, I’m concerned that the current behavior may pose a risk. I’ve accidentally executed unwanted commands multiple times. I’m worried this could happen again in the future.

cfleming22:04:52

Hmm, interesting use case, I hadn’t considered that. I’d be interested to know if this is a problem for anyone else. There isn’t a way to configure this at the moment, but there could be. One issue with that is that then the command will always be executed in the current REPL ns, not the ns the form was last executed in, which I think is a nicer experience. Perhaps one way to do this would be a confirmation: “Do you want to execute <form> in <ns>? Yes/Cancel”, with a checkbox for “Don’t ask me this again.”

Henrique Prange14:04:05

Thank you for considering my feedback. My team and I also rely on the REPL for maintenance in staging and production environments, which is why we’re concerned about mistakenly running commands from the search history. While I appreciate the suggestion of adding a confirmation prompt, it might not be the best solution from a UX standpoint. Instead, allowing users to re-map the keys for those actions would allow them to customize the behavior to fit their preferences. For example, I would probably re-map the Enter key to copy/paste the code to the REPL, and Cmd + Enter to execute the form immediately, making it more difficult to run commands accidentally. Is that possible?

cfleming22:04:26

I’m not sure about that, since they’re not standard actions at the moment because that UI appears in a popup. I’ll check whether those could become actions which could be re-bound.

👍 2

2023-04-13

Channels