transaction list vs address list logic

[buhtignew]

In another thread we've discussed about the transaction list command outputs and I was suggesting to output the data we are expecting the user to run more often with less flags adding the flags to widen the quantity of data.

You rightly argued that the output with more data should have less flags.

However we haven't followed that logic in case of address list command, because without the flags the list of addresses that is being provided is more restricted than with some flag, for instance in case of address list and address list -i.

I don't think we should and can afford at this stage the change of the flags for transaction list command, but maybe in the future it may have sense considering that change.

Update1 04-02-2025:
I was using intensively using transaction list these days and have realized that maybe we can improve this command usability by slightly editing our help.

For instance, we have the following usage mode:

    pacli transaction list DECK [-o [ORIGIN_ADDRESS]] -g [-u]

Which, doesn't even includes the -w flag. That, at least, for me was a great source of confusion, because the data displayed without the -w flag are a kind of "garbage" (superabundant) data compared to what probably the general user would be looking for while using this command. How many users would be really interested to know what are the burning or gateway transactions originated from elsewhere and just "touching" their wallet, if any?
So maybe it would make sense at least adding the -w flag as optional in the above usage mode and the same for the PoB decks.

Update2 04-02-2025
The more radical idea may be to introduce yet another flag -j that would stand for "joining transactions" (instead of "touching transactions") to be used as alternative to -w flag with the -g and the -b flags. So as the above mentioned usage mode may become as following, for instance:

pacli transaction list DECK [-o [ORIGIN_ADDRESS]] -g [-w|j] [-u]

In this way the -g flag alone would list both the joining and the wallet's transaction while the combination -g -j would display the joining transactions only. And maybe there would be possible to use the -g -j -u combination as well, although I'm not sure it would be necessary.

Update 05-02-2025:
If we decide to introduce the -j flag maybe it can be also useful together with the -c flag, since the transaction list DECK -c provides more information than transaction list DECK -g or transaction list DECK -b, and there is no flag that enables the user to get the same quantity of information of the transaction list DECK -g and transaction list DECK -b commands.
With introducing the possibility to use the -j with the -c flag we'd at least enable the user to have a separate list of "joining" transactions comparable with transaction list DECK -g -j and transaction list DECK -g -j -u outputs.