We should be treating the end of data the same way we treat a newline. A common issue that affects a good number of plugins is that we don't deal with trailing space well. For example, most plugins that respond with a large list of values, where we iterate over an array or list, or something else, they usually end up responding with a trailing space before the newline. If we feed that same string back as an update, we can end up in a situation where we lock up (or become very, very slow), because we want to read more data than is available. Why? Because `Serial.parseInt()` (used by Focus under the hood) will swallow up any leading whitespace. So if we have "255 \n" as an argument list, we'll parse the first number, and the second `parseInt()` will return 0, because it times out waiting for a number, consuming both the space and the newline in the process. Thus, the next `::isEOL()` will still return false, because `peek()` returns `-1`, signaling no data. That can confuse the heck out of our plugins. To combat that, we should treat end of data the same as EOL, and return false if `peek()` returns -1, too. Signed-off-by: Gergely Nagy <algernon@keyboard.io>pull/1178/head
parent
fd0795f375
commit
6106b9d6b2
Loading…
Reference in new issue