This Bugzilla instance is a read-only archive of historic NetBeans bug reports. To report a bug in NetBeans please follow the project's instructions for reporting issues.
It would be great if the editor had an option for how it handles newlines. This could be set with a dropdown where you select Unix (LF), Windows (CRLF), Mac style (CR). Having this option benefits the following scenario: NB being used in Windows, where files exist on Unix server, and files are accessed via Samba. The files should have a Unix newline because they exist on a Unix server, however when you save them in NB, they are saved with Windows newlines. It would be great to have the option here of always saving these files with Unix newlines to avoid extra work on the Unix side (dos2unix, munging on CVS checkin, etc).
*** Issue 38675 has been marked as a duplicate of this issue. ***
As an indication of how important users see this issue see eclipse issue 3970 and its high activity - particularly the high number of Added CCs.
If a file gets created from a template on the unix and gets '\n' line separators then regardless of where you open it the NB editor should always remember and retain the original line separators. If that is not true for your case then please file a bug. I agree though that there should be a way to change the LS for existing files.
A long time ago, the java.io.File class was capable of dealing with / or \ as path separators, no matter what the platform was. This is just a basic premise of portability. The data that any Java class uses must be handled in a portable way. File editing, in particular, is something that needs very flexible support. The language issues as well as the EOL issues need a solution that provides "easy" flexibility; i.e. the defaults should behave reasonably invisible to the user, and the user should have the ability to assert specific preferences. There should NOT be a configuration file somewhere that references all of my source files and has settings for them! Instead, EOL should always adopt the current platforms EOL behavior except when a global EOL setting is asserted. Language should be handled by scanning the file, and changing the font to a locally asserted i18n font when it is not plain ascii. During the editing session, the user can assert another font from a list of fonts that they can set up so that perhaps a simple keystroke would either cycle through them, or a toolbar dropdown would provide selection from those fonts configured. This would allow a development organization to establish the set of acceptable fonts for developers to use in their source files.
*** This issue has been marked as a duplicate of 72515 ***