We only handle top-level objects with an array of objects:
make sure it is one before we call the routines.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
This means we will document deprecations and additions, rather than just
pretending they've always been that way!
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
If there's only a single underscore, lowdown ignores it, but if there are multiple
(see min_final_cltv_expiry) it decides we're trying to highlight part of the word.
Reported-by: @wtogami
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
1. If the tool changes, you need to regenerate since the output may
change.
2. This didn't just filter that out, ignored all but the first
dependency, which made bisecting the bookkeeper plugin a nightmare:
it didn't regenerate the .po file, causing random crashes.
If we want this, try $(filter-out tools/fromschema.py) instead. But I
don't think we want that.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
You can't start a list without a paragraph separator.
```diff
--- /tmp/before 2022-07-20 22:02:23.485372596 +0930
+++ /tmp/after 2022-07-20 22:02:33.745528456 +0930
@@ -21,12 +21,16 @@
On startup of the daemon, no autoclean is set up.
RETURN VALUE
- On success, an object is returned, containing: - enabled (boolean):
- whether invoice autocleaning is active
+ On success, an object is returned, containing:
- If enabled is true: - expired_by (u64): how long an invoice must be ex‐
- pired (seconds) before we delete it - cycle_seconds (u64): how long an
- invoice must be expired (seconds) before we delete it
+ • enabled (boolean): whether invoice autocleaning is active
+
+ If enabled is true:
+
+ • expired_by (u64): how long an invoice must be expired (seconds) be‐
+ fore we delete it
+ • cycle_seconds (u64): how long an invoice must be expired (seconds)
+ before we delete it
AUTHOR
ZmnSCPxj <ZmnSCPxj@protonmail.com> is mainly responsible.
```
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
Mostly comments and docs: some places are actually paths, which
I have avoided changing. We may migrate them slowly, particularly
when they're user-visible.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
I've tried automatically parsing the docs, and these inconsistencies made it harder to do that.
(I tried to do that for a project which I can't share yet, I'm not sure if it'll even work).
After some discussion with @shesek, and my own usage, we agreed that
a more comprehensive interface, which explicitly supports grouping,
is desirable.
Thus keys are now arrays, with the semantic that a key is either a
parent or has a value, never both.
For convenience in the JSON schema, we always return them as arrays,
though we accept simple strings as arguments.
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
We add a generation counter, and allow update or del conditional
on a given generation.
Formalizes error codes, too, since we have more now.
Suggested-by: @shesek
Signed-off-by: Rusty Russell <rusty@rustcorp.com.au>
