This is done apart from the incomplete action cost support for merge-and-shrink
that is tracked in issue193 and issue211 and the suggested
capable()/admissible()/consistent() methods. I'm closing this. If someone is
interested in these methods, please open a separate "wish" issue.

> I will document what I know, and leave question marks where I'm not sure

I've filled in the blanks. Patrik,
   http://www.fast-downward.org/HeuristicSpecification
should now contain the info you're interested in. We're hoping to add action
cost support to more heuristics very soon (within a few days).

I will document what I know, and leave question marks where I'm not sure

Makes sense to me (but let's maybe wait until after the IPC deadline?). A
"consistent" method would be useful too -- we have one or two places in the code
that say something like "TODO: If the heuristic is consistent, we should assert
here that this node is not closed" or something along those lines.

In the meantime, I'm really sorry I haven't yet dealt with Patrik's very small
original request: to document current language support properly in the user
documentation. Erez, do you have time for that? I could do it too, but there are
some work-intensive things I'd have to do first (not related to the planner).

The heuristics that look at action costs:
h^m, landmarks, exploration (landmark's FF), LM-CUT

I suggest we add two methods:

bool Heuristic::capable()
bool Heuristic::admissible()

where capable would return whether this heuristic can work on the current 
problem, and admissible would return whether this heuristic is admissible for 
the current problem.
This would allow us (for example) to use selective-max between LM-CUT and 
landmarks where LM-CUT works, and landmarks alone otherwise.

Suggestion: as an interim measure, it would be really great if the documentation
(HeuristicSpecification page) simply listed for each heuristic if it respects
action costs or not. Also other restrictions (e.g., works/doesn't work with
conditional effects, axioms, etc) would be very nice to have listed there.

Agreed.

I think (following Holger's philosophy) that there should be a parameter of 
whether we ignore action costs or not (for the inadmissible heuristics at least)

After adding action costs, h_max and h_add have not been extended to properly
support them. In particular, the "poor man's h_add" is not suitable for problems
with widely varying costs, such as the attached problem by Moritz.

So, we need to
 * properly support action costs, and
 * test that this does not (much) negatively affect performance in the
   unit-cost case.

Also make sure that costs are taken into account when removing dominating
transitions.

For 1.0, if we don't get this implemented in time, the least we should do is to
properly complain if e.g. h_max is called on a non-unit-cost problem (since one
would expect admissibility here), and to warn strongly when h_add is called on
such a problem.