# Racket workflow feature comparison **URL:** \ **Category:** General\ **Created:** [April 1, 2023, 5:59pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851 "2023-04-01T17:59:32Z")\ **Posts on this page:** 16\ **Page:** 1
**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\ **Post date:** [April 1, 2023, 5:59pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/1 "2023-04-01T17:59:32Z")
I recently started helping out as an additional maintainer of the Magic Racket project (a VS Code extension for Racket), and as part of this, I was curious about the state of Racket workflow features (editing, debugging, linting, etc.) across different tools. I've started assembling a [Racket workflow feature comparison](https://docs.google.com/spreadsheets/d/1incspt3SExQKJ2gWqZc1RQpdidPaF8mebLSlqnjXcqA/edit) to attempt to visualise the different features that are currently supported. I expect this will be quite helpful as I prioritise future Magic Racket features, and it may be useful for others to get an clearer picture of what's out there. Let me know if you'd like to help out with this effort! I've already had several contributions via Discord. @benknoble added the Vim info, for example. Some cells are empty for things I wasn't sure about, so it would be great to know the status of those. There may also be additional tools that would be good to add, so do let me know about that as well. Feel free to leave comments in the doc, message me here or on Discord etc. if you have any feedback or corrections. πŸ˜„ ---
**Author:** ![Release-Candidate](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/release-candidate/32/1080_2.png) [@Release-Candidate](https://racket.discourse.group/u/Release-Candidate)\ **Post date:** [April 2, 2023, 6:58pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/2 "2023-04-02T18:58:54Z")
Thanks, I think that's a great idea! Emacs' Racket-Mode can rename, so there should be a `yes` in row 60 ---
**Author:** ![robertpostill](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/robertpostill/32/53_2.png) [@robertpostill](https://racket.discourse.group/u/robertpostill)\ **Post date:** [April 6, 2023, 12:01am UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/3 "2023-04-06T00:01:45Z")
@jryans, that is a fantastic thing. Thank you for putting it together. One thing that made me scratch my head is that I wasn't sure what some of the terms meant. Now I suspect that's partly a lack of knowledge on my part. But it did also make me want to find both definitions for the terms and links to the package docs so I could see them in action. Is there any way I can help annotate your document with that? ---
**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\ **Post date:** [April 6, 2023, 2:54pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/4 "2023-04-06T14:54:21Z")
> [@robertpostill](#): > > @jryans, that is a fantastic thing. Thank you for putting it together. Thanks, glad it seems useful! πŸ˜„ > [@robertpostill](#): > > One thing that made me scratch my head is that I wasn't sure what some of the terms meant. Now I suspect that's partly a lack of knowledge on my part. But it did also make me want to find both definitions for the terms and links to the package docs so I could see them in action. Is there any way I can help annotate your document with that? Ah, that's surely my fault for hastily summarising features and likely biasing my terminology towards the words VS Code would use. πŸ˜… It would be great to improve the naming and add cell notes to give longer explanations where needed. Let's talk about this more directly somewhere... Perhaps Discord, email, or private messaging here, whatever's best for you. πŸ™‚ ---
**Author:** ![spdegabrielle](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/spdegabrielle/32/95_2.png) [@spdegabrielle](https://racket.discourse.group/u/spdegabrielle)\ **Post date:** [April 10, 2023, 12:15pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/5 "2023-04-10T12:15:55Z")
Thanks for doing this! I’m wondering if this sheet can be extended to reflect where the features work for other languages using the `#lang` protocol? For example: ![image](https://global.discourse-cdn.com/free1/uploads/racket/original/2X/3/3ed73b848a23b434074112859c23f0ff4d9e60cb.png) > **[Shriram Krishnamurthi (@shriramk@mastodon.social)](https://mastodon.social/@shriramk/110170247356907904)** > > Attached: 1 image > > YOU WON'T BELIEVE what it looks like to have an IDE for the TABLOID programming language! > https://github.com/otherjoel/tabloid Best regards Stephen PS I’m struggling to work out what IDE features are enabled by the `#lang` protocol? I was expecting to find it in The Guide, DrRacket manual and Plugins manual, but I can’t quite work it out. Maybe I’m looking in the wrong places? ---
**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\ **Post date:** [April 11, 2023, 10:29am UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/6 "2023-04-11T10:29:34Z")
> [@spdegabrielle](#): > > I’m wondering if this sheet can be extended to reflect where the features work for other languages using the `#lang` protocol? Ah yeah, it would be good to highlight that dimension in more detail somehow. At the moment there's only one row in the highlighting category ("General language identifiers (active `#lang` forms)") that covers a `#lang`-dependent feature, but many more features may or may not be working for all `#lang`s vs. just Racket. Thanks for the suggestion! I'll try to think about the best way to add in that additional info. πŸ™‚ > [@spdegabrielle](#): > > PS I’m struggling to work out what IDE features are enabled by the `#lang` protocol? I was expecting to find it in The Guide, DrRacket manual and Plugins manual, but I can’t quite work it out. Maybe I’m looking in the wrong places? [Source-Handling Configuration](https://docs.racket-lang.org/guide/language-get-info.html) sort of hints at the language-specific features through `#:info` customisations. I am not aware of a straightforward list of editor features enabled by `#lang`, but perhaps we can write such a list once we've assembled a list of such features as part of the feature comparison here. ---
**Author:** ![greghendershott](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/32/98_2.png) [@greghendershott](https://racket.discourse.group/u/greghendershott)\ **Post date:** [April 11, 2023, 6:03pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/7 "2023-04-11T18:03:27Z")
I think the two main features a `#lang` can surface in an editor are: 1. Token coloring. The lang-supplied lexer can say, for example, that certain spans are certain kind of tokens (e.g "string", "number", etc.). Then the editor can use a color for each kind, chosen by the user or a theme. 2. Indentation. ---
**Author:** ![greghendershott](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/32/98_2.png) [@greghendershott](https://racket.discourse.group/u/greghendershott)\ **Post date:** [April 11, 2023, 6:21pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/8 "2023-04-11T18:21:56Z")
I think some of these "No"s for Racket Mode aren't quite right. - "Documentation". You can view documentation for the thing at point (caret) using two commands. - "Binding arrows". Emacs can't draw graphical arrows like in DrRacket, so if the feature must literally be arrows, it must be a "No". - "Potential binding arrows". Same. - "Tail-position arrows". Same. * * * p.s. Those links are to the [Racket Mode site page](https://www.racket-mode.com/), which consists of a hand-written guide, plus a reference generated from the same per-command "doc strings" you can see live in Emacs. So it's pretty good source of info about what's supported -- or at least attempted πŸ˜„. But I'm also happy to answer questions, or point out anything that seems not quite right like the above. Hope this helps! ---
**Author:** ![robby](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/robby/32/7_2.png) [@robby](https://racket.discourse.group/u/robby)\ **Post date:** [April 11, 2023, 6:24pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/9 "2023-04-11T18:24:41Z")
> [@greghendershott](#): > > "Binding arrows". Emacs can't draw graphical arrows like in DrRacket, so if the feature must literally be arrows, it must be a "No". [...] My $0.02: arrows drawn on the text and being able to navigate via the binding structure of the program are two separate things and while the first one is more discoverable the second one is a lot more useful! ---
**Author:** ![robby](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/robby/32/7_2.png) [@robby](https://racket.discourse.group/u/robby)\ **Post date:** [April 11, 2023, 6:27pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/10 "2023-04-11T18:27:48Z")
There's some documentation that's pretty drracket-specific about what `#lang` customization is available here: [1 DrRacket support for #lang-based Languages](https://docs.racket-lang.org/tools/lang-languages-customization.html) It would be nice if, eventually, we got to the point where IDE services and IDEs are a bit more decoupled so that people using Emacs, magic racket, the lang server protocol, and DrRacket all had similar capabilities available to them, but just tailored to way those different editors usually do similar things. I think we're making progress in that direction, too! ---
**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\ **Post date:** [April 11, 2023, 8:42pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/11 "2023-04-11T20:42:59Z")
> [@greghendershott](#): > > I think some of these "No"s for Racket Mode aren't quite right. I have almost certainly gotten some cells wrong, my apologies... πŸ˜… I am not an Emacs user myself, so thus far the Racket Mode / Emacs value came from skimming your (quite thorough, well-written) documentation page and then correcting based on feedback from actual Emacs users. πŸ˜‡ > [@greghendershott](#): > > "Documentation". You can view documentation for the thing at point (caret) using two commands. > > - [`racket-xp-documentation`](https://www.racket-mode.com/#racket_002dxp_002ddocumentation) uses an external web browser (you can configure this to be the Racket web site, or the locally installed doc HTML files). > - [`racket-xp-describe`](https://www.racket-mode.com/#racket_002dxp_002ddescribe) shows you the web page formatted in an Emacs buffer. > - Also flavors of both commands for the REPL buffer; same key bindings in both buffers. I wasn't quite sure how to handle this case, since IIUC Emacs doesn't really support "mouse hover" like VS Code and DrRacket do (a free-floating mouse cursor overlapping something that is separate from the "text cursor" position). I don't fully understand the Emacs interaction model at the moment, so I may still have it wrong... What triggers the documentation to appear and when does it appear? Moving the text cursor? Just when moving around or only while typing (which would make it more completion-focused)? I may need to tweak the naming in some rows properly convey this. > [@greghendershott](#): > > - "Binding arrows". Emacs can't draw graphical arrows like in DrRacket, so if the feature must literally be arrows, it must be a "No".However when the thing at point is a definition or a use, it is highlighted, as are its relations -- and there are commands to move among the related sites (even if not currently visible on screen). See [commands starting here](https://www.racket-mode.com/#racket_002dxp_002dnext_002ddefinition). So I feel like this is a "Yes", but I wouldn't be offended if you think it should be "Partial". > - "Potential binding arrows". Same. > - "Tail-position arrows". Same. I believe the part that Racket Mode / Emacs are doing here is (meant to be) covered by the "Yes" values for "Highlighting: References to selected binding" and "Highlighting: Tail position". The arrows are quite a unique DrRacket feature, so I think it's nice to list them separately via these "Hover" rows. I'll change them from "No" to "-" (out of scope) for non-DrRacket editors though, since I don't think any support drawing such arrows on top of the text area. > [@greghendershott](#): > > p.s. Those links are to the [Racket Mode site page](https://www.racket-mode.com/), which consists of a hand-written guide, plus a reference generated from the same per-command "doc strings" you can see live in Emacs. > > So it's pretty good source of info about what's supported -- or at least attempted πŸ˜„. But I'm also happy to answer questions, or point out anything that seems not quite right like the above. Hope this helps! As mentioned above, your docs were the main source of info for my first attempt at the Racket Mode / Emacs features, so thanks for writing them! πŸ˜„ Please do continue to pass along any other corrections, as I'm sure there are still things to improve. ---
**Author:** ![greghendershott](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/greghendershott/32/98_2.png) [@greghendershott](https://racket.discourse.group/u/greghendershott)\ **Post date:** [April 12, 2023, 12:07am UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/12 "2023-04-12T00:07:23Z")
> [@jryans](#): > > I wasn't quite sure how to handle this case, since IIUC Emacs doesn't really support "mouse hover" like VS Code and DrRacket do (a free-floating mouse cursor overlapping something that is separate from the "text cursor" position). I don't fully understand the Emacs interaction model at the moment, so I may still have it wrong... > > What triggers the documentation to appear and when does it appear? Moving the text cursor? Just when moving around or only while typing (which would make it more completion-focused)? I may need to tweak the naming in some rows properly convey this. If you want to see documentation for the thing at point, you ask for it: You press some keys. It appears (in an external browser, or, in another Emacs "window" (pane) next to your code's "window" (pane)). The on-command approach to docs is pretty typical for Emacs. Of course in Emacs it's also not unusual for people to configure things to happen automagically in whatever exact way they prefer. * * * There is also support for Emacs completion engines like company-mode, which can show you a snippet of the docs, while you're scrolling through completion candidates. But. Much Racket documentation [doesn't fit in one entire screen, much less a portion](https://docs.racket-lang.org/reference/match.html#%28form._%28%28lib._racket%2Fmatch..rkt%29._match%29%29). And it often include links to other topics and tech terms, which you'd like to click. Finally, some is most comprehensible when you can scroll across multiple adjacent topics, as opposed to a "peephole" view of just one at a time. In short, it was authored to be viewed in a web browser. When presented in a small non-interactive popup, sometimes it's OK... but sometimes it's not. That's why I put so much work into making the documentation experience good, including rendering full Racket doc HTML pages in an Emacs text buffer with mostly reasonable formatting and live links to other topics. That's why "Documentation: No" seemed not quite right IMHO. πŸ˜„ ---
**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\ **Post date:** [April 12, 2023, 12:39am UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/13 "2023-04-12T00:39:21Z")
> [@greghendershott](#): > > That's why I put so much work into making the documentation experience good, including rendering full Racket doc HTML pages in an Emacs text buffer with mostly reasonable formatting and live links to other topics. > > That's why "Documentation: No" seemed not quite right IMHO. πŸ˜„ Ah right, totally understandable! πŸ™‚ I've moved "Documentation" out of the "Hover" category and up to a top-level item of its own, so now it can more properly be about just having some way of viewing documentation (regardless of how it's activated). With that reorganisation in place, Racket Mode / Emacs now says "Yes" for that feature. πŸŽ‰ ---
**Author:** ![spdegabrielle](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/spdegabrielle/32/95_2.png) [@spdegabrielle](https://racket.discourse.group/u/spdegabrielle)\ **Post date:** [April 12, 2023, 12:55pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/14 "2023-04-12T12:55:42Z")
I really like this. Just an idea, but would it be better to organise by capability, rather than implementation? this is my attempt with a copy of your sheet using the cells to indicate how it is achieved. ![image](https://global.discourse-cdn.com/free1/uploads/racket/original/2X/7/7761ed8f167e16ded20b606c0a2eb6443f377277.png) [https://docs.google.com/spreadsheets/d/1sg1y\_Ix1BMCxv88DD4w8kCgCqnIlRdvYpvS8epBkNZA/edit?usp=sharing](https://docs.google.com/spreadsheets/d/1sg1y_Ix1BMCxv88DD4w8kCgCqnIlRdvYpvS8epBkNZA/edit?usp=sharing) best regards, Stephen :beetle: ---
**Author:** ![spdegabrielle](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/spdegabrielle/32/95_2.png) [@spdegabrielle](https://racket.discourse.group/u/spdegabrielle)\ **Post date:** [April 12, 2023, 1:11pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/15 "2023-04-12T13:11:35Z")
Ooh I'm excited now... 1. these google sheets allow linking- could the capability(feature) be linked to the documentation for the API? That way if someone decided they wanted a capability in their editor they would at least know where to find the API. e.g. say you want to add 'active `#lang` forms' to the Racket-Langserver 2. Add a column for [GitHub - jeapostrophe/racket-langserver](https://github.com/jeapostrophe/racket-langserver) so it is clear what happens via the LSP and what is part of VSCcode. (I thought Vim used LSP? am I remembering wrong?) best regards Stephen :beetle: (edited to fix unbalanced bracket) ---
**Author:** ![jryans](https://yyz2.discourse-cdn.com/free1/user_avatar/racket.discourse.group/jryans/32/31_2.png) [@jryans](https://racket.discourse.group/u/jryans)\ **Post date:** [April 19, 2023, 1:48pm UTC](https://racket.discourse.group/t/racket-workflow-feature-comparison/1851/16 "2023-04-19T13:48:03Z")
> [@spdegabrielle](#): > > Just an idea, but would it be better to organise by capability, rather than implementation? Hmm, perhaps so, I'll need to keep thinking about it. Thanks for sharing your example sheet. πŸ™‚ At the moment, I'm thinking both ways of organisation have utility, though perhaps for different audiences... I originally started building this sheet to get an idea of how editor features are used across different workflows, so that's why it currently categorised by editor feature and e.g. has multiple cells for given capabilities in different categories based on how the use editor features. As an editor workflow maintainer, I want to be able to track each way of implementing a capability separately so I can clearly see the difference between each toolset. As a user though (which is of course most people), you probably just want to know what features exist regardless of their precise implementation. Perhaps there's a way to support both organisation styles from the same data with e.g. separate tabs for each or something like that. I've added this to a backlog of ideas in the sheet while I think about this a bit more. > [@spdegabrielle](#): > > these google sheets allow linking- could the capability(feature) be linked to the documentation for the API? That way if someone decided they wanted a capability in their editor they would at least know where to find the API. e.g. say you want to add 'active `#lang` forms' to the Racket-Langserver Yes, overall it sounds good to add links to more info on each feature. A lot of them are currently only documented by the one workflow that best supports them, but still linking to that for the feature overall is probably helpful. > [@spdegabrielle](#): > > Add a column for [GitHub - jeapostrophe/racket-langserver](https://github.com/jeapostrophe/racket-langserver) so it is clear what happens via the LSP and what is part of VSCcode. (I thought Vim used LSP? am I remembering wrong?) Ah yeah, it does seem good to track the langserver features separately from the full workflow. AFAIK, at least VS Code and Vim use the langserver, but I'm sure there are others which do so as well. I've added this idea into the sheet as well as a future improvement. Thanks for the feedback, it's quite helpful! πŸ˜„