51–55 of 55 posts
I love the combination of these! Really opens up a world of possibilities. The one command I'm still trying to replace is `cd` itself. For instance, can anyone suggest a way to add bookmarks, so that I can move around faster? I found a few, but was never happy with them.
https://gist.github.com/chew-z/44f3bcdc08eaecdf306868f9a3d0e...
I added ctrl-P bind to open with vim. But if I realize I didn't want to do that and want to cancel then hitting ESC or ctrl-c just drops me into vim with no file. Any ideas on how to change that bind so that I can cancel back to the command line? Edit: actually it's even worse, it seems like rg keeps running in the background even after I ctrl-c, which if I'm starting in some directory at the top of my directory tree…
Sorry, I should update the article with the better solution, it's just a few more lines: https://github.com/bag-man/dotfiles/blob/master/bashrc#L116-...
https://gist.github.com/chew-z/db310b0e3184ae335e24d2ec7087a...
Earlier quoted context omitted.
I use both ag and rg with fish. For me, both are equally fast (because my repositories are small enough that it doesn't matter), but ag has better UI (I remember the --python option, but have no idea how to filter with rg). Those are about the only differences that matter to me, so I use whatever is muscle memory. Usually rg, unless I want to search for specific filetypes. If you're wondering whether to switch, don't…
> don't bother unless you find ag slow Or if you want more correct gitignore matching. > (I remember the --python option, but have no idea how to filter with rg) rg -tpy 'def __init__' or, to exclude Python files rg -Tpy 'def __init__' You can see the list of types available with `rg --type-list`.
Earlier quoted context omitted.
I use both ag and rg with fish. For me, both are equally fast (because my repositories are small enough that it doesn't matter), but ag has better UI (I remember the --python option, but have no idea how to filter with rg). Those are about the only differences that matter to me, so I use whatever is muscle memory. Usually rg, unless I want to search for specific filetypes. If you're wondering whether to switch, don't…
> don't bother unless you find ag slow Or if you want more correct gitignore matching. > (I remember the --python option, but have no idea how to filter with rg) rg -tpy 'def __init__' or, to exclude Python files rg -Tpy 'def __init__' You can see the list of types available with `rg --type-list`.
Earlier quoted context omitted.
There are good reasons to use Zsh beyond its autocomplete system. Zsh parameter expansions are a beautiful thing. When I write CLI scripts, I don't write Bash scripts, I write Zsh scripts. Documentation, however, is lacking. It's not quite as bad as Vim, but there are massive swaths of the program, entire subsystems, that are more or less completely undocumented. It's very user unfriendly. Also, the ad-hoc "plugin" e…
> There are good reasons to use Zsh beyond its autocomplete system... zsh also performs much better in practice than bash. Not only does it run the same code faster, it subsumes a great deal of functionality that normally requires external utility calls (which are very slow) into the shell itself. For example: * zsh has native floating-point arithmetic, so no need for `awk` or whatever. It can even format (digit-grou…
For the uninitiated: Zsh parameters expansions and globbing (called "filename generation" in the docs) are beautiful. As I said above, I don't write Bash scripts, I write Zsh scripts, and this kind of thing is why:
% cd /tmp
% mkdir example
% cd example
% touch foo
% touch bar
% mkdir "my documents"
% touch "my documents/baz"
% tree -N
.
├── bar
├── foo
└── my documents
└── baz
1 directory, 3 files
% for f in **/*(.);
> do echo File ${f:t} lives in ${f:A:h}
> done
File bar lives in /tmp/example
File foo lives in /tmp/example
File baz lives in /tmp/example/my documents
Fair enough. Although IMO "vague and disorganized" is just as good as "nonexistent". Just try reading the docs for `autoload`/`typeset`/`local`, or `zstyle` [0], or `zmodload`. The whole thing badly needs to be tagged and reverse-indexed by functionality ("how do I accomplish X"), not by flag ("what does foo -q mean?"). I wrote a long comment about this kind of documentation recently [1].
> The plug-in ecosystem (i assume you mean OMZ, zplug, and stuff like that) is entirely unofficial and most of the zsh developers don't seem to care for any of it because it tends to be slow, error-prone, and often just unnecessary. It's also a major support burden for the people on IRC and in the mailing list, which doesn't endear them to it. Might be cool to have something official though.
Yes, this. It seems like everyone and their mother at one point decided to try to write a "package manager" for Zsh.
But I think the problem with these unofficial plugins is mainly that sourcing thousands of lines of shell script on every terminal load, and running potentially dozens of functions before every command, is just plain slow. Zsh might be faster than Bash, but it's still really really slow. Just looping over 1..1000000 takes well over a second in Zsh, but less than 1/2 second in Python (which is already considered a slow language).
What I haven't tried is zcompile-ing all my startup scripts. Would that help?
And of course, actually documenting the C API and build process would be a good first step for the maintainers and devs. The example module is easy enough to follow, but actually writing a module is another matter entirely. This is especially frustrating because AFAICT Zsh builtins are themselves implemented as a statically-linked module called "zsh/main", so it must be a powerful system.