nav-panel is not always visible when Atom starts

[johnarwe]

For example, this will reproduce the problem on Windows 10:

1. Start an instance of Atom, open a file that results in visible markers in the panel.
2. Terminate Atom normally, e.g. using the window X control at upper right.
3. Start Atom again... the file open in step 1 will open again, but no markers will be visible.
   1. Toggle nav-panel-plus ... no change.
   2. Switch focus to the tree view and back to the file, or save the file,... markers become visible.

The cause is that nav-panel's activate() implementation does not populate the view for the active editor, and atom.workspace.onDidStopChangingActivePaneItem subscription does not fire when the editor is first opened; it fires when you change focus away from a file editor. Saving the file works because nav-panel adds on-save callbacks.

I am constructing a pull request to fix this, probably using observeTextEditors, but it's not quite ready yet. I don't know of any guarantee that editors are active at the point in time when activate() is called, so I'm reluctant to rely on getActiveTextEditor() in the constructor ... and doing that would have other side effects.

[johnarwe]

@0tho , how would you feel about me adding one or more commands to toggle console.log calls for various "topics" (all defaulting to off)? In debugging the causes of these issues, I added "more than a few" such calls that could be grouped into logical units (one around lifecycle events that drive parsing, one around actual rule parsing, ...). I'm a tiny bit reluctant to just remove what I added, OTOH I certainly don't want npp to flood the log unless a human has consciously requested doing so. I'm thinking they'd only be accessible via the command palette, although I would not object if you wanted them hung off the Packages > npp entry as well.

If that works for you, I'd probably do it as 1 pull request per command, and open a separate issue where we can debate the externals.

[marcel0ll]

Wouldn't many console.log polute the code with no other reason to exist other than debugging?

[johnarwe]

Fair to have a discussion on the merits of debug "hooks" in the code. Let's have that in issue #22 rather than tangling two things that could be handled independently into one. Whatever pull request I build for this issue will not add any debug content beyond what the base has.