Hi Tobias,

воскресенье, 10 февраля 2013 г., 1:10:06 UTC+4 пользователь Tobias Beer 
написал:
>
> Hi Yakov,
>
> I dare ask again: Why not use definitions as slices?
>
> Well, in principle this can be done, sure. I'm not sure about adding this 
to the core, though: while I don't use definition lists much, others can do 
that. And my vision about slices is there shouldn be as few "unexpected" 
slices as possible. For instance, GridPlugin from TiddlyTools creates 
colomns for all slices by default, and if there's a tiddler with some 
definitions, this would cause a grid table to grow much. May be this is not 
a strong objection, I'm not sure.
 

> I can imagine that this would be quite desireable.
> After all, we have just written down definitions!
>
>
> ## BEGIN EXCURSION ##
>
> Which brings me to the idea that a macro called <<slice>> might actually 
> be desireable whereas...
>
> <<slice slice-ref>>
>
> ...would rendered both name and value as...
>
> ;slice
> :slice-value
>
> Oh boy, thinking about this made me create a new plugin...
> http://get.tiddlyspace.com
>
> Hmm.. the plugin has some very nice syntax and looks neat, but I'm 
somewhat confused as there's already the list macro and 
ForEachTiddlerPlugin, and also SectionLinksPlugin from TIddlyTools (to use 
notations like [[##someSection]]). (in terms of auto-aggregation, I'm 
mostly concerned with another two issues: concatenating autoaggregated and 
manually written lists/tables and manual sorting of such things so that 
sort order is remembered [in a cookie]) What's the overall idea? 

## END EXCURSION ##
>
>
> Anyhow, if the concern is reduced to layouting... then tables are not the 
> issue, because layouting, obviously, has already been taken care of.
>
> So, what it then boils down to really is a formatter that matches the 
> "simple" slice-name variant and somehow is smart enough to realize when the 
> end of a slice-value has been reached without screwing up any other 
> formatting.
>
> ...would be kind of ambiguous. Lucky for us, the core slice regex actually 
> registers ambiguous slice value correctly, e.g....
>
> foo: bar //italic bar
> more italic bar//
>
> *slice-name:*
> foo
>
> *slice-value:*
> bar //italic bar
> more italic bar//
>
> Really? Doesn't work for me (TW 2.6.5) and shouldn't: slicesRE doesn't 
account regexps of formatters anyhow.. I mean

foo: bar //italic bar
more italic bar//

<<tiddler [[New Tiddler::foo]]>>

shows what I expected:

foo: bar italic bar
more italic bar

bar italic bar

>
> So, it seems like if we could identify that...
>

In fact, accounting formatters in not a simple thing to do at all as this 
would require to partially "copy" wikifier and its recursive algorithm.

But, like I said above, accounting

;sliceName
:sliceValue

isn't hard to achieve.. the simplest implementation is to add to the 
slicesRE something like..

|(?:^;([\'\/]{0,2})~?([\.\w]+)\:\1[\t\x20]*\n\:([^\n]+)[\t\x20]*$)

and modify calcAllSlices [1] or just substitue one of the definitions of 
slices (simple/table notation) with this one (this variant is not good as 
both notations are used in basic TW mechanisms..).

[1] 
https://github.com/TiddlyWiki/tiddlywiki/blob/master/js/TiddlyWiki.js#L175

>
>    1. what is being wikified right now is a slice-name
>    2. if we fetch the slice-value for the tiddler being rendered and the 
>    text that follows actually matches the slice-value... then we know that we 
>    have to wrap the whole thing in a span with the class .sliceValue and 
>    subwikify the rest
>
> 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.


Reply via email to