zoxide init ion

[shouze]

Would be nice to support ion shell too 👼.

[ajeetdsouza]

Ion definitely does look interesting, but I'm not familiar with the syntax. Is there a mechanism for prompt/pwd hooks?

If you can make a PR adding Ion support, I would be happy to merge it!

[kolia]

ion currently does not allow functions to be called with different numbers of args, unless the args are passed in as an array. So in practice, you'd need to write z [ query ] instead of z query.

With that caveat, here is an ion script that would be equivalent to the output of zoxide init for other shells:

fn _z_cd argv:[str]
    cd @argv
    exists -s _ZO_ECHO && echo $PWD
end

fn z argv:[str]
    match @argv
        case [ - ]
            _z_cd [ @argv ]
        case _
            let result = $(zoxide query @argv)
            if test -d $result
                _z_cd [ $result ]
            else if test -n $result
                echo $result
            end
    end
end

alias zi='z -i'
alias za='zoxide add'
alias zq='zoxide query'
alias zr='zoxide remove'

Adding a hook that calls zoxide add would require adding zoxide add to the fn PROMPT function definition, which is how ion lets users customize their prompt. Not sure how one would set that hook up by running eval $(zoxide init ion), best is probably to ask users to add zoxide add to their PROMPT by hand. There is also no way to call zoxide add when PWD gets modified, as far as I can tell.

[ajeetdsouza]

@kolia I had a look at ion today. I'm not a fan of changing the z syntax specially for ion, and having the user specifically add zoxide add to their shell also seems less-than-ideal.

However, given that ion doesn't try to imitate POSIX in any way, I can understand this. There doesn't appear to be a better way to do this at the moment either, and your implementation does work well - so do feel free to create a PR with these changes!

[kolia]

Sure I could make a PR.

I’ve also opened an issue for ion https://gitlab.redox-os.org/redox-os/ion/issues/962, alternatively we could wait and see if someone picks up on it.

[ajeetdsouza]

Yes, I too think waiting is a good idea for now. We can pick this up later if they decide against implementing variadic functions.

Thank you for your work on this!

[ahkrr]

@kolia @ajeetdsouza regarding the issue of adding the _zoxide_hook to the HOOK_PROMPT
one solution that currently works for me is

fn _zoxide_hook
    zoxide add
end

if not matches $PROMPT '.*?_zoxide_hook.*?'
	let PROMPT ::= "\$(_zoxide_hook)"
end

[ajeetdsouza]

@ahkrr, from what I've read, PROMPT could either be a variable or a function, so both cases need to be handled.

[ahkrr]

@ajeetdsouza I have no idea what to do if a user supplied a fn PROMPT function, maybe encourage the user to work with the variable instead.
Another problem aside from the variadic functions is this:

For me in ion echo $(zoxide query -i) and echo $(fzf)
don't interactively print to the terminal. It is executing in the background and after entering a string and pressing enter you get the result but I wouldn't call that interactive.
echo $(sk) this works interactively. sk is basically a rust version of fzf

A this point I also think that it is problematic to implement ion support. For the ones that are interested in ion, at this point in time they should probaly put this manually into their shell.

[matu3ba]

Let me summarize what to implement in the ion REPL as a sort of plan, once we get the grammar formally defined and the parser rewritten in a more robust way.
I would like to enforce readability in scripts, but I am not sure how to archive this at best without exploding complexity.

1. REPL must differentiate between status line, cursor symbol and cursor field.
2. Ideally REPL can properly handle background processes with counters, so one does not need ugly hacks. (Background processes are currently broken.)
3. I think hooks are a poor abstraction, when you know when things will happen. When we get working function returns, pwd can be used with the path before and after changing directories.
4. Aliased functions (of the initrc and other sourced files) must start with capital letters, if they are needed (I am not convinced yet).

[ajeetdsouza]

Hey @matu3ba, thanks for the update!

I think hooks are a poor abstraction

How so? I didn't exactly understand the alternative you proposed, could you elaborate?

I am not sure how to achieve this at best without exploding complexity

Admittedly, designing a shell is much harder than designing a programming language, because you have to ensure that it's easy enough for anyone to read/write, concise enough to be able to do a lot of work in a single line of code, and yet powerful enough to write scripts with.

I have no experience with programming language design, but I'm interested - could you explain why the mut keyword was introduced, and why references are necessary?

[matu3ba]

Hey @matu3ba, thanks for the update!

I think hooks are a poor abstraction

How so? I didn't exactly understand the alternative you proposed, could you elaborate?

You want to (over)write the shell configuration to have defined entry- and exit-points from what the shell is doing (on user keypress), since that is way simpler, has less delay etc.

I am not sure how to achieve this at best without exploding complexity

Admittedly, designing a shell is much harder than designing a programming language, because you have to ensure that it's easy enough for anyone to read/write, concise enough to be able to do a lot of work in a single line of code, and yet powerful enough to write scripts with.

And fast for the use case (batch processing = nu or individual processing = ion). Other shells use more tradeoffs (zsh, bash etc), but are still complex beasts. Or they are okay with being slower (fish). Dash is comparable (with less functionality), but it is very difficult to safely optimise C code (and you get some parsing+evaluation overhead of POSIX shell requirements).

I have no experience with programming language design, but I'm interested - could you explain why the mut keyword was introduced, and why references are necessary?

Copy-assign is always slower, since you need to allocate a not efficiently precomputable space (depends on context of execution). Hence you want mut and for safe usage of other accessible scopes references for functions.

Personally, I would also like to restrict the access to other scopes, but that are some rules for the longer future to do. And thats too slow+complex to do in every parsing for execution. Another, way simpler, parser could be used for that.

[ajeetdsouza]

Hm, doesn't the absence of let imply mut? Or has it been added to make mutations more explicit?

[matu3ba]

Hm, doesn't the absence of let imply mut? Or has it been added to make mutations more explicit?

let can shadow variables in functions, like in the following:

let var:int = 1;
let stuff:int = 2;
  fn testme
    let var:int = 3;
    mut stuff = 42;
    echo $var
  end
testme
echo $var
echo $stuff

3
1
42

We could also use local etc, but thats too long and variables should be ALWAYS local (or explicitly written global environment variables).

[ajeetdsouza]

I'm closing this issue for now. The related Ion issue (https://gitlab.redox-os.org/redox-os/ion/-/issues/834) has been open 4 years without a conclusion, so it's unlikely we'll be able to support it in the near future.

Feel free to reopen / create a new issue once Ion adds enough functionality / stability to support something like this.