Cannot install when current directory is not $HOME

[Aloxaf]

You always create impressive projects. 👍

Full log:

[root@261341dba2ed /]# cd /usr/
[root@261341dba2ed usr]# if command -v curl >/dev/null 2>&1; then
>   sh -c "$(curl -fsSL https://raw.githubusercontent.com/romkatv/zsh4humans/v4/install)"
> else
>   sh -c "$(wget -O- https://raw.githubusercontent.com/romkatv/zsh4humans/v4/install)"
> fi
Greetings, Human!

What kind of keyboard are you using?

  (1)  Mac. It has Option key(s) and does not have Backspace.
  (2)  PC.  It has Backspace key(s) and does not have Option.
  (q)  Quit and do nothing.

Choice [12q]: 1
What keybindings do you prefer?

  (1)  Standard. I delete characters with Delete key.
  (2)  Like in vi. I delete characters with X key in command mode.
  (q)  Quit and do nothing.

Choice [12q]: 1
You have the following Zsh startup files:

    ~/.zshenv
    ~/.zshrc

What should I do with them?

  (1)  Move them to ~/zsh-backup/20201023-135540. Recommended.
  (2)  Delete them.
  (q)  Quit and do nothing.

Choice [12q]: 1
Settings up Zsh For Humans...

z4h: fetching z4h.zsh from github.com/romkatv/zsh4humans
z4h: generating ~/.zshenv
z4h: generating ~/.zshrc
cp: cannot stat '.zshenv': No such file or directory

[romkatv]

Thanks for the report! Fixed.

---

By the way, there are a few things in zsh4humans that you might want to copy over to fzf-tab. At some point I wanted to upstream them but when I stopped using fzf-tab it was harder to justify the time cost for doing so. It's also hard work because fzf-tab has a lot of users, so backward compatibility is a thing.

---

There is a stream-based file colorized that's very fast. You can try it within z4h by pasting this:

# usage: colorize context
function colorize() {
  [[ -o list_types ]]
  local -i list_types=$((! $?))
  -z4h-set-list-colors "$1" $list_types
  local -i list_colors=$((! $?))
  -z4h-present-files $list_colors $list_types
}

And running it like this:

find . | colorize :complete:ls::

This outputs two columns separated by \0. The first is the original file, the second is colorized.

---

The way you can customize fzf is nice. See fzf-bindings, fzf-flags and fzf-command in #35 (comment).

---

When completing files, directories are recursed automatically. These completions appear below the normal ones.

---

Suffix match in fzf (e.g., .md$ to list markdown files) works as expected. In fzf-tab it doesn't work due to junegunn/fzf#2099.

---

There is no zle -R when completing. This makes it look much better on slow terminals.

---

