As per http://dev.yorhel.nl/ncdu/bug/31

This has apparently been broken since version 1.7 (v1.6-7-g5db9c2a to be
precise), yet NOBODY TOLD ME!? :-(

The OSS community has left me in despair!

Most of which made sense.

It's kinda annoying how you need to confirm the messages. I'd prefer
having some status bar where messages are automatically removed after a
short timeout or something. But that's more work, and for the few
cases where feedback is necessary this'll work fine, too.

This allows scanning stuff without initializing ncurses. Not too useful
at this point since ncdu will switch to an ncurses environment when it's
done anyway, but this will become more useful when the export-to-file
feature has been implemented.

This silences clang and gcc with -O2 -Wall -Wextra

The architecture is explained in dir.h. The reasons for these changes is
two-fold:
- calc.c was too complex, it simply did too many things. 399ccdeb is a
  nice example of that: Should have been an easy fix, but it introduced
  a segfault (fixed in 0b49021a), and added a small memory leak.
- This architecture features a pluggable input/output system, which
  should make a file export/import feature relatively simple.

The current commit does not feature any user interface, so there's no
feedback yet when scanning a directory. I'll get to that in a bit.

I've also not tested the new scanning code very well yet, so I might
have introduced some bugs.

Damn, it's 2012 already.

This should also allow compilers to generate better code.

This used to be the default before 1.5, but for some reason the default
changed in 1.5 and 1.6. Changing it back now, because the graph really
is useful, and there's still enough space for the filename even in
smaller terminals.

This solution is far cleaner. Thanks to Ben North for pointing me to the
*-width-specifier that has apparently been built into the printf-family
functions for, well, quite a while, it seems.

The memory for this format is now statically allocated as well. I
was under the impression its size would depend on wincols, but this is
the format we're talking about, the string does not have to hold the
actual line contents. I must have been sleeping again...

Oh well, this is a slight performance improvement, although it doesn't
seem the be the cause of the browing slowness when running under
valgrind. (Obviously running ncdu with valgrind is supposed to be
slower, but the current performance is rather bad...)

This changes the behaviour back to it was before the dirlist
abstraction, which is the behaviour I prefer.

Here is the new multi-page listing functionality I promised in
5db9c2ae.

It may look very easy, but getting this to work right wasn't,
unfortunately.

Rather than the ugly hack in delete.c.

I was overseeing a stupid mistake in
  a7b7841a
Obviously, you need to check against wincols and not winrows...

Fixes bug #2991787

This optimizes a few actions (though not all), and makes the code easier
to understand and expand.

The behaviour of the browser has changed a bit with regards to
multi-page listings. Personally I don't like this change much, so I'd
probably fix that later on.

The directory sizes are now incorrect as hard links will be counted
twice again (as if there wasn't any detection in the first place), but
this will get fixed by adding a shared size field.

This method of keeping track of hard links is a lot faster and allows
adding an interface which lists the found links.

Fixes bug #2831412 (debian #539553)

Reproducable with the following steps:
- Make sure the first item in the list is a directory starting with a dot
- Make sure the next item is a normal directory
- Select first item
- Press 'h' to hide it, next item will properly be selected
- Open selected directory (right arrow), and see how the first (hidden)
  directory was opened.

It's amazing how I've even found this bug, considering that really is the
only way to reproduce it...

It's a floating point division, so won't really cause any real problems
on most systems. Still, a percentage of 'nan' isn't really useful.

Which would happen if there's only one file is in a directory

And it wasn't even used for a path, but for a row on the screen...

So we're actually back to having one header file for everything,
except it's now maintainable.