This doesn't work "just" in the config.js files and the reason is that such js file has mimetype text/karmaconf+javascript and the implementation of org.netbeans.modules.csl.editor.hyperlink.GoToSupport in getResultIterator method doesn't count with this. This is probably a regression introduced with karma support, when these files get extended karma mimetype  -> cc'ing Tomas. 

I have done a simple fix in csl. In the method getResultIterator is checked, whether the required mimetype is not an inherited type from the mimetype path assigned to the snapshot / source. This work in this case, because the inherited type is really text/javascript. But I think that this method should be corrected to support more general mimetype inheritance. I'm cc'ing Svata to be aware of this fix. Svato is it ok?

http://hg.netbeans.org/web-main/rev/98a4c8c9e3a8

This should be fixed in the patch for NB 8.1. Probably for the patch the my fix is sufficient. What do you think?

Integrated into 'main-silver', will be available in build *201512290002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/98a4c8c9e3a8
User: Petr Pisl <ppisl@netbeans.org>
Log: #257190 - Refactoring, Navigation and Navigator is not working anymore when the files called config.js

(In reply to Petr Pisl from comment #1)
> This doesn't work "just" in the config.js files and the reason is that such
> js file has mimetype text/karmaconf+javascript and the implementation of
> org.netbeans.modules.csl.editor.hyperlink.GoToSupport in getResultIterator
> method doesn't count with this. This is probably a regression introduced
> with karma support, when these files get extended karma mimetype  -> cc'ing
> Tomas.

We already use this type of registration for some more files, e.g. bower.json (MIME: text/bower+x-json), so I guess the problem was there as well.

Thanks Petře!

Thx to you, sounds plausible to me, why this happen but yes, a JS file or a json file is still a js or json file. In this case for karma and bower a special json or js file.

verified in trunk

Transplanted to the releases / release81:

http://hg.netbeans.org/releases/rev/b930471d6680

According to Christian's latest update via e-mail the bug is not fixed even in trunk. Thus reopening.

I have fixed the instant rename action 
http://hg.netbeans.org/web-main/rev/c535b6ad73ba

But, I'm not sure, whether fixing all these actions is a good solution. CC'ing Svata, who understand to CLS more. Svato, what do you think?

Also still navigator is not fixed.

Integrated into 'main-silver', will be available in build *201606180002* on http://bits.netbeans.org/dev/nightly/ (upload may still be in progress)

Changeset: http://hg.netbeans.org/main-silver/rev/c535b6ad73ba
User: Petr Pisl <ppisl@netbeans.org>
Log: #257190 - Refactoring, Navigation and Navigator is not working anymore when the files called config.js

*** Bug 258776 has been marked as a duplicate of this bug. ***

Svato, do you want to look at this? :) The main problem now is the navigator.

*** Bug 257617 has been marked as a duplicate of this bug. ***

This will be a little tough: unlike all the other APIs, Navigator does not use (editor) MIME Lookup, but registers panels using its own impl.

As I went through the reg code, the entire panel registry should be probably updated, as it for example does not refresh when new modules are installed, is not thread-safe etc.

editor.mimelookup does not export API to construct MIME lookup over other area than Editors/* which is not suitable for Navigator.

I see two solutions: 

1/ hack a quick & dirty implementation of cascading mime-based search similar to MimeLookup into the Navigator impl: I could IMHO use MimePath parsing capabilities to enumerate constituent MIMEs. 

2/ create a new API, something like MimeLookup.create(String rootFolder, String providerTag) which would, at the discretion of the caller, create full featured cascading Lookup over another folder hierarchy, using MimeDataProviders registered in a specific (sub)folder etc. Possibly useful in general, as MimeLookup is anything but trivial.

In either case, we may have an issue with too many panels: suppose there's a navigator Panel registered for text/javascript, then another one for text/grunt+javascript. 
The navigator API seems to anticipate multiple registrations for a given content(mime) type - individual panels are then selectable form the navigator. The most specific mime type will surely appear first. The question is whether such presentation is desirable - for example Grunt presentation may need to hide/override some of the generic panels. We do not have any mechanism for that.

Opinions ?

(In reply to Svata Dedic from comment #13)
> for example Grunt
> presentation may need to hide/override some of the generic panels.

Please note that Grunt and Gulp have now their own "special" Navigator windows - they show their tasks [1].

Thanks.
[1] http://wiki.netbeans.org/NewAndNoteworthyNB82#Grunt.2FGulp

Understood, they are registered with @NavigatorPanel.Registration, right ? The reason why nothing appears (for example) for text/bower+x-json or text/karmaconf+javascript (= config.js file) is that no Panel is registered specifically for that content/mime. 

The algorithm for actions, ... use a series of MIME types (text/karmaconf+javascript, then text/javascript) to locate either the most specific impl or at least order impl from the most to least specific.
Navigator currently looks only for the most specific registration, which is typically missing.

(In reply to Svata Dedic from comment #15)
> Understood, they are registered with @NavigatorPanel.Registration, right ?

Yes, exactly.

*** Bug 257642 has been marked as a duplicate of this bug. ***

Can't set breakpoints into this file too.

Is there no way to disable the karma module to get rid of this problem? Really weird behavior, especially if you don't need karma at all. Every file containing the string 'conf' in its filename is concerned, quite an interesting way to implement such things

It is still a problem in 8.2 and a pain in the ass.

Anything new here?

when everybody are working in nb, you can avoid this, but if there is mixed environment and others create a lot of *conf* files, I probably have to migrate to ide with proper 'conf' files support