Dear friends
This is the ultimate goal of doing this manually
|tc-center|k
| 1. python |
| 2. java |
| 3. julia |
The effect is as follows
I came up with a method that only shows the outermost box of the table, but what I wanted was to show an automatically sorted numeric sequence number in each cell
<!-- 在Markdown中嵌入HTML来创建有序列表 -->
|tc-center|k
| <ol><li>Python</li><li>Java</li><li>Julia</li></ol> |
Is there a better way
Any reply would be greatly appreciated
I’m pretty sure that there are more choices to achieve what you want in TiddlyWiki.
Here’s my try:
\procedure numtable(input:"")
<table class="tc-center">
<$list filter="[enlist<input>]" counter="index">
<tr>
<td><<index>>. <<currentTiddler>></td>
</tr>
</$list>
</table>
\end
Manually numbered:
|tc-center|k
|1. python|
|2. java|
|3. julia|
---
Auto-numbered:
<<numtable "python java julia">>
-rr
Edit: add some more information:
The output shows two tables, the first is your manually created table and the second is a macro-generated table.
It takes space-separated strings as an input which are converted to a list with the enlist operator. This is the input for the ListWidget . The output of the ListWidget is numbered with the counter parameter and the current value is available within the index variable.
Each line of the table is generated by line <td><<index>>. <<currentTiddler>></td>.
If you rearrange the input string “python java julia” - e.g. “java python julia” the numbers are still from 1 to 3, but the text has changed.
You are right - as far as I know it is the only way to made it available everywhere.
Pasting it into every tiddler you need this macro would be no real fun 
Please check the import pragma.
Now that is interesting, thank you.
Are there any disadvatanges when using the global-tag instead of the import widget/pragma - like in slower performance, for instance?
For most wikis this will not be an issue, you can have a lot of global macros/procedures/variables without any problems.
I see, thanks for the summary!
@XYZ - here is an extended solution, just in case that you need to list a programming language with spaces in it’s name. I don’t know which programming language contains really spaces in it’s name, but just for the case.
\procedure exnumtable(input:"" splitby:" ")
<table class="tc-center">
<$list filter="[<input>split<splitby>]" counter="index">
<tr>
<td><<index>>. <<currentTiddler>></td>
</tr>
</$list>
</table>
\end
By default the split char is a single space, but you can choose whichever char do you like.
For instance:
<<exnumtable input:"python;c++;java;julia;some other language" splitby:";">>
The difference will be not really measurable. There is a global import filter configuration, which is used in the PageTemplate at the top of the tiddler.
It actually is an \import [subfilter{$:/core/config/GlobalImportFilter}]. So it does the same thing in a “global” context. That’s why “variables” tagged $:/tags/Global can be seen everywhere.
As Tony wrote, you only need to use \import in a tiddler, for variables that are not tagged for global use.
Thanks, @pmario for sharing more technical details.
This is a feature to share it with specific tiddlers instead of the whole wiki.
In other words: it is better to water in spots than to water everything with a large watering can.
Yes. The advantage is, that you exactly “know what you get”.
With the global import, that last “variable” defined with the “same name” will be the one, that you get.
As the import-mechanism was created (in the early days), there was “local” import only. But it is inconvenient, if you manually need to keep track where your “stuff” is 
Especially since the tiddler naming conventions where still unstable.
So it was pretty clear, that we need a “global” import, even if it means that there is a higher chance of “naming collisions”. There are always “pros” and “cons”.
ok, that makes sense to me.
Thanks also for the excursion into the beginnings of Tiddlywiki, for me as a late starter it’s always very interesting.
Off-topic:
By the way, I still can’t understand why I didn’t discover it earlier, because it’s extremely useful for me and I discover new applications every day. I’m really grateful for the software, it’s really great and exactly what I needed 
I can understand that and I consider the import pragma to be a successful way of skilfully avoiding possible conflicts in the naming.
@RetRoland interestingly the Opposite is also true; Some times we want conflict 
We can use the import pragma to import macros or procedures in a specific location that have the same names as existing global macros, in effect locally replacing the global macro. For example you may want to override a macro to include a new feature, but rather than reinvent the wheel, clone, and modify an existing macro/procedure, importing the new version only where needed.
You’re right, I wasn’t thinking about that when I wrote those lines.
My usual workflow was to copy the old macro (located n a global macro tiddler) and add a consecutive number (e.g. funkymacro2) - the new features were then tested accordingly with <<funkymacro2>>.
As soon as it worked, I deleted the old funkymacro and renamed the funkymacro2 back to funkymacro.
Not nifty at all, but it worked to preserve the working (old) macro while working on a newer version.
[Edited] added backticks to macros for better readabilty, too - was a bit in a hurry when writing the first message