To get $cb to fill a %variable/&binvar, we have to pass a non $null and a value different from 'u' as the second parameter,

Code:

//clipboard test | var %a | noop $cb(-1,,%a) | echo -a > %a < not good
vs
//clipboard test | var %a | noop $cb(-1,non-null,%a) | echo -a > %a < good
vs
//clipboard tést | var %a | noop $cb(-1,u,%a) | echo -a > %a < good

I'd like to be able to pass $null since passing a non null value doesn't make much sense
Scratch that I don't know what I did but that first line works fine.

This latest change to $cb() needs a fair bit of testing as it required a partial rewrite. If you spot anything odd, please let me know.

Well one thing that is odd is that I was pretty sure I tested correctly and that it didn't fill my variable
Other than that we checked it with maroon and we didn't spot anything wrong.
One thing is that perhaps $cb(-1,u).len could return the lenght of the utf8 encoded text, currently it seems like $cb().len ignores ,u,

$cb(N,2ndparameter,%var|&binvar)

36.Extended $cb() to support output to a %var|&binvar as third parameter
and to return length. If N == -1, stores entire clipboard.

Does the enhancement to $cb make it a binary command elegible for the 'a' switch given to other binary commands? And if so, would the "as long as no chars > 255" apply across the entire clipboard or be on a line-by-line basis when N=0 or -1?

It appears the 2nd parameter allows $null and has so far been defined only for the presence or absence of 'u'. The u-vs-$null has no effect when 3rd parameter is &binvar, nor for .len when N is 0 or -1.

$cb(0).len and $cb(-1).len appear to be the same thing, regardless whether 2nd parameter 'u' is used. The '1' tokens appear to be errors:



Also, it looks like $cb(-1).len now behaves the same way as the existing $cb(0).len in all cases I've checked, except that .len is ignored when used while using incorrectly to load a &binvar:

Please provide an example so I can test it here.

$cb(-1,u) returns two characters but with the .len property, it returns 1.

Thanks this issue has been fixed for the next version.

This still returns 1

Thanks this issue has been fixed for the next version. That said, there is lot going on in the $cb() routine now. It will need heavy testing in the next beta.

Hum, what has been fixed exactly? Shouldn't $cb(0,u).len ignores both the u parameter and the .len property since 0 has been passed?
If 0 returns the total number of lines in the clipboard, the utf8 version of a string of number is always that string of number, so it would not be making any sense to want such information, $cb(0) is always equal to $cb(0,u), isn't it?
And then, it does not make much sense to me to get the lenght of the total number of lines. It is to be assumed that the total number of lines is never going to be a number that is more than 4150 characters in which case $len($cb(0)) can always be used.
It would be consistent with other identifier's N parameter referring to a list to ignore ,u, and .len here and to keep returning the total number of lines in the clipboard

Nevermind this last post, I forgot/didn't know that $cb(0).len is documented and meant to return the lenght of the full clipboard and that the fix is just about preserving backward compatibility.

Any chance of giving /clipboard &binvar support, so we can use the new $cb() support of &binvar to modify the clipboard contents?

I was writing up this request but hadn't posted it, so here goes.

Adding a -b switch to /clipboard to allow restoring the clipboard from a &binvar, complementing the current $cb(-1,,&binvar) saving clipboard to binvar.

This would make it possible to accurately restore the prior multi-line contents of the clipboard, as the current clipboard /command isn't able to preserve leading/trailing/consecutive spaces. Nor can /clipboard restore clipboards longer than 4150 characters.