Feature Enhancement: improve sketch error messages in the editor console

Increasing Access

this would make the editor significantly more welcoming for beginners and learners. right now when a sketch has an error, the in editor console often shows a very short or vague message without any line number or location. to actually figure out what went wrong, a user has to know that they can right click and open the browser dev tools, which most beginners and students won't think to do. improving the in editor error messages means new programmers can debug their own sketches without needing to learn a separate developer tool first, which directly lowers the barrier for people who are just starting out with p5.js.

Feature enhancement details

the in-editor console currently surfaces a much less useful version of sketch errors than what the browser dev tools show. for example, a syntax error in the dev tools will include the file along with the exact line and column, whereas in the editor console the same error often appears as a short message with no location, or sometimes does not show up at all.

after looking through the codebase, it seems like a few gaps contribute to this:

• syntax errors from the parser appear to get silently swallowed before reaching the console
• the runtime error pipeline handles different error types inconsistently (e.g. unhandled promise rejections include stack traces, but regular errors often do not)
• error information is concatenated into a plain string before being sent to the editor, which makes it difficult for the console ui to present useful details like file names or clickable line references

a few ideas for improvement:

• capture syntax errors with accurate line and column information and forward them to the console
• ensure all error types consistently include full stack traces
• send error data as a structured object instead of a concatenated string, so the editor can render richer information (file, line, column, clickable links, etc.)
• improve the mapping between generated iframe code and user source so reported locations are always accurate

i would love to work on this! . wanted to open this discussion first to check if this direction aligns with expectations, and whether there are any constraints or prior discussions i should be aware of.

No files or tests are named. Start by tracing how parser and runtime errors move through the generated iframe into the in-editor console, compare that output with browser dev tools, and clarify a narrower first milestone with maintainers before changing the error representation or source-location mapping.