221–230 of 280 posts
bat is cool but is there a way to get not to dump everything into my terminal and just page just like less? i wonder if there's a `bless` ?
You should be able to pass `--paging always`. The default `auto` will only page if the file contents is bigger than your screen.
Earlier quoted context omitted.
Plain text was chosen to interface the various programs of Unix OSes because it's the least common denominator all languages share. It also forces all tools to be composable with each other. You can take output text that was obviously not formatted for easy consumption by another program and still use all the information it outputs for input into another program. Programs that were only thought to have users handling…
...As long as you don’t have spaces in file names. I’d like to see something like cvs used more, where it can handle the edge cases without breaking, but still doesn’t need a translation step
Earlier quoted context omitted.
Notmuch, which is IMHO superb and totally underrated. I like it a lot due to its clever architecture. It never ever touches your email. It operates on a separate tag database. Then, it's the task of a backend to translate tag changes into maildir actions before and after syncing email. Keeping tag to actions decoupled from the GUI is extremely clever, because it allows implementing basically any email workflow you ca…
Thanks, I'm in the process of migrating from Thunderbird to mutt/neomutt and am wondering if emacs might have advantages. I already use Emacs for Org Mode. I'm also looking for a scriptable, text-based RSS reader: https://community.codeselfstudy.com/t/text-based-rss-atom-fe...
Is anybody here aware of any TUI/CLI tools that bring UX patterns/ideas from other programs to the terminal? Examples: - bash/zsh/fish bring suggestions/autocompletion - fzf brings fuzzily-matching selections to the terminal, - https://github.com/ericfreese/rat brings the idea of "widgets" or "layouts", - https://github.com/mrnugget/fzz brings "preview as you type" I'm looking for more patterns like that, mainly to e…
Earlier quoted context omitted.
If you like exa, maybe you like my modifications about hiding the time output optionally when using '--long', too. https://github.com/thibran/exa/tree/time_style_hide Example output of 'exa -l --time-style=hide': drwxr-xr-x - foo Desktop drwxr-xr-x - foo Documents drwxr-xr-x - foo Downloads drwxr-xr-x - foo Music drwxr-xr-x - foo Pictures drwxr-xr-x - foo src drwxr-xr-x - foo Videos
For just listing without additional info, I'm good with just the file tree. With '-l' it can show bunch of stuff. $ l (exa --tree --level 1) https://i.imgur.com/RxppCIt.png $ l2 (exa --tree --level 2) https://i.imgur.com/Mba79iz.png
Earlier quoted context omitted.
Plain text was chosen to interface the various programs of Unix OSes because it's the least common denominator all languages share. It also forces all tools to be composable with each other. You can take output text that was obviously not formatted for easy consumption by another program and still use all the information it outputs for input into another program. Programs that were only thought to have users handling…
How hard is it to come up with a object format (more like a data structure format since I wouldn't want logic/code being passed around) and then come up with a standard text serializer for it? Not that hard, in my opinion. You'd standardize it once via an RFC and you'd be done with it. I don't think your problem is as big as you say it is. The real problem is that this pile of code we already have kind of works and i…
Earlier quoted context omitted.
Not to mention you get a language that is enjoyable but also compiles to native code. My first Rust project was a Haml parser and I created a CLI for it too that is similar to the Ruby version. It is nice being able to ship the 8Mb executable and not have to worry about users having the right runtime.
Just like any other compiled language. GCC's static linking issues with glibc don't apply to other compilers.
Earlier quoted context omitted.
IIRC, loc (in rust) might be even faster than tokei at times? I always forget, and I’m sure I saw an old benchmark... We have a whole working group this year focused on making the experience of writing CLIs awesome, so hopefully we’ll see even more great tools in the future!
Well luckily I recently published a new comparison benchmark[0]. :) The TL;DR is that loc is faster by a few hundred milliseconds depending on repository size, but as cgag mentions doesn't have comment in string detection so can be quite off in its metrics, for example on the Rust repo Tokei says it has 643,754 lines of code where as loc says it's 635,849. [0]: https://github.com/Aaronepower/tokei/blob/master/COMPARI…
Earlier quoted context omitted.
Not to mention you get a language that is enjoyable but also compiles to native code. My first Rust project was a Haml parser and I created a CLI for it too that is similar to the Ruby version. It is nice being able to ship the 8Mb executable and not have to worry about users having the right runtime.
Also don't forget Cargo. It makes it so much easier to work with than installing C/C++ dependencies.
Earlier quoted context omitted.
I've never understood complaints like this. If you are proficient in the unix environment any sort of gymnastics can be handled via generation of some 'object' from plaintext and command generation on the fly. find $PATH -name ' .c' -exec grep -l socket {} \; | awk ' {printf "mv %s %s\n",$0,sprintf("%s.old",$0)}' find $PATH -name ' .c' -exec grep -l socket {} \; | awk ' BEGIN {n=0} {printf "{\"items\": \%s",sprintf("…
Just because I built ripgrep doesn't mean I've reinvented a wheel without understanding the existing model/power, so your criticism feels a bit disingenuous to me. To be clear, with the current release of ripgrep, you cannot create structured objects from its output as easily as you might think. I get that it's fun to show how to do it with long shell pipelines for simple cases, but the current release of ripgrep wou…