UPSTREAM PR #17566: feat(repl): add configurable external hinter closure

[loci-dev]

Note

Source pull request: nushell/nushell#17566

Summary

Adds support for a configurable external REPL hinter closure via $env.config.line_editor.external.hinter.

Users can now provide a Nu closure that receives context (line, pos, cwd) and returns either:

• a string hint suffix to show/accept
• null to fall back to the built-in CwdAwareHinter

This change is backward-compatible by default (closure = null, enable = true) and keeps existing hint behavior when external hinting is disabled, missing, or errors.

Discussion thread: Discord

Examples

• Atuin-based hint closure

$env.config.line_editor.external.hinter = {
  enable: true
  closure: {|ctx|
    if ($ctx.line | str length) == 0 {
      null
    } else {
      let candidate = (try {
        ^atuin search --cwd $ctx.cwd --limit 1 --search-mode prefix --cmd-only $ctx.line
        | lines
        | first
      } catch {
        null
      })

      if $candidate == null or not ($candidate | str starts-with $ctx.line) {
        null
      } else {
        ($candidate | str substring (($ctx.line | str length))..)
      }
    }
  }
}

• Simple deterministic test closure (good for validating script hinter behavior)

$env.config.line_editor.external.hinter = {
  enable: true
  closure: {|ctx|
    if ($ctx.line | str length) == 0 {
      null
    } else {
      let target = "zzhint from-script"
      if not ($target | str starts-with $ctx.line) {
        null
      } else {
        let remaining = ($target | str substring (($ctx.line | str length))..)
        if ($remaining | str length) == 0 { null } else { $remaining }
      }
    }
  }
}

---

[loci-review]

Overview

Analysis of Nushell binary target.aarch64-unknown-linux-gnu.release.nu following implementation of configurable external hinter closure functionality across 4 commits. Power consumption increased by 0.121% (929,452.96 nJ → 930,579.16 nJ), indicating negligible system-wide impact. Of 40,134 functions analyzed, 3,278 were modified, 5,328 added, and 5,345 removed.

Function Analysis

The largest performance changes occur in functions with no corresponding source code modifications, indicating compiler optimization variance rather than functional regressions. Key findings:

HTTP Client Destructors: Multiple drop_in_place functions for ureq types show 7,000-17,000% response time increases (e.g., RequestBuilder<WithBody>: 221ns → 39,001ns) with unchanged throughput time (~37ns), indicating child function regressions in cleanup paths. No HTTP client code or dependency versions changed.

Experimental Commands: JobId::run and IsAdmin::run show 7,000-9,000% response time increases (273ns → 25,275ns and 342ns → 25,313ns respectively) with constant throughput time (~22ns and ~52ns), indicating downstream Value/PipelineData operations became more expensive despite no source changes.

Performance-Critical Function: Call::req_parser_info shows 4,300% response time increase (7.7μs → 337μs) with 25% throughput increase (110ns → 137ns). This function is part of the hot path for commands using parser metadata (source, use, let). The regression is primarily in child functions (eval_expression, FromValue) rather than the function itself, with no direct source code changes detected.

Third-Party Dependencies: chrono::DateTime::hash (6.73ns → 502ns, +7,366%) and ureq::RequestBuilder::header (3.2μs → 98.5μs, +2,994%) show substantial regressions despite unchanged dependency versions, suggesting compilation differences.

Value Type Cleanup: drop_in_place functions for serde_json and serde_yaml Values show 128% and 127% throughput increases respectively (+32ns and +31ns absolute). The new ExternalHinter feature creates Value::record objects on every keystroke, potentially amplifying Value cleanup frequency.

Other analyzed functions including path operations, hash implementations, and error handling destructors saw performance changes ranging from 20-1,000% but remain under 3μs absolute impact in non-critical paths.

Additional Findings

All code changes target REPL hinter functionality with no modifications to core execution paths (IR execution, pipeline data flow, parser, command calls). The pattern of unchanged throughput time with increased response time across multiple functions, combined with zero source code changes in affected areas, strongly indicates compiler optimization differences between builds rather than functional regressions. The single performance-critical regression (Call::req_parser_info) warrants investigation as it affects commonly-used commands, though the 330μs overhead represents the only measurable impact in hot paths.

🔎 Full breakdown: Loci Inspector.
💬 Questions? Tag @loci-dev.