Quote
{.from table|pot1=vert|pot2=jaune|pot3=rouge|pot5=violet|pot4=noir
|pot3.}
this is the {.switch.}
I do not believe that their functionings are identical same if under the shape which I propose they get closer to it but in a very particular case.
You cannot use
{.from table|pot1
,pot10=vert|pot2
,pot20=jaune|pot3
,pot30=rouge|pot5
,pot50=violet|pot4
,pot40=noir|
pot3.}
with the same result as
{.switch|
pot3|,|pot1
,pot10|vert|pot2
,pot20|jaune|pot3
,pot30|rouge|pot5
,pot50|violet|pot4
,pot40|noir| elsevalue.}
Which gives a result by default if there is no correspondence.
****************************************************************
{.set|special:strings|
a=1
b=2
c=3
.}
{.!b.}
this is 3.
i don't understand if you are trying to report a bug or not. If yes, please provide a way to reproduce it (what you do, what you get, what you expected).
This is a particular use for the case of the variable {.set|special:strings|.... as a masqued possibility,
I know nobody who would have had the idea to use it because the section foreseen for that exists. Excepted maybe TSG?
.
If you modify the fromtable() procedure as I proposed it, then we can amputate the code of fromtable('special:string') and use correctly with the same result :
{.set|special:strings|
a=1
b=2
c=3
.}
{.from table|{.^special:strings.}|b.}
******************************************************************
Quote
using [special:string] is caching. if this section is changed we can see only old values, not the refresh:
changed? how? can you make an example?
It has to correspond certainly to an old ghost bug which I had owed noticed in a previous build, I did not manage to reproduce, certainly corrected involuntarily since the build 222 with its big modifications, I shall experience with more hurdy-gurdies versions to confirm my error.
******************************************************************
Quote
To be able to use the macro ' from table ' it is compulsory to spend by macro 'set' and the associated variables, my version of this macro allows the users to spend the other values, but it is sometimes boring to use one macro 'set' with 150 lines in the continuation, while by separating every line by one' |' , we can write it on one or several lines
if you feel uncomfortable with too many lines, you may solve it with a user-macro that will replace a string you decide with the newline.
if this cannot be done, we can work on it.
Quote
and why not the possibility:
{.from table|{section|mysection|myfile.}|valuesearch.}
you just have to {.set.} first.
if you don't like the double step, you can {.set.} your macro (or maybe an alias)
It is true that we can always create alias from other alias, but it extends the length of the template and increases the possibility of errors, while to spread the possibilities of certain macro can allow certain forms of use to determine more quickly where can be an error which we would manage not to encircle at normal time.
I thus maintain my demand, indeed by reminding that it modifies not at all the normal functioning of the macro current.
*******************************************************************
Quote
I shall thus end by a quetion,without expectation of answer :
Why to use the macro MOVE, while we have COPY and DELETE who combined together make the same work
is move always the same as copy+delete? answer: no.
Set apart a remainder of the file in the local recycledbin, from the point of view of hfs the result is identical