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 -- You received this message because you are subscribed to the Google Groups "TiddlyWikiDev" group. To post to this group, send email to [email protected]. To unsubscribe from 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.
