Handling of final delimter (was Re: "this me"?)

[Paul D. DeRocco]

> From: Ben Rubinstein
> 
> It's easier to see with items, and I think it is consistent:
> 
> number of items in ","  ---> 1
> number of items in ",,"  ---> 2
> number of items in ",,a"  ---> 3
> number of items in ",,a,"  ---> 3
> item 2 to 3 of "a,b,c,d"   ---> b,c
> 
> If you take this model:
> - that the delimiters are not part of the chunk, but serve 
> only to split text 
> into two chunks;
> - that if there is no text following the delimiter, there is 
> a chunk before it 
> not after it;
> - and that the delimiter's appearance at the start of text 
> indicates an empty 
> chunk before it;
> 
> are there any examples of LC behaviour which are inconsistent with it?

YES. A listbox that has a return at the end of its contents allows the user
to select a blank item following the last visible item. When building up the
contents of the listbox a line at a time, you have to append the line of
text if it is empty, or append a return and the line of text if it is not.
Or, you have to append a line of text and a return each time, then remember
to go back and remove the trailing return if anything was added.

I'm not saying that behavior is necessarily wrong, it's just that there is
some precedent for a return at the end implying an empty line. One third way
to interpret a list would be to say that any trailing stuff that isn't
followed by a delimiter would be ignored entirely. This would be
counterintuitive when the delimiter is a printable character (e.g.,
"a,b,c,d" would ignore the "d"), but has some precedent when the delimiter
is a return (some parsers ignore an unterminated last line in a text file).

-- 

Ciao,               Paul D. DeRocco
Paul                mailto:pderocco at ix.netcom.com