All right, the new proposal is the following (passed tests, aside the 76 o):
current slicesRE:
/(?:^([\'\/]{0,2})~?([\.\w]+)\:\1[\t\x20]*([^\n]+)[\t\x20]*$)|
(?:^\|
([\'\/]{0,2})~?([^\|\n\f\r\t]*[^\|\n\f\r\t\:\x20])\:?\4\t*
\|[\t\x20]*([^\n]+)[\t\x20]*\|
$)
/gm;
where the third line is the slicename with wrappers, which is
([\'\/]{0,2})
~?
([^\|\n\f\r\t]*[^\|\n\f\r\t\:\x20])
\:?
\4
\t*
where the longest line is the slicename matching thing itself.
The name is proposed to become
[^\|\s\:\~\'\/]
|
(?:[^\|\s~\'\/][^\|\n\f\r]*[^\|\s\:\'\/])
The first line is one-symbol sliceName, both ~ and : are forbidden;
the third is 2+ symbol sliceName, all leading/trailing white-space symbols
[inside the slice name] are forbidden, but spaces/tabs are permitted inside
the slice name.
The proposed wrapper is
\x20?
([\'\/]{0,2})
~?
([^\|\s\:\~\'\/]|(?:[^\|\s~\'\/][^\|\n\f\r]*[^\|\s\:\'\/]))
\:?
\4
[\x20\t]*
so only one leading space is allowed (can't imagine other needs) and
arbitrary quantity of trailing spaces/tabs, which all are not included to
the sliceName.
The final version of the RE is
/(?:^([\'\/]{0,2})~?([\.\w]+)\:\1[\t\x20]*([^\n]+)[\t\x20]*$)|(?:^\|\x20?([\'\/]{0,2})~?([^\|\s\:\~\'\/]|(?:[^\|\s~\'\/][^\|\n\f\r]*[^\|\s\:\'\/]))\:?\4[\x20\t]*\|[\t\x20]*([^\n]+)[\t\x20]*\|$)/gm;
which is somewhat longer than the previous one:
/(?:^([\'\/]{0,2})~?([\.\w]+)\:\1[\t\x20]*([^\n]+)[\t\x20]*$)|(?:^\|([\'\/]{0,2})~?([^\|\n\f\r\t]*[^\|\n\f\r\t\:\x20])\:?\4\t*\|[\t\x20]*([^\n]+)[\t\x20]*\|$)/gm;
In principle, this can be artificially shortened: we can forbid sliceNames
starting with ":" and change
[^\|\s\:\~\'\/]|(?:[^\|\s~\'\/][^\|\n\f\r]*[^\|\s\:\'\/])
to
([^\|\s~\'\/\:](?:[^\|\n\f\r]*[^\|\'\/~\s\:])?)
but I don't think that makes much difference.
The version which I mentioned as "final" is pushed with a short summary
[1], see in comments.
> all variations with quotes, double square brackets, etc
Those weren't supported before, and actually slicename wrapped into *both*
// and '' is not a slicename (only one wrapper is allowed). Even supporting
"[[" will complicate the code significantly, as far as I can see.
As for the performance, I don't know about this impact either. Though,
slices are not typically calculated in all tiddlers at once, so I wound't
expect any problems with this.
Best regards,
Yakov.
[1] https://github.com/TiddlyWiki/tiddlywiki/pull/112
среда, 30 января 2013 г., 16:26:37 UTC+4 пользователь Tobias Beer написал:
>
> Hi again,
>
> Thanks for the clarification / reminder, Yakov.
>
> So yes, for tables I would say it makes perfect sense to allow for leading
> or trailing blanks and then strip them ...assuming all of that doesn't come
> with too much overhead in terms of code / performance. Let's just say, I
> have no clue of the overal peformance impact of (altering) slice
> calculations.
>
> So...
>
> |var|val|
> or
> | var|val|
> or
> |var |val|
> or
> | var |val|
>
> ...and all variations with quotes, double square brackets, etc.... should
> be valid ...from my perspective.
>
> Cheers, Tobias.
>
--
You received this message because you are subscribed to the Google Groups
"TiddlyWikiDev" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To post to this group, send email to [email protected].
Visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
