Brainstorming Features

[fdncred]

1. Line Editor UI/UX Features

Brainstorming of ideas about what features would make a line editor and programs that use it best-in-class. I'm interested to see which of these people agree with. These aren't necessarily MVP type ideas and perhaps even greater than 1.0 ideas.

• 1. Line Editor UI/UX Features
  • 1.2. Prompt Features #64
  • 1.3. Completions Features #65
  • 1.4. History Features #66
  • 1.5. Hinting Features #65
  • 1.6. Syntax Highlighting Features #67
  • 1.7. PopUps/PopUnders Features #68
  • 1.8. Keybinding #69
  • 1.9. Miscellaneous #70

1.2. Prompt Features #64

• [x] Ability to have Colors/Styles/Themes
• [x] Ability to have Left Side Prompt
• [x] Ability to have Right Side Prompt
• [x] Ability to have Animated Prompt - Clock, Ansi Spinners like -|/
• [x] Ability to use external prompts like starship or oh-my-posh
• [ ] Ability to make prompt extensible

1.3. Completions Features #65

• [ ] Ability to works as expected or better
  • [x] File and folder completion
  • [ ] zsh-style partial path expansion
  • [ ] Environment variable completion $nu.env.A<tab>
  • [ ] Table column completion (ls).n<tab>
  • [ ] Sub-Command completion str <tab>
  • [ ] Other
• [x] Ability to add external completions for things like git
• [x] Ability to make completions extensible

1.4. History Features #66

• [x] Ability to save commands in history
• [x] Ability to save multi-line commands in history
• [x] Ability to traverse backward and forward within history via keybindings
• [x] Ability to search history
• [x] Ability to search history and travese backward and forward within the search criteria
• [x] Ability to have rich data within the history, such as:
  • [x] run time in ms
  • [x] date/time command was ran
  • [x] sessionid of who ran the command assuming multiple sessions
• [x] Ability to have multiple sessions successfull write to history file(s)
• [x] Ability for each session to have it's own history or the appearance of it's own history so within history searching in a single session you only see the commands you created in that session
• [x] Ability to send all commands from all sessions into a global history which search interfaces can use
• [ ] Ability to have plugable technologies to make history searching and recall extensible
• [ ] Ability to reset history

1.5. Hinting Features #65

• [x] Ability to change the color of the hints
• [x] Ability to create hints from history
• [ ] Ability to have plugable hints specific to a vertical
  • [ ] Nushell
  • [ ] Azure
  • [ ] Dataframe/Polars/DataScience
  • [ ] Maths
  • [ ] Other
• [x] Ability to complete hints with keybinding
• [ ] Ability to change location of hints
  • [ ] On prompt line
  • [ ] Under prompt line
  • [ ] On status bar at the top
  • [ ] On staus bar at the bottom

1.6. Syntax Highlighting Features #67

• [ ] Ability to define word-types to highlight as you type and continue coloring even in failure modes
  • [ ] Keywords
  • [ ] Commands
  • [ ] External Commands
  • [ ] Bareword
  • [ ] Punctuation
  • [ ] Sub-Commands
  • [ ] Braces {}, Brackets [], Parentheses ()
  • [ ] Error modes
  • [ ] Operators
  • [ ] Paths
  • [ ] Pipe
  • [ ] Arguments/Flags
  • [ ] Variables
  • [ ] Comments
  • [ ] DataTypes (strings, int, datetime, duration, bool, units, etc)
  • [ ] Other
• [x] Ability to have add things you want syntax highlighted through extensibility

1.7. PopUps/PopUnders Features #68

• [ ] Ability to have popups for things like progress bars
• [ ] Ability to have popunders, think of this as row(s) under your prompt, to display things like statuses, documentation, or hints
• [ ] Ability to have extensibility

1.8. Keybinding #69

• [x] All major functionality should be exposed via keybindings
• [x] Ability to have multiple keybindings
  • [x] VI Mode
  • [x] Emacs Mode
  • [x] JT Mode (the ability to code like JT)
  • [ ] Other
• [x] Ability to load keybindings from file
• [x] Ability to execute previously defined code or externals via keybindings
• [ ] Ability to have keybinding chords (multiple keyboard shortcuts in succession execute a particular internal or external command)

1.9. Miscellaneous #70

