cytzol

You are correct. exa uses libgit2 for its Git column, and the library's networking parts must still be included when they aren't even being used anyway.

I can see how it looks VERY SUSPICIOUS for a file lister to be parsing HTTP headers! I'm not going to sell your directory entries to advertisers, I promise.

grep does have `--color=auto`, though, which checks whether you're printing to a terminal or not.

exa's opinion is this: users shouldn't be expected to know that adding colour to ANSI terminal output adds more bytes to the stream. If you run `foo`, see that it outputs a line, then run `foo | grep line`, you'd expect to see that line without having to stop and think about what representation the colours had.

Yeah, it's annoying that less is one of the few programs that doesn't alter its input and would be a perfect use case for reading in ANSI codes. There's just no way for exa to know that it's being piped into less while keeping the above rule true too.

I've been aliasing "l" and "ls" to "exa" for years now. Aliases in your shell won't cause any problems, because any scripts you run won't follow the aliases and will just use ls normally.

Actually replacing the binary? That would cause so many problems!

When I release a new version of exa, I upload the code and binaries to GitHub, and then someone else whom I have never met but very much appreciate takes it and publishes it to Homebrew, then a few days later I download and start using it.

It's the slowest file copy mechanism I've ever used!

Thanks for the kudos! It's absolutely mindboggling how many times I've decided to deviate from one of ls's default settings -- certain that the old way was inferior and outdated, and that the new way will be obvious and immensely popular -- only to find people have no idea why I'm doing things this way! I need the colours to help me scan the output; if I don't see human-readable units, I curse myself for forgetting the flag. But thousands of people don't like this, and it's usually a different set of features with each person, too. I would never have guessed I was so 'out there'!

ls is one of the most entrenched pieces of software there is; this is freeing, in a way, because it provides a stable base for people to rely on, leaving exa free to experiment. Everyone who values stability and simplicity most of all won't be switching from ls any time soon, which means I can push exa more in the direction I want it to go.

