dynamically building a string by concatenation in a macro

[CarloGgi]

hallo folks,
i need to feed the $template parameter of an <$action-createtiddler> widget with the correct template tiddler's name. The latter has a fixed part 'BASENAME' and a parameterized (or variable) suffix, which is choosen by means of a <$select> input. The idea is to have a macro build the full name based on the choice made by using <$select>, like in:

\define templatename() BASENAME-{{!!grammar_class}}

the suffix, as you can imagine, is taken from field grammar_class which is set by the <$select> widget control.

Now one would expect that things would work nice and easy writing this code:

<$button> create new test tiddler
         <$action-createtiddler
                 $basetitle='testTiddler'
                 $template=<<templatename>> >
                 <$action-navigate $to=<<createTiddler-title>>/>
         </$action-createtiddler>
</$button>

but disappointingly enough they do not! The new tiddler is created indeed, but from NO TEMPLATE at all!
Funny as it is, if we add a debug line like:

template's name: <<templatename>> <br/>

it displays correctly as

    BASENAME-verb (or BASENAME-noun, or adjective, or whatever the <$select> choice was)

Hard-coding the name in the macro makes the code work (just for testing purposes, there is no point here to have a macro just echoing an hard-coded string).

Now, before I ask why ON EARTH the above code doesn't work, let me say that I expect for it to be because of how macros are parsed and when macro substitution is made, in which case I will do a little comment on it later.

Thanks everybody,
CG

[Charlie Veniot]

I'm thinking you found a bug related to how the action-createtiddler handles the $template parameter.

In the meantime (i.e. until there is a fix or somebody can explain this "feature" going on) ...

The following seems to work A-1 for me in my testing (ignore the "pre" tags):

<pre>

<$button>
         <$action-createtiddler
                 $basetitle="testTiddler"
                 $template={{{ [[BASENAME-]addsuffix{!!grammar_class}] }}} >

                 <$action-navigate $to=<<createTiddler-title>>/>
         </$action-createtiddler>

 create new test tiddler
</$button>

</pre>

[Charlie Veniot]

TiddlyTalk is a pain.  Let me try pasting that code again so that it shows okay over there.

```

<$button>
         <$action-createtiddler
                 $basetitle="testTiddler"
                 $template={{{ [[BASENAME-]addsuffix{!!grammar_class}] }}} >

                 <$action-navigate $to=<<createTiddler-title>>/>
         </$action-createtiddler>

 create new test tiddler
</$button>

```

[CarloGgi]

It worked like a charm, thanks!

If it is really a bug, is there a dedicated place to submit it for analysis?

My TW version is 5.2.0

Thanks again and regards,

CG

[Charlie Veniot]

Good stuff !  

I often say "first things first, consider upgrading", but 5.2.1 has the same issue.  So I say stick with what you have if it is working no-worse than the latest.

As for bug-reporting, that, to me, is a crappy process that needs some tender loving care, including a need to update the related circa 2014 documentation (ReportingBugs).

If I had my way, there would be a pretty form for you to fill out (Google Form or other), but I am rather nit-picky ...

Rock'n roll !

[Jeremy Ruston]

Hi Charlie

I often say "first things first, consider upgrading", but 5.2.1 has the same issue.  So I say stick with what you have if it is working no-worse than the latest.

The problem is that the OP is using the macro "templatename" as an attribute value in the `<$action-createtiddler>` widget, which means that wikitext content will not be processed ("wikified"), so the transclusion in the macro is ignored.

The workaround is to use textual substitution within the macro (in other words the $param$ and $(var)$ syntax).

As for bug-reporting, that, to me, is a crappy process that needs some tender loving care, including a need to update the related circa 2014 documentation (ReportingBugs).

"Crappy"?

It would be more helpful to explain the specific problems you see, and perhaps suggest improvements.

Best wishes

Jeremy

--
You received this message because you are subscribed to the Google Groups "TiddlyWiki" group.
To unsubscribe from this group and stop receiving emails from it, send an email to tiddlywiki+...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/13f797cd-fc5f-457d-b598-80cfa214a017n%40googlegroups.com.

[Charlie Veniot]

Simply stated:  use a Google Form (or something similar) to submit bugs.

• Cognitively and in terms of sensory-overload, Github is brutal in general, but especially when one is dealing with a cognitive disability.  I can't offer up suggestions on how to change the Github interface, because I don't know if it is possible to change it, and it is too overwhelming for me to go digging into it to figure that out
  • Both Github and that ReportingBugs tiddler: way too frigging much to look at, everything is competing for attention, and I have attention-regulation difficulties, so I don't know where to look:  I desperately want to just click a button and type in text related to a problem
