Migrate to jline3 #2063
Migrate to jline3 #2063
Conversation
| private final NavigableMap<String, String> setOptions; | ||
| private final BiConsumer<String, List<Candidate>> completeIdentifier; | ||
| private final BiConsumer<String, List<Candidate>> completeModule; | ||
| public RascalCommandCompletion(NavigableMap<String, String> setOptions, BiConsumer<String, List<Candidate>> completeIdentifier, BiConsumer<String, List<Candidate>> completeModule) { |
There was a problem hiding this comment.
Why the BiConsumer approach? Because a simple function returning a list of candidates is less efficient?
There was a problem hiding this comment.
In the end yes, and since this is called frequently, I thought to keep the design of jline3 (namely: here, append onto this list) around. I've not measured it if concatenation would be an acceptable performance tradeoff.
| sw.write(value, wrt); | ||
| } | ||
| catch (/*IOLimitReachedException*/ RuntimeException e) { | ||
| // ignore since this is what we wanted |
There was a problem hiding this comment.
I do not completely understand this, but does this mean e should be an instance of IOLimitReacheException but we cannot catch that directly? If so, should we not check for this explicitly to make sure we are not ignoring another RuntimeException?
Mostly: only do stuff with the terminal when really needed, don't flash the cursor everytime. Don't remove the progressbar for every incoming write
DavyLandman
force-pushed
the
migrate-jline3
branch
from
33d2ec9 to
fa645ec
Compare
Years reflect if the file was new or came from the previous REPL implementation
There was a problem hiding this comment.
That's an impressive amount of work! Very nice improvements 🙂. Replacing streams with writers looks good: cleaner and less code. Regarding my comments:
- Most of them are nits
- I turned on full pedantic mode a few times to add suggestions for user-facing messages (and a few typos in comments). It's hopefully easy to batch them using the corresponding button and quickly be done with them.
- The bigger things (but non-essential) to consider, are related to moving code to more general, REPL-unspecific packages (e.g., I imagine we might want to reuse the completers in IDEs as well). See the comments for details.
- I don't have a separate comment for this, but I've been seeing some
nullarguments and returns occasionally, and also some checker annotations, but not consistently everywhere I think? This could be something to improve (but not necessarily in this PR). - Some of the deeper details of the implementation were a bit hard for me to get a good feel for (e.g., sequences of jline invocations; the way in which the progress bar is manipulated). I haven't seen anything obviously wrong with it, but it's very well possible I might have missed something in those code fragments.
Thanks Sung 👍🏽 Co-authored-by: sungshik <[email protected]>
This PR migrates the REPL to jline3, numerous issues are solved, but it also required a redesign of all the REPL classes.
This breaks some stuff, which could not be avoided. The most noticeble is that all Input&OutputStreams were removed from the evaluator. That was (in hindsight) not a good design choice, as they are about bytes, while we want to print text. This gets messy when we have to figure out which charset we should write to the stream.
Todo's:
main