2020-04-15 05:43:23 +00:00
|
|
|
use crate::commands::command::per_item_command;
|
|
|
|
use crate::commands::run_alias::AliasCommand;
|
2019-12-07 03:46:05 +00:00
|
|
|
use crate::commands::UnevaluatedCallInfo;
|
2019-11-24 22:19:12 +00:00
|
|
|
use crate::prelude::*;
|
|
|
|
use log::{log_enabled, trace};
|
2019-11-21 17:18:00 +00:00
|
|
|
use nu_errors::ShellError;
|
2020-04-13 07:59:57 +00:00
|
|
|
use nu_protocol::hir::InternalCommand;
|
2020-04-15 05:43:23 +00:00
|
|
|
use nu_protocol::{CommandAction, Primitive, ReturnSuccess, Scope, UntaggedValue, Value};
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2020-03-01 17:19:09 +00:00
|
|
|
pub(crate) fn run_internal_command(
|
2019-11-24 22:19:12 +00:00
|
|
|
command: InternalCommand,
|
|
|
|
context: &mut Context,
|
Move external closer to internal (#1611)
* Refactor InputStream and affected commands.
First, making `values` private and leaning on the `Stream` implementation makes
consumes of `InputStream` less likely to have to change in the future, if we
change what an `InputStream` is internally.
Second, we're dropping `Option<InputStream>` as the input to pipelines,
internals, and externals. Instead, `InputStream.is_empty` can be used to check
for "emptiness". Empty streams are typically only ever used as the first input
to a pipeline.
* Add run_external internal command.
We want to push external commands closer to internal commands, eventually
eliminating the concept of "external" completely. This means we can consolidate
a couple of things:
- Variable evaluation (for example, `$it`, `$nu`, alias vars)
- Behaviour of whole stream vs per-item external execution
It should also make it easier for us to start introducing argument signatures
for external commands,
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
2020-04-20 03:30:44 +00:00
|
|
|
input: InputStream,
|
2020-04-15 05:43:23 +00:00
|
|
|
scope: &Scope,
|
Move external closer to internal (#1611)
* Refactor InputStream and affected commands.
First, making `values` private and leaning on the `Stream` implementation makes
consumes of `InputStream` less likely to have to change in the future, if we
change what an `InputStream` is internally.
Second, we're dropping `Option<InputStream>` as the input to pipelines,
internals, and externals. Instead, `InputStream.is_empty` can be used to check
for "emptiness". Empty streams are typically only ever used as the first input
to a pipeline.
* Add run_external internal command.
We want to push external commands closer to internal commands, eventually
eliminating the concept of "external" completely. This means we can consolidate
a couple of things:
- Variable evaluation (for example, `$it`, `$nu`, alias vars)
- Behaviour of whole stream vs per-item external execution
It should also make it easier for us to start introducing argument signatures
for external commands,
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
2020-04-20 03:30:44 +00:00
|
|
|
) -> Result<InputStream, ShellError> {
|
2019-11-24 22:19:12 +00:00
|
|
|
if log_enabled!(log::Level::Trace) {
|
|
|
|
trace!(target: "nu::run::internal", "->");
|
|
|
|
trace!(target: "nu::run::internal", "{}", command.name);
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
|
Move external closer to internal (#1611)
* Refactor InputStream and affected commands.
First, making `values` private and leaning on the `Stream` implementation makes
consumes of `InputStream` less likely to have to change in the future, if we
change what an `InputStream` is internally.
Second, we're dropping `Option<InputStream>` as the input to pipelines,
internals, and externals. Instead, `InputStream.is_empty` can be used to check
for "emptiness". Empty streams are typically only ever used as the first input
to a pipeline.
* Add run_external internal command.
We want to push external commands closer to internal commands, eventually
eliminating the concept of "external" completely. This means we can consolidate
a couple of things:
- Variable evaluation (for example, `$it`, `$nu`, alias vars)
- Behaviour of whole stream vs per-item external execution
It should also make it easier for us to start introducing argument signatures
for external commands,
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
2020-04-20 03:30:44 +00:00
|
|
|
let objects: InputStream = trace_stream!(target: "nu::trace_stream::internal", "input" = input);
|
2019-11-24 22:19:12 +00:00
|
|
|
let internal_command = context.expect_command(&command.name);
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2019-11-24 22:19:12 +00:00
|
|
|
let result = {
|
|
|
|
context.run_command(
|
2020-01-02 07:07:17 +00:00
|
|
|
internal_command?,
|
2020-04-06 07:16:14 +00:00
|
|
|
Tag::unknown_anchor(command.name_span),
|
2019-12-07 03:46:05 +00:00
|
|
|
command.args.clone(),
|
2020-04-15 05:43:23 +00:00
|
|
|
scope,
|
2019-11-24 22:19:12 +00:00
|
|
|
objects,
|
|
|
|
)
|
|
|
|
};
|
2019-11-24 22:19:12 +00:00
|
|
|
|
Move external closer to internal (#1611)
* Refactor InputStream and affected commands.
First, making `values` private and leaning on the `Stream` implementation makes
consumes of `InputStream` less likely to have to change in the future, if we
change what an `InputStream` is internally.
Second, we're dropping `Option<InputStream>` as the input to pipelines,
internals, and externals. Instead, `InputStream.is_empty` can be used to check
for "emptiness". Empty streams are typically only ever used as the first input
to a pipeline.
* Add run_external internal command.
We want to push external commands closer to internal commands, eventually
eliminating the concept of "external" completely. This means we can consolidate
a couple of things:
- Variable evaluation (for example, `$it`, `$nu`, alias vars)
- Behaviour of whole stream vs per-item external execution
It should also make it easier for us to start introducing argument signatures
for external commands,
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
2020-04-20 03:30:44 +00:00
|
|
|
let mut result = trace_out_stream!(target: "nu::trace_stream::internal", "output" = result);
|
2019-11-24 22:19:12 +00:00
|
|
|
let mut context = context.clone();
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2019-11-24 22:19:12 +00:00
|
|
|
let stream = async_stream! {
|
|
|
|
let mut soft_errs: Vec<ShellError> = vec![];
|
|
|
|
let mut yielded = false;
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2019-11-24 22:19:12 +00:00
|
|
|
while let Some(item) = result.next().await {
|
|
|
|
match item {
|
|
|
|
Ok(ReturnSuccess::Action(action)) => match action {
|
|
|
|
CommandAction::ChangePath(path) => {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.shell_manager.set_path(path);
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
CommandAction::Exit => std::process::exit(0), // TODO: save history.txt
|
|
|
|
CommandAction::Error(err) => {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.error(err);
|
2019-11-24 22:19:12 +00:00
|
|
|
break;
|
|
|
|
}
|
2019-12-07 03:46:05 +00:00
|
|
|
CommandAction::AutoConvert(tagged_contents, extension) => {
|
|
|
|
let contents_tag = tagged_contents.tag.clone();
|
|
|
|
let command_name = format!("from-{}", extension);
|
|
|
|
let command = command.clone();
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
if let Some(converter) = context.registry.get_command(&command_name) {
|
2019-12-07 03:46:05 +00:00
|
|
|
let new_args = RawCommandArgs {
|
|
|
|
host: context.host.clone(),
|
|
|
|
ctrl_c: context.ctrl_c.clone(),
|
|
|
|
shell_manager: context.shell_manager.clone(),
|
|
|
|
call_info: UnevaluatedCallInfo {
|
2020-04-13 07:59:57 +00:00
|
|
|
args: nu_protocol::hir::Call {
|
2019-12-07 03:46:05 +00:00
|
|
|
head: command.args.head,
|
|
|
|
positional: None,
|
|
|
|
named: None,
|
Move external closer to internal (#1611)
* Refactor InputStream and affected commands.
First, making `values` private and leaning on the `Stream` implementation makes
consumes of `InputStream` less likely to have to change in the future, if we
change what an `InputStream` is internally.
Second, we're dropping `Option<InputStream>` as the input to pipelines,
internals, and externals. Instead, `InputStream.is_empty` can be used to check
for "emptiness". Empty streams are typically only ever used as the first input
to a pipeline.
* Add run_external internal command.
We want to push external commands closer to internal commands, eventually
eliminating the concept of "external" completely. This means we can consolidate
a couple of things:
- Variable evaluation (for example, `$it`, `$nu`, alias vars)
- Behaviour of whole stream vs per-item external execution
It should also make it easier for us to start introducing argument signatures
for external commands,
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
2020-04-20 03:30:44 +00:00
|
|
|
span: Span::unknown(),
|
|
|
|
is_last: false,
|
2019-12-07 03:46:05 +00:00
|
|
|
},
|
2020-04-06 07:16:14 +00:00
|
|
|
name_tag: Tag::unknown_anchor(command.name_span),
|
2020-04-15 05:43:23 +00:00
|
|
|
scope: Scope::empty(),
|
2019-12-07 03:46:05 +00:00
|
|
|
}
|
|
|
|
};
|
|
|
|
let mut result = converter.run(new_args.with_input(vec![tagged_contents]), &context.registry);
|
|
|
|
let result_vec: Vec<Result<ReturnSuccess, ShellError>> = result.drain_vec().await;
|
|
|
|
for res in result_vec {
|
|
|
|
match res {
|
|
|
|
Ok(ReturnSuccess::Value(Value { value: UntaggedValue::Table(list), ..})) => {
|
|
|
|
for l in list {
|
|
|
|
yield Ok(l);
|
|
|
|
}
|
|
|
|
}
|
|
|
|
Ok(ReturnSuccess::Value(Value { value, .. })) => {
|
|
|
|
yield Ok(value.into_value(contents_tag.clone()));
|
|
|
|
}
|
|
|
|
Err(e) => yield Err(e),
|
|
|
|
_ => {}
|
|
|
|
}
|
|
|
|
}
|
2019-12-07 06:24:58 +00:00
|
|
|
} else {
|
|
|
|
yield Ok(tagged_contents)
|
2019-12-07 03:46:05 +00:00
|
|
|
}
|
|
|
|
}
|
2019-11-24 22:19:12 +00:00
|
|
|
CommandAction::EnterHelpShell(value) => {
|
|
|
|
match value {
|
|
|
|
Value {
|
|
|
|
value: UntaggedValue::Primitive(Primitive::String(cmd)),
|
|
|
|
tag,
|
|
|
|
} => {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.shell_manager.insert_at_current(Box::new(
|
2019-11-24 22:19:12 +00:00
|
|
|
HelpShell::for_command(
|
2019-12-04 19:52:31 +00:00
|
|
|
UntaggedValue::string(cmd).into_value(tag),
|
2019-11-24 22:19:12 +00:00
|
|
|
&context.registry(),
|
2020-01-02 17:51:20 +00:00
|
|
|
)?,
|
2019-11-24 22:19:12 +00:00
|
|
|
));
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
2019-11-24 22:19:12 +00:00
|
|
|
_ => {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.shell_manager.insert_at_current(Box::new(
|
2020-01-03 21:11:21 +00:00
|
|
|
HelpShell::index(&context.registry())?,
|
2019-11-24 22:19:12 +00:00
|
|
|
));
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2019-11-24 22:19:12 +00:00
|
|
|
CommandAction::EnterValueShell(value) => {
|
|
|
|
context
|
|
|
|
.shell_manager
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
.insert_at_current(Box::new(ValueShell::new(value)));
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
CommandAction::EnterShell(location) => {
|
|
|
|
context.shell_manager.insert_at_current(Box::new(
|
2020-01-04 06:44:17 +00:00
|
|
|
FilesystemShell::with_location(location, context.registry().clone()),
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
));
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
2020-04-20 06:41:51 +00:00
|
|
|
CommandAction::AddAlias(name, args, block) => {
|
2020-04-15 05:43:23 +00:00
|
|
|
context.add_commands(vec![
|
|
|
|
per_item_command(AliasCommand::new(
|
|
|
|
name,
|
|
|
|
args,
|
2020-04-20 06:41:51 +00:00
|
|
|
block,
|
2020-04-15 05:43:23 +00:00
|
|
|
))
|
|
|
|
]);
|
|
|
|
}
|
2019-11-24 22:19:12 +00:00
|
|
|
CommandAction::PreviousShell => {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.shell_manager.prev();
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
CommandAction::NextShell => {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.shell_manager.next();
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
CommandAction::LeaveShell => {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.shell_manager.remove_at_current();
|
|
|
|
if context.shell_manager.is_empty() {
|
2019-11-24 22:19:12 +00:00
|
|
|
std::process::exit(0); // TODO: save history.txt
|
|
|
|
}
|
|
|
|
}
|
|
|
|
},
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2020-02-09 02:24:33 +00:00
|
|
|
Ok(ReturnSuccess::Value(Value {
|
|
|
|
value: UntaggedValue::Error(err),
|
|
|
|
..
|
|
|
|
})) => {
|
2020-04-16 04:25:24 +00:00
|
|
|
context.error(err.clone());
|
|
|
|
yield Err(err);
|
2020-02-09 02:24:33 +00:00
|
|
|
break;
|
|
|
|
}
|
|
|
|
|
2019-11-24 22:19:12 +00:00
|
|
|
Ok(ReturnSuccess::Value(v)) => {
|
|
|
|
yielded = true;
|
|
|
|
yield Ok(v);
|
|
|
|
}
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2019-11-24 22:19:12 +00:00
|
|
|
Ok(ReturnSuccess::DebugValue(v)) => {
|
|
|
|
yielded = true;
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2019-11-24 22:19:12 +00:00
|
|
|
let doc = PrettyDebug::pretty_doc(&v);
|
|
|
|
let mut buffer = termcolor::Buffer::ansi();
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2020-01-02 05:24:41 +00:00
|
|
|
let _ = doc.render_raw(
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.with_host(|host| host.width() - 5),
|
2019-11-24 22:19:12 +00:00
|
|
|
&mut nu_source::TermColored::new(&mut buffer),
|
2020-01-02 05:24:41 +00:00
|
|
|
);
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2019-11-24 22:19:12 +00:00
|
|
|
let value = String::from_utf8_lossy(buffer.as_slice());
|
2019-11-24 22:19:12 +00:00
|
|
|
|
2019-12-04 19:52:31 +00:00
|
|
|
yield Ok(UntaggedValue::string(value).into_untagged_value())
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
Err(err) => {
|
Restructure and streamline token expansion (#1123)
Restructure and streamline token expansion
The purpose of this commit is to streamline the token expansion code, by
removing aspects of the code that are no longer relevant, removing
pointless duplication, and eliminating the need to pass the same
arguments to `expand_syntax`.
The first big-picture change in this commit is that instead of a handful
of `expand_` functions, which take a TokensIterator and ExpandContext, a
smaller number of methods on the `TokensIterator` do the same job.
The second big-picture change in this commit is fully eliminating the
coloring traits, making coloring a responsibility of the base expansion
implementations. This also means that the coloring tracer is merged into
the expansion tracer, so you can follow a single expansion and see how
the expansion process produced colored tokens.
One side effect of this change is that the expander itself is marginally
more error-correcting. The error correction works by switching from
structured expansion to `BackoffColoringMode` when an unexpected token
is found, which guarantees that all spans of the source are colored, but
may not be the most optimal error recovery strategy.
That said, because `BackoffColoringMode` only extends as far as a
closing delimiter (`)`, `]`, `}`) or pipe (`|`), it does result in
fairly granular correction strategy.
The current code still produces an `Err` (plus a complete list of
colored shapes) from the parsing process if any errors are encountered,
but this could easily be addressed now that the underlying expansion is
error-correcting.
This commit also colors any spans that are syntax errors in red, and
causes the parser to include some additional information about what
tokens were expected at any given point where an error was encountered,
so that completions and hinting could be more robust in the future.
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
Co-authored-by: Andrés N. Robalino <andres@androbtech.com>
2020-01-21 22:45:03 +00:00
|
|
|
context.error(err);
|
2019-11-24 22:19:12 +00:00
|
|
|
break;
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
}
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|
|
|
|
};
|
2019-11-24 22:19:12 +00:00
|
|
|
|
Move external closer to internal (#1611)
* Refactor InputStream and affected commands.
First, making `values` private and leaning on the `Stream` implementation makes
consumes of `InputStream` less likely to have to change in the future, if we
change what an `InputStream` is internally.
Second, we're dropping `Option<InputStream>` as the input to pipelines,
internals, and externals. Instead, `InputStream.is_empty` can be used to check
for "emptiness". Empty streams are typically only ever used as the first input
to a pipeline.
* Add run_external internal command.
We want to push external commands closer to internal commands, eventually
eliminating the concept of "external" completely. This means we can consolidate
a couple of things:
- Variable evaluation (for example, `$it`, `$nu`, alias vars)
- Behaviour of whole stream vs per-item external execution
It should also make it easier for us to start introducing argument signatures
for external commands,
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
* Update run_external.rs
Co-authored-by: Jonathan Turner <jonathandturner@users.noreply.github.com>
2020-04-20 03:30:44 +00:00
|
|
|
Ok(stream.to_input_stream())
|
2019-11-24 22:19:12 +00:00
|
|
|
}
|