If we are building lists, it is possible to make a list in which items are delimited by both char 10 and char 13.
As long as it stays within FM; why do you want this? Why not just use what FM uses as the internal list delimiter.
If you get the data from elsewhere it should be easy enough to weed out the char(10) and keep the list FM save.
I'm writing a custom function that flattens lists to make them safe for passing around via variables. The mechanism uses the list functions, so depends on the data format of the values it receives.
It's an unlikely issue. It's hard to get char(10) into a field without using the functions. I use TextWrangler and have it set to use char(10) as the line delimiter instead of char(13) because I interact with the files on the command line. When I'm cutting and pasting TextWrangler puts everything on the clipboard with char(13). When I'm importing FileMaker handles the line endings properly.
I have been thinking that the CF had a responsibility to preserve the LF and the CR. That's probably right in the small picture, the CF shouldn't have to take responsibility for decisions about line formatting. In the larger picture, we will know whether or not the LF is important and right now I can only think of hypothetical cases when it would be preserved.
In any case, the CF can preserve the LF. It just has to have a few extra lines of code.
Other value-delimiter characters to watch out for are the Unicode line separator Char ( 8232 ) and paragraph separator Char ( 8233 ).
You're right. Both of those can be used to good effect when creating lists. I'll have to remodel my CF to include those two newcomers.