inconsistent account ordering

[legrostdg]

trafficstars

The order seems right for the top accounts, but it goes wrong for subaccounts. Subaccounts with subaccounts are always sorted after subaccounts without subaccounts...

So, given this test.journal:

account 2.a
account 2.a:1.c:0.d
account 2.a:2.e
account 2.a:3.f
account 1.b

$ hledger -f test.journal a
2.a
2.a:3.f
2.a:2.e
2.a:1.c:0.d
1.b

I guess there's something wrong in the recursion of sortAccountTreeByDeclaration in hledger-lib/Hledger/Data/Account.hs...

[simonmichael]

@legrostdg I took a closer look. What's going on here is discussed at https://hledger.org/hledger.html#account-display-order -> "Note that sorting is done...". Here's a smaller example:

account a:x
account b

$ hledger accounts
b
a:x

account a:x only affects the position of a:x (relative to its siblings under a), not of a. To do that you have to add account a as well.

Does this make it seem less bad ? I agree it's a little surprising and there might be a better behaviour. It takes a little time to test and explore the effects and I'm not quite clear on it.

[legrostdg]

Great! That's not intuitive, but it fixes my issue! At least the doc should be improved, but it would be better to really fix the ordering, so that a:x is displayed before b.

[simonmichael]

What about this one:

account a:y
account b
account a:x

Current output:

b
a:y
a:x

By your proposal it would be this, I think:

a:y
a:x
b

Would that be better / less confusing than the current behaviour ?

[legrostdg]

I think I would have expected

a:y
b
a:x

Just as the accounts are defined, assuming the user would have had a good reason to define the accounts in this order. But with assets and liabilities instead of a and b, I can understand why we would like to have the a:'s grouped together... Maybe we should have an exception for the top accounts?

Nevertheless, to me,

a:y
a:x
b

seems less confusing than

b
a:y
a:x

[legrostdg]

(with the reasoning that a:y implicitly defines a)

[simonmichael]

There's room for confusion with all of these approaches, as you can see. I can rule out ever displaying b between a:y and a:x, if you try it I think you'll see it's just incompatible with keeping hierarchical reports readable. Special cases are also to be avoided, they will be fragile and confusing.

[legrostdg]

Yes, I also think

a:y
b
a:x

is the worst of all cases.

[legrostdg]

I still think

a:y
a:x
b

is less confusing that

b
a:y
a:x

But I don't think I'll be able to propose code for this, and the declaration of top accounts fixed the issue for me, so... You decide :-). Feel free to close this if you prefer keeping the current behaviour.

[Xitian9]

Is there something to be done here? We don't have a clear reason to prefer one approach or the other, and we have one which is implemented. Can this issue be closed?

[Flimm]

I would quite like to have this declaration order, to have all the cash accounts first, then all other asset accounts next (which in my case are "receivable"), then liabilities, like this:

assets:wallet
assets:bank
assets:zbank
assets:receivable:aaa
assets:receivable:zzz
liabilities:loan1
liabilities:loan2

With headings, it would look like this:

# Cash:
assets:wallet
assets:bank
assets:zbank

# Receivable:
assets:receivable:aaa
assets:receivable:zzz

# Liabilities:
liabilities:loan1
liabilities:loan2

I'm having trouble achieving this, as declaration order doesn't seem to work as I expect, due to this issue and to issue #1891

[simonmichael]

Small comment on @legrostdg's original example at top: I don't know how that output happened. Here is the current correct output for that example (2.a:2.e and 2.a:3.f's sibling 2.a:1.c is not (directly) declared, therefore it is displayed last.):

account 2.a
account 2.a:1.c:0.d
account 2.a:2.e
account 2.a:3.f
account 1.b

$ hledger-1.26 accounts
2.a
2.a:2.e
2.a:3.f
2.a:1.c:0.d
1.b

[simonmichael]

https://hledger.org/hledger.html#account-display-order says, in essence:

currently, the directive account other:zoo influences the position of zoo among its siblings, but not of other among its siblings

It's worth reviewing whether we could safely (without breaking anything significant, without creating new complexity) allow this declaration to influence the position of both zoo and other. Possible a problem is demonstrated in the examples above, but I'm not sure.

[simonmichael]

Functioning as documented; I'm going to close this, unless anyone wants to work on enhancements.