'}' in a library function?

[vefatica]

I think I followed the rules by putting the function-terminating '}' on a line by itself. But LIBRARY doesn't seem to like '}' elsewhere.

g:\tc23\library> head /n3 iprocessline.txt
rv {
echo {foo}
}

g:\tc23\library> library /r iprocessline.txt /u

g:\tc23\library> library /f rv
rv {

}

 

[rconn]

If the last character on a line is a }, it is interpreted as the end of the function definition.

The beta testers complained that they didn't (always) want to have a line with just a } to terminate a function; they wanted to append it to the last line of the definition.

 

[vefatica]

If the last character on a line is a }, it is interpreted as the end of the function definition.

The beta testers complained that they didn't (always) want to have a line with just a } to terminate a function; they wanted to append it to the last line of the definition.

Putting the function-terminating '}' on a line by itself is very reasonable, and arguing against that seems a bit petty. I don't recall such a discussion and after looking for 30 minutes, couldn't find it. Can you direct me to it?

You probably should have said "last non-whitespace character on a line". Adding whitespace after "echo {foo}" doesn't help.

The way it is seems somewhat less than ideal. I prefer the behavior described in the help. In any event, the help and real life should agree.

 

[LarryBrasfield]

Having to "waste" an extra line to meet TCC's syntax requirement is a miniscule sacrifice compared to having obscure failures show up triggered by the library function content, such Vince found.

Most everybody (except LISP lovers) puts closing constructs at the same indentation as the matching opening construct, so putting the closing brace on its own line is clearer anyway.

The present behavior is clearly quirky, and to avoid it is hard, as Vince demonstrated. Documenting the quirky behavior will take more mental space than would be needed if the closing brace had to stand alone.

I suppose the present behavior means that text/endtext and functions are going to interact strangely, since there is no good way to escape anything inside of a text/endtext block. And here I have imagined text/endtext as a tool for writing brace-containing, multi-line code. I guess it's good for that, but probably not in library-defined functions.