Ok, while I was reading, studying and replying, you replied to the
first post. Let me leave this unchanged and than answer to the new
message.
***
As for the second post, I know most of this about the regexes (I know
a well-written russian handbook which I used for learning html, css
and JavaScript); the only thing I need is some practice. But thanks
for the link, perhaps there's something more to learn.
> The match is __only__ used to identify the start of a list.
> ...
> The "list" lookaheadRegExp is used to identify the "type" of a list.
Ok, this is important. Once again, thinking in a naive way, I would
say "ok, the body of the list is defined by the "match" in the
beginning and the "termRegExp" in the end", but the "justDiv example"
makes me think this is wrong.
Now the fact that lookaheadRegExp defines the list type is represented
in the lines 154-166 I guess. Afterwards, a baseType is defined which
I don't understand what it is.
> lookaheadRegExp: /^(?:(?:(\*)|(#)|(;)|(:))+)/mg
> ...
> eg:
> * list text .. lookaheadMatch[1] contains "*"
> ** list text .. lookaheadMatch[1] contains "**"
> # list text .. lookaheadMatch[2] contains "#"
This sounds strange: I would expect that for
** list text ..
lookaheadMatch[1] will contain "**": there's only \* in the brackets
and the "+" is out of there.
> lookaheadMatch[1] is "ul"
also sounds wrong:
> var lookaheadMatch = this.lookaheadRegExp.exec(w.source);
so isn't lookaheadMatch[1] a "" or "*" or "**" etc? Ok, perhaps by
"is" you ment "corresponds to".
Now you say it is needed to change lookaheadRegExp. Is it correct that
lookaheadRegExp is used to match the text right before the one (let's
call it W) which should be passed for further wikification (and
bounded by "match" and "termRegExp")? If so, I think match should be
altered as well since the "?" after the "***" shouldn't be passed as a
part W, shoud it?
> Now lookaheadMatch[5] contains either ! or ? which can be used to
> create a new eg: itemStyle variable inside the formatters.js - list -
> while()
Ok, this is rather clear. But I don't understand big part of the code.
What the w variable contain when the formatter is executed? What is
the stack variable used for? What is current level and what cases does
the 172-186 bunch of if .. else deal with? I can determine the type of
marker by adding the lookaheadMatch[5] check but where do I apply CSS?
The lack of understanding the code should be even more hindering for
implementing the "linebreak" modification described above.
Another obstacle here is the CSS for defining bullets. The only way I
know to replace usual markers with a symbol is this:
li { list-style-type : none ; } /* remove the marker */
li:before { content : "- " ; } /* generate "-" before the
content */
li { text-indent: -10px; } /* make an indent so that in the two-line
list item the generated content stays outside the "text box" */
so there is actually no real markers. The (small) problem is that text-
indent should be different for different sybols (pseudo-markers) so
that the first line is not shifted relative to the others. Even in the
page you referenced one can notice that the lines are shifted a bit,
but this can get worse with change of the font family. I wonder if
it's possible to fix this using JavaScript; but it's not that
important and will probably take us away from the main topic.
***
As for the new reply:
> The problem is, it isn't simple.
> ...
> and a new "listLineStart" formatter
Yes, that's the first thing I wanted to hear: it *is* necessary to
change the "list" formatter. As for the "justDiv trick" I implied the
example I mentioned before: in the lists the following works:
* list text {{justDiv{
> some citation
}}} more text
By "works" I mean this creates a list item which *contains* the
blockquote element. So list formatter is already not that simple.
> \n inside {{asdf{..}}} is no problem
I can't understand this matching to the previous context. It sounds
like contradiction with the fact that the list item content is
terminated by \n. Here we obviously need to consider the algorithm of
wikification.
> The only problem is: It's a hell lot of work and knowledge, to create that
> much power :)
Well, I can call the previous year's learning and describing
tiddlywiki (in many aspects, including those which are not described
widely and consistently, like tw mobile, inter-tw technologies,
navigation, workflow etc) as a hell lot of work (although many things
are not finished or close to be finished at all) and this doesn't
bother me, because I really need a powerful system for creating and
representing hypertext. But the problem is the developmental part of
tiddlywiki hasn't that much documentation and the only way is to try
and to ask here. Especially this is problematic with such involved
things as formatters.
--
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].
For more options, visit this group at
http://groups.google.com/group/tiddlywikidev?hl=en.
