> > do you have any recommendation for what that would look like in the output?
Something like this (I hope the screenshot will make it to the mailing list): [image: Inline image 1] Cheers, Daniel On Wed, Aug 17, 2016 at 10:02 PM, Stephen Mallette <[email protected]> wrote: > > 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. > > do you have any recommendation for what that would look like in the output? > > > > 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. > > I just sorta feel +0 on these but I'd like to tidy up a bit at the same > time. If others feel good about them, then by all means let's keep them > open. I'm just bringing them to everyone's attention since there are a lot > of them. > > On Wed, Aug 17, 2016 at 3:58 PM, Daniel Kuppitz <[email protected]> wrote: > > > 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. > > > > > >
