Add option to Print preferences: "Print double-spaced"

[OldGrantonian]

I'm not a techie, but I use N++ for quick unformatted text. For example, for long emails, I print the text and edit the printed copy before sending.

It would be nice if there were an option to print double-spaced (or even triple-spaced). This gives space to flag errors and comments during editing.

This option could be in Settings > Preferences > Print

Thanks.

[sasumner]

Sure, but RIGHT NOW you could also do a quick transform of your data before printing:

Find what: \R
Replace with: $0$0
Search mode: Regular expression
Wrap around: ticked

and, if needed, a reverse transform:

Find what: (\R)+
Replace with: $1
Search mode: Regular expression
Wrap around: ticked

[OldGrantonian]

That worked great - in both directions.

Just for feedback (not a complaint), the extra line is added at the end of each paragraph - which is fine by me. If I understood the code, I could probably have worked that out for myself.

Thanks for your help.

[sasumner]

I'm suspecting you have line Wrap turned on...if so there is no practical way with my method to insert extra vertical spacing inside a long line. :-(

[OldGrantonian]

In the View tab, I unchecked "Word wrap". That caused more space between paragraphs. That's fine.

Thanks for your help.

[sasumner]

I've always wondered why it is called "word wrap"...I like to think of it as "line wrap"

[OldGrantonian]

Interesting point :-)

I've never thought about it until now. I simply use the "monkey see - monkey do" approach, and copy other people.

Maybe it's because "words" are real, but "lines" are virtual. Lines exist only in the editor - not in RAM. And each user's editor will show the same number of words, but maybe different numbers of lines.

I think in the old days of C, a text file was simply a very long text string, with a NULL terminator. I think it was the duty of the application programmer to respect the NULL - not the OS. There was no concept of "lines" in memory. Paragraphs might be terminated by either LF or CR+LF, but as far as RAM was concerned, these were simply dumb bytes. Even the NULL was a dumb byte, which had to be very carefully managed by the application developer. If she accidentally deleted the NULL by using DELETE or BACKSPACE in a text box without checking if the character was a NULL, her editor might crash because I think it was trying to load all the dynamic text strings which started at the next byte after the deleted NULL, and continued till the end of the current heap :-)

I remember seeing stuff added to the editor, such as "Press any key to continue" followed by maybe "Insert the second floppy", and so on, with dozens of non-printing characters, all joined on at the end of the editor. (Which of course proves that the editor ignores NULLs unless specifically told otherwise by the programmer. Strings were handled by pointer arithmetic, so the programmer had to keep track of the pointer :LOL)

Assume the user deletes one character. If there is now sufficient space to move the first word of the next line to become the last word of the current line, only that word is "wrapped" - not the complete line. None of that is visible to someone who is simultaneously watching RAM in real time using one of the old utilities. The user simply sees that all the text after the deleted character is moved one position to the left (to the next lower RAM address).

So, in the previous paragraph, we can see that one word was wrapped. We can't say that one line was wrapped. So maybe that's why the term "word wrap" is used.

Using that thinking, we could say that the only way to "wrap" a complete line downwards is to insert a carriage return. To wrap a complete line upwards would require the removal of a carriage return.

BTW: you can probably believe about 60-70% of the above description. The remainder is either junk or bad memory.

[OldGrantonian]

Just occurred to me that some of the stuff about the use of the BACKSPACE key in a text box might not be accurate.

I don't think the BACKSPACE key can ever delete the NULL. If the user deletes text by placing the cursor at the end of the text. The cursor (in a DOS editor) is actually OVER the NULL. So, the NULL can never be deleted.

Regarding the DELETE key, if the user deletes only one character, the NULL is not deleted - so the bug might not be discovered till later. But if the key is held down, the bug will eventually be discovered.