I think you can do: groovy> /nano filename.groovy // edit script then save groovy> filename.groovy // execute script
On Mon, Jun 23, 2025 at 10:48 PM Guillaume Laforge <glafo...@gmail.com> wrote: > Hi Paul, > > I've just built that branch, and this new Jline integration looks cool! > I've only tried a few simple things, like some commands (inspecting > variables, calling the docs), creating some methods, calling them, printing > stuff on the output, etc. > I really like the fact of having syntax highlighting, or how it shows that > you're currently writing a method and implies the closing curly brace (also > the indentation is there). > I'm not sure what the nano editor is really supposed to be doing? Could've > been nice to be able to edit the current script we're working on? Or maybe > I'm missing something (on how it's supposed to work)? > Launching /console, when quitting the console, it'll quit the shell as > well. > > Anyway, that's really cool stuff! > > Guillaume > > > On Mon, Jun 23, 2025 at 8:07 AM Paul King <pa...@asert.com.au> wrote: > >> I found an (old) existing issue: >> >> https://issues.apache.org/jira/browse/GROOVY-8162 >> >> I'll attach a few screenshots there and use that for additional >> discussion. >> >> Paul. >> >> >> On Mon, Jun 23, 2025 at 3:45 PM Paul King <pa...@asert.com.au> wrote: >> >>> >>> Hi folks, >>> >>> I have been looking at what is involved with migrating our Groovysh repl >>> from JLine2 to JLine3. >>> >>> You can find the latest version in the jline3 branch. It would be great >>> if anyone has spare time and would like to help assess whether we think we >>> can knock this into shape in time for Groovy 5. >>> >>> The easiest way to try it out is switch (once fetched) to the jline3 >>> branch. >>> >>> Run "./gradlew iG" to build. >>> Then run "subprojects/groovy-binary/build/install/bin/groovysh2". >>> Hitting <TAB> can show some of the commands. >>> I found some implementation issues using our current ":command" commands >>> and so have instead used "/command" like jshell. The colon variants are >>> supported as an undocumented alias at the moment. We'd likely need some >>> changes to jline if we wanted the colon variants as the only variant. >>> >>> That branch has two versions side-by-side: >>> * The groovysh command is our old version with minimal work done to >>> "just port" from jline2 to jline3. (This might be currently broken but I'll >>> fix it soon.) >>> * The groovysh2 command tries to leverage many features from JLine3 to >>> make a feature-rich repl but also minimise the amount of code we'd have to >>> maintain. >>> >>> The two versions do parsing/completing/commands slightly differently. My >>> current thinking is that we'd throw away most of the earlier commands since >>> they are covered by alternatives. We need to see which, if any, of the >>> existing completers/parsing we'd like to bring across. >>> >>> The JLine3 project's repo has a Groovy-based repl as an example demo >>> application which shows off many built-in JLine3 features and widgets. I >>> have based our repl on that demo and kept a lot of the functionality. We'll >>> have to decide which features, if any, we want to keep. I have copied some >>> of the repl-related files from the JLine3 repo to ours. I imagine there >>> will need to be an assessment of which of those files we may be able to >>> leave on the JLine side of things. >>> >>> There will be lots of tidying up to do (dependency metadata, license >>> file updates, etc.) but the first thing to do is work out which bits we'd >>> want to keep or need further work. >>> >>> Things that I know need some work: >>> * The /grab completer completes maven coordinates based on dependencies >>> found in the users ~/.m2/repository directory. We might like to allow that >>> to be configured to use ~/.groovy/grapes or a URL to maven central. >>> * Theme support is "enabled" for syntax highlighting and existing >>> commands let you switch e.g. between light and dark highlighting, but I >>> don't know what parts are actually affected when you make such changes. >>> * There are some completers like BackslashEscapeCompleter that are only >>> in the old version. >>> * There is a rudimentary DocFinder class that looks up javadoc and >>> groovydoc using a browser. Our old version also handled GDK documentation >>> and had fallbacks if browsers weren't found. >>> * Many switches and system properties haven't been converted over >>> * I18N message resources are rather limited in the new version >>> * Interpreter mode hasn't been looked at >>> * testing on various platforms >>> * test suite is hard-coded to JLine2 implementation details in numerous >>> places >>> >>> If anyone does get some time, please get in touch and if there are bits >>> of work that can be divided up, that would be great. I am about to head off >>> on a mini-break, so may not respond for a few days, but I plan to work on >>> this again when I return. >>> >>> Cheers, Paul. >>> >>> > > -- > *Guillaume Laforge* > Apache Groovy committer > Developer Advocate @ Google Cloud <https://cloud.google.com/> > > - Blog: glaforge.dev > - X: @glaforge <http://twitter.com/glaforge> > - Bluesky: @glaforge.dev <https://bsky.app/profile/glaforge.dev> > - Mastodon: @glafo...@uwyn.net <http://%40glafo...@uwyn.net/> > >
