End of lines AND "\n" character
Currently in Yzis, as far as i understood how stuff work. Lines of text can be got from a call of buffer->textline(int n) and we get the QString of the nth line of the buffer.
The QString of the line do not contain a \n at the end of the QString. (but it contain the \t for tabulation).
Or at least the Search function("/") of the current Yzis don't found it while it found the \t
VIM search function("/" or "?") do find the \n char at the end of a line.
So i see 2 way to solve this issue.
1) Modify the buffer so we have the \n at the end of lines
2) Modify the seach function in yzis to make it found a \n at the end of line.
I don't know what influence the 1) can change of yzis structure and the issues it will create.
About the 2), it's seems dirty to do it this way (but if no other way to do because of structure of yzis). If we go this way, we should keep an eye on the last line of text that don't have a \n at its end (1 more test :p)
ps: yeah i know another stupid bug report from me :p, but i'd like to know how you gonna solve it (or not) that's may have some influence on how i should implement movement functions like end of paragraph/sentence (looking for blank line etc...).
I'd also like to have a confirmation that there'll be no '\n' in middle of textline, if possible?
Updated by Loïc P. over 13 years ago
Modifying the buffer to have \n at the end of lines is wrong.
The main reason we manage a list of lines without endline char is to support the different endline chars (depending on the platform, \n, \r\n or \r are endline chars).
Modifying the search function is the only way to support that, and for my part, this is the right way.
If you look how vim handles it, searching for \n will hl endlines, but same for \m\n :) So it means that it does'nt really match these chars into the buffer, but handles them in a different manner.
Btw, I think mailing list is a better place to discuss such topics. But you can create an issue asking for searching support of end of lines chars :)