Is there any built-in way (or plug-in) allowing for searching through the whole variable tree without manually expanding nodes?
I can't understand why isn't it done by default, just as I can't understand, why isn't search bar built into Variables view (browser style) and this unhandy, inconvenient dialog is opened instead. It makes my work, which is mainly debugging complex applications, a nightmare.
The Eclipse version is Luna, if it matters.
The watch expression feature is not what I want because it just doesn't work in this case, tried to fix it but none of the common ways to do that help me.
Such a feature has been requested earlier here: https://bugs.eclipse.org/bugs/show_bug.cgi?id=170396
You may want to reopen this bug to state your interest in this enhancement. And if you have experience in developing Eclipse IDE plug-ins, I am sure the maintainers would be happy to review a patch.
I usually use Alt+Shift+Right/Alt+Shift+Left and Ctrl+Shift+I to select and inspect variables and expressions, but this certainly depends on personal preferences.
Related
I've realized that the Eclipse IDE puts all packages in a project (at least in a Java one) at the same level, e.g.:
However, browsing the file system, you can find that packages are treated in the expected multi-leveled way. Does this have any logical explanation?
This is just a presentation feature. You can click on the little down arrow you see on the left of your screen shot and select Package Presentation -> Hierarchical to have it like your filesystem.
You can see this answer for more information.
I asked the same question a couple of times and found the link in above answer helpful in order to change the presentation because it's an option hard to find.
About the Why part, I think it's because of Eclipse being DE-facto standard IDE for Android development and having the packages organized this way is more useful and it forces you to think about a way your classes are organized according to Android project guidelines. It also looks quite like help files on http://developer.android.com/guide to me personally. Also another argument for this might be that in old versions of Eclipse (pre Android time) default view was different.
I often hear how good the code completion, coding assist features of Eclipse are compared to other editors which raises the question if these parts could be separated from the Eclipse code base.
If this part is separated with an API through which it can be told things it needs to know (where are the files of the project, what are the include paths, etc.) then it can return the necessary information (help for a symbol at the cursor, possible completions, etc.) and any editor (emacs, vim, etc.) can use it.
Why is it not done already? Are these code assist parts tied too tightly to Eclipse internals and they can't be sepaarated easily? Could someone who knows about the internal workings of Eclipe shed some light on this?
Edit: Here's a working setup with SharpDevelop for C#, emacs is the UI and the info comes from the SharpDevelop module. See the screenshot on this page. Eclipse's completion support could support emacs and other editors similarly.
The eclim project tries to solve this problem by interfacing directly with eclipse. Thus at least an headless running eclipse is required. While eclim's focus is afaik the vim integration, there also exist plugins for other editors (emacs, textmate, etc). The communication between eclim and an editor happens through a server interface.
Maybe not exactly what you where looking after, but imho worth a look:
http://www.eclim.org/
The content assist uses an internal model of the Java projects - without this model the content assist cannot work (that effectively).
I am not sure, how tightly is integrated to Eclipse internals, but I do know that it uses the Eclipse Resources API (file system handling) and other features such as Eclipse extensions (new completion providers can be added without modifying the code).
Alltogether, I believe to port this completion engine to other editors the mentioned editors would lose their (in some case relative) simplicity to Eclipse, thus it might not provide the smaller footprint of the mentioned editors - so I don't think, it is feasible to provide such engines effectively for other editors.
I was always wondering why it is a big deal having version control support inside an IDE.
I always preferred to use a command-line/standalone version of the version control of choice and never found IDE integration helpful.
I know it can be helpful sometimes, for example to automatically keep track of renames, but I was bitten by version control plugins a couple of times (especially the ClearCase Eclipse plugin) that I'm now finding it counter productive compared to the command-line version, where I have better control.
What is your opinion?
Integrated Source Control also helps to only keep the important files under Source control. For example, when I add a new File in Visual Studio, the Plugin (visualSVN) will allow me to add it easily without me having to remember to go outside of my IDE and run the command to add it to the repository. On the other hand, it will automatically ignore temporary files, like the obj/ and bin/ Folders.
Essentially: Integrated Version Control that actually works is a great way to keep the repository clean and complete.
I like how some IDE's implement this. Ankh-SVN for Visual Studio is not that great and is a bit buggy, however Subeclipse I find to work exceedingly well when I'm using Eclipse.
I think it really depends on the IDE you're using and the quality of that plug-in. It's going to work well for some setups and terrible for others.
That's why I like Subversion with Tortoise SVN so much. I can choose to use the IDE integration when and where it makes sense, otherwise, just like you said, I can simply use the command line or in my case, the windows explorer based client!
Integration of the IDE with version control and, in particular, software change management (SCM) helps bringing together the philosophies of the IDE and the source control system.
One example is temporary files and binaries, that should not be checked-in and, e.g. in Visual Studio, end up within the source directory if you're not carefully creating new project and solution templates with a non-default directory configuration.
Another could be tracking of work items and complex bug fixes.
Also it saves some ceremony and context-switching when editing files.
Advanced integrations may also allow to push the change management system's concept of "configuration" ("branch", "tag", "view") into the IDE.
ClearCase integration, however, is clearly not "advanced".
A lot of it is simply the preference and comfort level of the user. Some folks are comfortable with the command line. Some prefer a GUI.
I wouldn't make generalized assumptions that all version control within the IDE is bad or buggy based on experiences with a particular plugin which had issues.
Why even have an IDE? Why not just do everything with a command line? ;)
The answer is that having it integrated with the IDE is "better".
My #1 reason:
You can visually see if a file is checked out or not, and if you need to edit a file, you can take the action right there where you are working.
There are more, but that is the big one.
It's depend on your IDE and the way you work with VCS.
Me and my team using VSS plugin-ins inside Delphi IDE, it gives a lot of flexibable feature when working together for example, All our forms are check-in when you start to write a letter or move components it asked if you want to check-out the code file or form.
also when some one change any code in other forms, it pop up and telling you it's already update by someone else and asking you to update current files in your H.D.
and you just get everything while you are in the IDE, you don't need to move to other external file, or command prompt to do a simple task.
I find most people who like to deal with command prompt working mostly in code without GUI IDE or may I be wrong.
Nearly all of my subversion needs can be handled by the IDE interface. It's a lot faster to do 2 quick clicks than pop up a command line, cd to the right place, issue the command, etc.
Command line has it's place, but with the current crop of IDEs, that place continues to shrink.
I have battle scars from using a buggy implementation of an IDE/VCS integration. In all honesty, if it was not buggy it would have been great. As long as there are great tools like TortoiseSVN, I don't see a need for IDE/VCS integration. I'd rather have more tools that do their job well than a few buggy tools.
Version control support in an IDE generally gives you a better view. The IDE actually knows what type of file you are looking at when doing a diff, which means it can do context highlighting and help you do merges more effectively.
I also think it saves setup time. In stead of installing all kinds of tools, a developer can download the IDE, do a checkout an be on it's way. If every developer on a project uses the same IDE, they can help eachother.
"Counterproductive" is a large word. If you have serious CVS/SVN problems maybe once a month, it's still way to few to have complicated clients installed on all your dev machines.
I have both systems where there is an integrated IDE (Microsoft FrontPage against an IIS Development Web site with Visual Source Safe on all of the web content) and where there is not (java command-line development, Visual Studio Express Editions). An intermediate case that I use is jEdit 4.x with VSS integration via plug-in.
I think the integrated case is valuable for the reason it always is -- you don't have to leave your application to interact with source-control functions and you don't have to worry about remembering to add new files and to check out files before editing them. The ability to have a smooth work process and to minimize the risk of oversights is powerful, as far as I am concerned. Even when the IDE-plugin integration is less than perfect (the jEdit 4.x case), I still prefer it over not having it.
I also agree that having explorer integration on Windows, the case for Tortoise SVN, is also a great capability, even when IDE integration is available. This allows convenient operation without having to launch the IDE while also being able to launch from the explorer window into the IDE (depending on file type) or editor or make or whatever while operating in Windows Explorer.
And yes, the command-line interfaces remain valuable, especially for scripting of recuring-operation patterns.
I operate in many contexts. Having low barriers and fluidity of operation in all of them is to be prized.
I'm not sure I understand the question. IDEs by definition are integrated, meaning that they're supposed to help you avoid the need to get out of the environment for anything project-related. Version control obviously fits the bill.
If you're looking for more practical reasons, one is that IDEs can offer you awareness by the nature of their graphical presentation. Eclipse, for example, will present files and directories that have changed. With additional plugins or suites, you can ever get real-time awareness as soon as another user is editing the same file, helping you predict a merge conflict before it occurs. I'm not familiar with a commandline based mechanism.
I use intellij integrated with cvs on a regular basis and by far the best feature of the integration of version control inside the IDE is line-by-line indications of what is added, edited, or deleted along with easy access (mouse hover/tool tip) to the pre-edit changes.
This is all within the source code in a non-obtrusive way.
For the nuts and bolts of version control (checkin/checkout/update/etc) I sometimes use the IDE and sometimes use the command line.
The number 1 reason for an SCM integrated with the IDE is that it makes it more effortless to use it and eliminates the need to REMEMBER to check things out. Through experience I have seen that steps that developers construe as extraneous, which often encompases anything other than writing code, don't get done. Making them do extra steps increases the odds that developers won't bother with it and will work around the source control system
I use eclipse for quite a lot of work, including:
multiple "utility" projects that include code that most of my java work makes use of
various plugin-related projects that I sync and use periodically (eg: the Git plugin)
plugin projects I'm actually developing
the occasional pydev / non-java project
etc...
It is becoming quite difficult to keep all these things straight, particularly since I never need to use them all at once. I've tried using Mylyn (and I'm trying it again) but in the past it has caused eclipse to run extremely slow, and I am notoriously horrible at remembering to tell mylyn that I've switched tasks, so it tends to learn very odd (and largely useless) sets of resources.
I've considered using multiple workspaces, but that is problematic when multiple projects need to exist in multiple workspaces, and when I need to synchronize the eclipse metadata directories across workspaces.
What is the best way to manage complex working environments in eclipse? Other development environments aren't a viable option because there aren't any sane alternatives when it comes to developing eclipse plugins (and that is a requirement).
(I think a very similar question was asked a month or two ago, but I haven't been able to find it...)
It isn't quite clear to me what your need is. But have you tried using working sets in the Package Explorer?
Open the Package Explorer view, open its menu, and Select Working Set. That lets you give a name to a subset of all the projects loaded in your workspace.
Switch working sets using the package Explorer menu. Use working sets to limit the scope of Search, errors, problems, etc.
Define as many working sets as you need to group your projects. A project can be part of any number of working sets.
Here's a screencast about working sets -- this does look like the right answer.
http://www.peterfriese.de/eclipse-working-sets-part-i/
You want to use "Working Sets".
I would recommend using different workspaces, and then adding the common projects to each workspace (you can specify the location of the project to be outside of the workspace). I believe this will work, but I haven't tried it, so I can't be sure.
As #JesperE and #Dennis S suggested, working sets will help you organize your projects, but they may not make eclipse run any faster, since the projects will all still be loaded into the workspace.
Having programmed through emacs and vi for years and years at this point, I have heard that using an IDE is a very good way of becoming more efficient.
To that end, I have decided to try using Eclipse for a lot of coding and seeing how I get on.
Are there any suggestions for easing the transition over to an IDE. Obviously, some will think none of this is worth the bother, but I think with Eclipse allowing emacs-style key bindings and having code completion and in-built debugging, I reckon it is well worth trying to move over to a more feature-rich environment for the bulk of my development worth.
So what suggestions do you have for easing the transition?
Eclipse is the best IDE I've used, even considering its quite large footprint and sluggishness on slow computers (like my work machine... Pentium III!).
Rather than trying to 'ease the transition', I think it's better to jump right in and let yourself be overwhelmed by the bells and whistles and truly useful refactorings etc.
Here are some of the most useful things I would consciously use as soon as possible:
ctrl-shift-t finds and opens a class via incremental search on the name
ctrl-shift-o automatically generates import statements (and deletes redundant ones)
F3 on an identifier to jump to its definition, and alt-left/right like in web browsers to go back/forward in navigation history
The "Quick fix" tool, which has a large amount of context-sensitive refactorings and such. Some examples:
String messageXml = in.read();
Message response = messageParser.parse(messageXml);
return response;
If you put the text cursor on the argument to parse(...) and press ctrl+1, Eclipse will suggest "Inline local variable". If you do that, then repeat with the cursor over the return variable 'response', the end result will be:
return messageParser.parse(in.read());
There are many, many little rules like this which the quick fix tool will suggest and apply to help refactor your code (including the exact opposite, "extract to local variable/field/constant", which can be invaluable).
You can write code that calls a method you haven't written yet - going to the line which now displays an error and using quick fix will offer to create a method matching the parameters inferred from your usage. Similarly so for variables.
All these small refactorings and shortcuts save a lot of time and are much more quickly picked up than you'd expect. Whenever you're about to rearrange code, experiment with quick fix to see if it suggests something useful.
There's also a nice bag of tricks directly available in the menus, like generating getters/setters, extracting interfaces and the like. Jump in and try everything out!
One thing that helped me transition from Emacs to other IDEs was the idea that IDEs are terrible editors. I scoffed at that person but I now see their point.
An editor, like Emacs or Vim, can really focus on being a good editor first and foremost.
An IDE, like Visual Studio or Eclipse, really focuses on being a good project management tool with a built in way to modify files.
I find that keeping the above in mind (and keeping Emacs handy) helps me to not get frustrated when the IDE du jour is not meeting my needs.
If you've been using emacs/vi for years (although you listed both, so it seems like you may not be adapted fully to one of them), using said editor will probably be faster for you than an IDE. The level of mind-meld a competant emacs/vi user can achieve with a customized setup and years of muscle memory is astounding.
Some free ones:
XCode on the Mac
Eclipse
Lazarus (Open Source clone of Delphi)
Visual Studio Express
Editions
Try making a couple of test applications just to get your feet wet. At first, it will probably feel more cumbersome. The benefits of IDEs don't come until you begin having a good understanding of them and their various capabilities. Once you know where everything is and start to understand the key commands, life gets easier, MUCH easier.
I think you'll find IDE's invaluable once you get into them. The code complete and navigation features, integrated running/debugging, and all the other little benefits really add up.
Some suggestions for starting out and easing transition:
- start by going through a tutorial or demonstration included with the IDE documentation to get familar with where things are in the GUI.
- look at different kinds of sample projects (usually included with the IDE or as a separate download) for different types of areas you may be coding (web applications, desktop applications, etc) to see how they are laid out and structured in the IDE.
- once comfortable, create your own project from existing code that you know well, ideally not something overly complex, and get it all compiling/working.
- explore the power! Debug your code, use refactorings, etc. The right click menu is your friend until you learn the keyboard shortcuts just to see all the things you can do. Right click different areas of your code to see what is possible and learn (or re-map) the keyboard shortcuts.
Read the doc...
And see what shortcuts/keybindings equivalents are with your familiar ones. Learn the new ones...
Old question, but let me suggest that in some circumstances, something like Notepad++ might be appropriate for the OP's situation which may be encountered by others. Especially if you are looking for something lightweight, Notepad++ can be part of a developer's arsenal of tools. Eclipse, Visual Studio and others are resource hogs with all their automagic going on and if you are looking to whip out something pretty quick with a whole bunch of keyboard shortcuts and the like or if you are interested in viewing someone else's source, this can be quite useful. Oh yeah, and it is free too.