Sounds like a great idea to me. Implementation wise do you have an idea of how to do this?

what about a spinoff of FAQ? like frequent code mistakes, super short?

• in JavaScript, case matters. we use setup(), not Setup(), or SETUP(). JavaScript treats uppercase and lowercase as totally different characters.
• for p5.js variables we use camelCase, such as createCanvas or mouseClicked. camelCase is writing two or more words, where the first one is lowercase and each new word starts with uppercase.

Implementation wise do you have an idea of how to do this?

@limzykenneth
I have a rough flow in mind.
There are two types of mistakes that can occur.

• One is when referencing a predefined p5 symbol like createCanvas, color, mouseX, etc. For this, the first step would be to build a dictionary of everything in p5 that can be referenced by the user. This is already done for misusedAtTopLevelCode so I think I can just reuse it. We set up an error listener and when a ReferenceError occurs like createcanvas is not defined, we identify the object in it (createcanvas in this case) and run it through a word distance search against the dictionary. If the returned minimum distance is below a certain threshold, we have a likely candidate.

• The other type is when defining functions such as setup, draw etc. These get attached to either the window object in global mode, or the context passed in instance mode. We could then run through it and apply the word distance search. The dictionary used here is much smaller, only consisting of names that are to be defined by the user.

I am not yet sure about the exact specifications of the word distance algorithm. I have been reading on various ways it can be implemented to find something which fits here. I can also set it up so that capitalization has a smaller distance as compared to letter differences.

what about a spinoff of FAQ? like frequent code mistakes, super short?

@montoyamoraga Yes! We could also add this to the wiki I think.

@akshay-99 that sounds awesome!

yeah i have been thinking about ways to have less people post issues here when they are having trouble with their code, i am thinking this FAQ lisit could live both on p5.js website and be referenced when people open any new issue :)

@akshay-99 I don't think I understand the second solution well but the first solution seems like a good enough avenue to start exploring. A good word distance algorithm can be rather complicated to setup as there are many many ways a typo can occur, what I would suggest is to start simple with just a tolowerCase() comparison and use it to judge the performance in terms of usefulness to the user.

So excited for this! This could be a very powerful improvement to FES.

Just to echo @limzykenneth that a toLowerCase() comparison would be a great start. Then it might be a good idea to try out small npm packages (like this one?) for more granular word distance calculations to see how performance and package size is impacted.

Also, this is less important and maybe outside of scope, but I wander if you could easily do this same comparison for undefined variables that are close to user-defined variables.

Thanks for the suggestions everyone! I will try out these things and see the results.

Also, this is less important and maybe outside of scope, but I wander if you could easily do this same comparison for undefined variables that are close to user-defined variables.

@stalgiag Are you talking about variables which are defined by the user as a part of their sketch but may not be related to any p5 functionality?

@akshay-99 yes, just curious if the same solution for p5 functions could be easily expanded to help with a sketch like this:

let myX = 50, myY = 10;

function setup() {
  createCanvas(100, 100);
  rect(myx, myY, 10); // FES will say variable undefined, which is probably enough of a clue
}

This becomes a bit more of a fuzzy discussion about the scope of the FES and I don't think this functionality needs to be addressed. This was more of a passing consideration that I just wanted to think about in parallel to the work done here.

@stalgiag The FES does not currently have this much insight about the sketch. I think this specific case would need to involve parsing the user's sketch, basically having one script ( p5 library) read the code in another script ( the sketch ) . I had come up with some ideas about this a few months back, about how the FES could use the parsed sketch to build more context for its messages, and how this could be done. But it would be a much larger task.

Also, when the sketch is run locally ( not on a server ), the execution environment in the browser will allow us to see read the code written inside functions in the sketch, but not the code at the top level in the sketch file. And since let and const do not imprint on the global object either, I can't think of a way to make the FES read let myX = 50, myY = 10;

this is great. I will add that preLoad() vs. preload() is a common error I see when I am teaching, if you are looking for good test cases. :)

@akshay-99 right - hadn't considered where we were catching things currently. Thanks for the breakdown!