Further questions about pull requests and testing core

[Yakov]

Hi.

after making the first pull request [1], I've got two issues:

first, Mario pointed that there's a problem with my code according to tests [2], but I don't know how to build a test wiki under Windows. Can anyone help with this?

Second, I've done a small change in my commit [3] (without tests, I don't know whether it's a fix, it's just more consistent), but as the previous request is not accepted or declined, I can't push a new one (from this branch). What do I do in such a situation? Can I withdraw it? Or is the new commit added to the first Pull Request (a comment titled "YakovL added a commit" is added to the discussion of the request)?

Yakov.

[1] https://groups.google.com/forum/?fromgroups=#!topic/tiddlywikidev/O3NiED8Lk9c

[2] https://github.com/TiddlyWiki/tiddlywiki/pull/112

[3] https://github.com/YakovL/tiddlywiki/commit/86fbd9511a9292767485e66e33e4401cd7846d9b

[Jeremy Ruston]

Hi Yakov

I'm afraid I can't help with the first question, but as to the second when I view the pull request on github.com I can only see an option to merge it, and I don't see any option to reject it. From observing pull requests made by others I got the impression that the sender can modify them after they are sent but before they are accepted.

Best wishes

Jeremy

--

Jeremy Ruston

jeremy...@gmail.com

--
You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.
To view this discussion on the web visit https://groups.google.com/d/msg/tiddlywikidev/-/CLRGFzSFuqoJ.
To post to this group, send email to tiddly...@googlegroups.com.
To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.
For more options, visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.

[PMario]

On 2 Jan., 20:10, Yakov <yakov.litvin.publi...@gmail.com> wrote:
> first, Mario pointed that there's a problem with my code according to tests
> [2], but I don't know how to build a test wiki under Windows. Can anyone
> help with this?

> Second, I've done a small change in my commit [3] (without tests, I don't
> know whether it's a fix, it's just more consistent), but as the previous
> request is not accepted or declined, I can't push a new one (from this
> branch). What do I do in such a situation?

just push it again to the same branch. It adds up. So if merged, it
will get the latest version.

I'll run a new test and create 2 gists. One with the vanilla version
and one with your patch (if possible).

> Can I withdraw it? Or is the new
> commit added to the first Pull Request (a comment titled "YakovL added a
> commit" is added to the discussion of the request)?

The easiest way to withdraw, is to close it. So it can be reopened
later. I don't know, what happens if you remove your branch after
closing a "not merged" pull request.
but ...
I wouldn't close it atm, just push your new version.

I don't know, how to build TW with win. I switched my main OS, since,
for me, win doesn't play nice with open source projects.

-m

[PMario]

I did create a gist with the tests.html. created from master
(SHA:ef9683e902ab7c63bcabf9c65ae9e28cf6730455)

see the 2 revisions / versions
https://gist.github.com/4444413/revisions

If you click the links below, you can download and test them. See test
No. 76

tests.html with yakov's slicesRE
https://gist.github.com/4444413/69eeb445a033fef5e20c53e768d514e118b5143a

tests.html vanilla latest master
https://gist.github.com/4444413/41f2aa49b33859220acb33e134624ec52f1312fa


have fun!
mario

[Yakov]

Thanks guys for the answers and for the test assemblies. Most probably, I'll continue my investigation after the 17th of Jan (after my Master's degree exam).

Best regards,

Yakov.

четверг, 3 января 2013 г., 20:06:54 UTC+4 пользователь PMario написал:

[Yakov]

Ah, ok, I can see the problem with 76 q, t, u. Fair enouth, that's needed at least for some backward compability, currently ":" in the end is taken to the slicename, this is to be fixed.

On the other hand, I don't know why 76 o is problematic? Adding spaces to slice names is somewhat useful for more human-readable tables, especially those generated by the GridPlugin (from TiddlyTools). Does anyone know any background, reason for this restriction? Any core functions relying on this? Of'course I can just forbid spaces, but that's a major restriction..

Seems that new commits are automatically added to the pull request, at least on the page [1] the "commits" tab has the counter with a value "2". I'll update the slicesRE as soon as I fix the q, t, u issues. It seems that for testing I can just change the code of those assemblies Mario made.

Best regards,

Yakov.

[1] https://github.com/TiddlyWiki/tiddlywiki/pull/112/files