• [x] Validation to trigger multiline on incomplete lines
• [ ] Tested behaviour under various environments
  • [x] OSes
  • [x] Terminal emulators: gnome-terminal, iTerm, alacritty
  • [x] Multiplexers: screen, tmux
  • [ ] As ssh session
• [ ] possible plugins to use file searches and terminal browsers: fzf, skim, broot, zoxide, ranger, etc
• [ ] Responsive resizing

[sholderbach]

How should we vote or state our priorities?

[fdncred]

Good question. Any suggestions? It would be nice to allow people to upvote certain things. Maybe there's some voting site that does that?

[sophiajt]

One way to do the voting would be to let people pick their top three things, then count that. Folks could reply here if we do it that way.

[sholderbach]

As the granularity/scope of the ideas/milestones varies we may want to break the main themes out into separate tracking issues under a milestone so that we can better keep track what is relevant in that area. We than can use the one here to weigh on the focus of the general themes. Using the emojis on github with individual comments would probably get quite messy.

[fdncred]

@sholderbach I was going to split this up into issues like you did (Thanks!!!) but what do you think about adding the github emojis to allow people to vote by clicking on them? I think we just need to maybe number them and say to vote for X use the +1/thumbs up emoji, to vote for Y use the -1/thumbs down emoji. I just see 8 emojis so maybe we can only have the top 8 things to vote on. What do you think?

BTW - i added to History - ability to remove history

[sholderbach]

My suggestion would be to put a list of the eight currently most important/controversial ideas in a comment below with the emojis as labels, so we can update the top comment as an overview as needed without screwing with the past votes.

Template below:

Current voting

Vote for the topic(s) you care about by selecting the corresponding emoji. (No judgement based on the emojis sentiment!)

• :+1:
• :-1:
• :smile:
• :tada:
• :confused:
• :heart:
• :rocket:
• :eyes:

# Current voting

Vote for the topic(s) you care about by selecting the corresponding emoji. (No judgement based on the emojis sentiment!)

- :+1: 
- :-1: 
- :smile: 
- :tada: 
- :confused: 
- :heart: 
- :rocket: 
- :eyes: 

[sholderbach]

Voting on the feature areas you want the project to focus on

Vote for the topic(s) you care about by selecting the corresponding emoji. (No judgement based on the emojis sentiment!)

• :+1: Prompt #64
• :-1: Completions #65
• :smile: Hints #65
• :tada: History #66
• :confused: Syntax Highlighting #67
• :heart: Pop-ups/Annotations #68
• :rocket: Keybindings #69

[fdncred]

Thansk @sholderbach. Here's another feature that needs to go in some category.

• [ ] Ability to integrate with fzf, skim, broot, zoxide, ranger, etc

[sholderbach]

I would like to add the category 'System interaction' including stuff like compatibility validation on ssh, tmux etc.

There it would fit in. Where is the responsibility boundary between line editor and integration with nushell?

[fdncred]

Speaking of validation, there may need to be some type of Validator trait like rustyline's.

[fdncred]

Since these are all referenced in their own issues, I think I'm going to close this one to declutter. We can re-open if needed.

[fdncred]

oops, didn't notice it was pinned. Reopening. :)

[nixypanda]

Idea: Prefix based history search.

Example use-case: (assuming you are using vi mode)

1. Your start writing a command dock
2. Hit escape and start going through history using k
3. you will get suggestions like docker ls docker-compose ls docker-compose logs etc.

Note: adding this separately from 'history search based on a criteria' as one doesn't need to hit Cmd-r (or equivalent) for this.

[fdncred]

@sherubthakur This is what I meant by this item in the history list above. Maybe I should've named it Prefix based search

• [ ] Ability to search history and travese backward and forward within the search criteria

[hustcer]

In bash we can do :

nu \
  -c 'version'

to break lines, maybe we can add this feature too.

[sholderbach]

In bash we can do :

nu \
  -c 'version'

to break lines, maybe we can add this feature too.

This is beyond the scope of reedline as special casing characters in the buffer would constrain the grammar of the using language (nu might not want to adopt the backslash bashism as it is annoying with Windows paths). The Validator trait can be implemented to do checks whether an expression is complete. The submit on enter check could be extended on reedline's side to provide option to only submit on the last line/last char position.