Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

CLI: Improved

remysharp.com

Post reply on HN
Print view View original

261–270 of 280 posts

Re: CLI: Improved

#261

Post by vram22 »

epage wrote: post #124
vram22 wrote: post #63

Earlier quoted context omitted.

>We have a whole working group this year focused on making the experience of writing CLIs awesome Can you explain what you mean by this? Something like the people are going to focus on language and library features that help with writing CLIs? Or something else? Asking because CLIs are one of my interests.

We've tried to dig into various problematic areas of writing CLIs in Rust [0], worked to create or improve libraries [1], and are working on writing a "book" for Rust-based CLIs [2]. You can reach out to us on gitter [3]. [0]: https://github.com/rust-lang-nursery/cli-wg/issues [1]: https://github.com/rust-clique/ and https://github.com/assert-rs/ [2]: https://rust-lang-nursery.github.io/cli-wg/index.html [3]: https:/…

Thanks for the detailed answer. Will check out some of those links.

Re: CLI: Improved

#262

Post by NateEag »

nextos wrote: post #200
NateEag wrote: post #144

Earlier quoted context omitted.

+1. I spent a while trying to persuade Apple Mail to let me receive notifications only for threads I was 'watching'. I never did come up with a sane answer, and finally decided "well, I use Emacs for almost everything else. Might as well see how email pans out..." With notmuch and mbsync I have the best email setup I ever have. I wish I'd done it years ago.

Can you share your setup?

Sure. It's all available in my dotfiles and .emacs.d repos on GitHub. It's not elegant or pretty, but it has worked well for me so far.

My crontab (https://github.com/NateEag/dotfiles/blob/master/lib/.crontab) runs a check-mail script (https://github.com/NateEag/dotfiles/blob/master/bin/check-ma...) every five minutes.

The check-mail script is just a wrapper around mbsync (http://isync.sourceforge.net) that invokes 'notmuch new' after running, so notmuch can index and process new messages.

My notmuch post-new hook does a bunch of tagging for me, so I have to actually look at as little email as feasible, but the main thing it sounds like you're interested in is the notification setup:

https://github.com/NateEag/dotfiles/blob/858cabd9436d377f8fc...

With that, I can batch-process email a few times a day, while staying responsive to any discussions I actually want to be interrupted for.

The missing piece is reasonable logic for knowing when I should be notified of new threads. I'm currently in a job where people don't expect insta-responses to email, thank God, but I've been in ones where they do and I'd have to think about how to handle that more.

For reading and writing email, I just use notmuch's Emacs modes. You can see most of my interesting config here: https://github.com/NateEag/.emacs.d/blob/75d117befeaaab37cc7...

My one annoyance when reading email is that large inline images aren't auto-resized to fit. They should be, but the Emacs build I use doesn't have ImageMagick support compiled in.

My custom.el probably has some notmuch settings too.

That's the highlights. Hope it was helpful.

Re: CLI: Improved

#263

Post by NateEag »

lozf wrote: post #242
NateEag wrote: post #144

Earlier quoted context omitted.

+1. I spent a while trying to persuade Apple Mail to let me receive notifications only for threads I was 'watching'. I never did come up with a sane answer, and finally decided "well, I use Emacs for almost everything else. Might as well see how email pans out..." With notmuch and mbsync I have the best email setup I ever have. I wish I'd done it years ago.

Would love to learn more about that, do you have a blog post or any pointers please?

I'm not sure if HN sends response notifications or if people depend on them, but just in case, I answered the sibling question here:

https://news.ycombinator.com/item?id=17888628

Re: CLI: Improved

#264

Post by KingMob »

xxpor wrote: post #90
orf wrote: post #29

Is anyone else impressed with the quality (and speed!) of some of the tools written in Rust? I'm an avid user of fd and bat, the former being ridiculously fast. Often I find something on github, I'm impressed by the quality of the documentation, features, UI etc, then lo and behold it's written in Rust. Another one potentially for this list is tokei[1] I was trying to count the code in our repos at work and used the…

I'm surprised they said ack || ag over ripgrep. I'm a total convert. It's AMAZINGLY fast.

In the comments, the author admitted he hadn't heard of ripgrep, and would give it a try.

Re: CLI: Improved

#266

Post by always_good »

oblio wrote: post #198
jolmg wrote: post #112

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…

> You'd standardize it once via an RFC and you'd be done with it.

If you think something like this is easy much less "you standardize it once and you're done", then you are only cheating yourself out of an essential life lesson.

Re: CLI: Improved

#267

Post by I_complete_me »

chuckdries wrote: post #76
Mizza wrote: post #72

Another tool I use religiously: `autojump` (aliased to `j`) rather than `cd`. It learns where you go and lets you fuzzy-jump there. https://github.com/wting/autojump I also use `loop`, my own Rust-based replacement to bash's native loops: https://github.com/Miserlou/Loop

ZSH's z plugin does the same thing. Highly recommended for the ZSH users out there! https://github.com/rupa/z

I installed z which is great. Then I started thinking about all the available one letter commands in bash/zsh. So I went through them. This is the result. $d lists recent dirs $g a git shortcut $l shorthand for ls -l $t It's just after a quarter past twelve. $w Show who is logged on and what they are doing. $x X - a portable, network-transparent window system $z zsh fast finder

Re: CLI: Improved

#268

Post by collinmanderson »

enriquto wrote: post #222
collinmanderson wrote: post #205

Earlier quoted context omitted.

...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

is there any filesystem that does not enable spaces in filenames? I find the idea ridiculous. Would you design a programming language that allowed spaces in its variable names? Because that is the same level of atrocity.

Yes, but filenames are not variable names, they're values, and they often break plain text piping

Re: CLI: Improved

#269

Post by enriquto »

collinmanderson wrote: post #268
enriquto wrote: post #222

Earlier quoted context omitted.

is there any filesystem that does not enable spaces in filenames? I find the idea ridiculous. Would you design a programming language that allowed spaces in its variable names? Because that is the same level of atrocity.

Yes, but filenames are not variable names, they're values, and they often break plain text piping

This is not the unix philosophy. Filenames are indeed variable names. The values are the contents of the file.
Post reply on HN