Closed florentc closed 3 months ago
Maybe stop displaying "pubkey" vs "script" as a prefix when a hash has been resolved to a name (I lean towards keeping it)
I lean towards keeping it either. It does not hurt and bring an info that somebody who has not worked on a codebase will need in order to understand the outcome of a trace.
Investigate or postpone to future PR the token name parsing
I believe it should be postponed.
Experiment with highlighting names from the rest of the text. Hashes where easy to spot because of the # and hexadecimal characters. Now names, in particular if they have spaces or are lowercased, can be hard to notice in the middle of the text. For example Spends from script foo (Reference Script at 28282838!0), or Pays to pubkey Clint Eastwood could become Pays to pubkey [Clint Eastwood] or Spends from script [foo], Pays to pubkey #"Clint Eastwood", etc. (I'd keep it like it is for now)
It could be good indeed to have names highlighted. Now that I think about it, there could be a different highlight if it's a script or a pubkey, which would also kinda solve the first question. Something like script@[myscript]
and pkh@[mypkh]
Investigate using existential types or something to avoid having to split the names into several sublists for each concrete type. (That would be nice to have)
I'd say that would be nice to have but not mandatory. It practice, the only way I see that happening is by having a list of types as a type or something like that which would require type families.
There was a hardcoded check to print "Lovelace"/"Quick"/"Permanent" for the relevant currency symbols. Should this now be moved to the default name table (which would contain those 3 elements instead of being empty by default)? (I find it would be conceptually more elegant but maybe prone to accidental overwrites in practice)
I like the idea of having the 3 by default. And if in turn the user overrides it, well it's ok.
This PR is ready for review. The first post has been edited accordingly.
Decisions regarding the discussion items:
defaultHashNames
the user can extendIn addition:
pcOptHashVerbose
) matches the legacy style pubkey #a1b2c3d (some name)
we used to have when wallet numbers were displayeddefaultHashNames
This addresses #379
This PR introduces a quality of life feature to associate readable names to hashes in a new pretty-pretting option.
The option is grouped among others in the
pcOptHashes
field ofPrettyCookedOpts
. This field has the following subfields:pcOptHashLength
: this option already existed before, at the top level ofPrettyCookedOpts
, it sets how many characters of a hash to printpcOptHashNames
: This is the core of the new feature, it associates hashes to names. Use thehashNamesFromList
smart constructor. It takes a list of key/value pairs but the keys can be anything that has a hash: wallets, scripts, minting policies, datums, transaction ids, and pretty much all the associated types (might not be exhaustive). The associated new class,Hashable
, is defined inPretty.Cooked.Hashable
.pcOptHashVerbose
: By default, when a corresponding name is found for a hash, the hex representation is no longer printed. This flag forces it to be printed alongside the name just in case.(postponed)pcOptHashParseTokenNames
: Not yet implemented. This is intended to parse token names for a hex representation of a hash and if something is found inpcOptHashNames
, print it instead.Example:
TODO and discussion topics
Maybe stop displaying "pubkey" vs "script" as a prefix when a hash has been resolved to a name (I lean towards keeping it)#
and hexadecimal characters. Now names, in particular if they have spaces or are lowercased, can be hard to notice in the middle of the text. For exampleSpends from script foo (Reference Script at 28282838!0)
, orPays to pubkey Clint Eastwood
could becomePays to pubkey [Clint Eastwood]
orSpends from script [foo]
,Pays to pubkey #"Clint Eastwood"
, etc. (I'd keep it like it is for now)Investigate using existential types or something to avoid having to split the names into several sublists for each concrete type. (That would be nice to have)