Vec
is what you want. You probably want a struct
for the data we're goung to pass, then a trait to convert it to the right Python data type on the way out. The Lua one needs something like that too actually. What I have is a quick hack to stuff the Lua output table directly but I should have used a Struct with a conversion trait.
The interesting thing is if we get this right we should be able to swap out parts and use Pandoc (or
commonmark-hs+pandoc
extensions when it has them) and get syntax highlighting based on the actual parser.
Yeah, the pulldown-cmark find was really nice because it gave us something to try this idea on.
nvim__buf_set_luahl()
(docs).
Start
events, we also need to capture the offsets of Code
, Html
, FootnoteReference
, Rule
, and maybe HardBreak
.
nvim_buf_get_extmarks(0, ns_id, 0, -1, {})
(this emits output like: [[85, 0, 0], [86, 1, 0], [87, 2, 0], [88, 3, 5], [89, 3, 15], [90, 5, 6], [91, 6, 0], [94, 6, 53], [92, 7, 0], [93, 8, 0], [95, 10 , 0], [96, 11, 0]]
). But I can't find a way to retrieve the hlgroups.
line2byte()
(nvim_buf_get_offset) that you can query with any buffer handle, but you have to rely on running a callback on the viml interface for byte2line()
and assume the current buffer isn't something else when you do?
I also found we don't only need to capture the
Start
events, we also need to capture the offsets ofCode
,Html
,FootnoteReference
,Rule
, and maybeHardBreak
.
What do you mean by "capture the offsets" here? You mean figure out what is the delimiter for the syntax element and what is the text element inside it?