Commit Graph

6996 Commits

Author SHA1 Message Date
af2ec60980 Shell.nix cleanup. 2019-10-11 21:13:00 +02:00
f0ca0312f3 Adds racer, formats shell.nix 2019-10-11 19:06:24 +02:00
3317b137e5 Merge pull request #728 from nushell/better-pseudo-blocks
[DON'T MERGE] Overhaul the expansion system
2019-10-11 17:28:33 +13:00
c2c10e2bc0 Overhaul the coloring system
This commit replaces the previous naive coloring system with a coloring
system that is more aligned with the parser.

The main benefit of this change is that it allows us to use parsing
rules to decide how to color tokens.

For example, consider the following syntax:

```
$ ps | where cpu > 10
```

Ideally, we could color `cpu` like a column name and not a string,
because `cpu > 10` is a shorthand block syntax that expands to
`{ $it.cpu > 10 }`.

The way that we know that it's a shorthand block is that the `where`
command declares that its first parameter is a `SyntaxShape::Block`,
which allows the shorthand block form.

In order to accomplish this, we need to color the tokens in a way that
corresponds to their expanded semantics, which means that high-fidelity
coloring requires expansion.

This commit adds a `ColorSyntax` trait that corresponds to the
`ExpandExpression` trait. The semantics are fairly similar, with a few
differences.

First `ExpandExpression` consumes N tokens and returns a single
`hir::Expression`. `ColorSyntax` consumes N tokens and writes M
`FlatShape` tokens to the output.

Concretely, for syntax like `[1 2 3]`

- `ExpandExpression` takes a single token node and produces a single
  `hir::Expression`
- `ColorSyntax` takes the same token node and emits 7 `FlatShape`s
  (open delimiter, int, whitespace, int, whitespace, int, close
  delimiter)

Second, `ColorSyntax` is more willing to plow through failures than
`ExpandExpression`.

In particular, consider syntax like

```
$ ps | where cpu >
```

In this case

- `ExpandExpression` will see that the `where` command is expecting a
  block, see that it's not a literal block and try to parse it as a
  shorthand block. It will successfully find a member followed by an
  infix operator, but not a following expression. That means that the
  entire pipeline part fails to parse and is a syntax error.
- `ColorSyntax` will also try to parse it as a shorthand block and
  ultimately fail, but it will fall back to "backoff coloring mode",
  which parsing any unidentified tokens in an unfallible, simple way. In
  this case, `cpu` will color as a string and `>` will color as an
  operator.

Finally, it's very important that coloring a pipeline infallibly colors
the entire string, doesn't fail, and doesn't get stuck in an infinite
loop.

In order to accomplish this, this PR separates `ColorSyntax`, which is
infallible from `FallibleColorSyntax`, which might fail. This allows the
type system to let us know if our coloring rules bottom out at at an
infallible rule.

It's not perfect: it's still possible for the coloring process to get
stuck or consume tokens non-atomically. I intend to reduce the
opportunity for those problems in a future commit. In the meantime, the
current system catches a number of mistakes (like trying to use a
fallible coloring rule in a loop without thinking about the possibility
that it will never terminate).
2019-10-10 19:30:04 -07:00
d2eb6f6646 Adds .envrc and shell.nix 2019-10-10 21:23:12 +02:00
1ad9d6f199 Overhaul the expansion system
The main thrust of this (very large) commit is an overhaul of the
expansion system.

The parsing pipeline is:

- Lightly parse the source file for atoms, basic delimiters and pipeline
  structure into a token tree
- Expand the token tree into a HIR (high-level intermediate
  representation) based upon the baseline syntax rules for expressions
  and the syntactic shape of commands.

Somewhat non-traditionally, nu doesn't have an AST at all. It goes
directly from the token tree, which doesn't represent many important
distinctions (like the difference between `hello` and `5KB`) directly
into a high-level representation that doesn't have a direct
correspondence to the source code.

At a high level, nu commands work like macros, in the sense that the
syntactic shape of the invocation of a command depends on the
definition of a command.

However, commands do not have the ability to perform unrestricted
expansions of the token tree. Instead, they describe their arguments in
terms of syntactic shapes, and the expander expands the token tree into
HIR based upon that definition.

For example, the `where` command says that it takes a block as its first
required argument, and the description of the block syntactic shape
expands the syntax `cpu > 10` into HIR that represents
`{ $it.cpu > 10 }`.

This commit overhauls that system so that the syntactic shapes are
described in terms of a few new traits (`ExpandSyntax` and
`ExpandExpression` are the primary ones) that are more composable than
the previous system.

The first big win of this new system is the addition of the `ColumnPath`
shape, which looks like `cpu."max ghz"` or `package.version`.
Previously, while a variable path could look like `$it.cpu."max ghz"`,
the tail of a variable path could not be easily reused in other
contexts. Now, that tail is its own syntactic shape, and it can be used
as part of a command's signature.

This cleans up commands like `inc`, `add` and `edit` as well as
shorthand blocks, which can now look like `| where cpu."max ghz" > 10`
2019-10-10 08:27:51 -07:00
f8d337ad29 chore: omit the entire git.rs file when starship is used 2019-10-09 08:42:46 +01:00
47150efc14 chore: switch starship dependency back to the main one 2019-10-09 08:36:55 +01:00
3e14de158b fix(ci): can't push to quay.io (#1)
* ci(github): lowercase ${{ github.actor }}

* ci(github): fix robot username

* fix(ci): fix tag name on suffixed version
2019-10-09 09:58:49 +07:00
e18892000a Merge pull request #802 from twe4ked/improve-cd-docs
Improve cd docs
2019-10-08 20:20:28 -05:00
c8671c719f fix: addressed unused imports and dead code 2019-10-08 21:50:28 +01:00
0412c3a2f8 fix: remove the additional characters from highlighter
This resolves a small integration issue that would make custom prompts problematic (if they are implemented). The approach was to use the highlighter implementation in Helper to insert colour codes to the prompt however it heavily relies on the prompt being in a specific format, ending with a `> ` sequence. However, this should really be the job of the prompt itself not the presentation layer.

For now, I've simply stripped off the additional `> ` characters and passed in just the prompt itself without slicing off the last two characters. I moved the `\x1b[m` control sequence to the prompt creation in `cli.rs` as this feels like the more logical home for controlling what the prompt looks like. I can think of better ways to do this in future but this should be a fine solution for now.

In future it would probably make sense to completely separate prompts (be it, internal or external) from this code so it can be configured as an isolated piece of code.
2019-10-08 21:39:58 +01:00
ef3e8eb778 fix: update Cargo.lock with correct hash for starship fork 2019-10-08 21:16:52 +01:00
fb8cfeb70d feat: starship prompt
Kind of touches on #356 by integrating the Starship prompt directly into the shell.

Not finished yet and has surfaced a potential bug in rustyline anyway. It depends on https://github.com/starship/starship/pull/509 being merged so the Starship prompt can be used as a library.

I could have tackled #356 completely and implemented a full custom prompt feature but I felt this was a simpler approach given that Starship is both written in Rust so shelling out isn't necessary and it already has a bunch of useful features built in.

However, I would understand if it would be preferable to just scrap integrating Starship directly and instead implement a custom prompt system which would facilitate simply shelling out to Starship.
2019-10-08 16:25:12 +01:00
4d70255696 Add documentation for cd - 2019-10-08 18:32:42 +11:00
77c34acb03 Whitespace 2019-10-08 18:32:42 +11:00
e72bc8ea8b Remove unneeded - 2019-10-08 18:32:39 +11:00
a882e640e4 Merge pull request #793 from chhetripradeep/pchhetri/enter
Add documentation for the enter command
2019-10-08 06:02:49 +13:00
c09d866a77 Add documentation for the enter command 2019-10-07 23:21:58 +08:00
4467e59122 Merge pull request #792 from chhetripradeep/pchhetri/open
Add documentation for the open command
2019-10-07 11:17:28 +11:00
9c096d320a Merge pull request #797 from chhetripradeep/pchhetri/fetch
Add documentation for the fetch command
2019-10-07 11:16:36 +11:00
93ae5043cc ci(github): change REGISTRY to quay.io 2019-10-07 03:53:07 +07:00
b134394319 ci(github): refactor docker related run scripts 2019-10-07 03:14:51 +07:00
b163775112 ci(github): install cross from release page
Instead of compiling `cross` via `cargo install`,
downloading binary executable from release page will speedup the CI
2019-10-07 02:53:23 +07:00
8bd035f51d ci(github): renew trigger definition
There is an update in workflow syntax docs
https://help.github.com/en/articles/workflow-syntax-for-github-actions#filter-pattern-cheat-sheet
2019-10-07 02:51:35 +07:00
9f15017032 Add documentation for the fetch command 2019-10-07 02:17:57 +08:00
81fec11f88 Add documentation for the open command 2019-10-07 02:08:20 +08:00
8a6a688131 Merge pull request #795 from chhetripradeep/pchhetri/inc
Add documentation for the inc command
2019-10-07 04:35:08 +11:00
77a4de31fa Merge pull request #794 from chhetripradeep/pchhetri/sys
Add documentation for the sys command
2019-10-07 04:33:51 +11:00
09e88d127e Merge pull request #791 from chhetripradeep/pchhetri/trim
Add documentation for the trim command
2019-10-07 04:30:52 +11:00
7ff5734d5d Add documentation for the inc command 2019-10-06 23:30:52 +08:00
1d19595996 Add documentation for the sys command 2019-10-06 23:20:48 +08:00
7d115da782 Add documentation for the trim command 2019-10-06 22:35:38 +08:00
b066775630 Merge pull request #789 from cristicismas/patch-1
Update cd.md to look better
2019-10-04 16:24:42 -05:00
8bb6bcb6eb Merge pull request #790 from mfarberbrodsky/add-nth-docs
Add documentation for nth command
2019-10-04 16:24:06 -05:00
20031861b9 Add documentation for nth command 2019-10-04 17:37:11 +03:00
eb297d3b8f Update cd.md to look better 2019-10-04 15:10:46 +03:00
8faa0126eb Merge pull request #784 from coolshaurya/to-dash-sth-docs
Added docs for most of the to-sth commands
2019-10-03 21:47:00 -05:00
6aec03708f Fix minor typo 2019-10-04 06:44:45 +05:30
2f7b1e4282 Added improvements suggested by @andrasio
Added `open file.sth | to-sth` type examples
Also did a format conversion example with `open jonathon.xml | to-json` in to-json.md
2019-10-04 06:40:16 +05:30
7492131142 Merge pull request #770 from rnxpyke/master
add regex match plugin
2019-10-03 14:20:41 -05:00
3c6ee63e59 Merge pull request #777 from JonnyWalker81/fix-get-panic
Attempt at fixing `get` command panic.
2019-10-03 14:02:51 -05:00
45ad18f654 Merge pull request #785 from Charles-Schleich/master
Created Docs for env command
2019-10-03 14:00:51 -05:00
01829f04d5 Merge pull request #783 from notryanb/document-last
add documentation for the last command
2019-10-03 13:59:41 -05:00
cc1c471877 Merge pull request #779 from pema99/lines-doc
Add documentation for lines
2019-10-03 13:58:30 -05:00
de14f9fce8 Merge pull request #781 from coolshaurya/add-command-docs
Create docs for add command
2019-10-03 13:38:11 -05:00
6c3ed1dbc2 Merge pull request #782 from coolshaurya/docs-edit-command
Create docs for edit command
2019-10-03 13:37:49 -05:00
cf0fa3141a Created Docs for env command 2019-10-03 20:13:22 +02:00
539e232f3c Added docs for most of the to-sth commands
Partial fix of issue #711
Docs for the following commands were added -
to-csv
to-json
to-toml
to-tsv
to-url
to-yaml

Docs for to-db , to-bson , to-sqlite have not been added as I don't recognize and understand those formats.
2019-10-03 19:07:48 +05:30
9ed889ccbb fix grammar 2019-10-03 08:18:51 -04:00