четверг, 3 января 2013 г., 20:06:54 UTC+4 пользователь PMario написал:

I did create a gist with the tests.html. created from master

[Yakov]

Ok, problems in tests 76 q, t, u are now fixed.

[PMario]

On 24 Jan., 20:53, Yakov <yakov.litvin.publi...@gmail.com> wrote:
> Ah, ok, I can see the problem with 76 q, t, u. Fair enouth, that's needed
> at least for some backward compability, currently ":" in the end is taken
> to the slicename, this is to be fixed.

right

> On the other hand, I don't know why 76 o is problematic? Adding spaces to
> slice names is somewhat useful for more human-readable tables, especially
> those generated by the GridPlugin (from TiddlyTools). Does anyone know any
> background, reason for this restriction? Any core functions relying on
> this? Of'course I can just forbid spaces, but that's a major restriction..

I think it is because of
output = slices["foo bar"] is valid. At least js can handle it.
output = slices.foo bar ... won't work.

I think anybody creating plugins, that deal with slices, should use
the 1st notation. It is more obvious, that there is something special
going on.

So
+1 from me to accept spaces in slices, if they really work. (I didn't
test it). I think there is no backwards compatibility problem.
Because, TW just didn't work if slices did contain spaces. So users
did change them to get it working. Slices that have spaces but are not
used aren't problems anyway.

what do others think?

-m

[PMario]

On 8 Jan., 20:36, Yakov <yakov.litvin.publi...@gmail.com> wrote:
> Thanks guys for the answers and for the test assemblies. Most probably,
> I'll continue my investigation after the 17th of Jan (after my Master's
> degree exam).

How was your exam going ?:)

[Yakov]

Ah, quite nicely, thanks :) The highest mark.

воскресенье, 27 января 2013 г., 15:46:47 UTC+4 пользователь PMario написал:

[Yakov]

I'm a bit confused with these two threads duplicating one another, let's continue discussion here write some "milestones" in GitHub.

> On the other hand, I don't know why 76 o is problematic? Adding spaces to 
> slice names is somewhat useful for more human-readable tables, especially
> those generated by the GridPlugin (from TiddlyTools). Does anyone know any
> background, reason for this restriction? Any core functions relying on
> this? Of'course I can just forbid spaces, but that's a major restriction..
I think it is because of
output = slices["foo bar"] is valid. At least js can handle it.
output = slices.foo bar ... won't work.

I think anybody creating plugins, that deal with slices, should use
the 1st notation. It is more obvious, that there is something special
going on.

So
+1 from me to accept spaces in slices, if they really work. (I didn't
test it). I think there is no backwards compatibility problem.
Because, TW just didn't work if slices did contain spaces. So users
did change them to get it working. Slices that have spaces but are not
used aren't problems anyway.

In fact, plugins should probably have another issue. I can't imagine how the one you mentioned can even be an issue: usually there is a variable:

var sliceName;

...

output = slices[sliceName];

instead of a constant, and in this case the dot notation can't be used (right?).

On the other hand, some plugins use syntax which won't be compatible with the slices with spaces: for instance, in GridPlugin [1] the colomns parameter of the grid macro accepts a space-separated list of "colomns"; it seems that it doesn't support sections and fields with spaces in names as well. But this has nothing to do with backward-compability anyway.

In GitHub, you also asked about tabs..

currently, the following symbols are forbidden in slice names: \|\n\f\r\t ; among these,

\f\r\t

are arguable. Tabs currently are allowed after the slicename to create approptiate indents (to make a table look like a table in wikitext). An important note: currently, all other white-space is taken to the slicename. Do you propose to allow tabs within slicename (except as the last symbol)? Or may be to handle tabs in the beginning of the cell as white-space, not a part of the slicename? Also, may be the same thing should be done with spaces (don't put spaces in the beginning of the cell to the slicename)? This seems to be excessive snd will complicate slicesRE more, but can be done in principle. Note: allowing tabs within slicename is an extension, meaning that if we don't do it now, we can do it later with backward-compability, but not vice versa. On the other hand, the space-treating behavior (what to do with those in the beginning) is not extendable in either direction, we have to decide it now.

As for the \f and \r symbols, I'm not sure because they mostly appear in other OSs: for instance, according to wiki [2], \r is used in Mac OS to break lines in text files; I'm not sure about browsers.

[1] http://tiddlytools.com/#GridPluginInfo

[2] http://en.wikipedia.org/wiki/Control_character#In_ASCII

[Jeremy Ruston]

Ah, quite nicely, thanks :) The highest mark.

Hi Yakov

That is good news, congratulations,

Best wishes

Jeremy

воскресенье, 27 января 2013 г., 15:46:47 UTC+4 пользователь PMario написал:

On 8 Jan., 20:36, Yakov <yakov.litvin.publi...@gmail.com> wrote:
> Thanks guys for the answers and for the test assemblies. Most probably,
> I'll continue my investigation after the 17th of Jan (after my Master's
> degree exam).
How was your exam going ?:)

--

You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group.

To post to this group, send email to tiddly...@googlegroups.com.
To unsubscribe from this group, send email to tiddlywikide...@googlegroups.com.

Visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

[Tobias Beer]

Hi Yakov,

I very much like to see blanks in slice names.

I currently see no benefits in catering for...

a) tabs in slice names

b) leading white space characters for slice names

If b) is viable, then at least let both of...

var: val
var: val

...be interpreted as:
slice-name="var"
slice-value="val"

Cheers, Tobias.

[Yakov]

Hi Tobias,

as you may remember from the previous discussions [1], the proposal is to change only the behavior of slices in the *table notation*.

So leading space characters can be used to make a slice table align slice names to the right and slice values to the left. I haven't needed such styling, but somebody can.. The version you suggested (I mean

|var|val|

and

| var|val|

) is not implemented yet: currently, that would be different slice names, but I can change this as it's not in the core yet. Actually, that's the question I asked above, so thanks for your vote. Note: either forbidding leading space or making it outside the slicename would complicate the slicesRE a bit more. Currently, those are allowed in any position of the slicename except for the last one. Hmm.. may be to create a simple survey about these picularities is an option..

As for tabs, I don't think they're useful inside the slicename too, but I'm not sure what Mario implied either (may be he meant tabs after the slicenames to make tables look like tables in the edit mode; which is implemented already).

Best regards,

Yakov.

[1] https://groups.google.com/forum/?hl=en.&fromgroups=#!topic/tiddlywikidev/yFNObuerUw8

вторник, 29 января 2013 г., 12:28:32 UTC+4 пользователь Tobias Beer написал:

[PMario]

On Jan 29, 6:30 pm, Yakov <yakov.litvin.publi...@gmail.com> wrote:
> |var|val|
> and
> | var|val|

imo this should be the same slice name.
leading and trailing whitespace should be stripped.
Space as in "slice name" is ok for me.

> As for tabs, I don't think they're useful inside the slicename too, but I'm
> not sure what Mario implied either (may be he meant tabs after the
> slicenames to make tables look like tables in the edit mode; which is
> implemented already).

imo tabs should be stripped. As above only space inside slice names

-m

