This page is not created by, affiliated with, or supported by Slack Technologies, Inc.
2022-11-16
Channels
- # announcements (7)
- # babashka (8)
- # beginners (48)
- # calva (4)
- # cider (6)
- # circleci (2)
- # clj-commons (14)
- # clj-kondo (3)
- # clj-on-windows (7)
- # cljs-dev (34)
- # clojure (49)
- # clojure-dev (25)
- # clojure-europe (48)
- # clojure-losangeles (1)
- # clojure-nl (4)
- # clojure-norway (33)
- # clojure-uk (2)
- # clojurescript (37)
- # community-development (5)
- # conjure (17)
- # cursive (2)
- # data-science (1)
- # editors (10)
- # emacs (50)
- # events (22)
- # honeysql (11)
- # introduce-yourself (1)
- # jobs-discuss (13)
- # lsp (42)
- # malli (9)
- # off-topic (7)
- # pathom (11)
- # portal (5)
- # re-frame (3)
- # reagent (22)
- # reitit (8)
- # reveal (1)
- # rewrite-clj (4)
- # shadow-cljs (38)
- # xtdb (21)
Hi all, here is the recording of last night’s event at the London Clojurians Reveal: lessons learned (by Vlad Protsenko) https://www.youtube.com/watch?v=lZtxc66zU5s
@U47G49KHQ, Thanks for sharing! Lots of interesting insights. I keep coming back to the idea that all we need is a decent clojure-based text editor so that we can integrate all the various tools into a cohesive app.
• I'm not super familiar with LSP, but I thought LSP already had a programmatic interface • Does that address the problems of multiple windows that you talked about?
Eh, I meant pitching to LSP maintainers an extension of LSP that defines a protocol for adding generic REPL support. The intention is to not have yet another text editor, but instead to have a standard that can be implemented by any text editor and integrated with language-specific tools
That will allow defining a way to embed such tooling into text editor, so there won't be extra window problem
So the result would allow for embedding something like reveal?
Are you imagining something like https://github.com/BetterThanTomorrow/joyride, but with an API that would work with any editor?
Yes, embedding something like reveal, and without having to write bindings for every possible IDE that we want to integrate with
Interesting.
Joyride is vscode-specific, I want to avoid IDE-specificity. LSP is IDE-agnostic, basically an interface that can be implemented by text editor to support language tooling
Yea, I hadn't thought about that because it's really uncommon to embed UIs from other languages/environments/runtimes. Maybe that's possible? I know ChromiumEmbeddedFramework does that.
https://bitbucket.org/chromiumembedded/cef/wiki/GeneralUsage#markdown-header-off-screen-rendering
There's also onscreen rendering, but that would require pretty deep integration for both the IDE and the tool.
I was thinking, maybe this interface will not be about embedding UI, but instead about a common DSL for UI. THE problem to solve here is what this DSL will look like.
That's one of the problems I'm trying to work on for membrane, but in my experience, it's not a problem anyone really wants to work on.
I think the data model that Figma has is like 80% there, but there are a lot of details to work through.
IMO, the general gist is to define your UI in terms of shapes, text, and images (which is platform/framework independent).
Why wouldn't it work?
I've written a lot about how I think that should work, but the short answer is that's what membrane does. Here's an example of a treemap view that runs inside portal (on the web) and inside reveal (in cljfx). It's the same component (the slight differences in output are because they're using slightly different versions of treemap-clj). This particular example isn't an expandable tree view with scrolling, but I've built those before and it would work the same way. https://clojurians.slack.com/archives/C02V9TL2G3V/p1647286579886189?thread_ts=1647170441.434869&cid=C02V9TL2G3V