|
|
|
|
|
|
by aquariusDue
2 days ago
|
|
|
Yep, I'd like to use GT as an IDE for non-Smalltalk code like I currently use Emacs though the off-topic rant is very welcome too and I thank you for it! Regarding the point of Lepiter vs Org I gave GT another go after I posted my comment and I realized that with the power of "adornments" (which you've mentioned) and so on Lepiter can be more flexible than Org files in a way (though the HTML export seems to ignore outlines currently). If I understood correctly there's nothing preventing you from mixing blocks of Markdown and Org (if Org was implemented) with other custom made blocks (like a snippet of code, chart or view of a GitHub repo). In that regard Lepiter (and GT by extension) seems immensely powerful even if I can't summon spell-checking willy-nilly like I can in Emacs regardless of org-mode or dart-mode for example. Also there seem to be official examples which I didn't see last time that hint about the possibility of implementing text editors and potentially code editors with LSP integration. https://book.gtoolkit.com/controlling-completion-in-a-text-e... https://book.gtoolkit.com/editing-python-sources-through-the... |
|
|
Yes - I think this all comes from the insistence on using a single rendering tree for everything displayed on screen. It allows mixing all kinds of UI elements everywhere, including nesting of arbitrary widgets inside a text field (and arbitrary text inside any other widget). It's a genuinely powerful model for UI composition :)
> I can't summon spell-checking willy-nilly like I can in Emacs
Yes, that's why I mentioned "features I use regularly in Emacs which are (and will be, for a long time) missing in GT" - it's not that you can't build them; they just need to be built, and with how few developers work on GT, it'll take ages before GT Coder gets those features.
It doesn't help that GT editors seem a bit less ad hoc scriptable than Emacs. I'm not sure why this seems to be the case for me - I suspect the need to structure everything as classes and methods adds non-trivial cognitive overhead for simple scripting. At least compared to the pretty flat, procedural shape of typical Elisp code. Then again, I did not invest enough time into learning how to customize GT's editors, so it might be a shallow impression that would go away with time.
> Also there seem to be official examples
Oh, nice, thanks, I missed that. I mean, it's obviously possible to implement an LSP client for GT, but I didn't know one existed. I'm especially interested in how that is integrated into Coder, since it should be able to provide a lot of functionality that I'd also want to script in my custom Coder instances.