Kawa doesn't use JLine. Instead, you can do one of: (1) The GUIConsole class wraps the read-eval-print loop. This is pure Swing, so it should be quite portable. It looks and feels a lot like Emacs shell mode or the related inferior lisp mode.
See http://per.bothner.com/blog/2007/ReplPane/ for a summary and pictures. Since that article was written I've made various improvements to the GUIConsole, so for best effect try it from the SVN version of Kawa. The latest version of Kawa starts up the GUIConsole by default if there is no console, which should make it a little nicer on Windows. The GUIConsole is in some ways better than readline *or* JLine, in that it supports moving the cursor with the keyboard *or* the mouse. It uses the standard Swing key-bindings, which is both an advantage and a disadvantage. It allows "rich" output, including coloring, and embedded widgets, as shown in the article. GUIConsole has modest dependencies on Kawa. It does make use of the Kawa IO classes, which are subclasses of Reader and PrintWriter that add some extra useful functionality (such as pretty-printing). But the interface to Kawa can easily be made generic: It runs the method Shell.run in a thread, hooking up the standard input, output and error Reader/PrintWriters to ones supplied by GUIConsole. For many years I've been looking for the "perfect" terminal enumulator / console / shell mode. Emacs "term" mode was an attempt to provide the best of terminal emulator and shell mode. GUIConsole is another attempt. It's hardly perfect, but I think it has potential to do lots of cool things. If people are interested in using it separately from Kawa, I think we could make it a really great package. (2) Kawa also uses the real readline on systems that provide it. It uses a wrapper written in C that uses readline to process the input, and then feeds that to a child Kawa process, which is pure Java. This is similar to rlwrap, but a few extra benefits. One is that it looks at argv[0] to set the class-path to include the Kawa jar. (Of course a shell script could do the same.) It also calls isatty(0) and if not passes an option to start GuiConsole. This is useful for JDK 1.5 and earlier which don't have the Console class; on Java6 Kawa checks if System.console() is null. The communication with the child can be done either by starting it in a pty, or by using sockets. The latter (which is the default) uses an "inverse telnet" protocol. (The front-end runs as a server, and passes a command-line argument to the child telling it which port to use to connect to the front-end. Using inverse-telnet in this way has been remarkably reliable - I haven't changed the code since 2000. An obvious advantage of using readline proper is 100% compatibity with readline, including history, configuration, etc. This is helpful for those of us who use bash on a regular basis. Using readline in a separate frontend avoids licensing conflicts with the GPL'd readline. Note *all* input from System.in goes through readline, not just commands to the evaluator. If you read a line from from System.in that too can be edited using readline. Using JLine would add one extra use mode: readline-like interaction in an existing console on systems that don't have readline - primarily Windows users. But starting a GUIConsole is trivial, and gives some advantages, such as navigating with the mouse. So the extra benefit of using JLine is minor. I also have: (3) A small Ajax library combined with a read-eval-print-loop running inside a servlet. Your console is Firefox. This is more of a proof-of-concept, but it does work (or at least did not too long ago ...). It would be cool to have it use the Java6 com.sun.net.httpserver which would make deployment easier. Alternatively, ship Kawa with a light-weight servlet container, like Acme. -- --Per Bothner [EMAIL PROTECTED] http://per.bothner.com/ --~--~---------~--~----~------------~-------~--~----~ You received this message because you are subscribed to the Google Groups "JVM Languages" group. To post to this group, send email to [email protected] To unsubscribe from this group, send email to [EMAIL PROTECTED] For more options, visit this group at http://groups.google.com/group/jvm-languages?hl=en -~----------~----~----~----~------~----~------~--~---
