Hello! This is my first post here :)

I've played around with Picotron in the past week and have some suggestions and ideas that I'll throw here:

• Userdata Views - I can make a whole post about this alone, but basically I'd really like userdata to work like numpy, based around views. This is a generalization of slices (also in 2d), casting to different data types, reversing of userdata, looking at every other value, and much more. This allows code to be a lot more generic and easier to understand, and by having it be builtin to the way userdata works it ensures the obvious and clean code is cheaper in terms of cpu time.
• Mixed Types Userdata Operations - For example, matrix multiplication currently only works on two f64 userdata, and I came up with a cool usecase for f64 * u8 -> u8 matrix multiplication to efficiently do base64 encoding:

  I can't think of an intuitive default for a result type or good way to let the user choose it...

• Allow Fetching More Things - There's a discussion to be made about if fetch should be "nerfed", but as it currently is it's pretty arbitrary that it only allows you to fetch certain things like json, pods and pngs, but not others. It's not that big of a deal if you also write the backend but that's not always possible or forces you to use a proxy. This also goes for other limitations like changing the http method, supplying headers, etc. they are added complexity but they could work in a way that is opt-in for the user, exactly like the web fetch.
• Wayland Support - currently SDL2 seems to be statically linked into the executable, with only the X11 backend enabled on linux. This makes it very stuttery on certain environments, especially in windowed mode. There are additional backends that would be cool to have, like the framebuffer backend to run dedicated picotron machines on e.g. single board computers. Linking SDL2 as a shared library and providing SDL as a shared object with the installation will make it possible to override it with the system version of SDL2.
• Intuitive Open File Menu Item - Currently the "open file" menu item opens the current file in Filenav instead of the usual meaning of opening a file chooser to select a file to open. The current behavior is usually called "Reveal/Open/Show in Filenav", and should probably have a different icon than the one for saving. As far as I can tell the only way to open files in a program that is tabbed is closing the program and reopening by clicking the file or giving it as a command line argument.
• More Desktop Shortcuts - It would be nice to have shortcuts to open the terminal, open the Filenav, switch workspaces (just discovered ctrl + 1 hides the workspace bar while testing it, neat, also code editor doesn't fill up the extra height it's given when doing this), and things like that. Even something analogous to Super + Click + Drag on linux to move/resize windows.
• Context Menus - Currently there are very few places with context menus, apps like Filenav should really have them it's breaking my muscle memory, I right click and accidentally open things all the time :|
• Dark Interface and Colors - This one might be a bit controversial but I feel like there's a big lack of dark natural colors. The only colors that can work as a dark background in most cases is 0 (black) and 1 (dark blue), I think a dark natural color (somewhere around #1b1b1b) would go a long way, maybe in place of one of the blues/oranges (12 and 16, and 9 and 25 look really similar to me, although my display has awful color accuracy so I'm not sure). That will make a dark mode setting feasible (opt-in by the apps of course, terminal should always be white on black).
• Code Editor Themes - This also goes for gui_ed.lua in general, it only takes bgcol and fgcol, making the number display (and probably syntax highlighting, haven't tested it yet) pretty broken when you change theme. They could then be accessible from within the code editor.
• Follow XDG Basedir Spec - This is a very minor nitpick, but it would nice to follow the xdg basedir specification for storing the Picotron files instead of ~/.lexaloffle/Picotron. This can be done in a backwards compatible way, first check if ~/.lexaloffle exists and use that if it does, before using the new logic to get the location.
• Increase Stack Limit from 100k - The only way to convert userdata to string I found is to unpack it into chr, and you hit with limit when working with userdata the size of the screen, In my case 518,400. Maybe it can be increased to a million?

Sounds good to me! On NumPy views, here is the manual entry on those. I especially like the idea of enabling more generic/agnostic code and efficiencies of operating with view instead of copying the data buffer.

Also adding enough darker tones to enable functional "dark mode" is basically an increase in accessibility, and a pretty easy one at that.