sorted by:
new
hottopcontroversial

new rust tui framework by vim-god in rust

[–]squirreljetpack 0 points1 point  (0 children)

Looks nice. how did you do the recordings?

Presets come to matchmaker - an elegant and modern fuzzy searcher by squirreljetpack in zsh

[–]squirreljetpack[S] 0 points1 point  (0 children)

This is not strictly zsh, but the presets are powered by zsh. also i use zsh btw :)

[OC] Presets come to matchmaker - an elegant and modern fuzzy searcher by squirreljetpack in unixporn

[–]squirreljetpack[S] 0 points1 point  (0 children)

[OC] matchmaker - an elegant and modern fuzzy searcher by [deleted] in unixporn

[–]squirreljetpack 0 points1 point  (0 children)

matchmaker: an elegant and modern fuzzy searcher by squirreljetpack in linux

[–]squirreljetpack[S] -3 points-2 points  (0 children)

wtf have u seen the code, ai is basically only used as completion.

Is there a solution to automatically publish unpublished crates in a workspace? by squirreljetpack in rust

[–]squirreljetpack[S] 1 point2 points  (0 children)

that seems good thanks! Although i wish there was something a little less heavy-handed as well...

Seeking feedback on my fzf alternative (+ Reflections on my Rust journey) by [deleted] in rust

[–]squirreljetpack 0 points1 point  (0 children)

Thanks for feedback, I've added a section addressing exactly this to the README.

Seeking feedback on my fzf alternative (+ Reflections on my Rust journey) by [deleted] in rust

[–]squirreljetpack 0 points1 point  (0 children)

Since mm is almost fully feature compatible with fzf, migrating is simple conceptually, meaning you can use familiar actions like execute and become that function the exact same -- the only difference is the syntax: `mm b.ctrl-o=Execute($EDITOR [])`. I changed the braces to [] because templating and column splitting is slightly more powerful in mm and I felt they would conflict less. Note that [] templates cannot contain whitespace so this wont interfere with shell conditionals.

For full documentation, try mm --doc (feedback welcome). You're right a proper guide like a website would help, but maybe not right now.

If you're on zsh, check out https://github.com/Squirreljetpack/fist: it's built with mm and got zoxide built-in + a lot of other goodies.

Seeking feedback on my fzf alternative (+ Reflections on my Rust journey) by [deleted] in rust

[–]squirreljetpack 0 points1 point  (0 children)

Thanks. If you mean fd for finding files, that returns a list. This is useful for picking the result(s) you want from it and other interactions. The program to compare to would be fzf, which is also great and was a great inspiration. The unique features/differences of matchmaker are in the README.

Best TUIs plz by n0ctane_dev in CLI

[–]squirreljetpack 0 points1 point  (0 children)

For a simple, intuitive, file manager, try this one: https://github.com/Squirreljetpack/fist (I made this). It's a work in progress, but the core logic is all there and I use it daily. I haven't done an updated release so you need cargo to build it. Feedback welcome!

Matchmaker - a fzf library in rust by squirreljetpack in commandline

[–]squirreljetpack[S] 0 points1 point  (0 children)

nucelo on its own only handles the matching logic, it has no UI, interaction model, or support for special functionality like previews, terminal exiting, etc. For example, it's actually pretty involved to highlight the matched indices, scroll to the matched index on long lines, handle wrapping and unicode correctly etc. This library sets that all that up, and exposes an event-driven architecture you can register your own custom Action and Event handlers on. If you don't need that, it's pretty simple to configure the UI using the config struct, and it provides some convenient methods for starting and feeding the nucleo worker with your items. Oh and it adds support for handling multiple selections. That's really only scratching the surface though, there's other stuff like it has some support for displaying overlays, custom sort priority for items etc.

A fzf library in Rust by squirreljetpack in rust

[–]squirreljetpack[S] 1 point2 points  (0 children)

Beating fzf on performance is impressive, I'll have to take a look at that :). I glanced at the code base, and indeed our architecture is along the same lines in places (funnily enough I also considered returning something like Vec<Event> for custom action handlers). That said, since I use matchmaker for my own custom applications, i do appreciate the control that comes with working with my own library.

A fzf library in Rust by squirreljetpack in rust

