* Use the `target-name` argument in `jupyter-handle-comm-open`
* Remove hard-coded URL format and use the new variable
`jupyter-widgets-url-format` instead
* Add `jupyter-widgets-supported-targets` to explicitly state which widget
targets are supported
* Rename `widget-proc` to `widget-sock` in a `jupyter-widget-client`
* Initialize the widget socket only when opening a valid comm
* Previously it was initialized when the client was initialized, but a client
may not even create any widgets so the widget socket would be unused.
* Use `pcase` in `jupyter-widgets-on-message`
* Update documentation and commentary of `jupyter-widget-client`
This introduces a way of keeping track of both the encoded and decoded parts of
a message, only decoding the parts of a message when needed, and only encoding
the parts of a message when needed.
If the objects passed to `jupyter--encode` or `jupyter--decode` are lists with
the first element being the symbol `message-part`, then the second element of
the list is interpreted as being the encoded message and the third element
being the decoded part of the message. If either the encoded or the decoded
part are nil, then `jupyter--encode` or `jupyter--decode` will fill those
message parts in and on subsequent calls, passing in the same list, no work
will need to be performed.
This avoids double encoding messages when relaying messages between the channel
subprocess and the browser displaying widgets. This speeds up the communication
process. The cost is storing two representations of the same message, i.e.
speed vs memory.
Fixes:
- Use `eq` instead of `equal` in message status predicates
- Fix time string decoding
- `parse-time-string` was returning all nil on Emacs 26
- Include validation for parent header in `jupyter--encode-message`
- Use `jupyter-message-header' to access the message header instead of `plist-get`
