![]() ![]() in the meantime - regardless - it's clear that what appears to be a 'line' to the editor window isn't the same to the sort function. because I'm doing 6 things at once and don't want to err on the order in which I did them. Yes - I'll try to reproduce the exact steps. I'm surprised 32-bit and 64-bit would be different with sorting (with the new info on line-endings) So this is a bit of a cognitive difference between what the EDITOR window recognizes as a "line" and what the sort function does.Ī paste should unify line-endings into the target document's line-ending type. ![]() But because they are lacking the requisite "CR" before the "LF" - the sort function won't recognize them as actual lines. If a 'cut/paste' was done from a Unix(LF) file into a Windows(CR|LF) file, the line endings LOOK 'fine' (NPP recognizes the LF and dutifully numbers the lines. It has to do with the line-ending setting. I figured out the problem and it's probably not "technically" a 'bug'. I guess I couldn't say it seems to sort fine for me, so I suppose someone else might have to chime in I guess you'd have to be more specific on the type of problems before anyone can commentĪ collection of lines when sorting "lexicographically" (or any other way for that matter) doesn't happen. Hi all - Anyone else running into problems with the 64-bit version doing line-level sorting? A similar issue appeared on the Live Support channel:
0 Comments
Leave a Reply. |