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.

Bug 35233 - Request for editor option to set the newline style
Summary: Request for editor option to set the newline style
Status: RESOLVED DUPLICATE of bug 72515
Alias: None
Product: editor
Classification: Unclassified
Component: -- Other -- (show other bugs)
Version: 3.x
Hardware: PC Windows ME/2000
: P3 blocker (vote)
Assignee: issues@editor
: 38675 (view as bug list)
Depends on:
Reported: 2003-08-01 15:57 UTC by kokaku
Modified: 2008-09-23 11:46 UTC (History)
1 user (show)

See Also:
Exception Reporter:


Note You need to log in before you can comment on or make changes to this bug.
Description kokaku 2003-08-01 15:57:05 UTC
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, 
Comment 1 psuk 2004-03-19 19:09:13 UTC
*** Issue 38675 has been marked as a duplicate of this issue. ***
Comment 2 dynamite 2004-09-03 09:44:41 UTC
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.
Comment 3 Miloslav Metelka 2004-09-03 14:00:21 UTC
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.
Comment 4 greggwon 2006-08-01 15:19:18 UTC
A long time ago, the 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

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.
Comment 5 Vitezslav Stejskal 2008-09-23 11:46:14 UTC

*** This issue has been marked as a duplicate of 72515 ***