You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Once the initial display issue described by #19 is fixed, another problem will become apparent: currently nav-view and nav-parser each refer to the other, but nav-parser may be incompletely initialized at the point when nav-view would build the panel (even if nav-view doing so for an already-open file was triggered using a atom.workspace.observeTextEditors event... I've tested it). Nav-parser's constructor calls getProjectRules, but that requires I/O when project-level rules file(s) are present; the I/O will always be asynch, and may (in the general, and already tested, cases) finish after events like observeTextEditors have fired. In order to truly fix the race, any existing panels must be removed (and the active one rebuilt) when the I/Os complete.
I am building a pull request to split nav-parser's initialization (for clarity mostly), and to destroy/rebuild all the panels whenever a project rules file read operation completes. I've tested the flow and it does fix the problem, but separating the code for each of the problems into distinct pull requests will require a bit more time.
The text was updated successfully, but these errors were encountered:
observeTextEditors resolvesmarcel0ll#19.
Redriving the parser when project rules exist (after the I/O to read the rules completes) resolvesmarcel0ll#20.
Once the initial display issue described by #19 is fixed, another problem will become apparent: currently nav-view and nav-parser each refer to the other, but nav-parser may be incompletely initialized at the point when nav-view would build the panel (even if nav-view doing so for an already-open file was triggered using a atom.workspace.observeTextEditors event... I've tested it). Nav-parser's constructor calls getProjectRules, but that requires I/O when project-level rules file(s) are present; the I/O will always be asynch, and may (in the general, and already tested, cases) finish after events like observeTextEditors have fired. In order to truly fix the race, any existing panels must be removed (and the active one rebuilt) when the I/Os complete.
I am building a pull request to split nav-parser's initialization (for clarity mostly), and to destroy/rebuild all the panels whenever a project rules file read operation completes. I've tested the flow and it does fix the problem, but separating the code for each of the problems into distinct pull requests will require a bit more time.
The text was updated successfully, but these errors were encountered: