RFC: from profiles -i to a full aeroftp-cli TUI

[axpnet]

RFC: from profiles -i to a full aeroftp-cli TUI

This one starts with @EhudKirsh. In the v4+ wishlist (#270) he asked us to turn aeroftp-cli profiles -i into a proper raw-mode terminal UI, even linking his own demo of the technique (NodeJS-Unbuffered-Input-Raw-Mode-TUI) and saying it would "revolutionize the interactivity and accessibility of aeroftp-cli profiles -i well beyond what it and rclone config currently have."

We shipped that navigator (the arrow-key profiles -i, commit 96b90fe7). This RFC is about taking the idea all the way: from a single picker to a full-screen, keyboard-driven file manager over the same provider stack the line-mode CLI already uses. Think lazygit / ranger, but for 32 storage backends. The dual-panel ergonomics Ehud already likes in AeroFile, brought to the terminal.

Full circle. There is a nice symmetry here. AeroFTP began life as PhantomFTP, a Rust dual-panel TUI FTP client (local and remote panes side by side, async transfers, the "ghost in your terminal"). It grew into the desktop app and the big aeroftp-cli you use today. A TUI for aeroftp-cli is not new territory, it is AeroFTP coming home to the form it was born in, now with 32 backends behind it instead of three.

This is a request for comments before any code lands. Ehud, this is your idea, so you get first word. Everyone who lives in the terminal: please tear it apart.

(Mockup, not a screenshot yet. Layout and keybindings are exactly what is up for discussion.)

Why this is cheap to do well

We are not starting from scratch. aeroftp-cli already:

• depends on ratatui and crossterm, and
• ships two working interactive surfaces built on them:
  • the profiles -i navigator Ehud asked for (arrow-key picker, inline edit/rename/delete), and
  • the ncdu disk explorer (aeroftp ncdu opens a full alternate-screen, drill-down disk-usage browser).

So the foundation, terminal lifecycle, event loop, rendering, and safe restore-on-exit, is already proven in production. The full TUI is the same machinery, widened.

The one principle we will not break

The profiles -i navigator is built as a pure input front-end: it renders, lets you move and pick an action, then hands the equivalent line-mode command to the existing, tested command handlers, which do the actual work.

We want the whole TUI to follow that same contract:

The TUI collects intent and draws the result. It never re-implements an operation.

That keeps the ~100 existing command handlers as the single source of truth, keeps every destructive-op safety gate (confirmations, exit codes) in one place, and keeps the line-mode CLI fully scriptable and --json-friendly. The TUI is strictly additive, nothing you script today changes.

What it would actually do

A dual-pane browser (remote on the left, local on the right), connect from a saved profile, navigate, transfer across panes, plus the power features reachable without retyping URLs and flags:

• browse / sort / stat / mkdir / rename / delete (with the same confirm gate as line mode),
• get / put / mv / cp across panes, with a live transfer panel,
• the profiles navigator, ncdu, versions, df, and vault views embedded as panels,
• a : command palette that accepts any existing line-mode command, so power users get 100% feature parity from day one while the visual panes cover the common 90%.

One of Ehud's specific points in #270 was direct manipulation: when you want to change something, you click (or select) the thing itself rather than hunting for a separate menu. That principle carries straight into the browser: highlight an entry, act on it in place. Question 3 below is where we pin down how far to take it.

Three possible shapes (this is the main thing to discuss)

A. Picker, widened. Small modal pickers that return a line-mode command, exactly like profiles -i today. Lowest risk, reuses everything, but feels more like a menu than a file manager.

B. Stateful browser. A real app: one held connection, a dual-pane browser, async transfers with live progress. The product people actually picture. Needs a small new session + worker layer so the screen never freezes on a slow network call.

C. Embedded line-shell. A TUI frame whose main pane is the existing interactive shell, with side panels. Instant power-user parity, but the muddiest UX.

Our leaning: ship a thin A first (it directly continues the profiles -i work and validates the shared scaffold), then grow it into B as the headline, with C's "run any command" idea folded into B as the : palette rather than as the architecture.

Open questions for the community

1. Shape: do you agree with A then B, or would you rather we go straight to the full dual-pane browser?
2. Entry point: explicit aeroftp tui (or aero tui, using Ehud's alias from [DOCUMENTATION] I managed to make an `aero` alias for `aeroftp-cli` #273) only, or also bare aero on an interactive terminal, with a config opt-in so scripts are never surprised?
3. Direct manipulation: how far do we take the "select the element, act on it in place" idea? Single-key actions on the highlighted row (the profiles -i model), an inline edit mode, or both?
4. Keybindings: vim-style hjkl (matching what ncdu already uses here) as the default, with arrows always working? Any bindings you consider non-negotiable?
5. Layout: dual-pane (remote/local) as the default, or single-pane with a togglable local view?
6. Naming: tui, browse, nav, or something else? (shell / repl already exist under agent.)
7. Must-have first: if you could only have three actions in the first cut, which three?
8. Mouse: worth it, or keyboard-only is fine for a v1?

A full design note (current-state inventory, architecture, phased plan, risk register) backs this and will land in the repo under docs/dev/roadmap/APPENDIX-CLI-TUI/.

Thanks @EhudKirsh for planting this one. Let's build it in the open.

[EhudKirsh]

TUI for AeroFile is a cool idea. This definitely should go in #285.

Before we continue, I noticed that you didn't specify what's in scope for this post. So I'd like to ask what's in scope here:
Any TUI for AeroFTP or just for AeroFile? I wanted to share more feedback on the current TUI/NAV in aero profiles -i > tui,
and I wasn't sure if it's best to continue in the wishlist or a separate post. This post can be a [ROADMAP] for any and all TUI in AeroFTP.

---

Open questions for the community

1, 3 & 7) Shape & Must-have first:

It's difficult to envision these and make an informed opinion without first testing out some drafts. You might wish to draft these first,
but I suggest that it's best to first perfect my vision for a TUI for Profiles before moving to other members of the Aero family.
A lot of thinking went into how exactly to structure my TUI demo.

2) Entry point:

