Personally I like the execution time and syntax coloring feature requests. *Execution Time:*
clock() is still good, because it allows you to measure the execution time of larger code blocks and it does things like warmup rounds under the hood to provide more realistic execution times. But I still think that it would be beneficial to see the execution time for every single statement. Could be an option that can be turned on and off though. *Syntax Highlighting:* Especially larger results can be hard to read. Anything that makes the output more readable would be great. This can be either syntax highlighting or proper indenting (or both). If no one has any thoughts on these ..., I'll act on these as I've > described in this post. This means *"will not fix; close"* for both tickets. That's unfortunate, but if it's really such a pain to add those features, well, then that's that. Cheers, Daniel On Wed, Aug 17, 2016 at 8:23 PM, Stephen Mallette <[email protected]> wrote: > There's a handful of semi-related JIRA issues for Gremlin Console out there > - I say "semi-related" because they all largely revolve around usability. > Most recently is the discussion again about return of "null" for void > returns: > > https://issues.apache.org/jira/browse/TINKERPOP-1409 > > We've had that discussion many times over the years and I'm not sure that > we're going to come up with anything much better than the way it works now. > The JIRA discussion is already looking like past discussions on this topic. > > Then there is this issue to :clear automatically after an error: > > https://issues.apache.org/jira/browse/TINKERPOP-1226 > > I think I'd like to close this without implementing with the reasoning I > presented in the comment, but I thought others might feel different so I > thought I'd bring it to everyone's attention for discussion. > > This next one is about showing the "execution time" in the console: > > https://issues.apache.org/jira/browse/TINKERPOP-1123 > > I see the reasoning for presenting that information but I don't think it > fits the REPL environment that we have very well - I'd rather just close > it. I would say that users should simply use clock() or the other > performance tools we have if they want to track execution time. > > The following issue ultimately suggest we use line numbers in the console > as groovysh does: > > https://issues.apache.org/jira/browse/TINKERPOP-1285 > > I could see that as useful, but personally I'd rather not change that and > close the issue. I suppose it could be a configuration that users turn on > as an option, but is it that useful to people that we should take the time > to code that? > > In this next issue, there is a request for shell coloring: > > https://issues.apache.org/jira/browse/TINKERPOP-1037 > > I've never been able to get that to work.............I think it would be > neat, groovysh does most of the work and it really doesn't introduce much > code, etc. - maybe someone smarter than me can figure that one out and we > can leave it open (at this point though after multiple attempts, i'd > personally just rather close it). > > Finally, there is this one, which talks about "additional help": > > https://issues.apache.org/jira/browse/TINKERPOP-1246 > > Recall that we had that incomplete PR for displaying javadoc in the > console. That was a nice generalized solution, but didn't really belong as > a PR to TinkerPop. To me that was the best way to re-use existing > documentation. It wouldn't be great for us to maintain special docs just > for the Console. Anyone have any ideas here? Is this worth trying to do at > some point? or will we always end up pushing any such ideas down to > groovysh and not really make them a part of TinkerPop in which case, we > should just close this? > > If no one has any thoughts on these (aside from TINKERPOP-1409 which is > having active discussion), I'll act on these as I've described in this > post. >
