When I use IntelliJ for Java or WebStorm for HTML/CSS I get this change (I think that that is the best way to say it): it basically removes my file tree from the left side of the screen and forces it up which makes me unable to find and open/edit files easily, sometimes I cannot even edit the files at all. (See the picture)
This has been really annoying since it forced me to use NetBeans instead of IntelliJ.
I hope someone is able to help me with this so I can use IntelliJ again.
To open the Project view, press Alt-1 (or Cmd-1 if you're using Mac OS X).
Related
A while ago, Ctrl+V stopped working in Intellij IDEA. Neither the shortcut nor Edit > Paste works. It's really weird, since "Paste Simple" still works fine, so does Ctrl+C and Ctrl+X.
I've seen a lot of suggestions to solve this problem, but most of them are somehow related to the Vim Emulator for IntelliJ, which I don't use. I tried to play around with the Keymap, but could not get it to work.
I'm using Intellij 2017.2.5 on Windows 10. Maybe I screwed it up myself somehow, but I wish to fix it, because it's really painful to work without Ctrl+V.
You can try alternatives:
Ctrl + Shift + V for Windows or Linux
or
You might try Ctrl+INS for copy and Shift+INS for paste and
see if they work. They are the traditional cut and paste and have been
around a lot longer than Ctrl+c/Ctrl+v
I had the same problem, I regularly reboot so I always have a back-up of my settings. When I reimported them and updated the plugins I could paste again without issues.
Back-up your settings from a working state File>>Manage IDE Settings>>Export Settings and use >> >>Import Settings to apply them.
If you don't have a back-up you can try it, but you might be backing up the problem as well. In that case you will have to reset to defaults and reset the IDE to your liking.
My OS is Ubuntu 18.04, and i had this problem before. An effective solution for my IDE is to set the Keymap to Default, which is file>setting>Keymap.
I use the Ctrl+Shift+T keystroke in eclipse quite often, and in Neon it has stopped working some of the time.
I have been to the Window / Preferences / Open Type entry and deleted the Ctrl+Shift+T for JavaScript (though I don't think that should be necessary, it was recommended).
I have verified that this behavior happens in .txt and .xml windows in both Java and "Web" perspectives. It operates correctly if I have a Java file open in the editor, but I really want it to open when I'm looking at an XML file, since that often leads to wanting to look at Java source.
I also found a reference to going to one of the .metadata directories and deleting all the .index files and one other file (don't remember which now), then restarting eclipse. I did that, and it made no difference.
Is this a bug, so I should report it? Does anyone else see this behavior? Does anyone have another suggestion as a workaround? I'm quite keyboard-oriented, and this is a pain in the neck.
I've met the similar situation before, here is a solution,
left click the xml file---open with---xml editor
Using the eclipse's default xml editor may helps,I guess you've installed a plugin to open the xml file,so the problem may cause by the plugin,if you really want to use plugin to edit xml file,maybe you can try another plugin
I'm trying to figure out which files to check in to version control when using Eclipse for Android development. I have a workspace with a single project. I found this which suggested that the .metadata folder did not need to be controlled (minus the comment there about launch params, however I don't mind re-picking those again on a different machine).
If I remove the .metadata folder then open Eclipse the project is no longer shown. I searched for posts on this symptom and they suggest re-importing the project. This solution doesn't make sense here, I'm trying to check in whatever is needed so another developer can open the workspace and see the project and work on it. Having them move the project then re-import it would be a bit messy.
So which files should I be version controlling so that someone else can get the latest and be able to open the project without controlling a bunch of user specific preferences?
I have had similar experience using Eclipse for version control, and decided to quit using it because it is very annoying and buggy. Now, for git, I use SourceTree, which I prefer over eclipse version control. I think you should version control the source code folders, along with configurations, and other files you program needs to function, but never the executable files. If the other person is using Eclipse, for easiness, it is good idea to include the .classpath configuration file. If not, then the other person would need to clone the repository and make the required changes so that it works with his/her IDE.
I think I've settled on the following approach. This seems to work well so far and avoids some of the headaches mentioned in my original question.
1) each developer creates an Eclipse workspace on their machine somewhere, outside of version control; only the project directory is checked into version control - the workspace is completely uncontrolled
2) developers checkout the project directory from version control (in a different directory structure than where the workspace was created) and then use File >> Import, but they leave the "copy into workspace" unchecked.
So with the above, you can checkout from version control and work with the files right where they were checked out. There's no need to move them out then import them back in. When you import with the copy option unchecked, the workspace (which itself is not controlled) is just referencing the files where they're at on disk.
The only minor downside is that any workspace stuff has to be setup individually. Other articles mention controlling the launch params, but so far this hasn't been an issue - pretty easy to pick that once the first time you launch.
So anyway, hopefully this helps someone else :) This seems to be a reasonably smooth way to do it and avoids the issues we ran into initially.
So I was busy writing away in eclipse when there was a power cut. Luckily I had been saving regularly and so when I got back on I still had all my work.
However after writing a few lines and running it and spending a while trying to figure out why it wasn't working I realized that whatever I wrote didn't change what ran. I could even comment out bits of code OR EVEN the entire program OR EVEN YET DELETE LINES OF CODE, yet it still runs as if the same code was there from before the power cut. In the file menu all the save features are grayed out, yet if I control S and restart my pc or restart eclipse then it has made changes to the code and saved however the new code has made no effect on anything and still runs as before.
Has anyone else experienced this?
Has eclipse got some auto save feature for problems such as power cuts in order to prevent work less?
Has this put eclipse in a special mode that I can exit back to the normal mode?
When issues like this happen, the first thing to do is to click on Project -> Clean in the main menu.
The Project was corrupt.
Solution
Copying classes across into a new project and deleting old project.
Try restarting eclipse. Perhaps it kept some content in the editor but the link was broken from the actual file that it's building. Maybe copy your code just in case the file is out of sync with the editor.
My problem was the folder was in a different workspace, so the old version of my file was in there, but my newer saved version was in a different workspace. I didn't realize the newer version was somewhere else. This happened because I need to send files back and forth from my main computer to my laptop for school, then return the folder again. So be extra aware of your workspace locations! If you export a project from Eclipse, it will always choose one by default, but you can choose another in the export menu.
I have a problem with Eclipse Indigo regarding library source code. When I open a library class (e.g. from the JDK, but also from some other included libraries, such as Guava), either using the Open Type dialogue or simply through Ctrl+ click on the class name or some of its methods, once in a while (not always) something breaks.
Don't get me wrong, the source is always displayed without any problem (either JDK source shipped with the JDK itself or Guava source downloaded by Maven). What actually stops to work:
When I open the Quick Outline popup in that given class using Ctrl + O, the list of methods and fields displays normally, but when I click on any of them, Eclipse doesn't move the view on it as it should. Also Ctrl + clicking any of the methods or fields of that class in my code doesn't bring me directly to it, but simply at the top of the source file.
When I hover over that said class or its methods, no JavaDoc appears in the popup as you can see in the attached image. I am in the HashSet class, the source is clearly there, but it isn't displayed in the popup.
I found out that this can be fixed by opening the Outline View and briefly clicking through the class's methods and fields. After a few clicks, Eclipse catches on and starts to work correctly, but only for this one class, not for all which are broken in this way at the moment.
Has anybody met this kind of bug? Is it tracked at Eclipse Bugzilla? Thanks in advance for any advice.
For completeness, this is my configuration:
Windows 7 Professional x64
Oracle JDK 1.7 Update 2 32b
Eclipse Indigo for Java EE Developers 32b
your issue #2 may be resolved by following these steps :
Go to http://java.sun.com/j2se/1.5.0/download.jsp and choose to
download the JDK 5.0 Source Code.
For JDK 5.0, select Download(SCSL source).
Download JDK (SCSL) 5.0 (1.5.0). This will give you a file jdk-1_5_0-src.scsl.zip. You do not need to unzip this file; Eclipse likes it the way it is.
In Eclipse, go to Projects -> Properties -> Java Build Path -> Libraries and expand JRE System Library [jre 1.5.0], then rt.jar. Select Source attachment and click Edit...
Select the above zip file. and Finish by exiting the dialog boxes.
source
Hope this helps..
Sounds like wrong sources are attached to the libs inside Eclipse.
I had similar symptoms in a project where a class exist in both: inside a lib and in the project's src folder. Same canonical class name, but different implementations.
I would recommend to verify (or reinstall) your JDK-Installation and re-configurating it in Eclipse.
Hitting Ctrl+Shift+T and typing HashSet and taking a screenshot of that window may help here, too.
To answer my own question, I didn't find out how to solve the problem in Indigo, but updating to Juno fixed it.