You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
maiden uses a customized ace editor mode to provide an editing experience tailored to lua for norns. out of the box, ace provides basic client-side syntax highlighting and a web-worker-based syntax checker. though we've done a bit of customization already, there's a limit to how much we can change practically. notably, the syntax checker is not easily enhanced or replaced and even trivial changes to the parser are tricky to integrate (see: #9) .
work on the client-side has more fundamental limitations as well. doing semantic analysis in the browser (to provide, for example, awareness of norns functions or offer lua linting) is not practical. nor is rich code transformation (such as formatting or refactoring).
as alluded in #125, i've been playing with some ideas and have them far enough along that i'd like to open up a proper conversation. my WIP, called "scry" is up here:
it demonstrates server-side static analysis and linting and on-demand lua formatting.
the scry server is tiny and mostly lua, leveraging two lua libs: luacheck for static analysis and lcf for formatting (both are small and seem stable); it's wrapped in a small node server. were scry to be integrated into norns in a first class way, i'd imagine scry would run along-side matron and crone in much the same way (e.g., using ws-wrapper or similar, but certainly not node).
needless to say thoughts and considerations welcome! 👍
The text was updated successfully, but these errors were encountered:
maiden uses a customized ace editor mode to provide an editing experience tailored to lua for norns. out of the box, ace provides basic client-side syntax highlighting and a web-worker-based syntax checker. though we've done a bit of customization already, there's a limit to how much we can change practically. notably, the syntax checker is not easily enhanced or replaced and even trivial changes to the parser are tricky to integrate (see: #9) .
work on the client-side has more fundamental limitations as well. doing semantic analysis in the browser (to provide, for example, awareness of norns functions or offer lua linting) is not practical. nor is rich code transformation (such as formatting or refactoring).
as alluded in #125, i've been playing with some ideas and have them far enough along that i'd like to open up a proper conversation. my WIP, called "scry" is up here:
https://github.com/pq/scry
it demonstrates server-side static analysis and linting and on-demand lua formatting.
the scry server is tiny and mostly lua, leveraging two lua libs:
luacheck
for static analysis andlcf
for formatting (both are small and seem stable); it's wrapped in a smallnode
server. werescry
to be integrated into norns in a first class way, i'd imaginescry
would run along-sidematron
andcrone
in much the same way (e.g., usingws-wrapper
or similar, but certainly not node).needless to say thoughts and considerations welcome! 👍
The text was updated successfully, but these errors were encountered: