rejetto forum

{.set.}

0 Members and 1 Guest are viewing this topic.

Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile
in next build there will be a little change in {.set.} and {.set append.}

the value parameter will not be trimmed anymore.
i think this is a good move, because will easy the task of handling newlines.
you should rarely need to get your value trimmed, and in such cases you should handle it by using {.set|x|{.trim|  yyyyy  .}.}

if you find this to be a bad move, or if this will cause problems, please discuss.


Offline Mars

  • Operator
  • Tireless poster
  • *****
    • Posts: 2039
    • View Profile
I have absolutely nothing against this evolution, for my part I find that it weighs down writings with one {. ¦.} in more.

I shall just utter the following idea:
{.set| .}   and {.set append| .}   not trimmed

{.trimset| .}   and {.trimset append| .}  are trimmed

They are not two  new macros but just a concatenation of macro imbricated two based on the same principle as

{.if|{.not|eval.}|xx.}   or  {.if|eval||xx.}  are replaced by {.if not|eval|xx.}

 ;) to rejetto




Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile
if you like the {.trimset.} instead of just {.set|{.trim.}.} you can make an alias.
{.if|{.not.}.} is equivalent to {.if not.}, but it's not actually replaced.
i see it's a little superfluous, but actually the IF is one of the most used commands.

i may think of putting in HFS a default set of aliases.... :-\


Offline rejetto

  • Administrator
  • Tireless poster
  • *****
    • Posts: 13308
    • View Profile
i didn't understand your last post