"explore -i with :try" doesn't allow arrow left/right navigation to edit command

[MMesch]

Describe the bug

The command line in :try mode in explore -i (see upper left in the screenshot below with "filter ()" written) doesn't seem to allow navigating the cursor back and forth with the left/right arrow keys to edit code inline. Instead you have to use Backspace to delete/rewrite. It's a small but quite annoying issue.

How to reproduce

1. run [[a,b];[1,2],[3,4]] | explore -i, then Return;
2. type :try, then Return;
3. type some command/text and try navigating backwards with the arrow left key (←) [doesn't work on my machine].

Expected behavior

I'd expect to be able to use the Arrow left/right keys and edit the command inline.

Configuration

key	value
version	0.104.0
major	0
minor	104
patch	0
branch
commit_hash
build_os	linux-x86_64
build_target	x86_64-unknown-linux-gnu
rust_version	rustc 1.86.0 (05f9846f8 2025-03-31) (built from a source tarball)
cargo_version	cargo 1.86.0 (adf9b6ad1 2025-02-28)
build_time	1980-01-01 00:00:00 +00:00
build_rust_channel	release
allocator	standard
features	default, sqlite, trash
installed_plugins	polars 0.104.0, query 0.104.0

[fdncred]

Agreed. It would be nice for someone to implement left and right arrow navigation here.

[MMesch]

@fdncred, any thoughts on other features that would be nice for this explore -i :try command line? For example, command history intuitively feels very useful but I'm (a) unsure how difficult that is and (b) unsure whether it'd make sense to use the normal nushell command history then.

[fdncred]

The only thing I keep coming back to is that since it's a tui, I always want a theme to make it look like Borland C/Turbo C/Turbo Pascal from back in the day. That's mainly a set of themes but also a great status line and maybe a menu bar if we had options to configure.

Above all, more than anything else, it needs to be an excellent pager experience. I'm definitely open to ideas about how to make it better.

[JohnnySunday]

I think it could be useful to be able to do explore --try to launch with :try-mode open and focused, maybe even the option to pass for example --try { sort-by size | find $input } and use whatever you write in the input bar in the --try {}.

I guess kind of how fuzzy match cli's sometimes have a --cmd flag, for example the nu_plugin_skim which takes a closure I believe.

This might be stupid, just came up with the idea right now. But just to be able to launch in try-mode I think would be nice.

[MMesch]

Thanks for the ideas!

Dreaming a bit because I don't know implementation-wise how difficult it is: Why not merge the :nu and :try commands and then use reedline or the full nu-cli with completion etc but simply printing in the same TUI format and similarly to :nu piping the current view under exploration into $in and displaying the pipeline output.

In other words, how about considering the TUI just a different view on the terminal data but otherwise reusing much of the existing repl/cli code?

[fdncred]

explore's primary responsibility is to be a pager, we cannot lose that. i'm not sure I'd support what you're suggesting exactly mostly because I don't understand how it would work. it's like you want to have a tui without having a tui. there would probably have to be a popup dialog for completions that works differently than the repl. i mean the code generating any completions would be the same but the ui would be different.

[MMesch]

Ok. Well, let's try to express it differently. I'd love to have the same command line as in the shell in explore. Without changing much in terms of interface otherwise.

It's true that tab completion may be difficult in terms of interface at least one-line command line could be pretty much the same and maybe even reuse parts of the code?

Also why should try and nu be two different commands within explore?

Darren Schroeder @.***> schrieb am Mo., 19. Mai 2025, 13:27:

fdncred left a comment (nushell/nushell#15748) https://github.com/nushell/nushell/issues/15748#issuecomment-2890656696

explore's primary responsibility is to be a pager, we cannot lose that. i'm not sure I'd support what you're suggesting exactly mostly because I don't understand how it would work. it's like you want to have a tui without having a tui. there would probably have to be a popup dialog for completions that works differently than the repl. i mean the code generating any completions would be the same but the ui would be different.

— Reply to this email directly, view it on GitHub https://github.com/nushell/nushell/issues/15748#issuecomment-2890656696, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAT2HK6IJQSBPZS464UFBU327G5ZFAVCNFSM6AAAAAB5ASUUAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOJQGY2TMNRZGY . You are receiving this because you authored the thread.Message ID: @.***>

[fdncred]

The biggest difference between try and nu in explore is that try can automatically try anything you type as you're typing it instead of waiting for you to press enter. You have to have your config set to enable this feature. This is my config.

  explore: {
    table: {
      selected_cell: {bg: 'blue'}
      show_cursor: false
    }
    try: {
      reactive: true
    }
  }

[MMesch]

This is what copilot says:

---

Yes, it is possible—and potentially desirable—to use nu-cli's input handling (such as its line editor, completion, and keybindings) in the explore command for the :try and :nu command-line modes.

Why?

nu-cli already provides a robust, feature-rich line editor (via Reedline) with support for cursor movement, history, completion, and more. The current explore implementation for :try/:nu command input is custom and minimal, lacking features like left/right cursor movement, inline editing, and completions. Reusing nu-cli's input logic would provide a consistent and powerful editing experience across Nushell. How could this be done?

Refactor explore to invoke (or embed) the nu-cli line editor (or a minimal instance of it) when entering command input mode. Pass the current command buffer to the line editor, and retrieve the edited result when the user presses Enter or cancels. This could be done by creating a small "sub-REPL" or "mini-editor" session, or by exposing a function in nu-cli that provides a line-editing prompt for use in TUI contexts. Challenges:

Integrating a full-featured line editor into a TUI widget (like ratatui) may require some adaptation, especially for event handling and rendering. You'd need to ensure that the editor can run in a "modal" way, returning control to explore after input is complete.

Summary: Yes, using nu-cli's input system in explore for :try/:nu would be a good architectural improvement, providing a much better user experience and reducing code duplication. It would require some refactoring and careful integration, but is technically feasible and aligns with best practices for code reuse.

---

This was also my naive thinking. Any thoughts on this? The challenges it mentions may really be difficult to resolve.

[fdncred]

Have at it, I just don't want to combine or replace :nu and :try but I'm open to them using reedline. I think it's way harder than copilot thinks it is, and I'd bet that copilot has no clue how to make these changes.

[MMesch]

No it certainly doesn't 😅 But I also don't have any idea right now either. I am certain it's not a minor change but I'm tempted to explore nevertheless whether it's feasible, at least if it's not ruled out by someone with may more nushell experience than what I have upfront.

Darren Schroeder @.***> schrieb am Mo., 19. Mai 2025, 17:56:

fdncred left a comment (nushell/nushell#15748) https://github.com/nushell/nushell/issues/15748#issuecomment-2891528140

Have at it, I just don't want to combine or replace :nu and :try but I'm open to them using reedline. I think it's way harder than copilot thinks it is, and I'd bet that copilot has no clue how to make these changes.

— Reply to this email directly, view it on GitHub https://github.com/nushell/nushell/issues/15748#issuecomment-2891528140, or unsubscribe https://github.com/notifications/unsubscribe-auth/AAT2HK2L2ABZGLS5HJ4QINT27H5J3AVCNFSM6AAAAAB5ASUUAWVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZDQOJRGUZDQMJUGA . You are receiving this because you authored the thread.Message ID: @.***>