i'm just gonna work straight on the goal, communication later.  I get distracted like an explorer bee.

ummmm

the plan is to mostly keep the code the same.

- we can pull out the second option setting call

- we can change the

no wait ... it needs to transform the option when set.

ok so

- pull out the second option setting call

- change the condition in the handler to relate to the init list

sounds reasonable.  i'll change it in the commit it's made in, or make a further commit.

ok let's see what commit i'm in right now.  it's 1757.

I think i'll make a new worktree and walk through my existing commits.

it's 1759 and i'm about to bail!  oh no!  I already made the worktree!

let's try not to bail when when all-day-attempt.  1759.  made worktree.  plan was to reset worktree to first commit.  here go.

1800

1803

I picked up some food and spilled it around so my task now is cleaning the food up.

i'm having trouble controlling my hands to clean the food

taking it slower

ok my right hand is working a lot better than my left so I can hold a light with my left hand and clean with my right.  1805.

1809 and the food is cleaned sufficiently.  I was unaware I had such issues directing the fingers of my left hand independently, but now i've briefly experienced it.

1810 back to task.

so, all the code for mutation is in my rebase.  maybe I can open up the origin commits and change the check.

additionally, i'll want to change the thingy with the other thingy. i'll look at it 1811.

1812

all the changes are in the squash rebase, i'll open it up !

1818

ok I think I noticed an error in the main tree.

on windows, when an option is set on the default context, it would dereference a null pointer

it looks like it was introduced during the set_option kerfluffle

i'll visit the github

1821

ok I was thinking of an old version of the code.

when null is provided, the backend is _not_ presently called the first time.

that is, it looks like presently, the backend is only called in non-null situations.  the ctx pointer is always valid.

mutating my code is the way forward.

while github is open i'll submit the simplification.

1829

I totally replied to the comment on my pr!  I am such a social butterinsect!  butterinsecting everywhere I go ...

ok i'm a little confused around how to handle all the stacked rebases.  i'm kind of interested in going back to my original dev tree, and bringing it to consistency with the latest stable rebase.

some inhibition.

it's 1832 !

woohoo!  1832!  I am spamming a list on the internet and it's 1832.

near me is a laptop with github open.

the temperature is dropping now the sun has set.

i'll move the laptop to a dev terminal.

dev terminal instead of github!  yay!

maybe i'll just fix up my last rebase

and maybe add a commit to handle things

maybe I won't keep a new rebase yet, but use the previous rebase

1834

1912

i've pushed two commits.  just small obvious stuff.  but i've decided to try to work off the rebase branch I already linked the other guy to.

not sure what's next ummmmmm changing the check in options I think

1915 looking for the code, distracted again

1916

1958

so, there's a big issue, which is that my option takes a parameter, and the current code doesn't provide for that.

i've spent what feels like the entire day today, after planning to work on this for a few days, resisting my psychological issues and trying to make progress on it, and i'm maybe a little bit farther than I was three days ago.  I spent most of the day recovering confused ground.