TiddlyWiki5 lack of br?

[Arc Acorn]

Well playing around in TW5 I noticed that it doesn't seem to create <br/>'s 

Example:

Text

Text 

Becomes: <p>Text Text </p>

Well:

Text 

Text

Becomes: <p>Text</p> <p>Text</p>

[Jeremy Ruston]

Hi Arc

TW classic couldn't generate proper HTML <p> paragraph tags, instead relying on <br>. This highly irregular behaviour made it hard for CSS people to style TiddlyWiki.

TW5 does generate proper paragraph tags, by adopting rules similar to MarkDown:

* Single newlines are ignored

* Double newlines start a new paragraph

This is one of the biggest wikitext changes between TW classic and TW5. From an authors point of view, I find it much clearer, as these rules allow me to pepper text with newlines to improve readability. (We do need a way of marking up text - such as poems - that does include literal newlines). Hopefully, with MarkDown being so ubiquitous the new behaviour will be less surprising for new users.

Best wishes

Jeremy.

--
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.
Visit this group at http://groups.google.com/group/tiddlywikidev?hl=en.
For more options, visit https://groups.google.com/groups/opt_out.
 
 

--
Jeremy Ruston
mailto:jeremy...@gmail.com

[PMario]

as a workaround you can use

some text <br />
some more text.

imo this is ugly in edit mode, but it works.

-m

[Arc Acorn]

I can see how for some people styling TwClassics system could be tricky... I've never had any issue with it myself though. 

I suppose one reason for that is that I like all text to look a standard per element unless I want a small part to be different, and wrapping blocks of text in a span class allowed me to do everything I've ever wanted.

The new system is something I'll have to keep in mind though since I do a lot of scratch and quick note style typing that requires a lot of proper line breaks, I think it'll be best for my sanity and fingers for me to go ahead and bow out of the TW5 game for the foreseeable future.

[Jeremy Ruston]

Hi Arc

 

I can see how for some people styling TwClassics system could be tricky... I've never had any issue with it myself though.  

I suppose one reason for that is that I like all text to look a standard per element unless I want a small part to be different, and wrapping blocks of text in a span class allowed me to do everything I've ever wanted.

The new system is something I'll have to keep in mind though since I do a lot of scratch and quick note style typing that requires a lot of proper line breaks, I think it'll be best for my sanity and fingers for me to go ahead and bow out of the TW5 game for the foreseeable future.

That's disappointing, your feedback has been very valuable in the project so far. Please remember that TW5 is a work in progress, evolving in the light of the feedback from the early users; things like this are not fixed. In fact, this is pretty much the first discussion that's taken place about this aspect.

Right now, TW5 tries to emulate the behaviour of MarkDown with respect to paragraph handling. We can separate out some underlying options though: the first is whether to use <p> tags or <br/> tags. That is independent of the second issue: how to mark up the ends of paragraphs. So we could, for instance, stick with TW classic's behaviour of treating a single newline as a paragraph break, and still use <p> tags.

