Support for multi-line commands. #293
Merged
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
georgebrock
commented
Apr 22, 2017
| @@ -48,6 +49,19 @@ def read_command | |||
| retry | |||
| end | |||
|
|
|||
| def read_continuation | |||
| input = begin | |||
| line_editor.readline(CONTINUATION_PROMPT, true) | |||
There was a problem hiding this comment.
Passing true here results in each line of the command having it's own entry in the history. GNU Bash combines multi-line commands into a single history entry. That's probably a worthwhile enhancement, but maybe it should be a separate PR.
There was a problem hiding this comment.
Could improve the code documentation with weird syntax like:
line_editor.readline(CONTINUATION_PROMPT, history_entry_per_line=true)
georgebrock
commented
Apr 23, 2017
lib/gitsh/parser.rb
Outdated
| production(:subshell, 'SUBSHELL_START .program SUBSHELL_END') { |p| p } | ||
| production(:subshell) do | ||
| clause('SUBSHELL_START .program SUBSHELL_END') { |p| p } | ||
| end |
There was a problem hiding this comment.
This is an accidental change. I must have messed up a rebase somewhere.
a5d9652 to
0e6255c
Compare
d73f120 to
24a2287
Compare
0e6255c to
bab8382
Compare
sharplet
reviewed
May 12, 2017
| @@ -13,6 +13,7 @@ module Gitsh | |||
| module InputStrategies | |||
| class Interactive | |||
| BLANK_LINE_REGEX = /^\s*$/ | |||
| CONTINUATION_PROMPT = '> '.freeze | |||
There was a problem hiding this comment.
Can this make use of the PS2 environment variable? Is that standard?
There was a problem hiding this comment.
We don't use PS1 for the main prompt (there's a git-config(1) variable called gitsh.prompt instead). If we were going to support customisation, I think we should follow that pattern instead.
Line breaks are supported in similar places to sh(1). Line breaks can be
escaped anywhere by ending a line with a `\` character. Unescaped line
breaks are also supported:
- after logical operators (`&&` and `||`),
- within strings,
- between commands wrapped in parentheses, and
- between commands in subshells.
The Lexer has been expanded to insert a `MISSING` token in all situations
where the input is known to be incomplete (i.e. when the input ends with an
escape character, or the input ends in any of the places where an unescaped
line break can be used).
After invoking the `Lexer`, the `Interpreter` checks the token stream for
`MISSING` tokens. If it finds any it requests another line of input from the
current input strategy, appends it to the current input, and tries again.
A new `EOL` token has been introduced to represent line breaks between
commands. In the `Parser` it's treated exactly like the `SEMICOLON` token.
Lexical analysis of comments needed to be improved to allow for comments at
the end of lines in a multi-line command. For example, the following input
is valid:
(:echo 1 # comment
:echo 2)
It is semantically equivalent to:
(:echo 1; :echo 2)
To support this, the Lexer will now:
- ignore whitespace before a comment's initial `#` character. This prevents
extraneous `SPACE` tokens from being produced. A trailing `SPACE` token
in a single line command is fine, but it can cause problems in a
multi-line command.
- pop the `:comment` state without consuming the newline character at the
end of a comment, allowing the default parsing rules to handle the
newline, and produce an `EOL` token.
bab8382 to
22362e9
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Line breaks are supported in similar places to sh(1). Line breaks can be escaped anywhere by ending a line with a
\character. Unescaped line breaks are also supported:&&and||),The
Lexerhas been expanded to insert aMISSINGtoken in all situations where the input is known to be incomplete (i.e. when the input ends with an escape character, or the input ends in any of the places where an unescaped line break can be used).After invoking the
Lexer, theInterpreterchecks the token stream forMISSINGtokens. If it finds any it requests another line of input from the current input strategy, appends it to the current input, and tries again.A new
EOLtoken has been introduced to represent line breaks between commands. In theParserit's treated exactly like theSEMICOLONtoken.Lexical analysis of comments needed to be improved to allow for comments at the end of lines in a multi-line command. For example, the following input is valid:
It is semantically equivalent to:
To support this, the
Lexerwill now:ignore whitespace before a comment's initial
#character. This prevents extraneousSPACEtokens from being produced. A trailingSPACEtoken in a single line command is fine, but it can cause problems in a multi-line command.pop the
:commentstate without consuming the newline character at the end of a comment, allowing the default parsing rules to handle the newline, and produce anEOLtoken.