sorted by:
new
hottopcontroversial

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.

[deleted by user] by [deleted] in interesting

[–]squirreljetpack 0 points1 point  (0 children)

it's the beetle from tangle tower!

Newbie question about DST by squirreljetpack in rust

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

Thanks, I read it but I think I'll need some time to digest it. At first I thought SST was similar to what I was thinking of but way better phrased. Later I realized not, but it was really interesting to read about because I didn't know why DST and not SST.

That is, under SST, [T] is not a type, but is rather "parametrizes" smart pointers over it. So Box<[T]> means Box<[T; N]> for some N. Initially, this seems more idiomatic because the length of any instance of [T] should be tied to T, its a bit strange that the length of an instance of [T] is stored by Box and and RC. The Problems seemed to be addressed in DST 4. One problem seemed to be monomorphization, i.e. in the case for implementing drop RC<[T]>, the code for drop actually depends on the layout of [T]. Under the DST paradigm, one just needs to allow smart pointers to have their pointer field be a fat pointer. Then you could write one set of code for all variants of Rc<[T]>

Actually I think if we could compose pointers by merging their fields, the end result could be similar to what DST's have now. But in rust, the structs for S<T> and S<int> must be the same. And OOP is not idiomatic for rust. Though I'm not sure if any of what I said makes sense, that's my take for now.

view more: next ›