One deeper issue is whether and how far to be influenced by MarkDown. The motivation for taking it into consideration is its popularly, of course, but there are other perspectives (eg http://www.wilfred.me.uk/blog/2012/07/30/why-markdown-is-not-my-favourite-language/).

Anyhow, I hope TW5 continues to hold your interest,

Best wishes

Jeremy.

[Arc Acorn]

Interesting, I guess I may be over use to hanging around "bigger" beta stage projects where it's normally pointless to bring the idea of any form of function change up.

After doing some good reading about MarkDown and common wiki syntax I think I see the overall issue much better.

I also never realized how common/popular MarkDown was/is, so I can see the appeal from a developmental standpoint to use something that more people already use and therefore are use to handling and styling.

My own favoritism for having line breaks handled like classic TW aside, it dose look like MarkDown have a fairly simple linebreak standard that doesn't appear to be implemented in TW5.  

http://en.wikipedia.org/wiki/Markdown#Line_breaks

[Two spaces at the end of a line followed by a line break]

Which would be strange to get use to, would be usable for my typing/note taking style compared to manually adding hundreds of <br /> tags.

 On the subject of syntax and styling though: 

One other thing I noticed is that the old easy span class system no longer exists:

{{spanClass{Content}}}

If I'm right it looks like it was intended to largely be replaced with:

@@.pClass

Content

@@

For ease of proper and quick reusable styling structure I would really like to see the return of some kind of syntax for handling span classes. 

On Sunday, May 12, 2013 8:10:14 AM UTC-7, Jeremy Ruston wrote:

Hi Arc

 

I can see how for some people styling TwClassics system could be tricky... I've never had any issue with it myself though.  

[Jeremy Ruston]

Supporting Markdown's rule of forcing a line break with two spaces at the end of the line would be straightforward but I'm concerned that those spaces will be annoyingly invisible when using the browser textarea control to edit text. So it might be useful to add a more explicit syntax for line breaks. One possibility is double backslash at the end of a line:

This will have a linebreak\\

But these two

lines will not

The @@ rule also comes in an inline variant that generates a span much like the old {{class{content}}} syntax:

@@.class content@@

@@color:red;This is in red@@

It is more flexible in that it allows for styles as well as classes. However, while it is almost the same number of keystrokes, it doesn't read as well to my eyes.

One possibility might be to use double round brackets:

((class(content)))

I'm open to suggestions.

Best wishes

Jeremy

[Stephan Hradek]

Am Montag, 13. Mai 2013 11:13:27 UTC+2 schrieb Jeremy Ruston:

Supporting Markdown's rule of forcing a line break with two spaces at the end of the line would be straightforward but I'm concerned that those spaces will be annoyingly invisible when using the browser textarea control to edit text. So it might be useful to add a more explicit syntax for line breaks. One possibility is double backslash at the end of a line:

Please don't!

One backslash is already used in other places to define that the line is continuing on the next line.

While I find it okay, using MarkDown Syntax and so to ignore single linebreaks, I also understand that there are situations where it would be more than annoying to have to add something to every single line just in order to preserver the linebreaks.

Isn't there something like the <pre> tag which can be used to mark a section where linebreaks are significant?

I'm just thinking about how often I paste in some longish text and wouldn't want to make all the lines connect.

But there are as well situations where I want an explicit linebreak in my source but wuld want both lines concatenated in output.

T.b.h. I have no clue how to best solve this "dilemma".

[FND]

FWIW, this is a well-known issue:

While Markdown encourages[1] the use of line breaks to format (only) the
source, GFM[2] argues that line breaks in the source should translate to
line breaks in the output.

Personally, I *strongly* prefer the former. However, I understand that
in certain contexts, the latter can be preferable.

Would it be possible for TW5 to support both variants - with the
renderer being determined by the respective tiddler's content type?


-- F.


[1] http://daringfireball.net/projects/markdown/syntax#p
[2] http://github.github.com/github-flavored-markdown/

[Jeremy Ruston]

FWIW, this is a well-known issue:

While Markdown encourages[1] the use of line breaks to format (only) the
source, GFM[2] argues that line breaks in the source should translate to
line breaks in the output.

Personally, I *strongly* prefer the former. However, I understand that
in certain contexts, the latter can be preferable.

Would it be possible for TW5 to support both variants - with the
renderer being determined by the respective tiddler's content type?

Yes, that would work, and internally would be quite convenient. However I'm reluctant to overload the content type in that way if it can be avoided, because although it is an easy fix it would result in a proliferation of content types if applied widely.

An alternative would to switch line break mode via a pragma at the top of a tiddler, something like this:

\define tw-single-line-breaks() ignore

or

\define tw-single-line-breaks() break

The way that these definitions works means that the setting would be inherited by any transcluded tiddlers.

There's definitely a place for those kinds of switches in TW5, but it feels rather a last resort in this case because line break handling is so fundamental to wikitext processing. The best alternative we have so far doesn't seem sufficient: to introduce markup for explicit line breaks, and new markup for a block containing explicit line breaks.

Best wishes

Jeremy

 

-- F.


[1] http://daringfireball.net/projects/markdown/syntax#p
[2] http://github.github.com/github-flavored-markdown/

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

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

[chris...@gmail.com]

On Mon, 13 May 2013, PMario wrote:

> I think there needs to be a propper mime type for every tiddler, that
> exactly defines the content.

My preference goes like this:

I would not want to see a proliferation of media types, however the pragma
stuff is _icky_ (i.e. cumbersome). I would prefer syntax: default to correct
markdown behavior (no br), if you want brs, use fenceposts of some kind
around the block that gets the linefeeds.

This leads to tiddlers that can travel well (between systems) which is
my main goal.

--
Chris Dent http://burningchrome.com/
[...]

[chris...@gmail.com]

On Mon, 13 May 2013, chris...@gmail.com wrote:

> This leads to tiddlers that can travel well (between systems) which is
> my main goal.

Just to be clear, however: This does mean that a tiddler _does_ need
to have its media type recorded on itself. What I'm saying is that
there should only be a few media types for rendering tiddlers and
options amongst those types go somewhere else other than the media
type itself.

[PMario]

On Monday, May 13, 2013 1:55:33 PM UTC+2, Jeremy Ruston wrote:

Yes, that would work, and internally would be quite convenient. However I'm reluctant to overload the content type in that way if it can be avoided, because although it is an easy fix it would result in a proliferation of content types if applied widely.

An alternative would to switch line break mode via a pragma at the top of a tiddler, something like this:

\define tw-single-line-breaks() ignore

My response post has been deleted somehow. It was similar to:

I think "\define tw-single-line-breaks() ignore" will break, because it can be used in a template eg: myTemplate

SomeTiddler.text may be transcluded using myTemplate -> rendering OK.

If you copy paste SomeTiddler.text or SomeTiddler is included to a different space, that doesn't know myTemplate -> rendering will be broken.

IMO there is allready a wrapper for this.

$$$.type-that-does-break-lines
$$$

If text like this one is copied to an other space, that doesn't know how to handle it it uses "plain text" rendering, which is the right fallback here.

----

On the other hand I prefer GFM: http://github.github.com/github-flavored-markdown/
Since TW syntax isn't compatible with markdown anyway.
At the moment, I'd vote for GFM like linebreak handling.

-m 

[Arc Acorn]

It seems the br & p topic is much more heated than I would have imagined.

Since it dose seem like people are on one side or the other, maybe the simplest option would be to make it a site wide option that can be set in the ControlPanel? 

◎ Classic Mode [All linebreaks are created as br tags no p tags are generated]

◎ MarkDown - Standard Mode [p tags are created on double line breaks, br tags are made with double space + linebreak at the end of a sentence]

◎ MarkDown Mode + Creole linebreaks [p tags are created on double line breaks, br tags are made where \\ are]

◎ MarkDown - No linebreak Mode [linebreaks are only made when you use a br tag]

I do have one question though.

I assume it most not be easily possible but it seems like the ideal option would be to have things like this:

Single line-breaks = br

Double line-breaks = p

if you wanted more than one br you would simply add a space:

[line-break]

[space][line-break]

this of course relies on something I've yet to ever figure out... Why do we need a system that ignores single line breaks? 

If you want paragraph that don't have line-breaks than the answer seems to be to be simply not use line-breaks.

Last time I checked periods don't make line-breaks the line-break character makes line-breaks. 

The only time where single line-breaks create a mess is for styling and other special cases:

@@background:red;

text block1

text block2

@@

which is where you really need a special system to null out a line-break like like adding ^^ or // or ++ or &&

@@background:red;^^

text block1

text block2

@@^^

To me it seems like the need to remove single-line-breaks are the special case rather than the other way around.

-----

As for the other

I did notice that spans where created for single-line inline which is nice in some case but in many cases at least for me I need spans to wrap around a larger block of content.

Simple example:

 

@@background-color:red;display:inline-block;

text

text

text

@@

This of course gives p styles so isn't what we want.

<p style="background-color:red;display:inline-block;">text</p>
<p style="background-color:red;display:inline-block;">text</p>
<p style="background-color:red;display:inline-block;">text </p>

So how about the inline for the span?

@@background-color:red;display:inline-block;text

text

text

@@

Gives us a span output but nulls out all our <p>'s and with no <br />'s we loss all notions of white space.

<p>
<span class="tw-inline-style" style="background-color:red;display:inline-block;">text text text </span>
</p>

All and all very different than what I would have actually wanted:

<span style="background-color: red; display: inline-block;">

<p>text</p>

<p>text</p>

<p>text</p>

</span>

So I do very much think it's a needed component, to have a unique span system that properly wraps around multi-lined content.  

I may be biased to making transition easier for people who already use Classic TiddilyWiki but it doesn't seem like the 

{{Class{Content}}}

is being used by anything else in the new system, and logically makes sense simply to carry it over as the syntax given that any other real variation ((Class(Content))) is simply aesthetics and in the long run only forces people who use both TW5 and Classic to remember an odd difference, with no true benefits.

[Jeremy Ruston]

It seems the br & p topic is much more heated than I would have imagined.

I'm afraid so. Getting the wikitext syntax right feels like trying to do twelve dimensional tetris.

 

Since it dose seem like people are on one side or the other, maybe the simplest option would be to make it a site wide option that can be set in the ControlPanel? 

◎ Classic Mode [All linebreaks are created as br tags no p tags are generated]

◎ MarkDown - Standard Mode [p tags are created on double line breaks, br tags are made with double space + linebreak at the end of a sentence]

◎ MarkDown Mode + Creole linebreaks [p tags are created on double line breaks, br tags are made where \\ are]

◎ MarkDown - No linebreak Mode [linebreaks are only made when you use a br tag]

The trouble here is interoperability - this setting would mean that content imported or synced from different sources would appear differently depending on whether it was authored in the same mode as the host document.

 

I do have one question though.

I assume it most not be easily possible but it seems like the ideal option would be to have things like this:

Single line-breaks = br

Double line-breaks = p

if you wanted more than one br you would simply add a space:

[line-break]

[space][line-break]

That suffers from the issue discussed early that spaces are invisible when editting in the browser. It would be desirable to keep the wikisyntax visible.

 

this of course relies on something I've yet to ever figure out... Why do we need a system that ignores single line breaks? 

If you want paragraph that don't have line-breaks than the answer seems to be to be simply not use line-breaks.

I believe that the idea arose in the early days of email: when editing a message it was a nuisance to manually wrap the text at the customary column, and so email clients started to automatically reflow messages during sending. It turns out to be useful when you're copying and pasting text from systems that use hard line breaks.

 

Last time I checked periods don't make line-breaks the line-break character makes line-breaks. 

The only time where single line-breaks create a mess is for styling and other special cases:

@@background:red;

text block1

text block2

@@

which is where you really need a special system to null out a line-break like like adding ^^ or // or ++ or &&

@@background:red;^^

text block1

text block2

@@^^

To me it seems like the need to remove single-line-breaks are the special case rather than the other way around.

If I understood correctly, the time that this becomes an issue for you is when making quick notes, where you're accustomed to separating items with a single line break. Is that right?

 

-----

As for the other

I'll comment on the behaviour you're reporting here, but acknowledge that this is an area where the syntax has become confusing, and needs to change.

 

I did notice that spans where created for single-line inline which is nice in some case but in many cases at least for me I need spans to wrap around a larger block of content.

Simple example:

 

@@background-color:red;display:inline-block;

text

text

text

@@

This of course gives p styles so isn't what we want.

<p style="background-color:red;display:inline-block;">text</p>
<p style="background-color:red;display:inline-block;">text</p>
<p style="background-color:red;display:inline-block;">text </p>

Currently, when used in block mode, the @@ construction purposely doesn't create a wrapper element but applies the styling/classes directly to its child elements. This makes it possible to apply styles directly to, say, the <UL> element generated by an unordered list - in fact, there's no other way to do that.

 

So how about the inline for the span?

@@background-color:red;display:inline-block;text

text

text

@@

Here, by using the inline syntax for @@ you are causing the content to be parsed as inline text, which means that block syntax such as paragraphs and headings isn't recognised.

 

Gives us a span output but nulls out all our <p>'s and with no <br />'s we loss all notions of white space.

<p>
<span class="tw-inline-style" style="background-color:red;display:inline-block;">text text text </span>
</p>

All and all very different than what I would have actually wanted:

<span style="background-color: red; display: inline-block;">

<p>text</p>

<p>text</p>

<p>text</p>

</span>

Right now, the best way to do this is to write the <span> directly as a span. Once I'd enabled intermixed HTML tags with wikitext it seemed less important to provide wikitext equivalents to things that can already be expressed clearly in HTML.

 

So I do very much think it's a needed component, to have a unique span system that properly wraps around multi-lined content.  

I may be biased to making transition easier for people who already use Classic TiddilyWiki but it doesn't seem like the 

{{Class{Content}}}

is being used by anything else in the new system, and logically makes sense simply to carry it over as the syntax given that any other real variation ((Class(Content))) is simply aesthetics and in the long run only forces people who use both TW5 and Classic to remember an odd difference, with no true benefits.

Currently, TW5 uses double curly braces for transclusion, following the lead of a number of other wiki engines.

Best wishes

Jeremy

 

[Tobias Beer]

I strongly encourage this — excplicit is *good*!

Please use proper paragraphs rather translating linebreaks in the source into literal <br> in the output.

That may make transition from TW classic to TW5 a teeny tiny wee bit harder but there are far more difficult problems than this!

It seems to me that the previous quirky ways of taking linebreaks literal was one of the points where TiddlyWiki went astray compared to most other (wiki) markup. So, changing it now to me means to do it right.

Getting the old behaviour might be a global switch of sorts. If the architecture of TW5 also means that it would inherently be possible to override that on a per tiddler basis, fine. To me, this should be a plugin though, not core!

Cheers, Tobias.

[Jeremy Ruston]

We do need a way of marking up sections of text that has explicit linebreaks (eg poetry), but otherwise, yes, I'm finding content creation much easier for TW5.

Best wishes

Jeremy

--

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.

Visit this group at http://groups.google.com/group/tiddlywikidev.

For more options, visit https://groups.google.com/groups/opt_out.

[John McNulty]

I'm a little late to the party with this discussion but would like to add my bit.   I see that keyboard shortcuts are on the TW5 roadmap.  Could you add one so that <shift><enter> inserts a <br> before performing the CR-LF in the text input window please.   That would be a useful speed up.

Thanks.  John

On Monday, 19 August 2013 17:39:54 UTC+1, Jeremy Ruston wrote:

We do need a way of marking up sections of text that has explicit linebreaks (eg poetry), but otherwise, yes, I'm finding content creation much easier for TW5.

Best wishes

Jeremy

[Jeremy Ruston]

Hi John

The plan is indeed to have both keyboard shortcuts for invoking commands, and "keyboard macros" that expand key sequences in the text editor. The kind of thing that lets you type "omw" on the iPhone and have it automatically expand to "on my way" when you press space.

Best wishes

Jeremy