Community
Participate
Working Groups
It's frequent that when doing File > Open File... in Eclipse IDE, I'd later would like to reuse those files for other things like showing a local history, diffing with other files and so on. But the vast majority of those powerful actions require file to be visible in the Project Explorer. When opening a file from filesystem, instead of just showing the editor, it would be convenient to automatically imported as an external resource in the workspace. I imagine we could create a "opened non-project files" or even a "my-sandbox" project and add those external files as children on this project as linked resources.
+1 I have the same issue for opening files via the command line. Example: `eclipse build.gradle` opens the build.gradle in an editor. Now I would love to diff my changes via Eclipse but for this, I need it in the package explorer. As for the label I think using a name based on the folder name would be another optons. So if I open build.gradle from the directory "scripts" the label would be "scripts" with build.gradle below it.
Please note, that this will not help with git history context, becuse projects allow only 1:1 mapping to repos. The idea itself is interesting. We have already 'hidden' projects for search, jdt external folders and something else I can't remember right now. In our product we also create hidden project for some temporary files. May be this can be generalized? At lest for the opened external files: should the project disappear on Eclipse restart? Or other way around: how we will do a house keeping there?
(In reply to Andrey Loskutov from comment #2) > Please note, that this will not help with git history context, becuse > projects allow only 1:1 mapping to repos. Indeed. That could become later an enhancement request for EGit ;) > The idea itself is interesting. We have already 'hidden' projects for > search, jdt external folders and something else I can't remember right now. > In our product we also create hidden project for some temporary files. > May be this can be generalized? I don't think this one should be hidden. And I think we should try to have JDT or other reusing this too. They have their own hidden projects for their reasons which are probably not at all the same as the ones here. There are probably assumptions made on those hidden project that we cannot assume remain true with a "sandbox" project. > At lest for the opened external files: should the project disappear on > Eclipse restart? Or other way around: how we will do a house keeping there? Or another approach: should the IDE do the house keeping automatically or should the user take care of it. The later seems better to me.
(In reply to Mickael Istria from comment #3) > (In reply to Andrey Loskutov from comment #2) > > Please note, that this will not help with git history context, becuse > > projects allow only 1:1 mapping to repos. > > Indeed. That could become later an enhancement request for EGit ;) The restriction that a project must be wholly in one repository (modulo folders in submodules/nested repos) is so deeply ingrained in EGit that I will not change that. I'm not even sure it could be done at all; it would depend on the assumptions Team makes. The git history of non-workspace files and comparison between versions is available through the git history page.
Related suggestions for making Open File friendlier: - Give it a friendlier keyboard shortcut than the current Alt + F followed by period. - Have the dialog start in the workspace directory rather than the user's home directory.
(In reply to Nathan Ridge from comment #5) > Related suggestions They're actually not so related. Please.open separate tickets for those.
I've been using the atom editor recently to fill in a gap that I think Eclipse could fill. When I'm roaming around on my filesystem for folders that are coming and going (git branches or ephemeral workspaces) I really want to just "open this folder and see all the files that are under this directory tree in eclipse"). But Eclipse doesn't have a easy way to do this. Of course I can do this " File > new project > general project > custom location > point to folder > open". But those steps cause too much friction. Could we do this? $ cd /path/to/some/folder $ eclipse open . And eclipse will do the following 1. if folder already have a .project then just open it 2. if no .project, run through 'smart importers' to see if any of them can 'import this type of folder' 3. if no smart importers can do anything, just do the exact same thing as above "create a .project (basic project) for this folder and open it". If Eclipse had this workflow, I would avoid using Atom editor and just use eclipse. No one problem that I'm glossing over is removing the .project or removing the project from eclipse. I wish Eclipse had a "simple folder/project" concept that didn't require a .project. But maybe whatever is created by "eclipse open ." could be "uncreated" on workspace/workbench shutdown?? Just thinking out loud.
Also another problem that I glossed over is the "eclipse open ." getting an "eclipse" executable in your path. Maybe that is something the OOMPH installers could do?
(In reply to Greg Amerson from comment #7) > But Eclipse doesn't have a easy way to do this. Of course I can > do this " File > new project > general project > custom location > point to > folder > open". But those steps cause too much friction. File > Open Projects from Filesystem... does that with less friction. > $ eclipse open . > And eclipse will do the following > 1. if folder already have a .project then just open it > 2. if no .project, run through 'smart importers' to see if any of them can > 'import this type of folder' > 3. if no smart importers can do anything, just do the exact same thing as > above "create a .project (basic project) for this folder and open it". > If Eclipse had this workflow, I would avoid using Atom editor and just use > eclipse. This seems like proposal in bug 500388
Thank you for pointing me to that other ticket. The only thing I don't see there is about the automatically creating the general .project for a folder that has nothing pre-existing or smart-importer doesn't know what to do with it. I can followup there.
+1 A great idea. I like it. Maybe create a project called "Quick Access" or "Recently Opened" or let the user define a project in the preferences. A case can be that I open two files from different locations but with the same name, like pom.xml?
Additional idea: allow to select an existing project.
(In reply to Dani Megert from comment #12) > Additional idea: allow to select an existing project. Do you have a user-story making this useful? The issue with more option is that users tend to dislike the one they never use, so before adding more options, we should have some user-stories supporting them.
(In reply to Mickael Istria from comment #6) > (In reply to Nathan Ridge from comment #5) > > Related suggestions > > They're actually not so related. Please.open separate tickets for those. Filed bug 539128 and bug 539129.
