# Nushell core team meeting 2023-02-01

## Attendees

- Andres
- Darren
- JT
- Jakub
- WindSoilder
- Stefan
- Michael
- BobHy

## Agenda

- Release `0.75`
- Post release comments
- Unintended consequence of auto-trimming (see example below)
- `--ignore` semantics and the `do` + `complete` weirdness.
- Proposal: Remove overloading until we have a complete design ready
- requires dataframes considerations: could be moved to a module which can be applied as overlay on-demand
- which leads to: Should plugins be modules?

# Discussed Topics

## Release 0.75

Smooth sailing apart from winget

`release_pkg.nu` script is misbehaving

Darren reached out to Justin who wrote this script

## Auto trimming of quotes in arguments to `nu`

Auto-trimming issue:

> open foo.nu
def main [x] { print $x }

> nu foo.nu '(^ls)'
...prints native ls output

Danger zone: regular expressions look like subexpressions (that start by executing commands)
e.g. `(hello|world)`

BobHy: working on the error handling of syntax errors through the parser.
Bare string handling happens in many different places and tracking down errors there is really hard.

Also challenges in assigning types vs allowing numbers in command names (or possibly bare words) e.g. `7z`

Current state: we have type directed parsing with a large range of edge cases that have to be tracked through multiple stages (also duplication in the typechecking)

Big Problem: we are very context-sensitive and creating grammars and syntax plugins is hard or near impossible to get right.

Can we be more local to really constrain us in a helpful way.

Going back to the issue:

can we make the parser dumber in such situations? Ensure it remains a string (with quotes or maybe as an explicit `nu` command that knowns about types)

We are probably never able to fully solve the risk that a non-nu shell will strip quotes.

Can we declare best practices that are easy to remember for users.
And make it as seemless as possible from nushell.

Jakub can we filter based on what is currently "constevalable" i.e. basically literals

## Big bomb EVAL

See discord discussion with `broot` (also all the environment managers :P)

https://discord.com/channels/601130461678272522/759901889978040331/1070257365783433217

Different behavior between in the REPL and inside of scripts (REPL effectively allows modification of engine state parts that are considered constant in a script)

Jakub raises the pitchforks against eval
- Module systems/overlays added more comfort
- Not having eval is great for IDE experience
- SECURITY

Can we have eval lite?

## `do`/`complete` complications

problem our pipelinedata is not fully compatible with the existing POSIX model of `STDOUT`/`STDERR` and exit codes for error handling

Piping to `complete` is weird magic

`do` has ignore options for "all errors"/"program errors (external)"/"shell errors"

`try` `catch` is still around

## Shell/scripting language balance

https://github.com/nushell/nushell/discussions/7899#discussioncomment-4843817

Test: does a change make writing a one-liner easier or harder

- is it not painful to write
- is it going with a flow
- will it compose effortless

surrounding a pipeline stage with `try`/`catch` after you realize something could fail, feels fingertwisting

Jakub: can we have some syntax constructs that don't require wrapping with `{}` all the time

JT: keep the spirit of the `ls | where size > 10MB` base example

## PR's