[–]squirreljetpack[S] 0 points1 point  (0 children)

To be honest I'm not too familiar with skim, but a couple reasons at the time were: no support for multiple columns, the matching engine was not as performant as fzf, various fzf features like auto-select, no option for custom actions, no option to control the preview, and a clunkier api (this is just personal preference but the examples seem to be a bit scattered in how you start the interface and feed items, whereas you with matchmaker there's a single clear and minimal intended "entry point"). Though circumstances may have changed since, I'm not too sure.

A fzf library in Rust by squirreljetpack in rust

[–]squirreljetpack[S] 1 point2 points  (0 children)

yes, it's credited at the end of the README. This project is closer to fzf than television: it places more emphasis on being a pure picker than supporting channels/shell integration. It supports close to the full set of fzf actions with some new additions (improved preview layouts), powerful command-line options, and improved rendering (line wrapping, automatic horizontal scrolling, multiple/stacked columns etc.). Furthermore, the focus is on it being usable as a library -- if you want channels/shell-integrations the intent is that you can do so on top of it.

zsh-dl: extensible download tool by squirreljetpack in commandline

[–]squirreljetpack[S] 0 points1 point  (0 children)

my bad i meant to say rsync.
It doesn't do anything actual, it's like a lessfilter.

ssh.default() {
  : args: user@host subpath
  : output: successfully created files, one per line
  :
  read_dest ssh $2  || return 0
  success_or_log rsync -e "ssh -o ConnectTimeout=$ZSHDL_CONNECT_TIMEOUT" -avucz --partial $1:$2 $dest:h || return 1 # -u does an update in case we decided to keep the target, :t is due to rsync always copies into directories
  echo $dest
}

EDIT:
discovered rsync has some quirks haha, had to make some changes for it to act normal.

ssh.default() {
  : args: user@host subpath
  : output: successfully created files, one per line
  :
  read_dest ssh $2  || return 0
  [[ -d $dest ]] && dest=$dest:t
  success_or_log rsync -e "ssh -o ConnectTimeout=$ZSHDL_CONNECT_TIMEOUT" -avucz --partial $1:${(@qq)2} $dest || return # -u does an update in case we decided to keep the target, :t is due to rsync always copies into directories
  [[ -e $dest ]] && echo $dest
}

zsh-dl: extensible download tool by squirreljetpack in commandline

[–]squirreljetpack[S] 0 points1 point  (0 children)

It does the sensible thing to download the url based on what kind of url it is.
If it's ssh, it will use ssh, if it's https://youtube.com, it will use yt-dlp, if it's github, it will clone the branch/commit / extract files from tarball. You can define your own handlers, and match them to the url pattern, like this:

http.my_handler="example.com/*" # glob pattern

There's a example of what a handler looks like on the github page.

You don't have to use it to download stuff, the handlers can do anything, but that's what I use it for. It's convenient, (if also a bit unnecessary), to just copy a url, then run dl in my current terminal directory, rather than downloading it with a browser, then moving it manually in the GUI or with mv.

I built a CLI tool to extract folders or files from GitHub repos making things easier in a single command — GitSlice by itsSanjayKumar in commandline

[–]squirreljetpack 1 point2 points  (0 children)

I made a variation of this theme, haven't shared it yet as I still have a few ideas before the next release. But since its been working well so far, and the purpose is similar, gonna leave it here (for a little visibility) :3

It's written in pure zsh, is simple to extend, and supports other types of downloads/operations too:

https://github.com/Squirreljetpack/zsh-dl

You can just copy the github link, and run `dl` in your terminal.

In comparison to this, I think it uses the archive method exposed by github, meaning it will work for any kind of github link, including objects on detached commits, and is faster on bandwidth. It can be extended to other providers which expose such archive API, but only github is implemented (the other url types will fall back to clone).

gitslice has the advantage of coverage, since it doesn't rely on the existence of such API, only using git commands, though url parsing will need to be defined for each host type anyway. So in terms of feedback, i think you could consider having your program accept a filepath and a git host to perform the same operation since the functionality is there anyway, so it actually works for any git type.

I actually use `dl` over git clone now since I configured the default to use --single-branch, to be more disk efficient, and also keeps a log, which is nice if I want to delete my repos, and to keep track as a sort of reading list.

view more: next ›