Proposal to (slightly) enhance headings, with code
Martin Budden
I use headings quite extensively and have the following problem (which
I imagine others have as well): when editing a relatively long tiddler
it's hard to find the headings, unless you prefix them with a couple of
blank lines. However this then means that when you view the tiddler
there is a lot of white space above the heading.
My proposal is that the "heading" matcher eats any blank lines before
the heading, so that the amount of white space above a heading is
detirmined solely by the heading's style and not by artefacts that are
used to make the tiddler easier to edit. (Of course, if you really want
to add some extra white space above a header you can use one or more
<<br>>s).
Here's the code:
(btw, "heading" must remain before "lineBreak" in config.formatters
array.)
config.formatters = [
...
{
name: "heading",
match: "^\\n*!{1,5}",
lookahead: "^(?:\\n*)(!{1,5})",
terminator: "\\n",
handler: function(w)
{
var lookaheadRegExp = new RegExp(this.lookahead,"mg");
lookaheadRegExp.lastIndex = w.matchStart;
var lookaheadMatch = lookaheadRegExp.exec(w.source);
var e = createTiddlyElement(w.output,"h"+lookaheadMatch[1].length);
w.subWikify(e,this.terminator);
}
},
...
Eric Shulman
> I imagine others have as well): when editing a relatively long tiddler
> it's hard to find the headings, unless you prefix them with a couple of
> blank lines. However this then means that when you view the tiddler
> there is a lot of white space above the heading.
Put your blank lines inside TW comment markers: /% and %/, so they
won't be visible when the tiddler is rendered, but will still be
easy-to-spot when editing:
/%
%/
!!!!heading
blah blah blah
/%
... or put comments here... perhaps a dividing line?...
===================================
%/
!!!!heading
blah blah blah
-e
Eric Shulman
TiddlyTools / ELS Design Studios
Jeremy Ruston
bigger issue: TiddlyWiki not generating proper <P> tags. As you'll
have spotted, it doesn't have a paragraph formatter, but rather
instead processes new lines as <BR> tags. I guess people have got used
to it by now, but it hardly makes for semantic markup.
In contrast, other wikis (like MediaWiki) tend to ignore single
newlines, and use double newline as a paragraph break, but ignore runs
of more newlines, and have have different markup for forcing a
linebreak (like <br>).
http://meta.wikimedia.org/wiki/Help:Editing
(heavily spammed, sadly)
I should have done it like that this when I first designed the
wikifier, and it's going to be pretty hard to do it without changing
most of the formatters. And I'd worry about how much existing content
would get broken.
I'd be interested on your comments on this approach,
Cheers
Jeremy
--
Jeremy Ruston
mailto:jer...@osmosoft.com
http://www.tiddlywiki.com
Daniel Baird
This is an interesting problem. And actually, I think it's tied to a
bigger issue: TiddlyWiki not generating proper <P> tags. As you'll
have spotted, it doesn't have a paragraph formatter, but rather
instead processes new lines as <BR> tags. I guess people have got used
to it by now, but it hardly makes for semantic markup.
In contrast, other wikis (like MediaWiki) tend to ignore single
newlines, and use double newline as a paragraph break, but ignore runs
of more newlines, and have have different markup for forcing a
linebreak (like <br>).
http://meta.wikimedia.org/wiki/Help:Editing
(heavily spammed, sadly)
I should have done it like that this when I first designed the
wikifier, and it's going to be pretty hard to do it without changing
most of the formatters. And I'd worry about how much existing content
would get broken.
I'd be interested on your comments on this approach,
Cheers
Jeremy
The no-paragraphs thing has been bugging me lately too; for two reasons.
One was the same as Martin -- it's hard to make the raw content readable without introducing big spaces.
Secondly, I wanted my output to have just a small gap between paragraphs, but at present the inter-paragraph spacing has to be made up of full height blank lines.
I personally would like the wikifier to use proper paragraphs and eat other newlines, as proposed; that would solve both of my issues.
Obviously some existing content would wikify slightly differently, but it's only whitespace that would be affected.. so it's hard (for me at least) to think of a situation where the result would end up "wrong".
If that can't happen for whatever reason, I reckon Martin's fix to eat whitespace around headings should definitely go in.
Cheers
;Daniel
--
Daniel Baird
http://danielbaird.com (TiddlyW;nks! :: Whiteboard Koala :: Blog :: Things That Suck)
Luke Blanshard
Daniel Baird wrote:
> On 5/18/06, Jeremy Ruston <jeremy...@gmail.com> wrote:
> >
> > This is an interesting problem. And actually, I think it's tied to a
>
> ...I personally would like the wikifier to use proper paragraphs and eat other
> newlines, as proposed; that would solve both of my issues.
>
> Obviously some existing content would wikify slightly differently, but it's
> only whitespace that would be affected.. so it's hard (for me at least) to
> think of a situation where the result would end up "wrong".
The only real issue would be line breaks that stopped being line
breaks, and instead started jamming both lines onto the same line. For
certain sorts of content this could change its meaning.
Personally, I'd love to see this change though. It's really the only
aspect of TW that has always bugged me and that hasn't really been
addressed.
Luke
Daniel Baird
The only real issue would be line breaks that stopped being line
breaks, and instead started jamming both lines onto the same line. For
certain sorts of content this could change its meaning.
Hmm good point. If the linebreaks were chucked away completely, it could be quite bad. Replacing a linebreak with a space would make it not quite as bad, at least you wouldn't be creating crazy compound words :)
Hopefully in practice people have used bulleted lists etc, rather than single linebreaks.
..you know i've just had a crazy idea -- the wikifier could render /n's as <br>'s for tiddlers that were last edited earlier than the date the new wikifier is released. No no no.. i better put the scotch away, that's insane.
;D
Jeremy Ruston
Luke Blanshard
Daniel Baird wrote:
> On 5/18/06, Luke Blanshard <lu...@blanshard.us> wrote:
> >
> > The only real issue would be line breaks that stopped being line
> > breaks, and instead started jamming both lines onto the same line. For
> > certain sorts of content this could change its meaning.
>
> Hmm good point. If the linebreaks were chucked away completely, it could be
> quite bad. Replacing a linebreak with a space would make it not quite as
> bad, at least you wouldn't be creating crazy compound words :)
Well, I don't think anyone would expect compound words! That wasn't
what I meant to say. Most "markdown" variants treat a single
end-of-line as equivalent to a space. Same as HTML -- except HTML
treats any number of blank lines as equivalent to a single space.
Luke
Martin Budden
"correct" thing to do, the question is "Can it be done without too much
disruption?". I think that a fair number of the formatters will be
unaffected by the change, and that the implementation will probably be
easier than you think.
The main issue is: "Will it break content?". Certainly there will
cosmetic changes to the look of some TiddlyWikis, there will may also
be changes that are unacceptable to some TiddlyWiki owners. However
these can be dealt with: the version of TiddlyWiki that has this change
can ship with an upgrade/conversion plugin that does the appropriate
newline substitutions, so that the changes are made acceptable. The
plugin, once run, can tag itself as actioned, so that users don't
inadvertantly run it twice.
Jeremy Ruston
http://trac.tiddlywiki.org/tiddlywiki/ticket/34
Cheers
Jeremy
Jules
But is it not possible to have both? A single \n followed by a line
with some none whitespace gets a <br /> A \n followed by a line
containing only whitespace characters should end and start (in that
order) a <p>. Wrap the whole thing in a <p></p> and there you go - well
not quite as you have to allow for other block formats of course!
--
Jules
www.knightnet.org.uk
http://knighjm.googlepages.com/knightnet-default-tw.html
Jeremy Ruston
> with some none whitespace gets a <br />
The other suggestion made in the thread is that the \n should render
as a single space. This is actually really nice because it lets you
paste in text that's already got line breaks (eg from google groups or
an email) and it gets reflowed.
Cheers
Jeremy
MilchFlasche
generate those linebreaks in the first place? orz
Anyway, here's my proposal for some markup changes...
1. two adjacent \n's = ending the block element, whether it be a plain
<p>, a <ul>, an <ol>, or a <blockquote>, depending on the markup at the
beginning of the line.
2. one \n and then a markup *of a different kind* at the beginning of
the line = nest the latter element inside the former element; thus we
could have a <blockquote> inside a <li>, or a <ul> inside a <p>, or
even a <hr /> inside a <li>, etc.
3. one \n only and texts right away = a white space, like what Jeremy
has voted above.
4. one \n and some spaces or one \t and then texts = a linebreak, or
namely a <br />
How do you think of this set of reformation? Actually this would result
in a renaissance of TW markup before... maybe 1.2.34 or around. I'm
proposing this, taking advantage of this thread, because I really miss
the old markups, which enabled me to nest elements one in another very
freely. And I have to admit that, I never quite like the <<br>> macro,
because I think it's against some kind of "easy, semantic and non-HTML"
wiki formatting philosophy (which is theorized now by myself :p).
Yeah I know the old "heading following lists" problem, which forced us
to put two \n's before a heading to make it rendered right (otherwise
it just disappeared). But maybe we could make some escape of "!" after
a list item and a linebreak. Or we could just be generous enough to let
people insert headings *inside* lists, table cells, blockquotes... etc,
tolerating their weird needs.
Every kind of markup revolution is not always as simple. If you find
anything problematic which is beyond the ability my simple brain,
please let me know ^_^ I just hope that TW markup could be almost as
powerful as HTML markups, while no need to use the <html> tag for most
situations and many complicated needs.
As for the impact of existing tiddlers, I think some resolutions
proposed above are considerable, so I don't discuss them here :)
----
Two other proposals, considering posting a new thread, I still mention
them a little here:
1. TW doesn't have a markup for <dl> yet! Is it feasible? How about
this
;title: definition
thing (a semicolon and a colon) of MediaWiki?
2. Advanced markup for tables (but reserving the simple set of TW too).
Again, maybe we could take MediaWiki for reference, making something
like
{| <= <table>&<tbody>
|- <= <tr>
|Cell contents <= <td>
could have linebreaks,
*or even lists or other elements inside it.
|Another cell <= <td>
|} <= </tbody>&</table>
If this is feasible, I suggest that we copy the whole system of table
markups in MediaWiki. I'm not sure if it would contradict against the
existing table markup of TW, though.
MilchFlasche
the first two as end of the former element (as mentioned above), and
the omit the rest ones.
Jeremy Ruston
Cheers
Jeremy
Martin Budden
As you know, I've been doing quite a bit of work with the formatter and
as an experiment I made the following two changes:
1), in the formatter
{
name: "lineBreak",
match: "\\n{2,}",
handler: function(w)
{
createTiddlyElement(w.output,"p");
}
},
...
2) in the wikify function
function wikify(source,output,highlightRegExp,tiddler)
{
if(source && source != "")
{
var wikifier = new
Wikifier(source,formatter,highlightRegExp,tiddler);
output2 = tiddler !=null ? createTiddlyElement(output,"p") : output;
wikifier.subWikify(output2,null);
}
}
This seems to give paragraph formatting. But it just seems too easy.
Have I overlooked anything?
Martin
Jeremy Ruston
Very interesting, but I'm afraid it's not quite right.
As written, your formatter creates empty <p> tags when it encounters
two or more linebreaks, but nothing gets put into them. The wikifier
modification wraps it's output into a <p> tag; in practice it means
that the entirity of every tiddler is one big <p> tag.
Cheers
Jeremy
Martin Budden
So here's version 2. This is still not right: I realise that I have to
stack the creation of elements, so consider this a proof of concept,
with a 1 level stack. Of course there's quite a bit to do - such as
changing any of formatters that terminate the paragraph (so it's a v2.2
thing).
But it's a useful proof of concept. I also think that it would be
possible (by judicious choice of the paragraph line spacing, and by
cleverly dealing with multiple \\n (and seting by increasing the
paragraph line spacing according to the number of \\ns) it would be
possible to add proper paragraphs without altering the appearance of
the rendered output.
Martin
{
name: "lineBreak",
match: "\\n{2,}",
handler: function(w)
{
if (w.inParagraph)
{
w.output = createTiddlyElement(w.outputParent,"p");
}
else
{
w.outputParent = w.output;
w.output = createTiddlyElement(w.outputParent,"p");
w.inParagraph = true;
}
}
},
function wikify(source,output,highlightRegExp,tiddler)//mb**wiki
{
if(source && source != "")
{
var wikifier = new
Wikifier(source,formatter,highlightRegExp,tiddler);
if (tiddler==null)
{
wikifier.outputParent = output;
wikifier.output = output;
}
else
{
wikifier.outputParent = output;
wikifier.output = createTiddlyElement(wikifier.outputParent,"p");
wikifier.inParagraph = true;
}
wikifier.subWikify(wikifier.output,null);
}
}
Jeremy Ruston
It's a difficult think, this, isn't it?
Cheers
Jeremy
Martin Budden
w.outputParent needs to be replaced by an array, w.inParagraph by an
index to that array, and the assignment to and from w.outputParent
replaced by push and pop operations.
However the above code is enough to try it out. I wanted to do this to
see how much the format of the rendered text changes. My conclusion is
that it changes too much (that is too many paragraphs get concatenated)
to be submitted without some additional formatting support. However I
also believe that it is possible to add that support - that is
paragraphs could be added in such a way that the user sees no output
format change. And I also believe that it would not be too difficult to
do so.
Martin