mattj23 / interactivereadline Goto Github PK

Create a default lexer which allows a user to add regex expressions in for tokens. The regexes should be addable through a fluent-like interface, returning a Func<LineState, TokenizedLine>.

The same lexing engine should be used as the existing example lexer that splits on whitespace. The user should have the option to add an integer to identify token type, which will be accessible through the IToken inteface.

The https://github.com/tonerdo/readline library has a set of keyboard shortcuts based on the old GNU Readline.

Right now only a few of them are implemented, the rest of them should be added as common behaviors and either added to the ReadLineConfig.Basic config, or another slightly elevated configuration.

Right now there are special key behaviors, which are registered to a configuration, and the default key behaviors (insert character, enter) which are hard coded.

Replace the hard coded behaviors to use the same mechanism as the special behaviors, which will allow the behavior system to be modified in absolutely any way possible.

Create a default key behavior configuration which provides a normal, working console, and an empty configuration which has absolutely nothing and can be configured in any way.

The default Ubuntu terminal is extremely slow when rewriting the entire line of text (xterm, on the other hand, is not). It seems likely that it has to do with writing text character by character to the System.Console, and that if larger sections of text could be written at once it might speed up.

There has historically been a known issue with reading the cursor position from the terminal on non-windows consoles.

The last major feature missing for parity with other readline style libraries is the command history, navigable with the up and down arrow keys.

Some thought will need to be spent on figuring out where the history should be saved to and how it should be passed back out of the handler. Attaching the history to the configuration object seems like the most likely candidate, but it shouldn't be taken for granted that it's the correct choice.

Right now unit tests are missing some important areas. Key behaviors, lexing, and the input handler and ConsoleReadLine objects are all problem areas which need to be covered by tests.

The demo project is currently just a test area, and should be made to be a more useful display of the library.

It should showcase:

1. The composable key behavior system
2. The lexing system
3. The autocomplete system
4. Formatting
5. The history

The WriteMessage method is too specific, the method itself is more general. Rename it to something that actually makes sense.

It exists in IKeyBehaviorTarget, InputHandler, and IReadLine

Many of the interfaces and objects names have remained fixed even as the API has evolved, meaning that the names don't necessarily reflect the elements and their purpose. Rethink the naming and fix where it makes sense.

Candidates for renaming:

• IReadLine
• InputHandler
• ReadLineConfig
• IConsoleWrapper

Finish the implementation of the foreground/background color writing to the System.Console.