aero tui sounds good for opening a kind of welcome/home menu. From there, it would be possible to enter the various members of the Aero family, e.g. File, Sync, Vault, Profiles, etc. aero tui should be somewhere notable, like at the top of aero help.
To go to other members of the Aero family directly, it would be possible with aero profiles -tui, aero file -tui, etc.

4) Keybindings:

I've heard of VIM being an IDE with complex hotkeys, but I haven't used it, so I'm not familiar with it.

5) Layout:

It's easy to check the terminal's width. $Host.UI.RawUI.WindowSize.Width in PowerShell, and process.stdout.columns in NodeJS.
If you write or paste process.stdout.columns in NodeJS and don't press enter, you'll see it updating its eager evaluation for it in real time as you change the window's width by dragging its horizontal borders left and right.
Therefore, it's easy to decide whether to open a dual-panel or a single panel based on it.
A TUI dual-panel file manager is definitely unique. Therefore, the default should be a dual-panel when the terminal size allows for it.

6) Naming:

Please don't spend these terms now as aliases.
You may regret it in the future if you end up actually wanting these for future uses that will come up. TUI alone is fine for now.

8) Mouse:

Mouse would be fantastic to add, but it can wait if it's too much effort.
I see that aero profiles -i > tui already supports scrolling up and down, which is nice.

[axpnet]

You're right that I never pinned the scope, let me fix that: this post is the umbrella [ROADMAP] for TUI across the whole Aero family. AeroFile-specific TUI ideas stay cross-linked to #285, but the shared TUI shell and the entry point live here. So please bring your aero profiles -i > tui / NAV feedback into this thread.

And I agree with Profiles-first: your Profiles TUI demo is the proving ground. I'd rather get navigation and keybindings right there before spreading to File / Sync / Vault, exactly as you say.

On the rest:

