Should we have a cmd-end-char setting?

[PropGit]

[This is extracted from a conversation in the Parallax Wi-Fi Module API document. It is placed here to be decided on later.]

PropGit
Future thought: Since we have cmd-start-char, shouldn't we also have cmd-end-char?

dbetz I asked @AndyLindsay about this when we added cmd-start-char and he said he preferred to always use \r.

AndyLindsay
I think an optional cmd-end-char is fine, but we want the default to be \0x0D. Also, if certain terminals use \n\r, it might be worth adding that as an option too.

dbetz
If we allow a CR/LF or LF/CR option then the command must end with both characters. It's more difficult to allow either CR or CR/LF for example. Also, should I be able to set the end character to "?" or something like that? In fact, it's impossible to set it to ":" or "," since those characters are already used in commands. For that matter "/" is used in paths. Maybe the options should only be CR, LF, CRLF, or LFCR. In fact, I don't know of any terminals that use LFCR so that can probably be left out.

[PropGit]

Thoughts
The Serial interface will most often be used with an attached microcontroller, so single character endings will continue to be common there.

It's a very interesting thought to attach a terminal to those connections; it'd help foster experimentation that's very important for education. Most terminals output a two-character line ending.

Having options for two-character endings makes the setting name incorrect (cmd-end-char), so we'd probably want to adjust the name, and I think we should limit it to a set of CR (the default), LF, and CRLF.

[dbetz]

While I'm happy to do what you want I don't think that two-character line ends are common with terminal programs. I think the most common line end is CR if it is really emulating an old-style hardware terminal or maybe LF. CRLF is probably the least common and may not even be supported by some terminal emulators. Do you know of one that requires or even defaults to CRLF?

[PropGit]

To follow-up on this, we should have a settable end character, but just a single character. Default should be ASCII 13 "\r".

[dbetz]

Out of curiosity, why do you think that’s needed? My theory is that the start character gets you into command mode and the user might want to select which character triggers that because the one we choose might interfere with something the user would like to use in transparent mode. However, the end character gets us out of command mode and the syntax of commands is entirely defined by us. What would be the point of changing the end character?

On Oct 13, 2016, at 4:56 PM, Parallax Git Administrator [email protected] wrote:

To follow-up on this, we should have a settable end character, but just a single character. Default should be ASCII 13 "\r".

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #4 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAq-1pPk2gjnBv4HtNtIh4SLZGUg4IjAks5qzpsJgaJpZM4I98rT.

[PropGit]

Just for the same reason that the start character is configurable; to be flexible for different applications that may have a compelling reason to use a different character. In the Docs, I wrote that they are both configurable and indicate them in syntax descriptions by a single character symbol so that we can stay away from obscuring the meat of the command or response further with multi-character representations of the start and end character... so a configurable end character fits nicely within the context of the docs also.

[dbetz]

As I mentioned, there is no need to configure the end character because it is part of our CMD syntax and not an escape from normal user text. in fact, I’m not sure changing either is really a good idea since it breaks all of the sample code.

On Oct 13, 2016, at 6:57 PM, Parallax Git Administrator [email protected] wrote:

Just for the same reason that the start character is configurable; to be flexible for different applications that may have a compelling reason to use a different character. In the Docs, I wrote that they are both configurable and indicate them in syntax descriptions by a single character symbol so that we can stay away from obscuring the meat of the command or response further with multi-character representations of the start and end character... so a configurable end character fits nicely within the context of the docs also.

—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub #4 (comment), or mute the thread https://github.com/notifications/unsubscribe-auth/AAq-1sWwXXvC1qx4LSV1HgYPJG78aNauks5qzrdGgaJpZM4I98rT.