It’s quite common for us to see formatted code end without a newline char on the last line. Is it possible to modify the formatter config file to ensure that the formatter produces files that always end with a newline char?
You mean at the end additional “Enter”?
Newline may be LF, CR or LFCR … depend on your OS.
But think that adding new lank line at the end is not possible in this moment.
what do you want to achieve with that? maybe there is another solution for your need.
All trailing whitespace is trimmed by Toad after getting the text back from the formatter. There is no option to control it.
On 02/27/2014 03:37 PM, mark.s.davis wrote:
Thread created by mark.s.davis
It's quite common for us to see formatted code end without a newline char on the last line. Is it possible to modify the formatter config file to ensure that the formatter produces files that always end with a newline char?
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or
Unsubscribe from Toad for Oracle - General notifications altogether.Toad for Oracle - Discussion Forum
Flag
this post as spam/abuse.
–
Yes, we have other programs that read the output and they either complain or don’t work properly if the last line isn’t terminated with the line ending character. We’re on *NIX systems so that a newline char.
Som text editors won’t even let you produce such a file.
Of course many programs may treat EOF as implicitly including an EOL (newline char), but … others might simply ignore the last line in that case.
In our case we know that ending a file without an newline char is a problem, so we don’t allow code like this to be checked in. And that is an unnecessary headache for programmers.
It would be ok if it trimmed the whitespace at the end, but the last line (in our case) must have a line termination char (newline) on the last line.
Hm…
It will be easy to add extra new line on any file in bash … so why involved Toad in that? Toad is pure Win app and you are saying about files on *ix … so these files are saved somehow in Toad … who is making that automatically?
IMHO problem is not Toad related … sorry have no other idea
It would be ok if it trimmed the whitespace at the end, but the last line (in our case) must have a line termination char (newline) on the last line.
Nope, Formatter trim to the end of last line that have something ... I tried any special character and no success.
Think that formatter is not supposed to do that.
But newlines are whitespace. The default trim functions don't allow for customization of what should and should not be a whitespace. It wouldn't be hard to add, but this is the first it has come up to my knowledge. Perhaps the best option would be for the formatter
to completely control the spacing options and for Toad to do nothing in addition. I'll remove the trim call locally and see what happens using formatter options alone.
On 02/27/2014 04:12 PM, mark.s.davis wrote:
Reply by mark.s.davis
It would be ok if it trimmed the whitespace at the end, but the last line (in our case) must have a line termination char (newline) on the last line.
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or
Unsubscribe from Toad for Oracle - General notifications altogether.Toad for Oracle - Discussion Forum
Flag
this post as spam/abuse.
I think whitespace is generally thougt to be spaces and tabs. But that’s a good discussion for another time. 
In the windows world, end of lines (newlines) are marked by a pair of characters (hex 0d0a). In the *NIX world its just a lf char (hex 0a). When I format code in toad it is, by default, saved as a windows text file (but that’s an option). Even so, the windows text file contains a standard EOL (hex 0d0a) for each line except the last one. In fact, if the file is opened with the Vim text editor on the Windowss desktop (which handles bot DOS and *NIX files). It immediately notes the missing EOL char.
I tested with Toad settings to save files in native (DOS) format and UNIX format. In both cased the files aren’t ended properly (i.e. with either form of newline ).
The formatter also seem to strip trailing newlines. The old Formatter Plus used to have options to control trailing newlines. I could copy those to our formatter if you want.
Suggestion: on save to file then Toad - regardless of formatter - could fully trim first and then just add an newline. That would be a safe bet. I feel that nobody would ever object against files always ending on a newline. I vaguely remember even Windows tools complaining on missing newlines, so that’s not a unix-only “privilege”.
BTW, en.wikipedia.org/…/Whitespace_character nicely discusses what whitespace is.
I feel that nobody would ever object against files always ending on a newline
Except when you have version control software ... or have to compare versions manually (by size for instance)
Actually Andre’s suggestion (to ‘fully trim’ as is done now, and then add a newline) would work. The thing is that the formatter is already stepping in to rearrange and format the text. And typical workflow would be to check-in the formatted text to some VCS system. So that final newline would then always be present throughout the workflow. It was certainly there before the formatter got involved!
So version control would always see the final EOL (no difference) and manual comparisions would always the the final EOL (here there could be differences between pre- and post-formatting, but that’s to be expected).
On the whitespace discussion, even the wiki page says that newline chars may be considered whitespace depending on context. I’m not sure why they hedge there, unless their goal is to be more obtuse. Assuming the formatter makes heavy use of regular expression matching, it’s likely that it treats tabs and spaces identically as whitespace and EOL chars are either matched (or skipped over deliberately as a special charactter). I hope this doesn’t dilute my point above.
Thanks again to all here for their comments and hopefully a change in the formatter can be initiated.
depending on context
In this context, newline is whitespace as mentioned earlier. The discussion can go on and on, but just to be clear when whitespace is used with respect to the Trim functions Toad is using that's how it is.
You should throw this into the Idea Pond:
http://www.toadworld.com/products/toad-for-oracle/i/default.aspx . A change like this will cause differences to existing code in source control depending on how the differences application is configured. Most have options to ignore whitespace (or newlines
if we choose to differentiate) so for those that don't have such options set differences will be flagged even if the core code has not really changed.
Perhaps better still would be for it to add the newline when saving files only if the option to use LF newlines is enabled. That would be consistent with *nix applications it seems. I use Xubuntu as my host OS and tested several text editors and the general
consensus on my limited test was that a trailing newline is automatically added, but not always. Geany and vi add it, Leafpad does not.
Michael
On 02/28/2014 11:42 AM, mark.s.davis wrote:
Reply by mark.s.davis
Actually Andre's suggestion (to 'fully trim' as is done now, and then add a newline) would work. The thing is that the formatter is already stepping in to rearrange and format the text. And typical workflow would be to check-in the formatted text to some
VCS system. So that final newline would then always be present throughout the workflow. It was certainly there before the formatter got involved!
So version control would always see the final EOL (no difference) and manual comparisions would always the the final EOL (here there could be differences between pre- and post-formatting, but that's to be expected).
On the whitespace discussion, even the wiki page says that newline chars may be considered whitespace depending on context. I'm not sure why they hedge there, unless their goal is to be more obtuse. Assuming the formatter makes heavy use of regular expression
matching, it's likely that it treats tabs and spaces identically as whitespace and EOL chars are either matched (or skipped over deliberately as a special charactter). I hope this doesn't dilute my point above.
Thanks again to all here for their comments and hopefully a change in the formatter can be initiated.
To reply, please reply-all to this email.
Stop receiving emails on this subject.
Or
Unsubscribe from Toad for Oracle - General notifications altogether.Toad for Oracle - Discussion Forum
Flag
this post as spam/abuse.
If ending formatted code with a newline were made a formatter option, everyone could find a happy place.
I queued it as QP-2830.
Option name = “Ensure formatted text ends with a newline”’. Checkbox.
Default value = unchecked (this is the current behavior).
Behavior when checked: if formatted text does not end with a newline then a newline will be appended.
Andre
Do you have any idea when this feature will be included? I’ve tried to find any reference to QP-2830 and came up empty.
Mark
Mark,
QP numbers are internal references - just references.
It’s scheduled to be available within 2-3 months the latest. I’ll post a word here when included.
Thanks,
Andre
Hi Andre,
Any word on this feature being incorporated yet? (We’re almost to 3 months ). If so, what version would it be in?
Thanks,
Mark