(Fun facts: very early releases of exa didn't have a grid mode at all, just the long mode, because that was the only one I used. So there have been some concessions to popularity :)

"Like an engineer deeply in tune with his machine, Exa feels the world's component error deep in his bones, fractionally before anything has literally gone wrong." — from Sam Hughes's Ra (https://qntm.org/ra)

It was originally going to be a command-line "file explorer" like ranger, and exa is kind of short for explorer, but I like this quote too.

I wouldn't say it's bullshit, just a difference of opinion.

38 kilobytes of executable isn't small, it's tiny; there's no way exa could get to that level without compromising its featureset or development, and even if you did, you'd just have another ls, and we already have ls.

If it's not small, what would you call it? Medium-sized? Something of that size means "download tens of megabytes of runtime and scatter files all over your computer" to me, and exa's smaller than that.

I have a zillion iTerm profiles configured with popular colour schemes for testing with both light and dark ones. You're covered.

To the credit of both Microsoft and the Rust team, Windows has become a much easier platform to develop on than when that sentence was written!

(author here)

You know what's funny? Every time I have to use ls, I'm so used to seeing the colours that I have so much trouble finding anything. Which column in the permissions is group-read? I can just scan for the green one. Which file in the listing am I supposed to be looking at? I just look for the one with the yellow underline. Colours have familiarity to me in a way that letters and words do not -- if I expect to see green and instead see grey, I'll notice it faster than if I expected to see "r" and instead see "-".

Of course, not everyone feels this way. Colour terminals are not a new invention, and if the "colour in everything" crowd was larger, someone would have made exa sooner.

That said, I don't want to go too overboard with the colours. Here's an example: when exa was in its infancy I had the bright idea to highlight the root user in red, in the same way that it highlights your current user in yellow, because, I don't know, root is "dangerous" or something. I ended up seeing so many red usernames that I stopped seeing it as "dangerous, beware" and started seeing it as "just another file" -- which completely defeated the point! Now, red is a lot more scarce (just +w permission and inodes. probably some file types. not many)

I know the documentation is currently lacking -- I've been working on a better website that explains all the options and colours for a while now. It should be done Soon™

This took me by surprise too. For some reason it isn't happening in the Vagrant VM I develop on, but now I've run it on my VPS, it's totally there! exa uses libgit2 which must be requiring it somehow.

The GitHub issue offers a fix for Ubuntu: https://github.com/ogham/exa/issues/194

It's all good now! Rust has been stable with backwards-compatibility guarantees since 1.0 was released two years ago.

Of course someone links to exa right as I accidentally upload a broken linux version... of course!

I absolutely love having a colourful shell -- assuming that each program doesn’t end up competing for your attention! I’m far more likely to notice an error if it’s red, or a warning if it’s yellow, as I find out about them subconsciously without having to read each line. However, if every program has a different idea of what an “error” is, then I’m just going to start ignoring red lines instead.

Since Sierra, you've been able to do it from within System Preferences, no hacks required!

For anyone wanting to see the linked IOCCC program (now-broken link in the third paragraph), here it is: http://ioccc.org/1987/hines/hines.c

"This program was designed to maximize the bother function for structured programmers. This program takes goto statements to their logical conclusion. The layout and choice of names are classic."

Yeah, you got it. I have a webpack.config.js that compiles everything, bundles it together, and spits out a bunch of HTML files. But what I don't have is the confidence that I'm doing things the right way and not using Webpack inappropriately!

> You can have multiple entries (html files), but share common chunks between them might be difficult in some special cases.

This is what I'm trying to do at the moment -- create a static site that's just a bunch of HTML files, while still taking advantage of Sass, CSS modules, and Vue.js components. (God, I love scoped CSS so much.) I'm sure there's a way to get Webpack to do what I want, but I haven't found it yet. prerender-spa-plugin has been a huge help, though.

It seems very similar to when I was learning Git: I know what I want to do, but Git's interface uses a level one layer lower than the one I'm operating on. "Undo the last commit", not "Reset the working tree to the previous commit's, but leave the staging area intact". Webpack's interface seems too abstract for what I want. I want to think in terms of individual pages, not of entry points; components, rather than chunks. Hopefully in five years when flat HTML files are vogue again there'll be a friendlier interface on top of it all.

Edit: I don't mean to be 100% negative in my comment! Webpack has certainly helped me solve problems that, previously, I haven't been able to solve. That alone is great. I just wish it'll go "click" so I can "get" it.

My favourite part of the Webpack 1->2 transition was when they updated their old documentation to say that Webpack 1 was deprecated [0], but failed to mention if the user was currently looking at the Webpack 1 docs or the Webpack 2 docs!

I ended up reading the Webpack 1 documentation for several weeks after 2 came out. I'd see the warning, go "oh, I better not use Webpack 1 then", and continue reading its docs. Cue lots and lots of head scratching.

Webpack developers: if you're going to release a new set of documentation for 3, then please, please make this clear.

[0]: For example, https://webpack.github.io/docs/code-splitting.html. "webpack v1 is deprecated. We encourage all developers to upgrade to webpack 2." There's a link, sure, but I didn't follow it because I had no reason to think I wasn't already on the Webpack 2 docs page. grumble grumble

Ah, but is that a problem with the commit messages, or with the CI systems?

> This is my unsafe block's bug, but it seems like something that could take a good while debugging to attribute back to my unsafe block.

You are correct: it's possible to write nefarious code inside an 'unsafe' block then only suffer its effects outside of it, and Rust has to document that fact. The Nomicon, mentioned in the blog post a whole bunch, points this out early on:

> 'unsafe' does more than pollute a whole function: it pollutes a whole module. Generally, the only bullet-proof way to limit the scope of unsafe code is at the module boundary with privacy.

[ https://doc.rust-lang.org/nightly/nomicon/working-with-unsaf... ]

javac itself doesn't do any incremental compilation and will happily compile over your .class each time (though you can tell it not to; see http://stackoverflow.com/q/8271282)

Build tools like Maven and Gradle, as well as IDEs' internal build tools, will be smart and compile only the changed files.

I’ve started avoiding the whole pretence of “tagging” or “organisation” like I tried to do with Pinboard. My bookmarks are now Safari .webarchive files. I have access to them offline, I can back them up the same way I back everything else up, and I just organise them in folders however I want. I even get search!

A “bookmark manager” doesn’t need to be an app or a service -- it can just be a bunch of files.

Edit: I should say that Buku looks like a good program for those who like that way of things, though!

What you could do is commit half-finished work with the name “Backup”, and then commit --amend over the top of it once that piece of work has completed. This ensures your for-sync-only commits won’t get in the way of the other commits.

However, I recommend you use a separate tool for backups and syncing than the tool you use for version control. For example, you could use Rsync to push the files -- both the .git folder and your source code files -- to a remote server, and then pull them down on another computer. Not only will you only be committing for actual commits, but you can also save the state of your repository and continue working on it later; you could stage certain files and not commit them, sync your .git folder to another machine, then have those same files staged but not committed.

Ooooh, yes. Testing error-handling code is another thing I keep on forgetting to do.

A function can return void and still throw an exception. (Like one I wrote today, "insert row into table", which throws on failure and return nothing on success.)

A bunch of functions that all return void all being called in a row, though? That's a much smellier smell. What happens if their order gets mixed up, for example.

> things like small one-liner functions for conditionals and basic arithmetic that are designed with mock- and test-ability in mind

I've done this before. It's very easy to want to make all your function/method calls work the same.

To stop, I applied the following rule whenever I had to choose between making a function static or mockable: does this function's name completely describe its implementation? Small methods like "StringUtils::isEmptyOrWhitespace" pass this test: it's just going to check if the string is empty or only contains whitespace, and that doesn't need to have its implementation swapped out. On the other side, "ImageUtils::detectFacesInImage" goes into no detail about how it does the face detection, and definitely needs an interface to test against.

That said, it all depends. You might allow your users to pick which characters count as whitespace, I don't know.

> I think integration and other coarse-grained tests are far more useful more often!

Yes! Integration tests are the "main" tests. Unit tests are secondary. Use them when you need to debug why your integration tests fail.

If you’re logged in, it says that for the last public repo that you saw. You must have last seen Homebrew.

This is a perfect example of why comments that explain why something is going on, rather than just what is going on, are so useful!