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
{{ message }}
Repository navigation
Chronological last command at top view for command history #3913
What is the use case or problem this feature would solve?
For the Command Sender's editable command history section, it would be nice if commands would appear in their chronological order. They don't need to repeat, the current paradigm where each sent command only has a single command history line even if multiple commands are sent is fine. But the current operation keeps the command's line in place in the history rather than moving it to the top.
Describe the solution you'd like
A profile setting is probably easiest rather than trying to implement a toggle UI element on the script runner window. Maybe even easier would be a RMB context menu that lets you switch.
Thanks for the detailed request! This makes sense as a feature enhancement to Command Sender's editable history pane.
Current behavior confirmed in code: The history is just an Ace editor text buffer (this.editor) whose contents are persisted to localStorage['command_sender__history']. Per the docs, when you re-execute an edited command line, "if the command has changed a new line will be entered in the Command History," but a repeated identical command just updates the status text in place — it doesn't reposition that command's line .
The logic that writes into the Ace editor lives around the updateHistory/saveHistory methods (near lines 690–737), where this.editor.setValue(value) rebuilds the buffer and localStorage['command_sender__history'] persists it. Implementing "move existing line to top on resend" would mean, in that update path, detecting whether the sent command's line already exists in the buffer and, if so, removing it from its old position before re-inserting it at the top — rather than the current in-place update/append.
Why I'm not proposing a full one-shot patch
I wasn't able to fully trace the exact line-matching/dedup logic used to decide "this is the same command" (e.g., exact string match vs. some key), so a blind patch risks breaking the resend-tracking/status-count behavior. It would help to confirm:
Should the "move to top" apply only on Enter-triggered resend, or also on initial Send from the top command builder?
Preferred toggle mechanism — RMB context menu vs. a persisted user setting (localStorage key, similar to command_sender__history)?
This is a reasonable, well-scoped feature request — flagging for the engineering team to confirm the UX approach (context-menu toggle seems like the lowest-friction option) and implement.
Activity
crawlchat commentedon Sep 22, 2026
COSMOS Bot response — click to expand
Thanks for the detailed request! This makes sense as a feature enhancement to Command Sender's editable history pane.
Current behavior confirmed in code: The history is just an Ace editor text buffer (
this.editor) whose contents are persisted tolocalStorage['command_sender__history']. Per the docs, when you re-execute an edited command line, "if the command has changed a new line will be entered in the Command History," but a repeated identical command just updates the status text in place — it doesn't reposition that command's line .Relevant file:
openc3-cosmos-init/plugins/packages/openc3-cosmos-tool-cmdsender/src/tools/CommandSender/CommandSender.vueThe logic that writes into the Ace editor lives around the
updateHistory/saveHistorymethods (near lines 690–737), wherethis.editor.setValue(value)rebuilds the buffer andlocalStorage['command_sender__history']persists it. Implementing "move existing line to top on resend" would mean, in that update path, detecting whether the sent command's line already exists in the buffer and, if so, removing it from its old position before re-inserting it at the top — rather than the current in-place update/append.Why I'm not proposing a full one-shot patch
I wasn't able to fully trace the exact line-matching/dedup logic used to decide "this is the same command" (e.g., exact string match vs. some key), so a blind patch risks breaking the resend-tracking/status-count behavior. It would help to confirm:
command_sender__history)?This is a reasonable, well-scoped feature request — flagging for the engineering team to confirm the UX approach (context-menu toggle seems like the lowest-friction option) and implement.