"Working in TWiki is as easy as typing in text - exactly like email. "

No, it's not.

In particular consecutive lines get collapsed into one big mess.

Any reason why this can't be configurable? It's a completely retarded piece of markup, worse than TWiki being sensitive about how many spaces before a * make a bulletpoint.

-- Contributors: MartinCleaver

Discussion

-- MartinCleaver - 11 May 2006

Lynnwood: you raise a valid concern but I'm not convinced having it work like emails is an agreeable solution.
Soronthar: MartinCleaver: the point is that if the user want to use TWiki, must use TML. Else, we need a different syntax
MartinCleaver: ah, but it was not me that claimed it worked "just like email"
Lynnwood: yes - valid point that

http://www.google.ca/search?q=site%3Atwiki.org+%22like+email%22&start=0&ie=utf-8&oe=utf-8&client=firefox-a&rls=org.mozilla:en-US:official

-- MartinCleaver - 11 May 2006

Added a verbatim around the TWikiIRC snippet... I don't know if the bad formatting was part of the point, so this is how it looks without the verbatim:

Lynnwood: you raise a valid concern but I'm not convinced having it work like emails is an agreeable solution. Soronthar: MartinCleaver: the point is that if the user want to use TWiki, must use TML. Else, we need a different syntax MartinCleaver: ah, but it was not me that claimed it worked "just like email" Lynnwood: yes - valid point that

-- RafaelAlvarez - 11 May 2006

Well, and my main point (which wasn't copied) is that I run into the same kind of formatting problems all the time copying from emails and pasting into other applications - because of the hard returns that emails add after every line.

-- LynnwoodBrown - 11 May 2006

Isn't there a subtle difference between hard returns (by the user) and linebreaks (by the email app)? TWiki could support hard returns entered by the user.

-- ArthurClemens - 11 May 2006

I agree that the line breaks is the number one usability issue TWiki has.

But how will we address the ability to use HTML in TWiki pages? If a line break becomes a line break in the rendering you quickly run into problems with even simple HTML. And I am sure we do not want to give up that strong feature either.

-- KennethLavrsen - 11 May 2006

With wysiwyg added in lately, this issue is less pressing than it once was. I wonder how or if this conflicts with existing test cases?

-- SteffenPoulsen - 12 May 2006

We're talking about two different types of email format, which can make some comments sound contradictory.

Traditionally it is supposed to be up to 80 characters wide, with a hard return at the end of each line (and therefore giving the option for wider unwrapped lines when pasting in log files or code snippets etc), and the only way to get a paragraph was to hit Enter twice, just like TWiki.

When Microsoft and others made up their own idea of an email client, one of the incompatibilities they added due to not reading the specs was having each paragraph as a single line (the wrapping was only in the display to the user). That meant that users would only hit Enter once at the end of a paragraph, and recipients with wide X displays wore their necks out trying to read it

To deal with copying the second kind, I run a script or macro to double each carriage return, before doing anything else with it, no matter what app I'm pulling it into. The first kind, the one that's closer to the proper email spec in my view, is easy to deal with.

Fact is, in the wild we see both.

-- SueBlake - 12 May 2006

"Traditionally it is supposed to be up to 80 monospaced characters wide, with a hard return at the end of each line". This tradition is due to the constraints of ancient software and hardware, not for usability reasons.

When I read mail, I don't have my mail client zoomed to the width of my rather large screen, so I don't strain my neck. I also don't necessarily have it sized to show 80 character lines and so therefore much prefer not having line breaks, so that the paragraphs look like paragraphs no matter what.

-- MeredithLesly - 12 May 2006

Again, we need PageTypes it seems. This would allow some pages to be TML 1.0 and others TML 1.5 etc.

More powerfully other pages could be excel documents, etc.

-- MartinCleaver - 19 May 2006