Skip to content

Latest commit

 

History

History
137 lines (95 loc) · 4.32 KB

08-28-2020.md

File metadata and controls

137 lines (95 loc) · 4.32 KB

28th Aug, 2020

Nushell - Everything is Data?

  • Slogan and motto, how should we use it?
  • "Shell for the GitHub era" sounded marketing, but wasn't a good fit
  • "Everything is data" is pretty cool
    • "Everything is different" as the subtitle (not like any shell I've ever used)

Run-up to 0.19, what's needed?

  • Get back parity with the previous completion system. Eg) path to executable in the command position
  • ..\ stall during completion

Completions

  • Feels like we're a net postive position for completions for 0.19 (modulo fix above)
  • Category of a suggestion
    • Actually tag what the results are, like "these are internals" "these are externals" etc
    • Also with docs on the results so we can show more
  • For 0.20: given a command and the name of the argument (and maybe partial string) give the results

Infinity

  • Do we want to try to fix inf? IEEE standard approach to inf and NaN

Book

  • The book needs a lot of updating for the last few releases
  • Should we make it easier to see when we need to update the book?

Parsing

Spans

  • HIR expansion steps (like it-expansion) doesn't always set Span correctly
`foo; bar`
 ^^^^^^^^ span for the first `foo` appear to be incorrect
  • A/J will chat about this offline

Completions

  • How much do we want to lean on the parser? Vs making the completion engine responsible?
  • What about the case where something is missing?
  • We may have to experiment and see what feels best. Let's build up the heuristics in the completion engine first, and then make them more general.

Handling $it and argument invocation too

  • We should write more tests. Lots more
  • We should aim for natural workflow and not slow down to think of subtlety

Update with a block

ls | update foo ${my command}

What about invocation?

ls | update foo $(my command)

Then what about?

ls | update foo $( echo {my command} )

What would this do?

ls | echo $(first | echo $it)

String interpolation

Currently:

  • format "{}"

  • {{}}

  • Should we pick a single interpolation style?

  • ls | $"this is the format {$it.name} string"

  • $name.exe

    • In other shells, it expands the $name and then appends .exe.

  • dotnet style: $"{name}.exe"

  • What if we supported: ${name}.exe and then assumed the backticks?

    • $(name).exe - gives you the exe column out of the invocation

  • Another option: {name}.exe. What we have now so you could use { instead of {{

    • {= $(char lcurly)} might be too big. Let's clean this up.

  • What are the delimiters and what are the rules for how we expand so

  • "$(anything)"

  • Other shells use: for variable interpolation "${}" or $foo.bar

  • Let's look back through the help channel and see how people are trying to do things

  • Takeaway: Feels like we have to quote something to have string interpolation. Never on bare form.

  • Do interpolation rules differ between ", ', and `?

  • Should we remove the format command?

Config system

  • If we could possibly rewrite:
    • Configuration main set of properties and methods
    • Statically accessible as a singleton
    • Can we model something similar in Rust?

Questions:

  • If we update via config set we can also update the file, like we do today. No change?

  • Do we detect if the file has been updated outside of config?

  • Please let it be possible to use config set and not destroy file comments

  • We may let it live in the context. Knowing that this would make context even bigger, but maybe worthwhile.

  • One possible path:

    • Arc<RwLock> (focused on readers)
    • Whoever needs config, grab read lock and we'll be fine
    • config set grabs a write lock and then updates the in-progress configuration
    • We could optionally inotify to get if the config file was updated
    • Environment merging is something to keep in mind
    • cargo test shouldn't read the config.toml. We should be able to have tests to configure how the config file is loaded, and from where

Testing

  • Currently we're using nu! which invokes the actual Nu to run the test
  • We could update the test harness to call into the API now too
  • We could move some tests to the faster approach and some to the end-to-end style
  • End-to-end tests could move to their own crate
  • The "test pyramid" of light and heavy styles of tests, including different types of integration tests
  • We need a better way to construct Nu values