Community
Participate
Working Groups
When creating a new file we currently use the line delimiter returned form System.getProperties("line.delimiter"). But this is not whay a user always wants. Consider the following sceanrio: - Unix and Windows work station used to develop a Unix product / program. - the Windows work stations are used as X terminals and to run Eclipse (since PC are cheaper than Unix boxes). - even if the new file is created on Windows it should have Unix line delimiters since the end product is a Unix product. There should be a UI (Preference) to define the line delimiter for new files. Possible values are: - Dos / Windows - Mac - Unix - default platform line delimiter. The UI should be provided by the Workbench since all plugins should use the same line delimiter for new files. NOTES:
moved to 'active'
PRODUCT VERSION: 125
Line terminator handling improvements are currently considered for 2.0
leaving as is.
Starting with build 20020430 editor support the conversion of line delimiters. Default Text Editor: Edit>Convert Line Delimiters. Java Editor: Source>Convert Line Delimiters. The locations are subject to change.
Actually the PR asked for having a UI to define the default line delimiter not to change it.
This is not an editor issue. The editor provides the conversion actions as described but does not create new files etc.
no action for 2.0
This is actually a platform issue since all plug-ins should honor such a setting. Moving to platform.
Now that we have encoding support in 2.0 is this still required?
IMO yes since encoding is orthogonal to line delimiters
Just wanted to add a perspective from a user. I am no longer using Eclipse because I can not have complete control over the delimiter that is inserted into new files. My project requires that I always use Unix delimiters regardless of platform. So, everytime I add a new file I need to open it, click Source->Convert Line Delimiter->Unix and then continue editing. Quite a pain. Plus, if I forget and then do it later, I can potentially screw up CVS diffs and CVS log entries pretty badly.
I should agree with Brian, line delimiters control is a "must be". Is there any activity planned on this issue?
In addition to a global preference, setting the default line delimiter should have the same granularity as assigning file encoding. See bug #37933. This means if file encoding can be tuned on file, folder, and project level the default line delimiter should be defined also on file, folder, and project level.
Anymore status on this bug for release in 3.0?
Reassigning to Text since line delimeters apply only to text files.
*** Bug 15370 has been marked as a duplicate of this bug. ***
*** Bug 49894 has been marked as a duplicate of this bug. ***
*** Bug 56514 has been marked as a duplicate of this bug. ***
*** Bug 28669 has been marked as a duplicate of this bug. ***
Just another ping to see if this bug is going to make it into the 3.0 release. This is (still) the only feature that is keeping me from switching completely to Eclipse.
Not planned for 3.0 (you can see the planned items on dev.eclipse.org for each component)
Not to be a pain, but there are 18 votes on this and a few more watchers. A lot of other bugs are dependent on this or duplicates. This has been pushed off for 3 releases (2.5 years) now and is a pretty fundamental concept. Why is this bug still on hold for the next release rather than been addressed in this release?
I am an Eclipse user that needs to edit all the files I create in Eclipse. I work on an Windows XP machine but all our servers are unix (Solaris, AIX, Linux, etc.). I too would like to see this feature soon...
I opened bug 28669 a while back - it was judged to be a duplicate of this one (3790) I am still seeing this problem using Eclipse 2.1.2 - all of our users work off of Windows 2000 PCs, our CVS repository is on a Solaris server. It would be really helpful if we did not have to convert files from PC format before checking them in.
I have to concur with the others. Please think strongly about raising priority on this one.
The inability to choose a specific line delimiter when creating files (and checking them out of CVS) is a huge shortcoming for me; when running Eclipse on Windows, my projects are often outside the workspace on a unix development box running Samba. In order to build the project and use commandline cvs tools locally on the unix box from the working dir, ASCII files /must/ have LF delimiters. Even an integrated batch conversion tool would be better than nothing, as currently the only quasi-solution is to run an external s/CRLF/LF/g batch process whenever new files are introduced by Eclipse-on-Windows in the filetree. Which then breaks Eclipse's cvs diffs. *Please* consider upgrading the priority of this bug.
WORKAROUND This is a hideous hack, but it seems to provide a crass workaround for my specific problem. On looking at the source, it appears that Eclipse uses System.getProperty("line.separator") for *all* line termination logic - both for doing CVS diffs, creating new files, etc. So to make Windows Eclipse workspaces compatible with *nix commandline tools (e.g. when accessing a unix- hosted workspace over samba), all one has to do is to override Eclipse's JVM's line.separator System property to be just LF. All my Windows tools which work on the workspace are happy with UNIX line endings (e.g. javac, text editors), with the possible exception of TortoiseCVS - which Eclipse obviously supplants when manipulating the workspace anyway. To override system properties for a JVM, one would typically pass in - Dline.separator=<LF> at the commandline. Apologies if there's a better way of specifying properties for Eclipse's JVM than this; I couldn't see any in 'Running Eclipse' in Help. The problem arises in how to express LF (0x0a) in the commandline - under the NT CMD and batch files I see no obvious way to escape the 0x0a character, likewise in the Eclipse shortcut editing properties dialog. So instead I've used the win32 IShellLink Interface as wrapped by Win32::Shortcut in Perl to manually insert the appropriate commandline args in the Eclipse shortcut file: #!c:\perl\bin\perl use Win32::Shortcut; my $l = new Win32::Shortcut; $l->Load('c:\Documents and Settings\Matthew Hodgson\Start Menu\Programs\Programming\Eclipse 3.lnk'); $l->Arguments('-vmargs -Dline.separator='.chr(10).' -Xmx640M'); $l->Save(); for my particular case. And this appears so far to work and solve all my line termination problems. Apologies if this is obvious to everyone else, or a truly horrible way of passing in binary system properties :)
That is one pretty narly hack. I haven't tried to set that up yet, but I think it better if the Eclipse team could try to put this on the top of the priority list. I know that the 3.0 is in the end game and that probably has a lot of work that goes along with it and this bug probably won't be included, but I think that many of the users would agree that this bug should be very high on the priority list for the next release (3.0.1 or 3.1 or whatever).
For what it's worth, i've been running with this hack now for the last few weeks without any detectable problems at all (amazingly).
BTW, the CVS preferences has an option for disabling platform line ending conversions on checkout. Please consider this higher priority than P4. This may be easier to do now that the runtime nows supports a content type manager.
As another hack workaround, it should be pretty easy to write an action set action that does a System.getProperties().put("line.separator", ...); Not sure if this can have bad effects if set after starting up.
This is an overall issue. It is insufficient if only Text tries to do something about it. For example, every action by any plug-in generating files with some content such as the New Java Class wizard, need to be conformant.
*** Bug 69197 has been marked as a duplicate of this bug. ***
This is a very serious issue. Currently we are unable to use Eclipse in any of our development projects unless we start the platform on UNIX. Is there any solution in progress?
See the above comment about "Edit > Convert line delimiters" menu option. This is the current workaround. You can also try the hack and slash routine of sending the JVM the line delimiter character to use, but this is painful and completely unknown as to what else it might effect besides the editor. Eclipse folks... Any update on this beauty? 23 votes, 30 watchers, thoughts?
> You can also try the hack and slash routine of > sending the JVM the line delimiter character to use, but this is painful and > completely unknown as to what else it might effect besides the editor. I've now been using this hack for the last 2 months, and had a reasonably close look at all the places where the linesep property is references, and have had absolutely no problems with it. It obviously does have effects outside of the editor - but desired ones (e.g. stopping CVS from munging line delimeters). It's good enough for me, at any rate ;) It would be obviously be deeply desirable to not have to do this, however. And manually having to "Edit > Convert line delimiters" on every NT-originated file is simply not an option for me, at any rate.
I'd just be careful when using the JVM work-around because it may effect plugins and other code. As Matthew was saying, it appears to work fine for vanilla Eclipse. (Sorry to use this bug as a forum, but until it is fixed most people will want to use this as a main location for the various work-arounds).
A personal mail from Oski Wee has pointed out that the -Dline.separator=<LF> workaround can be achieved without resorting to Perl, by entering a 0x0a character in your favourite text editor of choice and just copy/pasting it into the Shortcut Properties dialog box. Unsure why I missed that the first time round - thanks Oski :) I agree with Brian that it's possible that other plugins & code running in the JVM may be adversely affected by the global line.separator being changed - however I can confirm that CDT, Lomboz, the Sysdeo Tomcat Plugin & the cloudsoft memory manager plugins all work fine (to date) with it.
Although this isue is very important to be implemented, the proposed (dirty) -vmargs -Dline.separator=<LF> really works. I've used SciTE (www.scintilla.org) editor in LF mode to copy-n-paste the LF character to the Eclipse shortcut on Windows. (sure, any other text editor handling Unix line-breaks can be used). I've noticed some small odd behaviours on my Eclipse 3.0 just after that change: Eclipse has not recognized my previous (CR+LF) workspace configuration file, with an error message on startup. Solution: simply re-configure the workspace: current perspective, added projects etc. In addition, the configurations already made on Lomboz plugin (basically paths for JDK and J2EE servers) was not correctly recognized, although the paths was correctly listed on Window > Preferences > Lomboz. Solution: just re-write those paths on Preferences dialog and re-apply. Conclusion: the workaround is too tricky, please seriously consider implement this feature in a future Eclipse release.
I think it's almost bordering on bizarre and arrogant that this bug hasn't been fixed yet. I last checked on this bug two years ago.. Came back to Eclipse on a new project, downloaded 3.1, and searched around -- thinking the default setting MUST be in there somewhere.. and it's not?? C'mon folks.. Many of us do development on one platform for a production system on another. This is a SIMPLE fix, and there's no excuse for letting it remain.
If you are using the workaround in Comment 28 or Comment 39, here is a tweak that is a bit easier to type (no need to copy/paste a <LF> character from another editor). Just use the hex string for ASCII 10: 0xa. -Dline.separator=0xa
Oops, sorry about the previous comment. :\ It works for creating new files, but not for the .classpath and .project files (which end up having 0xa literally). Stick with Comment 39 for now. :)
Yet another Eclipse user not understanding why this hasn't been fixed yet after nearly 3 years and a half.
Comment #41 may be a tad over the top. Though, it may just seem that way to me because I've been a happy user of idea until a recent job change. Either way, it is pretty ludicrous to leave this bug unfixed for so long. Maybe I need to convince my current employer to buy idea. It has had this option for as long as I've been using it. Perhaps there's a reason they can charge money for their IDE.
I left comment #41.. I don't think it's over the top, because several of the developer responses to this bug have been explanations of "proper discipline.." I.E. to the effect of "If you knew what you were doing, you wouldn't need this.." (Look at comments #7 and #9) I find this arrogant, and this is reflected by the fact that the bug has gone unfixed, and our comments ignored. (In reply to comment #45) > Comment #41 may be a tad over the top. Though, it may just seem that way to me > because I've been a happy user of idea until a recent job change. > > Either way, it is pretty ludicrous to leave this bug unfixed for so long. Maybe > I need to convince my current employer to buy idea. It has had this option for > as long as I've been using it. Perhaps there's a reason they can charge money > for their IDE. >
Ack. Certainly these open sores guys are ignoring a lot of comments from the user community. Argues strongly for paying for real, supported software. BTW, anyone no of an editor that will allow me to implement the hack from 39 that doesn't require a C++ compiler on my box?
Sorry, "know of an editor" of course. I must be tired.
Comment #39 doesn't require a C++ compiler to be installed. All you need to do is to copy and paste a LF (0x0a) character from any windows application which allows you to type one into the right place into the Shortcut Properties box for the shortcut you use to launch Eclipse, as per comment #28. For what it's worth, I've been using this now on all kinds of Eclipse installs from 2.1 through 3.1m5 without any problems, and whilst it's undeniably a very serious shortcoming that there's still no support in the UI, this workaround does the trick for me.
(In reply to comment #47) > > BTW, anyone know of an editor that will allow me to implement the hack from 39 > that doesn't require a C++ compiler on my box? As I've said in comment #40, I've been successfully used SciTE (Scintilla Text Editor) to copy the LF character to the clipboard and then past it into the shortcut command field. SciTE is an open-source, simple and powerful text editor and can be downloaded for Windows and Linux at http://www.scintilla.org/SciTE.html
_Please_ raise the priority. They are already discussing this bug on theserverside.com, and why some bug like this one can be open for more than _42_ months.
We switched to Java and Eclipse some months ago and allow each developer to use his platform of choice since this Java stuff is designed to be highly platform-independent. However, to our great surprise we have no independence setting our default line delimiter within the otherwise great Eclipse IDE at all. And as it turns out, lots of people have already asked - if not begged - for this feature since years. So why don't you just go ahead and implement it? Do we really need to write a plugin ourselves to convert line endings on save?!? Shall I ask all of my over 50 developers to insert a comment here proofing that people really need this feature?
In response to comment #52.. Implementing this fix recently became *critical* to my development, due to the availability of certain govermnent machines at certain locations -- and code maintenance became horribly tedious using eclipse due to this problem.. (We had to write a script to check and correct each build.. Although switching manually on each file was specified to developers, that obviously didn't always happen, so the script was necessary, which took -too much time- for an already limited schedule.) The fact that this issue is being ignored is simply unacceptable, and the silence speaks volumes. If only to get some attention to this bug, I'm going to again call folks out and say.. what's the deal here? So, Gisbert, while a 50-developer rush to the bug probably wouldn't produce much -- I think that a good amount of well thought out complaints wouldn't hurt matters if they got "on the record".
(In reply to comment #53) > In response to comment #52.. > > So, Gisbert, while a 50-developer rush to the bug probably wouldn't produce > much -- I think that a good amount of well thought out complaints wouldn't > hurt matters if they got "on the record". Well, our reasons are the same as for others: Different platforms for development but one target platform for production. The borderline is marked by the source control management system. If the IDE does not provide the possibility to set the appropriate line delimiter at file creation time - what currently is not the case - one has to convert line delimiters later in the process - at the latest before committing into the SCM. This produces several kinds of work and overhead for every unit using Eclipse which could be easily avoided if there was that possibility to set the preferred line delimiter within the GUI. Of course there will not be comments of all of our developers - they actually have to do their work. I hope I can get some of them to vote for this bug anyway.
Mmh. So if you've got 50 Java developers working with an open source project having a 'critical', but in your opinion simple-to-fix issue, why don't you get one of those 50 developers to fix it?
RE: Comment #55. This is the EXACT type of immature attitude and comment that gives open-source a bad name. First of all, I am not the person with the 50 developers. I have a small team - but that does not matter. Our job is to write the code we write; not fix obvious problems in an open- source application because some people are either too dogmatic or arrogant to fix it. (That last comment makes me lean towards the latter.) So, you say, then pay for something - don't use open source! Well, that's exactly what people will do, and that's exactly why open-source is NOT the answer that everyone touts it as until attitudes like this get wiped out. I have enough problems and issues maintaining the code I am -WORKING ON-. To expect USERS to fix and maintain such an application in the "real world" is unreasonable, and severely discredits the concept of open-source. If you have free time, have at it. I don't. If development is going on with Eclipse, this bug should have been fixed. Period.
First off, please try to avoid making derogatory comments about *anyone* (the developers or the other posters). If this bug degenerates into a place for people to call each other names, I guarantee you that it will be closed. Having said that, you need to understand that I am absolutely 100% NOT trying to be arrogant, and I recognize that this issue is currently causing you grief. I'm going to discuss this with the developers and I will annotate this PR with a better description of the current situation by the end this week. In the mean time here are some things to keep in mind: 1) This really is an enhancement request, not a bug. There are many, many Eclipse (and Eclipse based commercial product) users that do not need this feature. You're use case is *very* real, but it does not impact the vast majority of people who use Eclipse. 2) Architecturally, this is not a simple enhancement for Eclipse to make. If it was, it just outright WOULD have been implented by now. Man, for something that seems so obvious, line termination is unbelievably pervasive and subtle. As has already been noted, both operating systems and VCM systems typically want to control line terminaters, but there are other factors. Are the rules different for specific "kinds" of text files? At what granularity do we allow these to be set? Where is the information stored? Even just "What *is* a text file?" isn't an easy question to answer. In any case, as I said above, I'll get back to you with more info once I have it. In the mean time, if you're going to flame me, *please* remember to be civil while you're doing it.
To hopefully end the back-and-forth.. I do apologize for my perhaps harsh tone in the last comment.. I really, really -want- to use Eclipse. I think a lot of people do who have commented about this issue, and I don't think I'm alone in *feeling* that the issue has been ignored up until now. Three and a half years seems a long time for such a thing to be outstanding. It also puts someone between a rock and a hard place when one touts the benefits of such a project to your peers and superiors, and such a (ok, seemingly) minor issue throws a wrench in the works. We all hear about the revolution OSS is to bring; I wasn't flaming anyone in particular -- just the attitude I see way too often.. "Got an issue? Fix it yourself or shut up." The last comment about the guy with 50 developers really got to me.. If I had the time and resources to dedicate to fixing such things, I would. I don't. Eclipse isn't only the right tool for the price, it's usually the right tool period - and this problem was being ignored. It forced me to use lower quality, more expensive tools because this was such a block to productivity. It's not about me being cheap and expecting something for nothing.. Just expecting more than a couple years of silence when multiple people express the same concern. Anyways, I won't digress and derail this any further. I didn't mean to get vitriolic -- it just seemed our complaints were falling on deaf ears for too long. If this issue is being addressed, tremendous. I am clearly not alone in needing this feature. Albeit, I may have been more vocal -- but this issue needed to be addressed. I think some may be underestimating the number of users who work on disparate platforms; I also think the number of people with such a need is more likely to increase in time, versus decrease. That being said -- re: technical subtleties of the issue.. Since it's possible to select this on a *per-file* basis, would it not be possible to simply have the option to make that "stick" as a default; and therefore any file edited would be treated with the correct delimiters, just as if the user had manually selected it on file open? I know that may not be the most robust solution, but it may help a lot of us get on with work and not have to be so concerned about the problem until a more robust solution can be implemented. I will remain in the peanut gallery from now on; however I am glad to hear the issue is being considered. I think that's what we all wanted to hear.
(In reply to comment #55) > Mmh. So if you've got 50 Java developers working with an open source project > having a 'critical', but in your opinion simple-to-fix issue, why don't you get > one of those 50 developers to fix it? I want to apologize for my impolite tone. From reading the comments it seemed to me that the problem was simply ignored for a very long period of time. But after the comment #57 From McQ saying that the issue is being considered with all its difficulties I have nothing to ask or to add anymore and will stay silent and patient. I did not think or say that this was a simple-to-fix issue at all. And as I said, we started development with Java only months ago, so most of the developers are still beginners. But - even if one of the more experienced could do it - I'm not their boss, so I can't tell them what to do. I could try to convince the boss that it would be worth the time and effort - you know, how difficult that is. Sorry again. I should have voted and kept my comment under my hat.
Just a side note, it does not fix the problem but might improve the situation a little bit: for 3.1 the line delimiter conversion has been improved to work over several files, folders and even projects (File > Convert Line Delimiters To).
Ok. I've talked to most of the teams that are potentially effected by this, and here's what I found... In the current Eclipse R3.1 development builds the following support for custom line separators already exists [yes, you probably know this already]: 1) When opened on an existing text file that contains line separators, the standard Eclipse editors detect which line separator the file uses, and continue to use that one as new lines are added. This should prevent "mixed" line separators from appearing in files. 2) The CVS repository provider (i.e. the Eclipse code we wrote to talk to CVS) has a preference checkbox "Convert text files to use platform line ending", which can be found in the "Files and Folders" tab of the "CVS" preference page (under the "Team" preference page). By default this preference is checked, but if you *uncheck* it, CVS will not modify the line separators of text files when they are checked out of (or into) CVS. This, together with point 1), should allow a team with developers working on multiple platforms to work with existing text files without causing the line separator to be modified. 3) As Dani mentioned above, the "File" > "Convert Line Delimiters To" menu operation can now be applied to whatever is selected, be they files, folders or projects. This should allow wholesale conversion of existing text files without grief. Honestly, I think this already a pretty good story, but none of it actually addresses the feature requested by this bug: "UI needed to define the default line delimiters for new files". So here's what we're going to do [To be clear, THESE FEATURES ARE NOT YET IN]: 1) We'll provide a per-project preference that allows you to choose what you want the default line separator to be for new text files created in that project. By putting it on the project, the value will be shared with the project. This, together with the features described above, lets a team of developers working on the shame project always use a particular line separator both when editing existing files and creating new ones. 2) We'll provide the same kind of preference for the workspace as a whole. This will be used for projects that do not explicitly have the preference set. Note that, if you want the line separator setting to "stick" to your work, you will want to use the project setting rather than this one (because even if you weren't sharing the project, you would have to remember re-set it every time you got a new workspace). 3) We'll modify the standard places where text files are created to detect and use these properties. One *very* important thing to keep in mind about this is that, we don't have control over all of the text file creating tools that have been written by the Eclipse community. Some of these, by nature of how they fit into the underlying frameworks, may do the right thing with the new preferences, some probably won't. I presume you will take on the task of evangelizing the need to support this new capability with the authors of the plugins you care about. ;-) So... the intent is to get this in before R3.1 ships. Because we are so close to the end of the cycle -- our M7 milestone, which is our first release candidate, is in two weeks -- I'm still pretty worried that we won't get all of the cases right, so it will be important for you to do serious testing once we do get the code in. I can't even promise that the code will be in for M7; it may slip past it by a week or so, so you'll have to watch for it.
doh. "...working on the _shame_ project..." That better not be a Freudian slip. :-)
Too bad "contentType" not included in the chain of preferences to check (to be analagous to "charset/encoding"). I've heard that request/use case, that's it not just "text files", but "html" specifically (and only) that was desired to be a non-platform delimiter. Would I seem like a "give an inch take a mile" kind of guy to request this be considered? (At a minimum, I'd suggest not locking out that possibility in future enhancements).
This is what were are going to do at the Core level to enable people above us: (all on the org.eclipse.core.runtime.Platform class) 1). Add preference key: PREF_LINE_SEPARATOR 2). Add method to return the known platform line separators: Map knownPlatformLineSeparators() The initial return set will be (keys are translated): {"Windows" -> "\r\n", "Unix" -> "\n", "Mac OS 9" -> "\r"} Since these are API additions, we need approval. Mcq & Jeem please comment.
This is a high priority polish item. I approve.
Released Core support as described above into HEAD. This will NOT be in today's 4pm build but will be in the nightly build and next week's integration build.
released the UI support for modifying this preference in HEAD (NOT M7). See Window > Preferences > Editors Or select a project and see Properties > Info page.
Is it intentional that the project property isn't a shared setting? I would have expected that this can be stored on the server similar to the encoding property i.e. the value is written into a *.prefs file in the .settings folder.
I agree with comment in #68, seems it ought to be shared, as a property of the resource (used by whole team) ... not just an individual's users personal preference.
It's supposed to be shared. That's the predominant reason for putting it on the project, in fact.
re: comment #68, thats a bug. Fixed in CVS now.
Reminder for Platform Text clients: An IDocument does not care about mixed line delimiters i.e. it accepts and handles them gracefully as long as they are part of the legal line delimiters. Clients who want to ensure a single line delimiter in their document should use the line delimiter returned by org.eclipse.jface.text.TextUtilities.getDefaultLineDelimiter(IDocument).
How about a description of the new API plugin writers are supposed to use to allow them to honor the delimiter preference?
The info hasn't been collected into one place yet. The preference and method that answers default values are described in comment #64 of this bug. The discussion of the Text team API is in bug #94987. It's marked fixed, so I just annotated it with a request for the final version of the API.
I've attach the final API to the other bug report but I assume this is probably not what Bob's looking for. I guess what plug-in developers are really interested in are the changes they have to apply to their code. Regarding this the new Platform Text API will not affect plug-in developers if they use either file buffers or a FileDocumentProvider since I've added code that gives them the new stuff for free :-) I suggest that we collect all the changes that affect the plug-in developers, append it to this bug report and add it to the migration doc.
Fixed in HEAD since last week. Will be in upcoming I-builds and in 3.1 RC1.
verified in 3.1 RC3
