Patch to make command/application input history modal
| Project: | JNode Core |
| Component: | Code |
| Category: | feature request |
| Priority: | normal |
| Assigned: | lsantha |
| Status: | closed |
Jump to:
Description
The attached patch makes the console input drivers support for history and completion modal.
- When the command shell is the consumer of keyboard input, TAB does command completion, and the history keys select from the shell's command history.
- When an application is the consumer, TAB does nothing (for now), and the history keys select from a separate application history list. These application history lists are created afresh each time an application is launched, and are accessed via an inheritable thread local.
I'm not convinced that this is the best way to implement this functionality, but it is good enough for now, IMO. I want to clear the decks so that I can rework and submit my earlier "proclet mode" stuff.
BTW, the patch renames the CommandHistory class as InputHistory, and renames various of its methods to be more appropriate to its new usage, This is an incompatible change, but IMO it is the right thing to do for future users of the API.
| Attachment | Size |
|---|---|
| issues_54 | 83.67 KB |
- Login to post comments
#1
I've tested it and it looks good enough for now. I've commited it and it really makes a difference now to be working with an interactive commandline interpreter under JNode.
On the improvement side, probably the input history of a command should be bound to a kind of command context where other command execution related objects reside. The current ThreadCommandInvoker.CommandRunner class seems to be pretty close to it. This begins gaining importance when we want to send a long running command or an interactive program to the background and later bring it back again for further work. Though probably such feature will need a bit more work if we only consider the strange results of sending a running js to the backgorund with Ctrl-Z and after that trying to continue working with the shell.
Oeverall good progress...
Thanks, Levente
#2
I agree that application input history need more thought. Having the history shared by instances of an application is seems attractive, but should that sharing extend to instances launched in different shells? Ahat should happen when two instance of an application are launched from the same shell? I think we'd need to do some useability experiments.
Another things we should consider include command and application history persistence, hooks for application completion and more advanced history searching.
BTW: one way to address your last issue is to create a new ConsoleInput Stream with its own InputCompleter context each time an app is launched. That way we don't need to do any funky switching or multiplexing when an application is backgrounded / foregrounded.
But I think we need to address the System.{out,err} problem before all of the above ...
#3