• Entry point: aero tui as the home/welcome menu, with aero <member> -tui (aero profiles -tui, aero file -tui, etc.) for going straight in. aero tui gets a spot at the top of aero help.
• Layout: dual-panel by default when the width allows, single-panel below a threshold, re-laying out on resize. crossterm already gives us the terminal size (it's what the current arrow-key navigator uses), so this is straightforward.
• Naming: agreed, I won't spend any alias terms now, tui alone is enough.
• Mouse: deferred; the scroll you already get in profiles -i > tui stays.

No code yet: the next step is your Profiles TUI feedback here, then I draft from it.

[axpnet]

Well, this work is proving more complex than expected. It's not just about applying a new interface, but also about completely rewriting some files and testing all the operations manually since the agent can't.

There are currently a lot of bugs and various interface issues, and there's still work to be done. I don't know if it's worth releasing a beta version for the community so we can test it together, or releasing a more mature version later.

[EhudKirsh]

Thank you for trying. It's not a priority. The TUI can wait. I plan to share more TUI feedback here later.

[axpnet]

🟢 Decision: the TUI ships in 4.0.5 as a quiet alpha preview (rev 1.0.3)

Thanks @EhudKirsh, that is exactly the right framing and we agree: it is not a priority and the TUI can wait. So we are treating it that way.

Following up on my earlier question here, whether to release a beta to test together or wait for a more mature build, we landed in the middle: 4.0.5 will include the interactive TUI as an alpha preview, revision 1.0.3. It is published in the release but it stays deliberately quiet. No headline in the changelog, no README badge, no docs page yet. It lives behind aeroftp-cli tui and is meant for the people following this discussion, not for the general audience. The label stays alpha on purpose: expect rough edges, a few bugs, and interface details still in motion.

The point of shipping it quietly rather than holding it back is so it is simply there to test whenever anyone feels like it, with no pressure and no deadline. From here this becomes a phase of slow collaborative development: bugs, updates, and new features get discussed here together, and we move the revision forward one step at a time, alpha to beta to stable, only when each step feels right. Ehud, whenever you share that further TUI feedback, it folds straight into this path. This is a road we walk in parallel with the main app, the GUI and the line-mode CLI keep getting their own improvements at the same time.

One thing worth stating plainly: every capability the GUI and the CLI already have is potentially extendable to the TUI. The architecture is additive by design, the TUI collects intent and the existing command handlers do the work, so adding a feature to the TUI is mostly a matter of deciding we want it there. We will decide case by case what to bring in next, guided by what you ask for.

What is in this first preview: the IntroHub (your saved servers, multi-user, groups, favourites, health and quota), a full-screen dual-pane browser (remote and local), cross-pane transfers with a live transfer strip, and the table-stakes file-manager set a terminal user expects, sort, filter, multi-select with batch ops, view and edit in $EDITOR, hidden files, reload, recursive size, go-to-path, synced browsing, a : command palette that accepts line-mode commands, mouse support, and a help overlay.

No rush at all. Try it, break it, and whenever the feedback comes it is what will shape the road from alpha to beta.

[axpnet]

If you want to take the preview for a spin

Build and run it from a real terminal (it needs a TTY): aeroftp-cli tui. It reads your existing vault, so your saved profiles and users are already there. Nothing is destructive unless you ask for it, the same confirm gates as the line-mode CLI apply.

A short tour, and the exact things we would love a report on:

Key	What it does	Notes
Tab / Enter / Bksp	switch side / open / go up
B	cycle sort (name / size / date / type)
/	live filter (substring or * ? wildcard)
a / L	toggle hidden / reload
Space m / Ctrl+A Alt+A	mark / mark all / none
d	delete the marked set (one confirm)	new, least exercised
g / p	download / upload the marked set	new, least exercised
v	view file (pager, binary-safe)
o	edit in $EDITOR, re-upload on save	new, least exercised
i / Ctrl+S / N	file info / recursive size / new file
G / Y	go to path / synced browsing
:	command palette (line-mode commands)
mouse wheel / ?	scroll lists and overlays / full help

The three rows marked new, least exercised are the freshest in this preview and the ones we have run through automated tests but not yet hammered by hand, so a real-world report on delete / transfer / edit is the single most useful thing you can send back.

Edge cases that are genuinely useful to hear about: a narrow window or a live resize, NO_COLOR=1, an S3 / WebDAV / OAuth profile, an expired or failing connect, and anything on the IntroHub (groups G, health H, quota Q, favourites f). Ehud, the IntroHub is the Profiles centerpiece you asked us to perfect first, so feedback there is the most valuable of all.

Candidate next steps

Nothing here is locked, this is to anticipate the direction; the order will follow your feedback:

Track	Candidates	What it means
Table stakes	copy (cp), chmod, activity/log panel, save-as	cp server-side where the provider supports it, else download plus upload
Palette parity	cp, df, link, hashsum	each a thin arm over a provider method that already exists
UX	context-aware footer, editable advanced S3 form	footer shows transfer controls only when that strip is focused; S3 = bucket / region / endpoint / path style in-TUI
Differentiators	AeroVault browse + extract, AeroSync hooks, AeroAgent "ask the agent"	the reason this TUI exists beyond a plain file manager

Tell us which of these you would reach for first, and what is missing from the list.

[EhudKirsh]

So is an aeroftp-cli tui alpha planned to ship in v4.0.5? I'm looking forward to it.

I suggested that it's best to first perfect my vision for a TUI for Profiles before moving to other members of the Aero family.
This is because aero profiles -i is already interactive, so much of the work is already done for it.
I don't have a preference between prioritising an aero tui home menu and the TUI of the other members of the AeroFamily.

[EhudKirsh]

Currently in v4.0.4, aero profiles -i > tui is quite different from my demo. This is not necessarily all bad.
I need to think more about what I prefer. For now, let's start with some improvements that I know I want for sure:

• Scrolling up and down with the mouse middle button currently goes up and down 3 profiles.
  Please don't skip, and only scroll 1 up and down at a time.

• My TUI allows cycling from the end to the start and vice versa, so going one forward from the last option focuses on the first option, and vice versa, going backwards from the first option focuses on the last.

• My TUI can use the Left ←, Right →, Tab ⭾, Shift ⇧ + Tab ⭾, Page Up and Page Down keys.

• My TUI adjusts based on the width of the screen, so every option is fully shown.
  In split-screen on my small secondary 1600 x 900 monitor, the 'd delete' option is hidden in v4.0.4's aero profiles -i > tui.

• I prefer the format I had of re-index(#)|List/ls(L)|Tree(T)|Delete(D)|Fav★(F)|Copy(C)|Rename(R)|Edit(E)|Quit(Q/0).
  It's clear and compact. By the way, I'd like aeroftp-cli to show ★ or ♥ correctly in the TUI options as well, based on the user's setting.

• The Profiles table should have the same columns shown and hidden as when entering the interactive session. If you look at the TUI now,
  it doesn't show which profiles are favoured and which are not. So I need to guess or remember what should be shown to me.
  The cols don't have headers, and all the text is quite dim and difficult to read except for "Profiles" at the top-left, and the 2nd col.
  It's also quite intrusive that the TUI takes the whole page, which is actually the opposite of what it was meant to do: only take 2 or 3 lines, which is fewer than rclone config takes, as I noted in https://github.com/EhudKirsh/NodeJS-Unbuffered-Input-Raw-Mode-TUI#main. I put all of these in the same bullet point because I believe that it's best to make the TUI look like it does in my Demo.
  Please see the video and screenshot in my repo again, and if you like, run my simple NodeJS script. Basically, my TUI was designed to be able to select with either a single key or the arrow keys and then Enter, any of the options, and then for some of them,
  select multiple profiles at the same time to save time for the user. If you read the comment that each option prints in https://github.com/EhudKirsh/NodeJS-Unbuffered-Input-Raw-Mode-TUI#unbufferedinputrawmodetuijs, you'll understand the format I'm suggesting. There's also no need to reprint the table in the page it opens, as aero profiles -i just printed the table
  (or aero profiles -tui will in the future), and by the time the user performs a change.
  The table shouldn't reprint if a user quits, chooses l or t, or "changes" the index of a profile to itself, because there's no change then.

  • In my repo, I gave the example of Y/N as a TUI that most people should be familiar with when deciding whether to install a package using a terminal. If you think about this example, it doesn't open up a window that hides everything that came before it,
    like aero profiles -i > tui does in v4.0.4, because it only needs a few lines, and that would be too intrusive. Same here.

  • There is therefore no need for Esc to exit the TUI, because it shouldn't be a Window that needs exiting.
    It's fine to have it, but honestly, q and 0 are sufficient for this.

  • Where I was coming from with my TUI demo is wanting to be able to select an option and a profile in separate steps, like
    rclone config allows, but doing so better than it does. So unlike rclone config that writes the options in multiple lines, I tried to write the options in fewer lines, and save a line on the selection. So while in rclone config you type a letter and then press Enter,
    in my TUI demo it's obvious which option was selected, because it's the one that stays highlighted.

An important philosophical question here for both of us that will affect any TUI design is:
Should the entire functionality of the CLI be possible to perform entirely by TUI, much like all of it can be done currently outside of any TUI?
Is it even possible? Has any app ever done this?

The way I designed my TUI demo would allow selecting actions with TUI controls, but the profiles will still be typed, and so will the new index when re-indexing, etc. The question is whether everything should be a TUI like it currently is in aero profiles -i > tui.

At any rate, wherever possible, I prefer to not have a window take over my entire terminal tab,
which prevents scrolling to the top to read what came before and make decisions for the TUI based on that.

[axpnet]

🟢 You were right, and this one was on us: the Profiles selector had drifted into a full-screen app, the opposite of your demo. I rebuilt it to your inline model.

The short version: aero profiles -i > tui no longer takes over the terminal at all. It prints nothing of its own except a compact action bar of two or three lines, directly under the table that aero profiles -i already printed, and that table keeps its real columns, headers and the favourite column because the menu never redraws it. You pick an action with a single key or by moving the highlight, then you type the target, exactly like your demo. Here is each point.

Wide, the bar is one line and the table above is untouched:

On a narrow split screen the bar wraps on option boundaries so nothing is ever hidden, here with Fav highlighted:

Two steps, the action is picked in the bar, then the target is typed, blank cancels:

Your point	What it does now
Whole page takeover	gone. No alternate screen, two or three inline lines, and the table above stays as normal terminal output so you can scroll up to read everything that came before
Wheel scroll jumped 3	there is no scrolling list inside the menu anymore, so this is moot. The table is plain output again and your terminal scrolls it one line at a time as usual
No cycling at the ends	wrap around: moving past the last option focuses the first, and before the first focuses the last
Missing keys	Left, Right, Up, Down, Tab, Shift+Tab all move the highlight, Page Up and Page Down jump to the first and last option
d delete cut off on a narrow split screen	the bar measures the terminal width and wraps on option boundaries, so every option stays fully visible, verified down to 40 columns, and it re-flows cleanly even if you resize the window while it is open
Option format	your exact form: re-index(#) | List/ls(L) | Tree(T) | Delete(D) | Fav★(F) | Copy(C) | Rename(R) | Edit(E) | Quit(Q/0), and the favourite option shows ★ or ♥ to match the user setting
Columns and readability	the menu does not draw its own dim list at all, so you read the normal aero profiles -i table with its headers and favourite column right above
Reprinting	the menu never reprints the table, quitting or picking List or Tree or re-indexing a profile to its own index leaves the screen as it was
Quit	q, Q and 0 all quit, Esc still works but nothing depends on it, there is no window to exit

On your philosophical question, should the entire CLI be doable through a TUI, and has any app done it.

We land on no, and on purpose, which is also what this rewrite now does in practice. Everything in aeroftp-cli works with zero TUI, the menu is only an optional accelerator on top of the same line-mode commands. So the model is exactly the split you designed: the TUI picks the action, the profile and the new index are typed. That keeps the terminal scrollback intact, keeps a single source of truth for every operation and every confirmation, and avoids the trap of forcing arguments through widgets. Both shapes exist in the wild and both are valid, lazygit and k9s own the screen, while rclone config, apt's Y or N, and git rebase -i stay inline, so we use inline for Profiles and keep the full screen only for aeroftp-cli tui, the dual pane file manager where a full screen is the whole point.

This Profiles menu ships in 4.0.5 as part of aeroftp-cli, which is by now a first class surface we maintain in earnest, so the selector gets real care and is not a side experiment. The immersive aeroftp-cli tui is the separate one that stays an unhurried alpha with no deadline, the piece that can wait, exactly as you framed it. Your demo stays the reference we check the Profiles menu against.

[axpnet]

One more on your "is it even possible, has any app done it", because it deserves a straight yes.

It is possible, and we already do it, just not in the Profiles menu. The place that reaches full CLI parity is the immersive aeroftp-cli tui: it carries a : command palette that runs any line-mode command, so the visual panes cover the common 90 percent and the palette covers the remaining 100 percent. That is the same pattern lazygit uses with its : prompt, so yes, apps do exactly this.

So the honest split is two answers, not one. Can everything be done through a TUI: yes, via the full aeroftp-cli tui and its : palette. Should everything be a forced TUI widget with nothing typed: no, and the Profiles selector stays the mixed model you designed on purpose, the TUI picks the action and you type the profile or the index.

In short, full parity lives in the full TUI, the Profiles menu stays a focused inline tool, and the line-mode CLI remains complete on its own.

[EhudKirsh]

Thank you very much! Your first 2 screenshots look exactly like I wanted the TUI to look like,
except for the spaces, though that's just me being picky.

By the way, your fullscreen TUI was impressive, and I didn't know that it was even possible, but I just think we can both agree that it's not ideal for Profiles because the users should be able to scroll up to see past command lines and the table evolving.
Perhaps some users will prefer fullscreen TUI, especially for other members of the Aero family.

As for the 3rd screenshot: so, I envisioned the white highlight staying after selecting an option,
which makes it obvious what option was selected, and what options there were.

Regarding your table:

• 2nd row: well, I actually liked the scrolling. But I suppose it should be kept for being able to scroll up and down to view old lines above,
  and not to cycle through the options, considering that so many keys can already do that. Still, I think it will be nice to have in other areas where the TUI will have a full screen, like the aero tui home menu and aero file -tui.
  The mouse doesn't typically get much accessibility in terminals, so it's a nice touch. I just wanted it to not skip options.
• 4th row: I think it's more intuitive that Page Up and Page Down act like the rest of the keys.
  So I suggest using Home and End to focus on the first and last options, respectively.

One important note you might've missed: I thought about each action in aero profiles -i and whether it makes sense to be able to select multiple profiles, like when deleting. This can save the user time from having to manually run an action on several profiles individually.
You can see it in the comments that the options leave in my GUI as to which support multiple profiles at once. For example, since I like the arrow during re-index, and because it can be too complicated, it's best to only re-index profiles one at a time. The reason I write this here is because it's obvious how to specify multiple profiles by names and index numbers separated by spaces. But how to do it with TUI? Imagine if aero profiles -tui will print the table as interactive at the same time as the options will be interactive, but it won't be fullscreen, and some keys will cycle through the options, and some keys will cycle through the profiles and even be able to select multiple of them. Just a thought.

[axpnet]

🟢 All three concrete points are shipped for 4.0.5, and the spaces are gone too, so you were not being picky, you were right.

On the spaces: the bar now uses your exact compact form with no padding around the pipes, re-index(#)|List/ls(L)|Tree(T)|Delete(D)|Fav★(F)|Copy(C)|Rename(R)|Edit(E)|Quit(Q/0), matching the demo character for character.

On the 3rd screenshot: the white highlight now stays on the option you picked. The bar is no longer wiped after selection, it stays on screen with the chosen action still reversed, and the target prompt opens on the line directly below it, so it is always obvious what you selected and what the other options were. Since the bar is normal terminal output it scrolls into your history with the table, exactly the evolving scrollback you wanted.

On the keys, following your table notes:

• Page Up and Page Down now behave like the rest, stepping one option at a time and wrapping at the ends, instead of jumping to the first and last.
• Home and End now jump to the first and last option respectively, which is the more intuitive split you suggested.
• Mouse wheel: in this inline menu there is no scrolling list to skip through anymore, the menu is just two or three static lines, so the terminal scrolls your scrollback one line at a time as normal. The no-skip wheel scrolling is the right behaviour to carry into the fullscreen members like the aero tui home menu and aero file -tui, where a scrolling list does exist, and we will hold it to one step there.

On your multi-select thought, this is the interesting one and I think you have put your finger on the real design question for aero profiles -tui.

Today the multi-profile actions already accept several targets, you just type them space separated at the prompt, d 3 4 7 or f alpha beta, which as you say is the obvious way to specify many by name or index. The actions that make sense for many (List, Tree, Delete, Fav, Copy) take a set, Rename and Edit take one, and re-index stays strictly one at a time with its arrow, exactly the matrix you described in your demo comments.

What you are sketching is the next step up from that: selecting the profiles interactively in the table rather than typing them, while the menu stays inline and non-fullscreen. So one set of keys cycles the action bar, another set moves a cursor through the table above and toggles a mark on each profile, and an action like Delete then runs on the marked set. That is a genuinely nice model and it keeps the scrollback intact, which is the whole point. It does need the table itself to become live, which is a bigger move than this inline menu, so we are treating it as the headline design item for aero profiles -tui rather than something to rush into 4.0.5. The single-key plus arrows model you have now is the foundation it builds on.

So for 4.0.5: spaces removed, highlight persists, Page keys cycle, Home and End jump. Your demo stays the reference. The interactive table multi-select is the next thing we design together for -tui.

[EhudKirsh]

I just had another TUI-related thought: In #276 (comment) I wrote "So the user won't just tap Enter on the default setting,
but actively click (GUI) or type (CLI) their preferred encryption algorithm".
I missed the opportunity to write about TUI there, but it would've made that comment too long.

I thought about it, and the most common option in any program is to quit or exit. It's available in various forms under various names nearly all the time. E.g. N in Y/N when about to install an app in the terminal. Exiting is also typically the safe option. Therefore,
I'm considering the following suggestion: Quit(Q/0) should always be the option that's focused on by default when entering a TUI.

This can be adopted in general, especially where there is risk. If you think about it,
re-indexing can be annoying if someone might have a glitch or an accident and will enter some numbers and press Enter.
With Quit, it just takes them back, so aeroftp-cli's design can't be blamed, since even focus is opt-in.

Regarding #276, which is what I started this comment with, when selecting the Crypt setting,
the focused option in a future TUI can be Quit(Q/0), while picking Rclone, Aero or no Crypt should all be opt-in.

[axpnet]

🟢 Done for 4.0.5.
Entering aeroftp profiles -i now starts the highlight on Quit(Q/0), the safe option, so a stray Enter just leaves instead of triggering a re-index, and every consequential action is opt-in, exactly your safe-by-default point.
We also took your re-indexing example to heart: it used to be the default-focused action, which is the riskiest one, so flipping the focus to Quit removes that footgun.
The same rule is written down for the future Crypt-setting selector you mention from #276: the focused option there will be Quit / no change, with Rclone, Aero or no Crypt all opt-in.

[EhudKirsh]

Another thought: re-index(#) is the first because the # column is on the left.
I think it might be best to reorder the options in the same order as the columns. So that will be something like:
re-index(#)|Rename(R)|Edit(E)|Copy(C)|Delete(D)|Fav★(F)|List/ls(L)|Tree(T)|Quit(Q/0)

You can see how I'm grouping List/ls(L)|Tree(T) next to Quit(Q/0) which are all changing nothing and therefore do not reprint the table, whereas the group beforehand are grouped based on the order of columns.
Not just the columns in aero profiles, but also in the table view in the My Servers page in the Actions column.

[axpnet]

🟢 Done for 4.0.5.
The action bar now follows the column order you proposed: re-index(#) | Rename(R) | Edit(E) | Copy(C) | Delete(D) | Fav★(F) | List/ls(L) | Tree(T) | Quit(Q/0).
The leading group mirrors the table columns left to right, and the read-only group that reprints nothing (List, Tree, Quit) sits together at the end, exactly your grouping logic.
One honest note: this is the CLI profiles -i selector. Matching the same order in the My Servers page Actions column in the GUI is a separate, smaller change that is not in this build yet, so we are tracking it as a follow-up.

[EhudKirsh]

There's no need to change anything there in this regard. The Action column is already in this exact order.
You can easily quickly check.