-
I am attempting to modify the behavior of the Latex - Endless list example on the wiki to effectively reverse the order of operations between choosing and jumping. In the wiki example, to make a new entry in the list, you must first jump to an invisible node then change it to a new list entry. My goal is to first make the new list entry then be able to jump to it. The snippet below achieves this functionality, but introduces another issue. If I write some text on one item then attempt to create a new list entry, the text I previously wrote is removed. local recursive_list
recursive_list = function()
return sn(nil, {
c(1, {
sn(nil, {t({"", "\t\\item "}), i(1)}),
sn(nil, {t({"", "\t\\item "}), i(1), d(2, recursive_list, {})})
})
})
end
s("ls", {
t({"\\begin{itemize}"}),
d(1, recursive_list, {}),
t({"", "\\end{itemize}"}),
i(0)
}), I was hoping to use restore nodes to save the text between choices, but it seems I have no idea how to properly use the restore node functionality. My attempt is below, but it errors when attempting to make more than 2 items. Any advice would be appreciated. local recursive_list
recursive_list = function()
return sn(nil, {
c(1, {
sn(nil, {t({"", "\t\\item "}), r(1, "test", i(nil))}),
sn(nil, {t({"", "\t\\item "}), r(1, "test", i(nil)), d(2, recursive_list, {})})
})
})
end
s("ls", {
t({"\\begin{itemize}"}),
d(1, recursive_list, {}),
t({"", "\\end{itemize}"}),
i(0)
}), Here is the error message:
|
Beta Was this translation helpful? Give feedback.
Replies: 1 comment 1 reply
-
Oh, one immediate problem (not completely sure if that is exactly what's going on here, but it could definitely lead to bugs) I can spot is that only one restoreNode with a given key may be visible at any time, so you'd have to somehow generate a different key for each depth. I don't think that's easy to do, so I'll instead recommend the dynamicNode with user input, which makes these recursive-choiceNode cases much cleaner and easier to handle (although it requires a bit of code for setup) |
Beta Was this translation helpful? Give feedback.
Oh, one immediate problem (not completely sure if that is exactly what's going on here, but it could definitely lead to bugs) I can spot is that only one restoreNode with a given key may be visible at any time, so you'd have to somehow generate a different key for each depth.
I don't think that's easy to do, so I'll instead recommend the dynamicNode with user input, which makes these recursive-choiceNode cases much cleaner and easier to handle (although it requires a bit of code for setup)