Proposal - dumpvariables and search-variables macros are available as a GH Preview

[pmario]

Hi folks,
I did just push a new WIP pull request at GitHub. Dumpvariables rewrite new syntax plus search #7992

The whole thing is work in progress so nothing is fixed yet.

Latest Preview: TiddlyWiki — a non-linear personal web notebook

The dumpvariables macro has a subfilter parameter now

It is proposted to add a “Variables” tab to the AdvancedSearch tiddler

The filtered list can be expanded 2 times.

• The first list shows all global macro titels, that match the filter string
• The second list searches all shadow+tiddlers titles and tags. So it shows, where the macro is used and defined.

Feedback is very welcome here or at GH.

have fun!
mario

[CodaCoder]

One thing I’ve been doing for a while is wrapping <$log...> so that the $$message param contains the location where the call is placed:

\define my-macro()
  <<log my-macro "list of variables">>
...
\end

If you could somehow automatically include the nearest transclusion/parent in dumpvariables that would extremely useful.

[TW_Tones]

Very nice @pmario I will look at this in more detail shortly but it looks very helpful.

My only feedback for now is to list the variables tab before the filters tab. The filters tab is quite different to the other tabs and has being the rightmost for sometime.

• I introduced some tabs of my own and found it frustrating until I reorded them. Having standard search to the left, filter to the right with more specific tabs between.

[pmario]

@CodaCoder

If you could somehow automatically include the nearest transclusion/parent in dumpvariables that would extremely useful.

Transclusion is only set by “real” transclusions and not by macrocalls. So it usually reflects the <<thisTiddler>> variable.

---

I will add the possibility to define some additional suffixes and parameters to the variables-operator. eg:

[variables:raw:include/exclude[var, fn, proc, def, widget]] … Similar to the fields-operator

suffix1:

• sort … default if empty
• raw … Do not sort the result list. This returns “nearby variables” first. Usually the list is long. So we can use limit[x] to shorten the output and still get useful and relevant info

suffix2

• include (default) … The parameter contains eg: var, fn, proc, def, widget. If empty it includes all variables. eg: fn will only show function definitions.
• exclude … will exclude the elements listed in the parameter

eg:

• [variables:raw:include[fn]] will create a raw list of function names
• [variables::include[fn]] will create an alphabetically sorted list of function names

So <<dumpvariables subfilter:"[variables::include[fn]]">> will only list function names and shows the evaluated value.

---

I think it would be also interesting to see the function-name, the parameters and the code. I’m not sure yet how this can be achieved.

may be with a second parameter eg:: [variables::include[fn],[template]]

template could be [variables::include[fn],[\function $name$ ($params$) $code$]]

All the elements surrounded with $ will be replaced by real values. \function and the braces () surrounding the params are just template-text.

This configuration should be very similar to the substitute-operator. So the concept already exists.

Just brainstorming
-mario

[TW_Tones]

@pmario

The second list searches all shadow+tiddlers titles and tags. So it shows, where the macro is used and defined.

This looks great, Do you have information about the definition such that an indicator next to the listed tiddlers could tell us a little more? For example the list below .attr

where M is indicating the Macro definition, otherwise they are tiddlers that use the definition. But if we could also indicate procedure ⓟ or function ⓕ as well would be excellent.

Exclude common variables

Since dump variables mostly return the same values due to all the global definitions, perhaps if we had a list we could use to excluded “standard” and core variables, at least those that exist in empty.html, perhaps this would make custom or local values stand out a little more?

• Similar to excluding standard or core fieldnames after using fields[]] to see those locally in use.

Because dump variables can be affected by its local position?

Dump variables will return different values depending on where it is placed. for example a few levels deep in a nested structure a few variables will be different there than globally. Perhaps one function of the dump variables, could be a button to snapshot all variables at that position and moment, and store them and their values such that they can be read later and or along side reading the code that they existed in?

• Even just dump to a data tiddler and let the designer / user make use of this as they need.

Love your work @pmario

[TW_Tones]

Idea;

The way to open a popup or modal that applies get variables to the results generated by Importing the current tiddler, thus listing all variables defined within the current tiddler, and only those. Perhaps with more information?

[pmario]

@TW_Tones

This looks great, Do you have information about the definition such that an indicator next to the listed tiddlers could tell us a little more? For example the list below .attr

Something as shown in the screenshot? – At the moment the formatTemplate is hardcoded: $type$ $name$$params$ for development. I’m not sure if it can be dynamic. We’ll see.

Opening the the second search now copies the “type” and the “name()” with braces into the search string. So it should be much clearer where it is defined. So the user only needs to delete come text, to “widen” the search.

The problem is that we do not have the info, where a macro is defined, other than a “search”.

@TW_Tones

Since dump variables mostly return the same values due to all the global definitions, perhaps if we had a list we could use to excluded “standard” and core variables, at least those that exist in empty.html, perhaps this would make custom or local values stand out a little more?

