Widget messages #449
Widget messages #449
Conversation
There was a problem hiding this comment.
Over all, these changes look good to me now. I wasn't involved in the original conversation, but I do wonder whether it would make sense to have separate contexts for the different use cases of PosContext in case these won't overlap as nicely as they currently do in the future, or just to make the type name better describe which position is actually provided by the context.
This could be a good idea; any suggestions? |
Allows embedding user widgets in structured messages. Companion PR is leanprover/vscode-lean4#449. Some technical choices: - The `MessageData.ofWidget` constructor might not be strictly necessary as we already have `MessageData.ofFormatWithInfos`, and there is `Info.ofUserWidget`. However, `.ofUserWidget` also requires a `Syntax` object (as it is normally produced when widgets are saved at a piece of syntax during elaboration) which we do not have in this case. More generally, it continues to be a bit cursed that `Elab.Info` nodes are used both for elaboration and delaboration (pretty-printing), so entrenching that approach seems wrong. The better approach would be to have a separate notion of pretty-printer annotation; but such a refactor would not be clearly beneficial right now. - To support non-JS-based environments such as https://github.com/Julian/lean.nvim, `.ofWidget` requires also providing another message which approximates the widget in a textual form. However, in practice these environments might still want to support a few specific user widgets such as "Try this". --- Closes #2064.
|
Hmm, the only reasonable name I can think of is something like |
|
Okay, renamed to |
Implementation of leanprover/lean4#2064. Besides adding support for widget messages, this adds an `EnvPosContext` that stores the position that a component is "about" (see the docstring for more detail). This was originally proposed in #197 and eventually dismissed (see #226 for a detailed discussion), but I think it warrants a reconsideration. While Gabriel's point that there are many positions around remains true, the `EnvPosContext` stores a very specific one. This position is only used to retrieve a snapshot, and from that a `Lean.Environment`, on the server-side. Widgets currently have to pass this position around manually; this has led to [errors](leanprover-community/ProofWidgets4@ca66ebb) in user code. Furthermore, so far I have not encountered any situation where it makes sense to modify the position; thus a context seems like a preferable approach. If needed, the context can still be set by users. I also had to update some package versions to have tests building again. I hope that didn't break anything!
Implementation of leanprover/lean4#2064. Besides adding support for widget messages, this adds an `EnvPosContext` that stores the position that a component is "about" (see the docstring for more detail). This was originally proposed in #197 and eventually dismissed (see #226 for a detailed discussion), but I think it warrants a reconsideration. While Gabriel's point that there are many positions around remains true, the `EnvPosContext` stores a very specific one. This position is only used to retrieve a snapshot, and from that a `Lean.Environment`, on the server-side. Widgets currently have to pass this position around manually; this has led to [errors](leanprover-community/ProofWidgets4@ca66ebb) in user code. Furthermore, so far I have not encountered any situation where it makes sense to modify the position; thus a context seems like a preferable approach. If needed, the context can still be set by users. I also had to update some package versions to have tests building again. I hope that didn't break anything!
See #449. Co-authored-by: L Lllvvuu <[email protected]>
Implementation of leanprover/lean4#2064.
Besides adding support for widget messages, this adds an
EnvPosContextthat stores the position that a component is "about" (see the docstring for more detail). This was originally proposed in #197 and eventually dismissed (see #226 for a detailed discussion), but I think it warrants a reconsideration. While Gabriel's point that there are many positions around remains true, theEnvPosContextstores a very specific one. This position is only used to retrieve a snapshot, and from that aLean.Environment, on the server-side. Widgets currently have to pass this position around manually; this has led to errors in user code. Furthermore, so far I have not encountered any situation where it makes sense to modify the position; thus a context seems like a preferable approach. If needed, the context can still be set by users.I also had to update some package versions to have tests building again. I hope that didn't break anything!