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.

That's what you get when you change the way a function works...

ncdu already does seem to handle longer paths now, though there are
still a few places where the code still relies on PATH_MAX. Will fix
those later.

This makes deleting multiple files a -lot- easier...

Just hide the info window in that case.

Looks much better this way!

It was a totally useless feature, anyway.

This actually makes the struct itself obsolete, as all information is now only
useful within calc.c itself and other files don't have to do anything with it.

Not fully finished yet with this one, though.

ncdu is currently pretty much in a non-working state, but things will
get fixed eventually after porting the other source files to the new
framework.

git-svn-id: svn://blicky.net/ncdu/trunk@48 ce56bc8d-f834-0410-b703-f827bd498a76