Yes. I did think about this too. The “raw” suffix will show variables, that are “near” the macro call first. So I think it should be easy to add a “limit[x]”, which imo is the easiest way. If users set limit to eg: 20, that may be good for most cases.

@TW_Tones

Dump variables will return different values depending on where it is placed.

That’s right. But I think, that’s the usecase, where the <$log/> and <$action-log/> widgets come into play, using the browser dev-console. I’m not sure, if I can get a “context” info from the [variables[]] filter operator.

[CodaCoder]

@pmario Something else you might consider: render the dump into the dom (set display:none). I do this with my $log wrapper. It’s very useful to see the variables evolve throughout the TW rendering process.

But of course, I’d never do this without your subfitler

[pmario]

@CodaCoder

@pmario Something else you might consider: render the dump into the dom (set display:none). I do this with my $log wrapper. It’s very useful to see the variables evolve throughout the TW rendering process.

That’s interesting. But I’d rather add this functionality to the <$log/> widget, since it already creates a DOM node, to be refreshed with the core refresh cycle.

I think dumpvariables and search-variables have a slightly different usecase. – We will see.

-m

[CodaCoder]

@pmario

But I’d rather add this functionality to the <$log/> widget, since it already creates a DOM node,

Where? That screenshot is $log running (inside my wrapper). I don’t see any dom node other than the one my wrapper is creating. Did $eventcatcher throw you off?

And just to be clear, no one wants to do this to $action-log… can you imagine?

[pmario]

@CodaCoder

That screenshot is $log running (inside my wrapper).

Do you have a link to the code? or a JSON with the code?

[CodaCoder]

Sure.

This is the original, a simple wrapper that takes a msg param and a list of vars in extra – this is merely to “tidy up” the $$param assignments and covers 99% of my primary needs.

\define log(msg, extra)
  <$log $$message=<<__msg__>> $$filter=<<__extra__>> />
\end

The msg param I think of as a context so that later, when I see a ton of console output, I know where to find it:

<<log "my-context" "param1 param2 currentTiddler transclusion etc">>

Then I added the in-place dom dump…

\define log(msg, extra)
<style>log {display:none}</style>
<$log $$message=<<__msg__>> $$filter=<<__extra__>> />

<!-- dump the vars into the dom -->
<log msg=<<__msg__>> >
  <$list filter=<<__extra__>> variable=item>
    <log item=<<item>> value={{{ [<item>getvariable[]] }}} /> 
  </$list>
</log>
\end

Hope that’s useful.

[CodaCoder]

@pmario I just took a better look at dumpvariables… wow, it definitely needs your (sub)filter approach. It’s completely unapproachable as it is.

My review also revealed an issue, a “naive” application of background-color to the <pre> element. That’s a cosmetic bug at the very least.

(Yes, I know, report it – maybe later).

Anyway, I await your improvements to DV, moreso than before!

[pmario]

There is a new version at: Latest Preview: TiddlyWiki — a non-linear personal web notebook

It allows you to use the “serach-variables” macro in the AdvancedSearch tiddler → Variables tab.

There is a new VariableFormat tiddler, which describes a new suffix of the format Operator

The variables Operator has a new suffix raw and now accepts a parameter

There are some (3) test-* tiddlers, which I use to test the macro parameters. If macor parameters are “hard coded”, the interactive elements are removed.

Advanced Search → Find the macro definition

have fun!
mario

[TW_Tones]

@pmario this is very impressive and provides a considerable resource and way to explore tiddlywiki, good work.

Many of the advantages of this should be called out but for now some quick constructive comments. I am raising them at a high level and can give more detail of needed.

• the current layout of results is not so easy to read, especialy in mobile.
  • The red colour of the single back tick is not appropriate and would be better with a gray background more like the tripple back tick style, however something similar but different could be used when displaying the value.
  • placing a border arround expanded sections, at least the first (outer) would help see where related content begins and ends.
  • if you used different symbols for the expand and colapse buttons it would help eg > and >> to see where you are and find the appropriate close.
• as came up elsewhere please ensure filters handle both shadows+tiddlers if the documentation and other resources were stored in a plugin

Trying to take a naïve reader perspective these are not so much variables, as there definitions, and could confuse. We are comfortable with this output but it could scare code shy people, so perhaps there could be a simplified and advanced view perhaps simplified could be a curated set of key core variables and tv- variables?. Perhaps the ability to exclude the documentation or ‘.variables’ for tiddlywiki would help.

It would be interesting to see if there were a way to tie definitions back to the documentation more clearly?

At least on tiddlywiki.com When the definition tiddler is known tags and other relationships could help.

Love you work !

[pmario]

\procedure my-macro()
  <$log $$message="my-macro" $$filter="thisTiddler list of variables"/>
...
\end

With the latest version of TW the thisTiddler always is where the macro is called, even if that tiddler is transcluded as a template.