Keyboard input patch - another new version

Project:JNode Core
Component:Code
Category:feature request
Priority:normal
Assigned:Unassigned
Status:closed
Description

This patch tweaks the keyboard driver layer and refactors the CommandShell's event-based command-line editting code as an input stream. These changes mirror changes I've made in my hacking to suppprt line editting for interactive terminal input to an application via its standard input stream.

If you look at my changes to KeyboardInputStream.java and KeyboardInterpretter.java, you will see some FIXME comments. Thee point out some important issues that need work. I'll talk about them in a Forum topic.

The patch also includes tweaks to a couple of Eclipse .classpath files necessary to make JNode compile under Eclipse.

The patch is against the version 3288.

AttachmentSize
issues_4228.41 KB

A new version is in the pipeline ...

I've coded (not tested) a more sophisticated version of this patch that addresses many of the issues I noted on the forum note. It should pass through (nearly) all valid Unicode characters properly without any collision with unmapped VK codes.

The extra newlines ...

... in the above are due to the 'cat' command inserting extra newlines at the end of files. I think this is wrong.

Good work ;-)

Thanks for your nice workings Smiling keep it up.

JNode is going for NxtGen Hero!! Smiling

Thanks for applying the patch

I intend to keep working to refine this functionality. Thanks for your feedback:

Prompts from 'js' are displayed in red because js writes them to stderr, and the console stderr renders output in red. The anomaly of the prompt turning white is happening because the KeyboardInputStream redraws the entire line including the prompt each time a character is entered. There are a number of ways to address the issue.

  1. API methods could be added to allow an application to control coloring.
  2. The CommandShell could use the console 'out' stream for a command's default stdout and stderr.
  3. The KeyboardInputStream's line redisplay could be smarter.
  4. The KeyboardInputStream could try to grab the color attributes when snarfing the current prompt.
  5. All of the above ...

Re the DEL character: it dosn't work from the command line either. That's a bug / missing functionality.

Re command history and completion: I was thinking along the same lines as you. (That's why I separated the InputCompleter interface from CommandShell!)

As far as I rmemeber the

As far as I rmemeber the DEL key worked in the shell. So this might be a regression and a quick fix would be good.

I've fixed the Delete key.

I've fixed the Delete key.

#1

Status:active» closed

I've uploaded a new version of the patch that:

  1. deals with the previous version's issues with confusing characters and keycodes,
  2. hooks the line-editing keyboard input stream into system input, and
  3. updates the 'cat' command so that it can be used as an input filter.

With the new version you can do this:

jnode> cat > /jnode/tmp/foo
The quick brown fox ...
^D
jnode> cat /jnode/tmp/foo
The quick brown fox ...


jnode>

#2

Against which version did you create this patch?

#3

Sorry, I should have noted that. I synced my 'CLEAN' tree with trunk
before making the patch. IIRC the trunk was at 3294 or 3296.

But given where you have been working in the JNode tree recently,
the patch will probably work against any recent revision.

#4

This patch looks promising!
There are several problems though which stopped me from committing it right now:
- 'leed' shows some strange behaviour on exit otherwise it works (this is the somaller one)
- 'console -n' got completely broken - this is for opening a new console that you can access with alt-f2,f3...
- 'js' and 'bsh' do not work any more - apparently they do not get the imput data, in trunk this is done on enter
- the swing console stopped working too - this is in the start menu under 'Tools'

Could you take a look at these, otherwise I will do so later?

Please remember that in certain cases echo should be denied in the console. See the Console class in Java 6, this supports entering a password - in that case there is no echo or there could be a masked echo. So wee need to have this option in mind so that we can provider propper java.io.Console support later.

Thanks,
Levente

#5

Levente, I will take a look at those issues. -- Steve

#6

This version of the patch addresses the issues raised by Levente.

Console -n works, the swing console workes, leed works, and bsh and jsh both work (modulo a problem with the way that I'm handling prompts ...)

To get this to work, I had to merge the line editing, etc functionality back into KeyboardInputStream and make that class aware of keyboard focus. I noted a couple of new issues in the patches as FIXME comments.

#7

P.S. The patch is against trunk version 3363

#8

P.P.S. I noticed that the KeyboardInputStream was in the wrong package. This patch fixes this snafu.

#9

P.P.P.S Arghh .... I generated the patch incorrectly. Here's the corrected version.

#10

This version fixes the problems reported by lsantha in the last version.

  • I've removed the API method that I added to the 'completer' interface to get the prompt. The current prompt text is is now inferred as the text at the start of the line containing the cursor when we start line editing following a 'read' request.
  • I've removed the (wrong headed) setting of System.in when the console focus changes, and changed DefaultCommandInvoker and ThreadCommandInvoker to set System.in in the execution thread before running a new command. This addresses the problem with running 'js' in a second console.

The patch is against trunk version 3372.

#11

This patch was good enough for being committed.

I noticed a single regression where the command history was behaving stangely. I fixed that.
There are still some places where this feature needs improvements:
- it would be good to investigate why js is displaying the prompt in red after repeated new lines
- the del key is not working in js
- the command history of the shell should be disabled somehow while js is running and enabled again with the commands already entered unaltered when js exits
- the above applies for code completion too
In fact these two features could be generalized so that when we start up a js/bsh-like program jnode will provide a line history for it too, and even basic code completion (for instance based on the line history) much like it is providing line editting right now. With these features I can see a chance for JNode to start developing a competitive edge wrt. support for command line Java tools in other operating systems. For instance with this path committed, and complete line editting being enabled, it is more confortable to work in the interactive js interpreter under jnode than under linux, and we are achieving this without any particual change to Rhino itself.

So thank you for this really useful pacth and keep up the good work! Eye-wink

Regards,
Levente

#12