Reproduction steps:

1. Change the canvas to a non-default size (e.g. 8 width, 5 height)
2. Press cmd-R or open canvas size modal manually
3. Press cancel

The canvas will then be set to 10x10 even though no changes should occur.

(Thanks for this IDE; it's great!)

reproduce the issue

• Drag and drop an image onto the Pietron window

Observed result

• Since it is fundamentally a web browser, the Pietron window transitions to the image itself
• Once this happens, it becomes completely stuck and unusable
  

Expected result

• Pietron loads the image as a valid Piet program, just as it does so when the image is supplied by File → Open

It would be of great help to add an analysis mode, a mode where you can trace an execution path and the codels get decompiled (e.g. dup 5.push greater point 5.push sub) according to the path.

Another issue on here suggests adding a "Selection Mode", that lets you copy/paste/etc parts of the image, and dubs the current default mode "Paint Mode". After having downloaded this IDE and played around with it a little, I think I also have some ideas for improving the Paint Mode:

• Line tool that draws a straight vertical or horizontal line of the selected color
• Rectangle tool that lets you draw a solid box of a given color
• Bucket tool that fills a contiguous area of one color with a different color, MSpaint style
• Something to show how many pixels are in a given color block, either when you hover over it or as some sort of overlay on the pixels

While String.fromCodePoint is handled in L341-345,

it is not handled in L249-251.

This causes Pietron to fail:

In my opinion, invalid code points qualify as "operations which cannot be performed", and hence should be ignored.

Since the full state machine is relatively simple, it is quite feasible to retain the history of the step execution (~1000 steps to the past) in memory and allow undoing a few steps back into the past. This becomes quite handy when debugging a complicated Piet program: for instance, a wrong CC might cause the path of execution to leak into an unintended area and wreak havoc, and in those situations it becomes convenient to be able to roll back a few steps.

Reproduce the issue

• Move the mouse pointer between the canvas and the I/O text areas

Observed result

• Nothing happens

Expected result

• A cursor: row-resize appears and allows dragging and adjusting the visual boundary

Since the current implementation does not allow the image to be edited while executing, it is confusing for the cursor to remain cursor: pointer when in the debug mode. A semantically better option is the use of cursor: not-allowed.

When integers are separated by something else than whitespace In(n) removes all characters until the next whitespace.

Example

input is "2-4,6-8 2-3,4-5" and In(n) is executed

Expected behaviour

2 is pushed onto the stack and input is "-4,6-8 2-3,4-5"

Actual behaviour

2 is pushed onto the stack and input is " 2-3,4-5"

Selection Mode should at least have:

• Rectangular selection
• Copy
• Paste ignoring white codels
• Paste retaining white codels
• Rotate the selected area

It might also be a good idea to have:

• Modify the hue & lightness
• Flip the selected area

As a side effect, the current UI should be dubbed as the Paint Mode.

Change the canvas size one by one with CTRL+ALT+[↑↓←→] (⌥⌘ on OSX).

The current keyboard shortcuts for resizing the canvas can be reinterpreted as:

This reinterpretation begs for the addition of four new keyboard shortcuts:

To further facilitate the intuitive understanding of these eight shortcuts, it might help to add an icon similar to cursor: move in the top-left and bottom-right corners, and make it highlighted whenever Ctrl + Alt or Ctrl + Shift is pressed.