Community
Participate
Working Groups
I don't yet have the CDT installed. If I hit "File" -> "Open File..." and select a .c file my system editor (Visual Studio) is launched. I would not expect File -> Open to launch another app in any circumstance. In this case I would expect a basic text editor. A hex editor might be more appropriate if the file is detected as binary
*** Bug 178011 has been marked as a duplicate of this bug. ***
*** Bug 216615 has been marked as a duplicate of this bug. ***
*** Bug 224702 has been marked as a duplicate of this bug. ***
As per http://wiki.eclipse.org/Platform_UI/Bug_Triage_Change_2009
Remy is now responsible for watching the [EditorMgmt] component area.
*** Bug 303021 has been marked as a duplicate of this bug. ***
*** Bug 53359 has been marked as a duplicate of this bug. ***
Before a file is opened with the System Editor, we should ask the user by default. The dialog should have a checkbox "Always use the System Editor for this file type". If checked, the file type should be added to the "File Associations" preference page and the System Editor should be assigned as default editor. If a file type has the System Editor configured as "associated editor", but it's not the default editor, then the dialog should also not be shown any more if the user opens a file with Open With > System Editor.
I like the idea of configuring file associations on the fly, by asking back for file associations not yet known. The dialog should be capable of making a file association with any editor (internal or external), not only with the System Editor (like Open With ... Other). I'm not yet sure to what extent the "Default Open Behavior" should be a Product Setting. For products that behave like an editor or IDE, end users would probably expect opening files in the internal editor by default. And, I'm not yet sure how to handle file types that don't have an extension (like many UNIX shellscripts).
(In reply to comment #8) > Before a file is opened with the System Editor, we should ask the user by > default. Hmm... If we are going to change it after all those years, I'd prefer a Firefox-style solution where some file extensions are asked, and some are opened without asking, and there is an option to change it. - For ".c", ".cpp", ".project" files, in other words, well-knows file types that cause issues like what described in the comment 0 we should ask on the first file opening - For ".jpg", ".wmv", and such we should open system editor, if any - We should have both programmatic and UI ways to change the preferred behavior.
(In reply to comment #10) All these concerns are met with the proposal in the rest of comment 8, where the "System Editor" is only used after it got an explicit file association. File associations are already contributable today. See bug 46297 about file types without extension.
*** Bug 368641 has been marked as a duplicate of this bug. ***
*** Bug 421805 has been marked as a duplicate of this bug. ***
The general issue here seems to be that by default, the platform provide a very minimal set of defined content-type, so that most filetypes ends up by being unknown so open with External Editor. Is this interpretation correct? If so, what about creating a contenttype registry plugin inside platform which would define as many content-types as it can so most known fileformat who can be opened with Text Editor would actually be opened with Eclipse Text Editor ?
*** Bug 232345 has been marked as a duplicate of this bug. ***
From my point of view the solution should be same for DnD and "Open File...". See my proposed solution from duplicate https://bugs.eclipse.org/bugs/show_bug.cgi?id=232345#c16 ... In "other" editors the fall-back is done by using text editor or asking you what editor should be opened (also external). Our developers are expecting the same from eclipse. The problem is: you cannot just open an unknown file with eclipse text editor or hex-editor (javahex-plugin). My offer is to provide checkbox for this feature (General->Editors): [] Prompt to select editor if opening unknown file type If this checkbox is selected, eclipse should show the same dialog like "Open With -> Other". ...
I created a small plugin [1] that overrides the default behavior of the platform and opens text file of unknown type in the plain text editor of Eclipse instead in an external editor. [1] https://github.com/eclipselabs/default-text-editor
New Gerrit change created: https://git.eclipse.org/r/46341
I pushed a Gerrit patch that contributes the implementation of the plugin plus a preference to enable and disable the overriding of the default editor. The new preference is in the General > Editors page - a check box with label "Open unknown text files in the text editor".
I will have to take a closer look. I'm not sure that we want to make that change so late in the game but rather postpone it to 4.6. If we decide to take it for 4.5 then the default must be like in 4.4.
(In reply to Dani Megert from comment #20) > I will have to take a closer look. I'm not sure that we want to make that > change so late in the game but rather postpone it to 4.6. If we decide to > take it for 4.5 then the default must be like in 4.4. +1 from my side to include it in 4.5. If the default stays as in 4.4 we should adjust it early in 4.6.
(In reply to Lars Vogel from comment #21) > (In reply to Dani Megert from comment #20) > > I will have to take a closer look. I'm not sure that we want to make that > > change so late in the game but rather postpone it to 4.6. If we decide to > > take it for 4.5 then the default must be like in 4.4. > > +1 from my side to include it in 4.5. If the default stays as in 4.4 we > should adjust it early in 4.6. +1 from me too for 4.5. I did the review, after few requested changes are fixed I think the patch could be integrated into 4.5 (the default would be like in 4.4) but we need PMC approval since a new constant is added to the IDE class.
Current contribution state (https://git.eclipse.org/r/46341) doesn't allow to be submitted for 4.5, but I highly encourage Kaloyan to work towards 4.6 integration, see review comments.
(In reply to Andrey Loskutov from comment #23) > Current contribution state (https://git.eclipse.org/r/46341) doesn't allow > to be submitted for 4.5, but I highly encourage Kaloyan to work towards 4.6 > integration, see review comments. +1.
Thanks for the feedback! I will submit a new patch set soon with the suggested changes. Since we now target this for 4.6 instead of 4.5, I guess I should not switch this feature off by default, right? Regarding, improving the TextFileDetector to be more reliable in detecting text vs binary files there a few possible options. 1. Have a predefined list of known file extensions for binary files (e.g. PDF, ZIP, PNG, etc.) and another list of known file extensions for text files (e.g. TXT, JAVA, HTML, XML, etc.). So, first we try matching the file extension of the tested file with these to lists, and only if there is no much to try to test the file content with the ICU CharsetDetector. 2. Try to detect magic numbers in the file content like the Unix file command [1] does. There is a Java library [2] that does this using the magic number definition from the Unix file command. If no match then use the ICU CharsetDetector. We can use either of the above, or even a combination of both. However, please note that most probably we will never reach a perfect state of detecting if a file is binary or text. For some file types it is quite debatable. For example, are SVG files text or binary? It's an image file, but it's content is XML-based. So, if I double click on an SVG file and the Eclipse installation does not have an associated editor for it, should it be opened with the internal text editor showing the XML content, or should it be opened with an external system editor/viewer showing the image? There are other file types like this.
I forgot to add the bookmarks. [1] http://linux.die.net/man/1/file [2] https://github.com/j256/simplemagic
(In reply to Kaloyan Raev from comment #25) > Thanks for the feedback! > > I will submit a new patch set soon with the suggested changes. Since we now > target this for 4.6 instead of 4.5, I guess I should not switch this feature > off by default, right? > > Regarding, improving the TextFileDetector to be more reliable in detecting > text vs binary files there a few possible options. > > 1. Have a predefined list of known file extensions for binary files (e.g. > PDF, ZIP, PNG, etc.) and another list of known file extensions for text > files (e.g. TXT, JAVA, HTML, XML, etc.). So, first we try matching the file > extension of the tested file with these to lists, and only if there is no > much to try to test the file content with the ICU CharsetDetector. > > 2. Try to detect magic numbers in the file content like the Unix file > command [1] does. There is a Java library [2] that does this using the magic > number definition from the Unix file command. If no match then use the ICU > CharsetDetector. > > We can use either of the above, or even a combination of both. However, > please note that most probably we will never reach a perfect state of > detecting if a file is binary or text. For some file types it is quite > debatable. For example, are SVG files text or binary? It's an image file, > but it's content is XML-based. So, if I double click on an SVG file and the > Eclipse installation does not have an associated editor for it, should it be > opened with the internal text editor showing the XML content, or should it > be opened with an external system editor/viewer showing the image? There are > other file types like this. I'm not a fan of that approach. We do not want to contribute content types in the platform for which we don't offer support. E.g. WTP will provide content types for XML, HTML etc. Also, we do not need new preferences. Comment 8 describes the correct fix for this problem.
I believe the solution contributed to bug 90292 covers this bug too and we can close it as duplicated.
Yep. *** This bug has been marked as a duplicate of bug 90292 ***
