By default Eclipse CDT will scan the source tree for binaries so that it can
add those binaries to the list of things that it can run. This scanning is a
constant interuption and can last several seconds. Besides that, it's
currently useless for our setup since the only binaries that we're interested
in running are in the object directory (which it doesn't scan), and those are
set up during project generation. (The only binaries found in the source tree
are a couple of uninteresting bundled libraries.)
CLOSED TREE
MozReview-Commit-ID: 2WaH8qceALq
By default, scalability mode is activated for files with 5,000 lines or more.
There are quite a few C++ files with more than 5,000 lines, and Eclipse seems
to work fine with them with scalability mode turned off (even
nsCSSFrameConstructor.cpp which is over 13,000 lines long). Increasing the
number of lines before scalability mode is enabled allows Eclipse to handle
these files better.
MozReview-Commit-ID: 8mGYIHStHes
Without this setting, eclipse will refuse to open Objective-C files (it will
defer to an external editor). Adding *.mm to the file types that are treated
as C++ allows Eclipse to open them, and to provide some code assistance for
the bits of the files that it can understand.
MozReview-Commit-ID: ASeXesWxY4g
This setting allows Eclipse to notice when files it has open are changed
externally (such as by hg/git, for example). It can then update the contents
that it has for the open files, avoiding annoying issues such as saving changes
after an `hg pull -u` resulting in either "Resource is out of sync" errors or
else clobbering of the changes hg made to files.
MozReview-Commit-ID: 8WmewM7lbHe
The blocking Welcome screen is quite confusing for a new user. It is not clear
where to find the Mozilla stuff they expect to see when opening Eclipse, or
that the user needs to close the entire content area to get to it. Besides that
the screen isn't very useful for Mozilla people who will find more relevant
help from searching the online documentation, and who won't be creating new
projects in the generated workspace, etc.
MozReview-Commit-ID: 8YssnonAR1d
The setting to ensure that there is a newline at the end of files when they
are saved is very annoying. Besides adding unnecessary and unexpected cruft
to diffs, some parts of the codebase (some of the reftest directories for
example) have a policy of NOT having a newline at the end of their files.
MozReview-Commit-ID: IjIYxDsKS13
This makes us write the code formatter settings into the workspace settings
directory instead of the project settings directory. This is preferable
since when users make settings changes they are more likely to work with the
workspace settings, so we should put them there. Putting them there also
fixes a bug whereby the calls to _write_noindex/_remove_noindex would
overwrite the formatter settings file shortly after it had been created.
To get the formatter to show up in the UI we also need to set the formatter
settings as a one line pref value in the CDT UI settings. This duplication
is what Eclipse does when a new formatter is manually added, and it's
necessary to get the formatter working correctly.
MozReview-Commit-ID: KP4w0VbNCF7
This mostly restores us to the previous behaviour where we would set mWillBuildScrollableLayer to false for event handling display lists. But it's better because we don't keep flipping its value.
The real reason we want to do this is that it fixes bugs with event handling.
