Upon thinking further about this bug, I realize that "correct" behavior is
not obvious and might warrant some discussion.
At first, I questioned whether it is appropriate to handle data differently
depending upon whether it is typed as BLOB or text. Maybe the edit()
function needed a flag for this. However, since this can always be
affected, either way, by a type cast, there is no such need. And, given
this (effective) option, it seems that treating a text-typed value as being
subject to the usual text transformations [a], is perfectly fine, and
convenient when they may be needed in order for a user's favored
text-editing program to be used. [b]
[a. The CRLF <-> "\n" translation is just one such transformation.
Character coding could be another. ]
[b. On Windows, notepad.exe is always available and "on the PATH", which
might make it favored sometimes. But it handles LF as line boundaries very
I notice an upcoming change to the edit() function, checked in a few days
ago, which appears to make the allow-text-transformation decision based
upon whether the original input contained any CRLF pairs. I would urge not
adopting this approach because it presupposes something not necessarily
true, that the input to edit() reliably signifies what should happen to its
output. That would not be true if, for example, a single "line" of text
without a terminating CRLF were to be edited to become multiples "lines"
containing CRLF pairs (which might number one less than "lines".) I submit
that a better approach is to embrace the possibility of newline
transformation for text-typed edit() input, leaving in the user's hands
whether to block that by type-casting to BLOB. That is an option that is
eliminated with the recent check-in.