---
feature_story: FS_91_88_07_23
feature_title: jump tree
feature_status: TEST
---

TODO: The plan is to obsolete this feature.
      A separate tree can be avoided - simply add configuration in FS_33_76_82_84 composite tree nodes.

TODO: All this feature does is to return curr tree path to tha last interp used within that path
      (the first interp from the tail of the path).
      Do we really want to have excessive flexibility to jump anywhere when we only jump in well-defined place?

      `jump_tree` is already "global" (suitable to FS_33_76_82_84 to merge into composite tree).

      It navigates (jumps) back to another interpreter when function is selected (to select next func).
      `FuncTreeInterpFactory` uses `select_next_interp_tree_abs_path` func which is where the jump is performed
      based on current `interp_ctx.interp_tree_abs_path`.
      What `run_interp_control` for `FuncTreeInterpFactory` does is to ask e.g. `HelpDelegator` what is the next
      `plugin_id` (interp) to use.

      Currently, we need both:

      *   New interp id (interp factory instance to instantiate new interp instance).

      *   New path to jump:

          Because that instance has to distinguish that specific path as
          the same factory plugin can be reused in different tree paths.

This feature is related to:
*   FS_01_89_09_24 interp tree
*   FS_26_43_73_72 func tree

Jump tree allows overriding exiting tree path by another tree path
when current interp found a func (and, therefore, delegator) and selects next interp.

For example, it is used to continue completion from another part of the tree for functions like:
*   FS_71_87_33_52 `help_hint` func
*   FS_88_66_66_73 `intercept_invocation` func