Tab inserts unambiguous prefix automatically. If you set auto_menu option (it's unset by default at the bottom of .zshrc), fzf will open automatically without requiring a second tab.

---

The query in fzf is based on the command line and not on the longest prefix among completion candidates. This way, if you have auto_menu unset, you don't need to look at the query because it's always what you've already typed in zle.

---

The support for groups is completely lost though. It's possible to add them but I couldn't design a UI that would work well.

[romkatv]

One more thing. If you'd like to switch to zsh4humans, check out #35. It's super long but has a ton of useful info for advanced users. The default .zshrc and the docs are aimed at the average user but there is much more to z4h than that.

At the very least please read #35 (comment). I'd love to have you onboard and would welcome feedback and bug reports from you!

[Aloxaf]

By the way, there are a few things in zsh4humans that you might want to copy over to fzf-tab. At some point I wanted to upstream them but when I stopped using fzf-tab it was harder to justify the time cost for doing so. It's also hard work because fzf-tab has a lot of users, so backward compatibility is a thing.

Yes. I am very interested in it. But this may take much time since I have lots of things to do but little free time.

---

There is a stream-based file colorized that's very fast. You can try it within z4h by pasting this:

# usage: colorize context
function colorize() {
  [[ -o list_types ]]
  local -i list_types=$((! $?))
  -z4h-set-list-colors "$1" $list_types
  local -i list_colors=$((! $?))
  -z4h-present-files $list_colors $list_types
}

And running it like this:

find . | colorize :complete:ls::

This outputs two columns separated by \0. The first is the original file, the second is colorized.

That's amazing. I will look into it later to check whether I can replace zsh-ls-colors with it.

---

The way you can customize fzf is nice. See fzf-bindings, fzf-flags and fzf-command in #35 (comment).

Nice design! I always regret putting all parameters together, it exposes all parameters to users and makes it hard for me to add/remove parameters.

---

When completing files, directories are recursed automatically. These completions appear below the normal ones.

I'd like to use fd + zsh-tmux-capture here. Listing all files seems messy.

---

Suffix match in fzf (e.g., .md$ to list markdown files) works as expected. In fzf-tab it doesn't work due to junegunn/fzf#2099.

To be honest, I haven't used suffix match before. I use matcher-list tag to let me complete a file with its extension.

This may be useful when combining with the feature above (directories are recursed automatically).

---

There is no zle -R when completing. This makes it look much better on slow terminals.

That's really nice! I will also look into it later.

---

Tab inserts unambiguous prefix automatically. If you set auto_menu option (it's unset by default at the bottom of .zshrc), fzf will open automatically without requiring a second tab.
The query in fzf is based on the command line and not on the longest prefix among completion candidates. This way, if you have auto_menu unset, you don't need to look at the query because it's always what you've already typed in zle.

That's good. I think it is time for me to fix Aloxaf/fzf-tab#8...

---

The support for groups is completely lost though. It's possible to add them but I couldn't design a UI that would work well.

Yes, my ideal UI is like zstyle ':completion:*' menu yes select search. But this is impossible unless I create a another fork of fzf.

Another approach is Aloxaf/fzf-tab#127 (comment). But this need users to write code themselves.

---

One more thing. If you'd like to switch to zsh4humans, check out #35. It's super long but has a ton of useful info for advanced users. The default .zshrc and the docs are aimed at the average user but there is much more to z4h than that.

At the very least please read #35 (comment). I'd love to have you onboard and would welcome feedback and bug reports from you!

Thanks! This project is awesome. I will try it more later and decide whether I can switch my configuration to zsh4humans.

---

Your project inspired me a lot!

I really should remove some rarely used features from fzf-tab to reduce its complexity and speed. It used to be simple, but now it is very compelx and not so efficient.

Streaming completion is cool. But it's getting more and more hard for me to implement it since I have built too many functions on the top of this feature (like Aloxaf/fzf-tab#130). I think I won't implement it in the short term.

[romkatv]

That's amazing. I will look into it later to check whether I can replace zsh-ls-colors with it.

It won't be easy because the new API is stream-based. This works in z4h because I colorize completion candidates only when all of them are files. In fzf-tab you colorize files even if not all candidates are files (this is extremely rare in practice).

When completing files, directories are recursed automatically. These completions appear below the normal ones.

I'd like to use fd + zsh-tmux-capture here. Listing all files seems messy.

Initially I was afraid of this myself but now I like this a lot. Since the normal completions are always displayed at the top, the recursive completions are extra. If you don't want them, they are easy to ignore. On the other hand, I'm now frequently relying on "deep completion". E.g., when I want to look at a _git burried somewhere in /usr, I would type less /usr/, hit Tab and type /_git$. It takes only a second to traverse /usr -- much less than completing /usr/local/share/zsh/5.8/functions/_git one segment at a time.

To be honest, I haven't used suffix match before. I use matcher-list tag to let me complete a file with its extension.
This may be useful when combining with the feature above (directories are recursed automatically).

Indeed, searching becomes more important when you have a lot of files to choose from.

Suffix match is not only for extensions though. It's just is a fast way to trim the number of matches.

There is no zle -R when completing. This makes it look much better on slow terminals.

That's really nice! I will also look into it later.

This one may not be possible to implement in fzf-tab, or at least not as nicely as in z4h. This is because z4h has full control over all widget-wrapping plugins such as zsh-syntax-highlighting, zsh-autosuggestions and powerlevel10k.

This control has a ton of advantages. E.g., in z4h highlighting is correct in corner cases where it would be wrong when using zsh-syntax-highlighting with zsh-autosuggestions in the officially approved way. In addition, highlighting is twice as fast.

Streaming completion is cool. But it's getting more and more hard for me to implement it since I have built too many functions on the top of this feature (like Aloxaf/fzf-tab#130). I think I won't implement it in the short term.

Wow! This is super cool!!

I don't use tmux because I really like having native terminal scrollback, so I cannot just use tmux popup. I hacked something together that allows me to use the equivalent to tmux popup without running everything in tmux. More precisely, I run zsh in a hidden tmux compiled from patched sources but this is invisible to the user of zsh. So far it seems to work well. It doesn't preclude the user from running tmux if they want to. I'll need to experiment more with this. If I can make fzf pop up without pushing the command line up, that would be fantastic.

[Aloxaf]

It won't be easy because the new API is stream-based. This works in z4h because I colorize completion candidates only when all of them are files. In fzf-tab you colorize files even if not all candidates are files (this is extremely rare in practice).
...
This one may not be possible to implement in fzf-tab, or at least not as nicely as in z4h. This is because z4h has full control over all widget-wrapping plugins such as zsh-syntax-highlighting, zsh-autosuggestions and powerlevel10k.

This control has a ton of advantages. E.g., in z4h highlighting is correct in corner cases where it would be wrong when using zsh-syntax-highlighting with zsh-autosuggestions in the officially approved way. In addition, highlighting is twice as fast.

So embarrassed, it seems that all the features I am interested in is hard to port to fzf-tab.

I planned to port more part of fzf-tab to C to imporve its speed. LOL, It seems that we finally go to two different paths.

Initially I was afraid of this myself but now I like this a lot. Since the normal completions are always displayed at the top, the recursive completions are extra. If you don't want them, they are easy to ignore. On the other hand, I'm now frequently relying on "deep completion". E.g., when I want to look at a _git burried somewhere in /usr, I would type less /usr/, hit Tab and type /_git$. It takes only a second to traverse /usr -- much less than completing /usr/local/share/zsh/5.8/functions/_git one segment at a time.

That sounds attractive. I will give it a try. It's a pity that fzf-tab has no chance to integrate it (at least, in the short term).

BTW, a compromise solution is using less /usr/**/_git\t, though it is a little slow.

I don't use tmux because I really like having native terminal scrollback, so I cannot just use tmux popup. I hacked something together that allows me to use the equivalent to tmux popup without running everything in tmux. More precisely, I run zsh in a hidden tmux compiled from patched sources but this is invisible to the user of zsh. So far it seems to work well. It doesn't preclude the user from running tmux if they want to. I'll need to experiment more with this. If I can make fzf pop up without pushing the command line up, that would be fantastic.

Yes, I also don't like tmux at first. It invalidates some special features of the terminal emulator--if you use tmux, all terminal emulator will have nearly the same experience. I started use it just because alacritty doesn't support splitting window.
But soon I found that tmux allows me to better interact with the content on the terminal. Some plugins like tmux-copycat or zsh-tmux-capture is really useful.

Your solution is interesting. I will waiting for you finish it.

[romkatv]

I planned to port more part of fzf-tab to C to imporve its speed. LOL, It seems that we finally go to two different paths.

I'm not sure we are taking different paths.

Moving stuff to C is definitely on the table in zsh4humans. In fact, it's much easier to do in zsh4humans than in fzf-tab. fzf-tab currently doesn't have the machinery to ship compiled binaries and cannot utilize zsh modules. I know you are providing a script to compile a zsh module locally but this is both cumbersome and unreliable. Zsh modules have no stable ABI, so they only work with the same version of zsh compiled with the same libc and the same compiler flags. Since fzf-tab has no control over how the local zsh was compiled, it cannot produce a module that would be compatible with it.

z4h has several tools that make it much easier to utilize native code. There is infrastructure for building and releasing naively compiled binaries for all popular architectures. E.g., the latest release of gitstatusd has binaries for 12 architectures: https://github.com/romkatv/gitstatus/releases/tag/v1.3.1. z4h can install zsh if necessary. This allows zsh4humans to put requirements on the local zsh that are infeasible for a regular zsh plugin. Right now z4h code can assume the following:

1. Zsh is 5.8.
2. There is zsh/zselect module.
3. There is a terminfo entry for TERM.

If at least one of these requirements is not satisfied, z4h simply installs its own zsh.

That last requirement about terminfo means that you can use a terminal with an exotic terminfo (Alacritty, Kitty, Termite, etc.) without suffering the consequences. When you ssh to a server, z4h ensures there is terminfo for your terminal.

The list of requirements can be easily extended. E.g., z4h can require a custom zsh module.

z4h also has the infrastructure to patch its dependencies similar to how Linux distributions maintain patches for their packages. E.g., syntax highlighting is much faster in z4h thanks to custom patches. The same approach can be used to add features to fzf if required.

Since z4h has control over the "packages", it can provide custom plumbing that integrates them better than when each part is left to their own devices. Syntax highlighting, autosuggestions, completions and prompt are all integrated manually in z4h. This yields better performance, smoother rendering and fewer glitches. Think of the issues you've faced in fzf-tab with widget wrapping done in the wrong order, the defensive zle -R, etc. In z4h these issues don't exist.

Overall, building a nice shell experience is easier in z4h than in a plugin like fzf-tab. It gives you (as a developer) so much more freedom in terms of tools you can use. The downside is that it's a much larger project, requiring more time and effort to maintain and develop.

[Aloxaf]

Disscussing with you inspires me again!

In fact, I doesn't need to stick with zsh module. I can write a custom fzf which can process the output from _ftb_compadd directly.

In this way, I don't need to use C anymore (I love Rust) and streaming completion is also possible. I can even write a new UI to support groups.

[romkatv]

In fact, I doesn't need to stick with zsh module. I can write a custom fzf which can process the output from _ftb_compadd directly.

In this way, I don't need to use C anymore (I love Rust) and streaming completion is also possible. I can even write a new UI to support groups.

This sounds awesome! Whether you'll end up with a special binary tailored for displaying zsh completions, or an extended fzf with new generally-useful capabilities, this can have dramatic improvements on zsh UX. Cannot wait to see what you come up with.