[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.

[JL]

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 написал:

[Yakov]

Oops, wrong account, that was me.

среда, 30 января 2013 г., 18:09:52 UTC+4 пользователь JL написал:

[Tobias Beer]

Hi Yakov,

Reading RegEx is not quite my strong suit. Could you please provide a MTC via dropbox to test around with? Alternatively, where do I find /reproduce those tests of which you are talking?

Cheers, Tobias.

[Jeremy Ruston]

Just as an aside, http://regexper.com/ is a great tool for visualising regular expressions.

Best wishes

Jeremy

--

Jeremy Ruston

jeremy...@gmail.com

--

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 tiddlywikide...@googlegroups.com.

To post to this group, send email to tiddly...@googlegroups.com.

[Yakov]

I see. The tests I mentioned in the previous post are from the testing system of TW core. I don't know how to cook tests.html under Windows, so Mario cooked two versions ([1], [2]) for my testing. Basically, you can download the one which is for the vanilla version of TW [1] and then change slicesRE there (grab the current one from the Pull request [3]; [2] is outdated anyway). For additional testing, you can just change slicesRE inside a TiddlyWiki and then try transclusion etc in there. If you want to change slicesRE for testing via a plugin, that one should consist of two lines:

TiddlyWiki.prototype.slicesRE = ...

store.slices = {};

Without the second line, slices won't be recalced.

> Just as an aside, http://regexper.com/ is a great tool for visualising regular expressions.

Nice one, Jeremy. That's http://www.regexper.com/, though, without www it haven't opened for me.

By the way, does anyone know when \x20 is preferrable to just space symbol? It is used in the core, but I'll be glad to switch it to plain space as it's rather bad for reading the RegExp and eats some extra space as well.

[1] https://gist.github.com/4444413/41f2aa49b33859220acb33e134624ec52f1312fa

[2] https://gist.github.com/4444413/69eeb445a033fef5e20c53e768d514e118b5143a

[3] https://github.com/TiddlyWiki/tiddlywiki/pull/112/files

среда, 30 января 2013 г., 23:54:01 UTC+4 пользователь Tobias Beer написал:

[Yakov]

Hi guys,

I've found one "bug" in the current "slice value part" of the slicesRE. This bug caused some troubles with themes to Alfonso Arciniega [1]. The current "slice value" part of the slicesRE is this

[\t\x20]*([^\|\n]*)[\t\x20]*

which means that if one specifies a slice like this

|PageTemplate| WebPageTemplate |

he or she gets the slice value as "WebPageTemplate ". I haven't debuged this, just tried different variants:

|PageTemplate| WebPageTemplate |

|PageTemplate| WebPageTemplate|

|PageTemplate|WebPageTemplate |

|PageTemplate|WebPageTemplate|

and those with a spacebar after the "implied slice value" doesn't work while those without trailing spacebars work. I guess this is because matching process tries to match

[\t\x20]*([^\|\n]*)

first and that actually matches, giving the spacebar in the slice value; and than the trialing

[\t\x20]*

matches as zero spacebars.

----

This "bug" is inherited in my slicesRE (althought I prevented it in slice names by explicitly forbidding white-space symbols as first and last ones in the "slice name part":

[^\|\s\:\~\'\/]|(?:[^\|\s~\'\/][^\|\n\f\r]*[^\|\s\:\'\/])

). Now, to solve this issue, I changed the "slice value part" of my slicesRE

[\t\x20]*([^\n]+)[\t\x20]*

to this:

[\t\x20]*([^\n\t\x20](?:[^\n]*[^\n\t\x20])?)[\t\x20]*

so now both leading and trailing spaces/tabs in the "value part of the table" are not accounted as parts of a slice value.

PS if someone explains how the testing system works, may be I can start to add tests for the new slices. On the other hand, Eric haven't commented this ticket yet, so I'm bit lost about the status of this proposal.

[1] https://groups.google.com/forum/?fromgroups=#!topic/tiddlywiki/9S8R5Sk2niA

[Tobias Beer]

Here's what I think about tables and slices...

slice-name: ANY NUMBER OF leading or trailing blanks are ignored and NOT part of the slice name. That is consisitent with sooo many other use cases, first and foremost... tiddler names cannot start or end with blanks either and I think that makes sense.

As for the slice-value, that's a different matter. I would suggest to remove the first and last blank of the slice value, if existing, AS WELL AS CSS DEFINITIONS from the slice-value because their purpose usually is that of cell formatting.

Cheers, Tobias.

[PMario]

did you try:

|key| value with spaces |

wich imo is a valid slice definition.

-m

[PMario]

On 17 Feb., 14:13, Tobias Beer <beertob...@gmail.com> wrote:
> As for the slice-value, that's a different matter. I would suggest to
> remove the first and last blank of the slice value, if existing, AS WELL AS
> CSS DEFINITIONS from the slice-value because their purpose usually is that
> of cell formatting.

I'm not sure, if CSS definitions should be removed. What if

key: @@value@@

is what I want? I'm not sure, if this is usefull but I'm sure, I don't
want, that a "progamms thinks" it should change my text. leading and
trailing whitespace -> yes. but imo don't touch non whitespace.

-m

[Tobias Beer]

What I was referring to with css definitions was purely related to tables...

| slice-name |color:green; ''slice-value'' |

...here, color:green; should definetely not be part of the slice-value... however the rest sure can contain any other desired wiki formating, such as the bold formating in the example!

Cheers, Tobias.

[PMario]

Imo.
If you want to remove "color:green" and bold, than you'll need to
implement an escape mechanism, because if I want to get

key: slice-name
value: color:green; ''slice-value''

it needs to be possible too. (but: I'm not sure, what the core does at
the moment)

-m

[Tobias Beer]

Hi Mario,

I disagree. I see no context where...

| slice-name |color:green; ''slice-value'' |

should be interpreted as...

key: slice-name
value: color:green; ''slice-value''

The blanks as well as the css simply are not part of the slice value -- their intention and use is for the wikifier to format the cell. Besides, if you desperately needed your value to be...

value: color:green; ''slice-value''

you could use...

| slice-name | color:green; ''slice-value'' |

With the interpretation proposed earlier the first leading and trailing blanks would be stripped from the slice-value... as their purpose is always that of cell formatting, not of value definition. So, using blanks would be your escaping mechanism. One simply cannot have it both ways, either one desires cell formatting or a slice value... never both. At least that sounds like a sensible distinction to me.

Cheers, Tobias.

[Yakov]

Hi guys,

regarding the css in slice values, here's what I think:

* if css striping is added to slice values, it's consistent to add it to slice names (which would cause additional growth of slicesRE)

* "simple" striping of css would be "stripe all "<latin letters or '-'>:<latin letters or numbers>;" thing" which is quite general and would probably cut some other things

* it's quite uncommon to create slices where one need to have a css value, but this can appear in CSS reference like this: |Example|font-size:20px;|

* it's rather rare situation when one needs to apply styles to slice names/values, but can be desired as well

My conclusion is (due to the idea of core simplicity and the conflicting ideas mentioned above) not to stripe css. Instead, what I would think of, is a table-farmatter-modifying plugin.

This is a bit offtopic, but let me draw a picture here. No secret, TW table formatter is somewhat rather limited: one can't add any attribute to a cell (or row or column). But formatter can be extended like this:

| cells | withoug | attributes |

| cells | with | attributes | class="myClass" id="myId" style="font-size:20px" | | attrubute1="value 1" attrubute2="value 2" |attr

or like this:

| cells | withoug | attributes |

| cells | with | attributes |

| class="myClass" id="myId" style="font-size:20px" | | attrubute1="value 1" attrubute2="value 2" |attr

so that the rows with the "attr" ending cause adding attributes to corresponding cells. These two approaches have a drawback, thought, as without the plugin tables will be displayed in a wrong way and also this have poor compability with things like TWtid plugin [1] (former TableEditor and TWted). Another approach that would have a better compability is

| cells | withoug | attributes |

| cells | with | attributes |

/%tableAttr

2| class="myClass" id="myId" style="font-size:20px" | | attrubute1="value 1" attrubute2="value 2" | rowAttribute="attrValue"

%/

Here "2" is the number of the row to apply the attributes to. (for colspans, some other thing should be invented)

So, that's the root I'd propose to look into.

[1] https://groups.google.com/forum/?fromgroups=#!searchin/tiddlywiki/twtid/tiddlywiki/0FT6iBneYOk/2nozw_XRYNoJ

воскресенье, 17 февраля 2013 г., 22:09:14 UTC+4 пользователь PMario написал:

[Tobias Beer]

Hi Yakov,

I would agree by now that stripping out css is a classical case of over-engineering, i.e. if you want to define slices using tables, don't use TiddlyWikis cell styling options.

When it comes to text-aignment using spaces, I'm not so sure though. I would always remove any blanks preceeding or following slice-names as well as a first blank at the beginning and a last blank at the end of a slice value... as they are there for text-alignment. If you actually need that beginning blank for your value, then add another blank that won't be stripped.

As for extending table styles, I like this approach...

/%tableStyles

2| class="myClass" id="myId" style="font-size:20px" | | attrubute1="value 1" attrubute2="value 2" | rowAttribute="attrValue"

%/

It's very flexible and does nothing to a TiddlyWiki lacking the required plugin support -- quite the ingenious method that might be helpful in a number of use-cases.

Cheers, Tobias.

[Yakov]

среда, 20 февраля 2013 г., 3:41:08 UTC+4 пользователь Tobias Beer написал:

Hi Yakov,

I would agree by now that stripping out css is a classical case of over-engineering, i.e. if you want to define slices using tables, don't use TiddlyWikis cell styling options.

When it comes to text-aignment using spaces, I'm not so sure though. I would always remove any blanks preceeding or following slice-names as well as a first blank at the beginning and a last blank at the end of a slice value... as they are there for text-alignment. If you actually need that beginning blank for your value, then add another blank that won't be stripped.

Sure; current implementation is slightly different: for the slice name, there can be one leading space and any number of trailing spaces/tabs; for slice value, there can be any number of both leading and trailing tabs and spaces; but it doesn't allow the white-space symbols as first and last symbols of both name and value -- because of ambiguities mentioned above. Can you provide any use-cases that require white-space in the beginning or end of a slice name/value?

[Tobias Beer]

Hi Yakov,

A valid usecase for desiring blanks may be some form of markdown styled content, e.g. where you know that your value is supposed to be indented. But then, I'd think it would make more sense to leave the formatting to whichever script would gather such slices and put them together with proper (markdown) formatting.

So, no... I guess, I currently wouldn't know of a usecase for leading / trailing blanks... neither for slice-names nor for slice-vaues.

And if we're actually strict about handling blanks... well, try adding superfluous blanks before or after a tiddlers title. I think it makes sense to not allow that. It's just way too confusing to find errors based on unidentified blanks surrounding a string.

So, actually, I think there's a sound argument for trimming both, slicename and value. Not doing that, are we actually losing something that we will miss later? Right now, I really can't think of a situation where this would be the case.

Cheers, Tobias.

[Yakov]

Hi Tobias,

I didn't get exactly your point about trimming white-space around slice names/values; as I understood, you propose just to trim them all, and that's the case for current [my] implementation.

The only inconsistency is what is accounted as slices. Currently, there can be:

* up to one leading space in the slice name part

* any number of spaces/tabs trailing slice name and around slice values

By inconsistency I mean that the rule is a bite more complicated than just "any number of leading/trailing tabs and/or spaces for both slice names and values", but I wouldn't expect that somebody would add more than one space before a slice name.

This issue seems to be closed in my implementation, isn't it?

Best regards,

Yakov.

четверг, 21 февраля 2013 г., 23:10:30 UTC+4 пользователь Tobias Beer написал:

[Tobias Beer]

Hi Yakov,

This issue seems to be closed in my implementation, isn't it?

How would I go about testing / verifying that assertation? Copying your slices reg into a vanilla TW and test it?

Cheers, Tobias.

[Yakov]

воскресенье, 24 февраля 2013 г., 5:10:03 UTC+4 пользователь Tobias Beer написал:

Hi Yakov,

This issue seems to be closed in my implementation, isn't it?

How would I go about testing / verifying that assertation? Copying your slices reg into a vanilla TW and test it?

Well, as I pointed previously, there are two ways to start testing:

* change code of a vanilla TW directly: put this line

TiddlyWiki.prototype.slicesRE = /(?:^([\'\/]{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](?:[^\n]*[^\n\t\x20])?)[\t\x20]*\|$)/gm;

instead of current slicesRE definition;

* or create a plugin which has that line and than this one:

store.slices = {};

There's of'course one more thing: creating extra tests for core (mechanism Mario mentioned) but I have no idea where to start.

 

Cheers, Tobias.

[Tobias Beer]

Hi Yakov,

There's of'course one more thing: creating extra tests for core (mechanism Mario mentioned) but I have no idea where to start.

I guess, eventally, that is simpler than we think... there sure is some definition of test contents (tiddlers) and then calling the respective code to run your regex against the test date to see if you get the expected results... also testing cases that are designed to fail.

Not sure, if there is a js test framework involved and how that would be used with the TW core. Would be nice if there were a 10-30min tutorial somewhere that would explain the process.

Cheers, Tobias.

[PMario]

On Feb 24, 2:44 pm, Tobias Beer <beertob...@gmail.com> wrote:
> There's of'course one more thing: creating extra tests for core (mechanism
>
> > Mario mentioned) but I have no idea where to start.

The core has some build utilities. cook and ginsu. (both are going to
be replaced by the tw5 nodejs build mechanism in the future.)

> I guess, eventally, that is simpler than we think... there sure is some
> definition of test contents (tiddlers) and then calling the respective code
> to run your regex against the test date to see if you get the expected
> results... also testing cases that are designed to fail.
>
> Not sure, if there is a js test framework involved and how that would be
> used with the TW core. Would be nice if there were a 10-30min tutorial
> somewhere that would explain the process.

http://dev-template-doc.tiddlyspace.com/#About

tests can be seen at: https://github.com/TiddlyWiki/tiddlywiki/tree/master/test

The TW2 build mechanism is quite complicated, mainly because you need
to get the ruby stuff working. But if it works, it is quite powerfull.

-m