ID:1494273
 
BYOND Version:503
Operating System:Windows 8 64-bit
Web Browser:Chrome 33.0.1750.70
Applies to:DM Language
Status: Unverified

Thus far we've been unable to verify or reproduce this bug. Or, it has been observed but it cannot be triggered with a reliable test case. You can help us out by editing your report or adding a comment with more information.
Descriptive Problem Summary:
Findtext does not provide expected result when a space is placed next to a new line.

Code Snippet (if applicable) to Reproduce Problem:
client/verb/test()
var/t = {"test
"}

src << findtext(t,"test ")


Expected Results:
Output is '1'

Actual Results:
Output is '0'
New lines in some languages are represented as \n perhaps try that? I don't have the access to do so myself at the moment.
It doesn't happen when you have a string like "test \n"
At a guess,

var/t = {"test 
"}


Possibly the whitespace on the end of the line is not preserved properly? In your example above, there's no space in your text. Is it there if you close the tab for that code-file, and re-open it?
Many editors will remove whitespace at the end of a line. I don't recall DM's editor doing this, but it might; at the very least I would suggest that the extended string format is not the ideal choice if you want to preserve whitespace at the end of a line; I think it will remove whitespace from the beginning of the line, so it's probably trimming all whitespace around the line break.
Ah, yep. The space is being removed each time the file is reopened.
However, this is also happening with text files loaded with file2text.
The internal code for file2text() says that whitespace at the end or beginning of a line should be preserved. The only thing file2text() alters is the carriage return character, which it removes so that there will be portability between DOS and UNIX text files.
The text file I'm using was initially stored as unicode, then resaved as ANSI. It was generated by this program: http://www.nirsoft.net/utils/chrome_history_view.html. I highlighted a few entries and used the 'File->Save selected entries' command.
Also worth noting, I was specifically using findtext(text,": ") to retrieve different entry parameters, howver in instances where an entry had no value for a certain parameter and went straight to a newline, findtext(text, ": ") would return 0.
Are you certain the text file actually contains those spaces? As I said, I looked at the file2text() code and found no evidence it would lose any trailing spaces, but many text editors will do that automatically--or at least as an option. I've got my own editor set to do that. Your results are consistent with the file itself not having the space after the colon.
Yes, I can definitely see the space when I open it in notepad and highlight the area.
If you don't highlight, but just press the End key, does the caret appear after the space, or at the end of the word? I ask because when you highlight, some editors will include the newline as a space, although Notepad in XP definitely doesn't so I expect Windows 8 probably isn't different. Comparing in a different editor couldn't hurt either.

All that said, why don't you go ahead and zip up the file (so that its proper format is preserved) and send it to me at [email protected]. I'll see if I can find anything. If you could develop a simple test case project that'd be even better, but with the file I can at least verify if file2text() is reading it correctly. As I said I don't see any reason for file2text() to skip the space, but I won't rule out I could be missing something.
Lummox JR changed status to 'Unverified'