• A major turn off for anybody not technically inclined, and a turnoff to create yet another account somewhere just to report a bug
  • sure a person does not need to use Github to report a bug, but the documentation on reporting bugs gives so much prominence to github, that it feels like it is the preferred method, and the other options seem like an afterthought, a kind of "if you must";
  • regardless, how many clicks does it take to report a bug?  Way more effort than it should be looking at that ReportingBugs tiddler
  • Yeah, I'm a career Information Systems Programmer/Analyst, but I don't like technical when I'm wearing my "user" hat
• The ReportingBugs documentation needs to be simplified something silly:  ideally, it should have only this one line: "click on this link/button and fill out this bug report form"
  • If everything else really matters, cleave that into some other tiddler called something like "Bug Management", and put a link to that mess of details  on the ReportingBugs tiddler for the few folk who really want to see all of that
• Use a simple and friendly form (Google Forms or other) that requires no account and no sign: one standard spot with just the necessary help/documentation to submit a bug from that spot;  how that bug is managed after I hit Submit, I don't care (but if you want to add a note at the bottom about tracking the bug in Github, that's A-1)
  • I'm no fan of using posts in discussion groups for reporting bugs; better a visible link/button to click on and get to that form and filling it out
    • But TiddlyTalk is, to me, a much better place to discuss a bug (from user perspective, not technical discussions), so something that generates a post in TiddlyTalk (as part of submitting a form, or as part of processing the form, or whatever), that would be cool.
    • Regardless, if I want to report a bug, I'm likely to go to TiddlyWiki.com, and click on a "report a bug" button

Now everything to me is connected to everything else.  So I could go on and on and on.  But there are too many intertwingled details in my head to sort out and neatly summarize.

If I'm sounding always frustrated and annoyed, it is because I am cognitively overstimulated (along with sensory overload) 24x7.  The question of how to report a bug should have been as easy as me simply saying: click on this button.  But it isn't.  And now I'm consumed by thoughts of "why do they make things so busy and/or complicated?"  And now I'm in a rabbit hole I really don't want to be in.   Mmm, rabbit ...

[CarloGgi]

@jeremy thanks for the clarification. So it seems that you can correctly (in the sense of *syntactically* correct) use a macro call as argument of a widget attribute, but functionally fail to have it work as intended. This shows clearly that TW is way too much stuffed with booby-traps and something must be definitely done to make coding easier and safer for the average user.

We need a stricter syntax, even at the expense of flexibility, to spare the user from these pitfalls, and we need debugging tools to make him easily single out the problem when syntax doesn't help. We cannot go on relying on knowledge of how the parser and 'wikifier' behaves, it simply cannot be viable if TW is to become widely used as is everybody's wish.

I'm not a complete beginner in programming, and as a matter of fact I spend 50% of coding time trying to debug obscure malfunctioning that mostly turns out to require a developer-level knowledge of the parser to be worked out: I dare say that this scares away a lot of would-be users after the first, frustrating attempts.

In the meantime that TW morphs to something less tricky, a huge effort should be done IMHO in bettering the documentation so that the user is aware of the pitfalls left open by its syntax.

Thanks and regards,

CG

[Jeremy Ruston]

My reply used the jargon because I was being brief.

It's really not as irregular as it appears; it's largely a matter of ones terms of reference. It's like the difference between an expression and a string literal `a=b+c` and `a="b+c"`, if you're familiar with programming languages.

A simple tranclusion like the following works in two distinct steps: first, it retrieves the text of the tiddler "foobar", and then it recursively processes the retrieved text as if it had appeared in the same place as the transclusion. This deals with any wikitext within it.

```

{{foobar}}

```

In the case of using a transclusion as an attribute we get the same actions: it retrieves the text of the transcluded tiddler and then treats the text as if it had appeared in the same place as the transclusion, which means that it is treated as a literal string.

```

<div id={{foobar}}>

```

Best wishes

Jeremy

--

Jeremy Ruston

jer...@jermolene.com

https://jermolene.com

On 23 Jan 2022, at 12:32, CarloGgi via Talk TW <nor...@talk.tiddlywiki.org> wrote:



To view this discussion on the web visit https://groups.google.com/d/msgid/tiddlywiki/961c6974-ef92-487a-8b05-40859ea4db32n%40googlegroups.com.

[Brian Theado]

Jeremy,

That is a very enlightening way of explaining it. I wasn't sure where in the docs this exact explanation would fit, but I did make a PR at https://github.com/Jermolene/TiddlyWiki5/pull/6417 which adds warnings about the non-recursive nature of attribute value processing.

On Sun, Jan 23, 2022 at 8:41 AM Jeremy Ruston <jeremy...@gmail.com> wrote:

[...]

[PMario]

On Saturday, January 22, 2022 at 7:07:59 PM UTC+1 CarloGgi wrote:

...

Now, before I ask why ON EARTH the above code doesn't work, let me say that I expect for it to be because of how macros are parsed and when macro substitution is made, in which case I will do a little comment on it later.

There is some docs about string concatenation. https://tiddlywiki.com/#Concatenating%20text%20and%20variables%20using%20macro%20substitution

-m