Tinderbox Forum

Illegal characters in comments in Function definition

Trying out Michael Beckers Tbx on “Dynamically create notes…” one can see that the attribute “ShortTitle” will not be set. The cause is found in function “fGenerate Short Title”. The definition contain a one-line comment starting with “//”. In this comment line is the word “note’s” and the apostrophe is the bad character. Remove it and the functions start to work.

I tried to find a definition of allowable characters for comments within functions I aTbRef but could not find any.

[Ed. note: this discussion concerns the behavior of Tinderbox 9.1.0 and is likely not to apply to subsequent releases.]

What version of Tinderbox are you on? This works find for me. I wonder if it is a versioning issue.

Sorry for the delay.
I’m using 9.1(b542).
It looks like this is a language/keyboard mapping problem. I am using Swedish keyboard and localization Sweden in my setup and it seems to confuse Tinderbox.
I have tried to change my setup to US American keyboard and localization US and then it works.

1 Like

I’ve updated my note on action code commenting to reflect this hard-to-guess (especially for non-coders) behaviour for unpaired quotes and re line-wrap and the fact the code parser and code colouring are separate processes with possible different implications.

In the following example ignore the code colouring added by the forum software

BAD. Unpaired straight quote:

// don't do this.

GOOD. Uses curly quote for apostrophe:

// don’t do this.

GOOD. Avoid speech-style contraction:

// do not do this.

BAD. Unpaired double quote in wrapped comment text.

// Here is "Some
//   wrapped quote text". Etc...

GOOD. Wrapped partial quote is fully quote-enclosed:

// Here is "Some..."
//   "...wrapped quote text". Etc...

GOOD. Uses curly double quotes for quoted text:

// Here is “Some
//   wrapped quote text”. Etc...

Also, action code comments do not have an explicit multi-line method. I have had odd effects if I just let the comment soft-line wrap. For this reason, and pending any changes to comment function, I think it best to hard-break a long comment into a series of single like comments. So, instead of this:

I would do the comment like so:

This makes it far less ambiguous for Tinderbox’s action code parser—which is process discrete from the regex doing the code colouring. the code colouring should be seen as a guide to typos buy won’t warn of things like lines of code lacking a ‘;’ terminator or lines wrapping owing to the RTF-style ruler.

Lest someone point it out, yes, I am suggesting judicious use of curly quotes in code comments as opposed to the actionable code itself as a means to avoid confusing the code parser. For more complex code use like functions—especially if to be shared with others—good and clear comments are a good thing (plus we all forget our own code’s meaning after a few months)

1 Like

I think there may actually be a bug here, but we don’t have it defined yet. Here’s what should happen:

  1. A comment begins with //
  2. A comment continue until we encounter:
  • the end of the text, or
  • a second //
  • a newline \n
  • a linefeed \r
  • a unicode Line Separator, U+2028
  • a unicode Paragraph Separator, U+2029

It is certainly possible that the parser is getting fouled up; there has a been some recent action with the pertinent part of Tinderbox’s recursive descent parser in support of complex regular expressions.

I am particularly curious about the possibility that the Norwegian keyboard is mapping to a character that looks like [ ’ ] but is actually something else.

FWIW, looking at the original text it seems that the offending character is mapped to hex 27. Its appearance is “’”. Changing to “´”, hex c2b4, is accepted and the function will work.

OK: that theory bites the dust. (I saw a similar issue recently in which a letter that appeared to be a familiar lower-case roman letter was actually a different character taken from another script — perhaps Armenian — causing a program no end of trouble. But not in this case)

There was a recent change in parsing single quotes outside of comments, and it sounds like we’re missing them inside comments. Should be straightforward.

1 Like

Later: yes, it’s a parser blunder.

For now, avoid comments that contain single or double straight quotes, or curly braces “{}”.

I expect this will be addressed in. 9.1.1 and subsequent versions.