Hi Paul, I haven't had a chance to try things yet, but I was just wondering if in your work on this you could identify anything that might be troublesome for folks who extend groovysh? As you probably recall, TinkerPop makes pretty heavy use of groovysh for our Gremlin Console and I'm curious if there are any gotchas we will need to consider in the future.
Thanks, stephen On Mon, Jun 23, 2025 at 5:35 PM Paul King <pa...@asert.com.au> wrote: > 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/> >> >>
