# Nushell Core-Team meeting 2022-05-25

## Attendees

- andres
- michael
- reilly
- jt
- jakub
- fernando
- sholderbach (note taking)
- darren

## Brief topics

- incoming issues after the new release
- **Fixed** Win version
- Are overlays and hooks compatible?
- Deactivation rules for the end of the blocks/hook blocks?
- Missing docs
- Hooks are not yet documented in the main documentation.
- Enable hooks to modify environment properly
- String of code vs. blocks that are able to transparently affect an environment.
- new syntax for that? (See discussion of options [below](#Syntax-Ideas))
- Would the new block be usable for other things (like in if for setting env variable)

## Syntax Ideas
**Q:** *how to modify the "immutable" environment and more with code.*

We already have implicit variables like `$nu`, `$env`, etc. What if you could say which is mutable?

### Fancy parameters

def bar [mutable env, mutable overlays, x, y] {
    //...
    $overlays
    
    $env
}


# old style
def-env bar [] {

}

def bar [mutable env] {

}

### "Type signature"
Fernando's version

def foo [x, y] 
    uses mutable env, mutable overlays
{

  # Pro: explicit syntax
  # Con: Maybe too focussed on defs
}

def foo [x, y]
    keeps env, overlay
{
    
}

### Block focussed

def foo [x, y] 
{
    keeps env, overlay

    let-env foo = bar
}

# extra signature part of the block
def foo [x, y] ![env, overlay] {
    let-env foo = bar
}

if true ![env, overlay] {
    foo
}

if foo {
    @env
    @overlays
    # This would have the advantage of being part of the block
    
    let-env BAR = "bar"
}

if  2 > 1 {|@env, @over, it| "foo" } else { "bar" }

### Call site focussed

updates env, overlay { foo a b c }

foo a b c @env @overlay

if @env  2 > 1 { "foo" } else { "bar" }

# Other topics

## SQlite history for reedline/UI for that
- Should be possible to land soon.
- Error handling of reedline should be improved.
- TODO: Porting the `history` command to read with the same implementation from the same file
- Status not yet landed

## How bash do we want to be

JT reports from the trenches hacking on jakt with AK. Frequent usage of some bash typical glyphs shows which value they can add in just quick typing.

`&&` for shortcircuiting conditional execution only if the first part succeeds.
We already have the most important ones for history recalling `!!`, `!$`

Maybe non goals `2>&1`

>err,out>

Good decision criterion if we want to accept a bash feature: Is the muscle memory applied in a "I don't think about it" automatic fashion when typing quickly (e.g. one-line command), vs do I need to pause for a moment to solve a specific problem. Here reading and understanding it later is important and we might want to be explicit in our nushell world.

# Open PR's discussed:

- Handling of STDERR/STDOUT (https://github.com/nushell/nushell/pull/5608)
- Pr started out to fix stderr handling `| complete`
- They are introducing `|&` as completely separate bash compatible syntax. Carrying stderr explicitly

**Decision:**
- Ask them to contribute the fix to complete and hold off on syntax (and pipeline) changes for further discussion. We want to solve the problems first, make it convenient in the next step.