Clean up dependencies in brackets.js

[marcelgerber]

For case 2 of #1783.

[busykai]

Why another require is preferable? Does it solve any issue at all?

[marcelgerber]

I removed the require above since we should only require module over there that we actually need in our code, for example for calling their methods.
The only occurence of CodeHintManager, though, is here in brackets.test.

See #1783 (case 2) for more details.

[busykai]

It does not quite explain all the changes. LanguageManager is loaded twice via require, for example.

[marcelgerber]

Oh, I see. This PR is 3 months old, so I don't exactly know the initial motivation, but I think it might be that this just looks cleaner to me, than having a mixture of requires and variable references.

[busykai]

OK. Now I see. Not going to argue aesthetics. It may improve readability for this one case, but I prefer variables since they can be linted and not get back at you at runtime. Technically, there's a negligible difference and the code is executed once. So if you want to, you can merge it with master and we can merge it back in. If not, let's close it.

[marcelgerber]

@busykai Merged with master.

[busykai]

@marcelgerber, it works OK. The only comment I have is: I'd also move the CodeMirror load/global def lines 104-114 to before line 47 (right before all the CodeMirror plugins are loaded). First of all, these lines create a global; secondly it makes sense (for readability) to load the module itself before loading its plugins. Tried the change, it causes no problems. Does it make sense to you?

[marcelgerber]

The issue with that is, though, that these lines need DeprecationWarning, which is defined later on (and thus causes a JSLint error).

The only thing we could do is load CodeMirror before line 47 and then create the global, deprecated object afterwards, but that would then be out of context.

[busykai]

@marcelgerber, you're right. However, I think we could well load DeprecationWarning at the very beginning (using separate var). It's a utility and does not really belong among other "functional" modules. What do you think?

[marcelgerber]

I'm not too fond about that. We've pretty much always kept the requires in one block and I don't like the idea of making an exception just for this module.

[busykai]

@marcelgerber, ok! This looks good to me. It solves the purpose that you outline in the PR description. Merging.