Let me know about Slynk problems

[joaotavora]

Not a bug, SLY's author here. I think this project is interesting, even though it will inhibit some design decisions on SLY's side. This is not a bad thing. If you come across any API difficulties or Emacs-specific stuff, let me know in the SLY bug tracker. Maybe this could be the kickoff for making Slynk a standalone package once and for all.

[s-clerc]

, even though it will inhibit some design decisions on SLY's side.

What are your concerns? The architecture of this plugin is based primarily around SLIMA and I don't think they had any issues, although SLIME isn't really adding new features.

If you come across any API difficulties or Emacs-specific stuff, let me know in the SLY bug tracker.

I'll probably file bug reports a bit later, but I just wanted to give my initial run-down:

In terms of API difficulties, the main issue was the stickers API. I couldn't for the life of me figure out what the numbers that we would get when querying the stickers meant and how we should figure out where they should be placed.

Apart from that, the other difficulty I encountered was that the data was expressed as s-expressions. The issue was that alists, plists and normal lists are basically the same format so I have a lot of code converting them to dataclasses in my code which could've been avoided if say JSON were used. Then my code could automatically convert the packet into a dataclass rather than needing me to manually parse it and therefore specify the schema in my code. If we included a type parameter with every JSON object then it would be trivial to convert it into a Python or Lisp struct. Even if JSON isn't used, abolishing plists and exclusively using alists would already be a big gain in terms of ease of parsing.

For the inspector, because the text doesn't really carry its semantics with it, I couldn't pursue alternate display opportunities like representing it as a folding table.

I noticed that positions seem to index lines in N* but index characters in N which was a bit jarring, at least since ST does both in N.

[joaotavora]

What are your concerns?

It's just that now that another program is being built on top of Slynk, I can't rearrange the API at will without breaking stuff. Not that I was going to, at least gratuitously...

In terms of API difficulties, the main issue was the stickers API. I couldn't for the life of me figure out what the numbers that we would get when querying the stickers meant and how we should figure out where they should be placed.

Stickers are numbered on the client side. You must find some way to manipulate text in Sublime so that multiple levels of "overlays" be placed on top of forms. Then, when compiling a form (or a file) where you detect there are stickers, you must take special actions (among which are numbering the stickers, injecting the wrapper forms/instrumentation code, and compiling the thing twice!). When stickers are registered on the server side, running the instrumented code will produce recordings. Then there are 3 separate ways of "querying stickers": fetching recordings onto the source, replaying a batch of recordings, and just letting stickers run until they break. If the Debugger is already working, you should probably just focus on the last and then the second to last. The numbers involved in the messages should always be sticker ids. I suppose you read the source both the CL and Emacs Lisp? Let me know which comments and or docstrings you think could be clearer.

Even if JSON isn't used, abolishing plists and exclusively using alists would already be a big gain in terms of ease of parsing.

I'm afraid JSON would be an entirely alien thing to SLY/Slynk (and to SLIME). But in terms of parsing, I don't understand why alists are simpler than plists. I suppose you should have some Javascript helper which makes a JSON Object out of each (of course you have to know in advance if you're parsing a plist of an alist, is that a difficulty?)

I noticed that positions seem to index lines in N* but index characters in N which was a bit jarring, at least since ST does both in N.

Can you explain this part?

[s-clerc]

replaying a batch of recordings

Specifically this query:

 (slynk-stickers:search-for-recording 'stickers-replay-0
                                      '(3)
                                      'nil 'nil 1 'nil)
 nil t 113)
(:return
 (:ok
  (4885 118 1 4735 119 3807350619
        ("3 (2 bits, #x3, #o3, #b11)")
        nil))
 113)

I only know what the first three numbers mean in the response.

I'm afraid JSON would be an entirely alien thing to SLY/Slynk (and to SLIME). [...] (of course[,] you have to know in advance if you're parsing a plist o[r] an alist, is that a difficulty?)

Yeah, I found keeping track of alists vs plists to be a bit of a pain. But I can completely understand that using JSON in lisp is very icky.

Can you explain this part?

Sorry, I meant 1-indexing vs 0-indexing. Slynk expects me to send the first character of the first line as (1; 0) not (0; 0) which is inconsistent.