SpaghettiCode - a Picotron code editor
v0.2.0 - alpha
SpaghettiCode is a code editor for Picotron that aims to provide more features than the built-in code editor, providing a little extra help and quality of life.
Important notes before you start using SpaghettiCode!
SpaghettiCode is in alpha
Please back up your carts before editing them with SpaghettiCode! I am not aware of any bugs or issues that could lead to corruption or data loss, but until it has seen a bit more of a shakedown, I don't want to risk being responsible for anyone losing work.
Also, let me know if you run into weird issues or have ideas! Feedback would be greatly appreciated.
Close files in the in-built code editor (or close the editor entirely)
Having files open in the in-built code editor will prevent them from being saved by SpaghettiCode, meaning any changes made in SpaghettiCode will be lost. Remember the code editor automatically opens main.lua when you start Picotron.
SpaghettiCode doesn't run properly embedded online
It doesn't seem to be able to properly access the ram - so you can get an initial look at it, but if you want to use it, please load it locally with load #spaghetticode-2, then save spaghetticode (or whatever name/location you choose). Saving it is needed so you can then load your own cart that you want to edit.
Features
- Everything the in-built code editor offers (I think?) - syntax highlighting, find/replace, equivalent keyboard shortcuts, etc.
- Additional syntax highlighting
- functions defined by the user are highlighted a slightly darker green. All files included in your main.lua are scanned automatically and functions defined in these will also be highlighted.
- local variables and function variables, allowing you to see at a glance whether you're using a global/local variable.
- table indices (e.g. in table.variable, the variable shows up a different colour, differentiating from other variables.)
- Function tooltips - hover over an in-built or user-defined function and get a tooltip with information on syntax/arguments/use. For user-defined functions, text is drawn from any comments in the lines immediately after the function your_func() line, allowing you to write useful reminders on use for your own code.
- Autocompletion of function names - If you start typing a function name and pause, SpaghettiCode will suggest an autocompletion from its list of inbuilt and user-defined functions. Press tab to accept this suggestion or keep typing to ignore it (or give it more letters to make a better suggestion). Can be turned off in settings.
- Up to 3, side by side files - Right click on a code file in the file navigator on the right to open a new frame side by side. Up to 3 of these can be used at once. You can even open up the same file two or three times to allow you to look at different parts of it at the same time.
- In built code testing - Write your tests for your functions and run them, all within SpaghettiCode. You get a summary of what passed and failed, and a message explaining why a test failed if possible. See further down for more info on how to write/run tests.
Using SpaghettiCode
Mostly, you can use SpaghettiCode very similarly to the in-built code editor - I've tried to make switching as painless as possible. There's a few things it's worth knowing about, though:
Saving
Changes made in SpaghettiCode are automatically saved to the ram (as long as the file isn't open in the in-built code editor!). Then just hit ctrl-s (as usual) to save the ram to the cart.
File navigator
This is the panel on the right side of the screen and shows all of the files currently in the ram. At present, only a cart loaded into the ram can be edited.
The buttons on the left side of the navigator allow you to switch between views - from top to bottom: the main editor, tests, settings, help.
Click on folders to expand them, and click on files to open them. Right clicking opens them in a new frame, side by side with the currently open file. Clicking the 'X' in the top right of a frame closes it.
Click '+new' to add a new file/folder.
Scrolling with the scroll wheel allows you to see more if necessary.
You can collapse the file navigator using the arrow in the bottom left, giving you more screen space for your code.
Keyboard shortcuts
These are mostly the same as in the in-built editor, but listed here for convenience:
- ctrl-s - save the ram to the cart.
- ctrl-r - run the cart in ram.
- ctrl-c, ctrl-x, ctrl-v - standard copy, cut, paste.
- ctrl-a - select all.
- ctrl-f - open the find and replace menu for the current frame.
- ctrl-g - repeat current find.
- ctrl-z, ctrl-y - Undo/redo. Up to 25 undo steps are stored for each file.
- ctrl-b - Comment/uncomment selected line(s)
- ctrl-d - Duplicate the current line
- alt-up/down - shift the current line up/down
- ctrl-left/right - jump one word at a time.
Writing and running tests
Tests are bit experimental - While fully usable, tests are the most experimental aspect of SpaghettiCode at the moment. Let me know if you run into any weird issues with them.
Tests are used to make sure your functions do what they're meant to, and can be helpful as you write and edit code to ensure the components of your program are working how you expect.
To write a test, create a 'tests' folder inside /ram/cart/. Within this, create a new code file, e.g. 'tests.lua'. Test can be placed in any number of files or subfolders within /ram/cart/tests to help with organisation.
Tests within each file then look like standard Picotron functions and should call a function you've written and use an assert (or multiple) statement to ensure it's producing the expected outcome.
For example, a simple test might look like:
function test_two_plus_2() local expected = 4 local result = two_plus(2) -- two_plus() is the func we're testing assert(result == expected, "Expected 4, got "..tostr(result)) end |
A file can contain as many tests as you like, just defined in different functions.
If you've done it right, your tests should appear in the tests view (checkbox icon on the file navigator). Click 'RUN ALL' to run them.
NOTE: When testing your code, SpaghettiCode only loads the functions and DOES NOT run _init(), _update(), or _draw(). If there are any global variables that need to be initialised for your function to work, initialise these within the test.
Planned Updates/Features
- Polish - currently the presentation is a bit bare-bones in a lot of ways
- Goto - jump to any file or defined function by typing its name
- Find/replace across files
- Ability to delete/move files within the file navigator
- Multi-line comment shortcut (e.g. ctrl-shift-b)
- Display of gfx pods in the editor
- Handling of different environments for user function recognition.
- Multi-cursor editing.
- Your suggestion here!
Changelog
excellent :) thank you
As "Slate" would it be possible to add a button to start the program? (ctrl-r) and button (ctrl-s)
Superb!
Just what I needed to better explore and understand existing projects. What I was looking for in an external IDE, I found inside Picotron itself, and that's pretty cool.
At first glance, the Home and End keys don't seem to be implemented in the same way as the basic editor (at least, nothing happens in my case) same for Page Up & Page Down.
@heliuse - Sure, can add graphical buttons for those too to compliment the keyboard shortcuts.
@Armitage1982 - Ah, I knew I missed something. You're right, they're not implemented but that should be an easy fix. Will sort that soon. Thanks for flagging!
I took a lot of notes while messing around with it. SpaghettiCode is quite impressive, though there's a bunch of small things that put me off from really wanting to use it though.
undos should really not be limited to 25. if you're really worried about running out of memory, you can track it with stat(0) and cut off undos when getting close to a lower bound. I can't remember the memory limit though. or maybe just add a setting for it.
If you want to get REALLY crazy with it, add an undo"tree" instead of a "stack". (I never used it before though and it might be a bit much for picotron.)
I would recommend not using double click to jump to a variable's/fuction's definition as it interferes with selecting a whole word. Maybe ctrl+(some key). Pico8 does use ctrl+u to display the description of the function below the text cursor.
multi-line comments aren't highlighted properly
also maybe add ctrl+shift+b for multi-line commenting/uncommenting
hexadecimal and binary number formats aren't being highlighted
(would like) alt+up/down to shift current line or selected lines in that direction
(would like) triple click for selecting whole line
missing ctrl+d for duplicate line
missing end/home keys to go to the end/start of a line
missing ctrl+left/right to jump between words
missing pageup/pagedown
missing x position memory for when pressing up/down
if test > 0 then| f() elseif test < 0 |then -- cursor "|" should move to the one below after pressing down twice -- even though there's a lot of missing characters after "f()" end |
also pressing up/down will count tabs as single characters instead of 3, resulting in changing x position
missing gfx pod displaying :(
(copy sprite from gfx editor and pasting it into code)
ctrl+b for UNcommenting can result in the cursor disappearing when positioned at the start of the line (probably at position -1)
infact, the position of the cursor doesn't properly move with the text during ctrl+b
can't press undo until 1 second after the last thing that was typed
I would recommend speeding up the find window sliding in and probably use a smoother interpolation function for a nicer look
maybe smoothstep x * x * (3 - 2*x) (this is from 0 to 1)
same with the file view buttom (the arrow on the bottom right)
pressing ctrl+f doesn't do anything when the find field is selected
when the code is currently focused, the find window closes
(other editors I use have ESC to close the window, but that's reserved for openning the terminal)
also would probably be a good idea to add the highlighted text to the find text box when pressing ctrl+f
maybe move the boxes with "find and "replace all" on the same y position as their fields to save on space
could change replace with "replace all"
also give them proper highlighting on mouse over/down since they appear to be buttons
is it possible to have the documentation placed just before the function call instead of inside?
a lot of my code is already using this format and it might be the more common one for lua
though I know inside the function is the format for python
would like allowing for openning other file extentions other than .lua if they're recognized as text files.
mostly .txt and .md, but I have a custom file extention ".pepper" for my preprocessing code.
got an error pressing enter (for a new line) at the very bottom of the page and pressing undo
/desktop/SC.p64/src/input.lua:12: attempt to index a nil value (local 'ln') stack traceback: /desktop/SC.p64/src/input.lua:12: in function 'xisp_update_line_input' /desktop/SC.p64/src/frame.lua:168: in function 'xisp_update_line_input' /desktop/SC.p64/main.lua:293: in function 'xisp_update_editor' /desktop/SC.p64/main.lua:248: in function '_update' |
incorrect syntax highlighting in some cases
-- example
-- first w is white and not the parameter color, later w is green and counted as the function name
d2.param.sprite = function(w, h)
func(d2, w, h)
end
-- also d2 is a table, but is shown as grey
-- defined like this
d2 = {param = {}} |
multi-cursor editing? not really a necessity and could be a bit difficult.
One thing that might be hard to get working is function tooltips with how I'm currently implementing a couple of my projects with encapsulated environments. for instance in picotron solitaire suite, each gamemode gets their own _ENV and automatically have a set of functions included rather than the gamemode itself calling include. This is largely because I wanted to keep the files safe from eachother. Also making it easier to get the functions since the gamemode files could be stored in multiple locations. One thing that could be done with this is to add an option to export a .json file contining function definitions, similar to what this editor uses, and adding another option to load it when a specific file/project is open.
Hopefully these are useful.
@Werxzy - Wow, that is very thorough and definitely very useful. Thanks very much for taking the time to try stuff and write that up. A lot of that should be relatively easy to address - things like missing keyboard shortcuts or most of the changes regarding find/replace. I'll add it all to my 'to investigate' pile at least, though, and really do appreciate it.
Amazing work so far! I've only played with it a little but I like it a lot already, it feels really nice to use.
Only suggesstion I have at the moment is a fullscreen/workspace mode: I know it's difficult or impossible to switch between fullscreen and windowed modes of a cart rn, but I wonder if you could have a setting that applies upon the next launch? I'm not very familiar with this yet so it may not be possible!
a bug I found:
I had a cart loaded to ram, then I started up spaghetticode, and by default it was open on that cart's main.lua. Then, I loaded a new cart into ram (which also has a main.lua file). I refreshed from the file menu, but spaghetticode kept the previous cart's main.lua, even after I opened another code file and then opened main.lua again. In both cases while spaghetticode was open, picotron's native code editor had the current cart's main.lua file open in a tab. I don't remember much more than that but I think it shouldn't be hard to reproduce.
Can't wait to see where this goes!!
@xietanu
the 'jump to definition' double-click shortcut no longer seems to work in the new version-2 of SpaghettiCode.
Also, I noticed that editing files around 1000~2000 lines, depending on the system, lead to significant drops in performance.
While trying to edit bigger files, like the nice Geo2D library from Eigenbom, will inevitably crash into “Out Of Memory” (to about ~4060 lines of this single-file library of 192Kb).
I guess that, from the user's perspective, splitting this library into several small files would be a good practice to this issue.
I understand that Picotron is a matter of limitation. But it's going to be tough to get such a rich editor under 16Mb and on par with the built-in editor in terms of loading file size.
nice update!
more things I found in 0.2.0:
ctrl+left and ctrl+right have slightly different behaviours for spaces. right skips spaces while left doesn't (not sure which is the correct one)
people will probably want a monospace font option.
while shifting a single line up or down wiht alt+up/down is nice. highlighting multiple lines and being able to shift them all up or down would help a lot.
hmm, having the find window open, highlighting another word, and pressing ctrl+f just closes the window rather than adding it to the list. attempting to change might just make it awkward to use in a different way.
also pressing ctrl+g while the find window is focused should probably function the same as when the code view is focused
While searching, if the found word is too far across the line, it won't be in view. probably adjust the horizontal scroll to make it visible.
no horizontal scroll limit? Might not be that much of an issue.
Seems to struggle with metatables or metatables haven't been checked for. Guessing that would be a bit difficult to implement.
you might give self special highlighting.
non lua files could probably have syntax highlighting disabled.
forgot to mention multiline strings oops. (after I saw multiline comments not being highlighted correctly before)
no idea what happened here, but got another error. I think when selecting multiple lines and pressing space?
might have been while partially selecting a function declaration that had comments before and after it.
/desktop/SC.p64/src/token.lua:338: bad 'for' initial value (number expected, got nil) stack traceback: /desktop/SC.p64/src/token.lua:338 in function 'xisp_sub_tokens' /desktop/SC.p64/src/functions.lua:?? in function 'xisp_generate_user_func_tooltip' /desktop/SC.p64/src/frame.lua:?? in function 'xisp_update_frame' /desktop/SC.p64/main.lua:?? in function 'xisp_update_editor' /desktop/SC.p64/main.lua:?? in function '_update' |
(I was copying by typing them out rather than ctrl+c, so some of it is incorrect)
highlighting for hexadecimal numbers is still a bit off. hex numbers a to f break the highlighting.
btw, it's possible to have decimals in the hexadecimal and binary numbers
0xabc.def and 0b11.11 are valid in picotron.pico8
undoing/redoing should probably jump to the line where changes happen.
maybe have the cursor placed at the changes? not entirely necessary though.
one case you might consider checking that it works comfortably, is when the changes during undo/redo results in deleting the entire line while the view is scrolled horizontally to the right. putting the end of the line off screen to the left.
(forgot to update the version number of the cart, still says 0.1.0)
to slightly increase screen space for the code, you might reduce the width of the line numbers take up when they're below 1000 or based on the pixel width the largest displayed number.
mostly would be helpful for when multiple files are open.
A neat feature you could add is a TODO list checker.
Usually when I code, I just add --TODO: ... wherever I'm going to need changes.
Basically finds comments with start with TODO. Then there would be a button for a different view that would list all the TODO comments and clicking them would jump to the comment. THOUGH this would almost be replaceable with the search that's across files.
option to disable case-sensitivity for searches?
not necessary, but one thing I got comfortable with in vscode was ctrl+p. being able to type in the name of a file and getting a list of loosely matching file names to open
@Armitage1982 - the double click to jump has been taken out for the moment. I'll put it back in, just considering the best approach for it.
And yeah, I think that may just be a limitation for particularly big files/projects. I'll keep looking for ways to reduce the memory footprint/improve performance (and I have some ideas), but I think that not getting to use some of the richer features of something like SpaghettiCode may just be a necessary trade-off given the limitations of the system.
I don't have a great sense yet of what a 'typical' Picotron cart looks like as it's early days - a lot of the carts I took a look at were 1-10 files of a few hundred lines of code, which generally work fine. Certainly if this is a problem being run into with a lot of carts, I'll prioritise the performance more.
One thing that might be possible is a 'low memory mode' where some features are disabled to allow for a smaller memory footprint. Will have think about that, though, as if it just gives basically the same features as the inbuilt editor, there's not too much point.
@Werxzy - thanks again for the feedback, very helpful. Honestly, I didn't know multiline strings were a feature in Picotron/Lua, so I've learned something new! The ctrl-p you mention is broadly what I had in mind for the 'goto' function I have planned, agree it's very useful.
@xietanu - Yes, that's exactly what I was thinking. Disable the features that take up the most memory when the file to be opened reaches a certain size, or a manual switch if the editor underperforms.
At least, before going into wild optimizations :-)
But these are delicate suggestions to evoke when, like me, you're not yet familiar with Picotron.
I also noticed that the Enter key on the Numpad didn't work like the main Enter key, but this is also the case in the built-in editor. I wonder if, at the moment, this is the kind of problem that can be solved in a cartridge without modifying the workstation.
In any case, this editor is brilliant.
Thanks
@Armitage1982 - glad you like it!
I'm pretty sure it's not brilliantly optimised at the moment, so I'm sure there will be ways to handle bigger files. It's just a bit of balancing act between processing and memory - using less memory usually means doing more processing each frame and vice versa.
Regarding the enter key on the numpad - I admit hadn't noticed this as the main keyboard I use doesn't have a numpad. I will dig one out which does and see if it's an easy fix. It oddly might not be as the key function isn't super well documented yet, so I'm not sure off hand what to check for for the numpad enter.
[Please log in to post a comment]
