Tags:
create new tag
, view all tags
If I am not wrong, we are not using at all the simple indentation without markers (*,+ or others).

I propose we implicitely convert indented text preceded and followed by a blank line to a PRE block or to a BLOCKQUOTE block. (I prefer PRE)

So, the following

text text text

   indented indented indented indented indented indented
      indented indented indented indented indented indented
      indented indented indented indented indented indented
   indented indented indented indented indented indented

text text text 
will be rendered as (PRE)

text text text

   indented indented indented indented indented indented
      indented indented indented indented indented indented
      indented indented indented indented indented indented
   indented indented indented indented indented indented
text text text

or as (BLOCKQUOTE)

text text text

indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented indented
text text text

-- AndreaSterbini - 13 Sep 2000

I was considering this before. WardCunnigham's original WikiWikiWeb does that. It makes it much easier to write preformatted text. I agree, better to use leading space for <PRE> text instead of <BLOCKQUOTE> text.

One thing to consider: An item of a list (bulleted, numbered or definition) can be spread over more then one line. Leading space defines follow up lines. The implicit <PRE> rule would not apply for those lines, because this would break the rendering of existing text.

Any "gocha" for existing text?

Question is if the implicit <PRE> rule should work exactly like the current hardcoded <PRE> rule, e.g. not Wiki rendering text? IMO it should do exactly the same.

-- PeterThoeny - 13 Sep 2000

The following lines of a list item are immediately preceded by the first line that is NOT an empty line. They belong to the item.

A simple hack to solve the above question is to actually STORE a <PRE> tag pair in the topic text (see CanonicalTopicStoredForm).

-- AndreaSterbini - 14 Sep 2000

We can start with the implementation. This rule should apply:

  • Preformatted text is done automatically for paragraphs with leading space.

Note the it says paragraphs and not lines, e.g. preformatted text must begin with an empty line. This is to avoid breaking existing text where bullets and tables (TableEditingProblems) may have follow up lines with leading spaces.

Example of PRE formatted text: Example of not PRE formatted text:
     This is line 1,
     This is line 2,
     This is line 3.
This is line 1,
     This is line 2,
     This is line 3.
Gets rendered as: Gets rendered as:
     This is line 1,
     This is line 2,
     This is line 3.
This is line 1, This is line 2, This is line 3.

-- PeterThoeny - 14 Sep 2000

Wondering if this should be implemented or not. It could break existing text. We do have this functionality with the <verbatim> ... <verbatim> tags. For now I change it from FeatureToDo to FeatureBrainstorming.

-- PeterThoeny - 26 Feb 2001

I would suggest:

(blank line)
(three spaces)"
text here more text

new paragraphs lists etc.
(three spaces)"
(blank line)

for blockquote and use ' for pre.

E.G.


   "
   here is a blockquote entry for your examination and the 
   nice part is that it is easy to type. And this is so long
   that it will wrap lines sonner or later, or later, or later,
   or later, or later, or later, or later, or later, or later,
   or later, or later, or later, or later, or later, or later.

   More paragraphs.
   "

formats as:

here is a blockquote entry for your examination and the nice part is that it is easy to type. And this is so long that it will wrap lines sonner or later, or later, or later, or later, or later, or later, or later, or later, or later, or later, or later, or later, or later, or later, or later.

More paragraphs.

and


   '
   here is a pre entry for your examination and the 
   nice part is that it is easy to type. And this is so long
   that it will wrap lines sonner or later, or later, or later,
   or later, or later, or later, or later, or later, or later,
   or later, or later, or later, or later, or later, or later.

   More paragraphs.
   '

formats as

   here is a pre entry for your examination and the 
   nice part is that it is easy to type. And this is so long
   that it will wrap lines sonner or later, or later, or later,
   or later, or later, or later, or later, or later, or later,
   or later, or later, or later, or later, or later, or later.

   More paragraphs.

The analogy between the use of " and ' in the shell is obvious to us nerds, but will it be ok for the less technical, or will it just confuse?

A possible alternative with a run-in quote is presented in TWikiMarkupForBlockquotes that looks like:

   "here is a blockquote entry for your examination and the 
nice part is that it is easy to type.
   "

I like the solitary quotes myself, but...

-- JohnRouillard - 29 Nov 2001

In trying to implement this since at least one person at work saw writing <pre> as a bother and wanted a wiki way of doing it. I came across the fact that PRE is actually treated specially in the wiki code. The inside/outside pre handlers are looking for pre.

So does this mean that I can only implement my substitution in the s/   "[ ]*$/<pre>/ startRenderingHandler to have it really take effect and affect the handlers that are called on the text.

-- JohnRouillard - 22 Jan 2003

I love this suggestion. My very first thought was, "This is so simple, it's elegant!" I can see lots of people easily grasping this the way Andrea suggests it. It's very simple, and that's why it's so good. My rule of thumb when educating users is write the text as you would an e-mail.

Johns proposal is not as good, because it relies on counterintuitive use of quotes. This would confuse users, and it doesn't match my rule of thumb above. It's unnatural, unrealistic, to have a quote on a line - and then nothing more. It looks incomplete.

Also, the different use of single and double quotes is too close. Quotes (in the grammatical sense) are always double, so whenever I would use quotes, I would use ". I consider single quotes to be apostrophes and not quotes at all. Apostrophes aren't used to enclose text. It may be that single and double quotes are clear for programmers, but the target audience of TWiki is wider than that.

Whichever method is chosen, I vote for the meaning <PRE> because that would make it possible to write code samples and similar (verbatim) quotations without any interfering wikization.

I believe it won't affect much existing code, because having three spaces in the beginning of a paragraph would be a rather odd thing to have, when there's no bulleting or other purpose to it.

(Dreaming) This is the sort of thing I wish I could instantly add to my twiki at work.

-- TorbenGB - 23 Jan 2003

Empty line before and after, and indent by a space - cannot be easier that that. Intuitive. I vote for that.

-- PeterMasiar - 23 Jan 2003

One problem is that cut and paste of quoted material requires you to go back and insert all the spaces at the beginning of the lines. Not a problem in a real editor, but a nightmare for large quoted sections in the text area. I was trying to not have to do that. Hence the use of quotes and apostrophe's.

I'll see what I can do though.

How about this:

this is pre text since it doesn't start a paragraph with a quote.

but this

"this is a blockquote since it starts with a quote. should it also end with a quote at the end of a line?"

"Then the next paragraph starts with indented quote for a blockquote"

and I can use solo quotes for blockquotes that are longer that I don't want to indent, or for nested blockquotes. Solo apostrophe's could still work for non-indented pre and verbatim blocks since they are like quoted material, only stronger implying that the quote shouldn't be formatted at all as in a block quote.

-- JohnRouillard - 23 Jan 2003

John, your point about pasting in long quoted texts is noted. I hadn't thought of that when I replied earlier. But I'd still like to argue that your suggestion adds a certain amount of implicity; users won't know intuitively how to apply this formatting (see also RuleOne). While I find that you're trying to solve a valid problem, I think the solution is mostly useful for experienced Twiki users but will confuse novices. It's just a little too complex to remember, even for me now: I read your contribution just moments ago, but now I can't remember how I would go about adding a PRE or a BLOCKQUOTE the way you suggested it.

Perhaps less is more: having less formatting rules gives a formatting ruleset that is easier to remember and use. The downside would be that when dealing with for instance long quoted texts, you'd have to work with the text to make it fit. But the rule you are working with would still be simple, and that's the real argument for choosing it. Besides, other formatting markup has this same flaw, for instance when pasting in a bullet list or even a table you would also need to adjust the pasted result to make it follow Twiki formatting, but this is straightforward (though possibly much work) because the ruleset is simple. AndreaSterbini's proposal is a beautifully simple implementation of PRE, though it does not address BLOCKQUOTE.

-- TorbenGB - 25 Jan 2003

I am trying to support both approaches. But there are ambiguities with the list syntax.

I currently have a BlockPlugin implementing a natural blockquote using a blank line followed by an indented line starting with a ". The blockquote ends at the first non-indented line after a blank line. Putting a <NOP> before the indented quote stops this formatting.

That is probably all most people will use. I did not implement a "natural" way for nested blockqotes falling back on the artificial syntax:

[three spaces]", [three spaces]"", ... [three spaces]"""""
for those roles because it is nonambiguous. Also I am counting the depth level, so a ' """' can be closed with a ' " ', and the right number of end blockquote markers are automatically emitted. A natural implementation could be done by tracking the indentation level's but you will have to do a lot of manual formatting on long passages where they are most likely to be used. Also, I don't think nested blockquotes are used heavily enough to write the code (and take the performance hit) required to do natural nested blockquote formatting.

Natural preformatted text work similarly: it starts with an indented line after a blank line if the indented line does not look like the start of a list, and ends at the first non-indented line after a blank line.

The start of list detection isn't great. Since I have seen a lot of lists started with blank lines, I don't select preformatting mode if the first indented non-blank line starts with tabs (three spaces are converted to tabs internally to TWiki) followed by a digit or * (bullet). This prevents most conflicts with the current list syntax. If list syntax is extended to allow alphabetic and roman style item numbering then there are problems. A preformatted line starting with "A" is ambiguous. Since the current numbered list syntax doesn't start with number followed by punctuation, there is no way to resolve the ambiguity without the user helping out. E.G.

   3 west street
   5 port drive
   7 blue way
is this a numbered list, or a preformatted list of addresses? On the other hand:
   '
   3 west street
   5 port drive
   7 blue way
   '
can't be anything but the preformatted list of addresses. Sadly changing the numbered list syntax require punctuation like:
   3. west street
   5) port drive
   7. blue way
resolves the ambiguity, but breaks all the current markup pages since they explicitly don't handle the punctuation following the numbers.

I also haven't handled the ambiguity in labeled lists yet either. They can still be picked up as preformatted text. I will probably look for tab, 1 or more alphanumeric, :, and users will have to use explicit markup to get these blocks as preformatted text.

-- JohnRouillard - 25 Jan 2003

Edit | Attach | Watch | Print version | History: r16 < r15 < r14 < r13 < r12 | Backlinks | Raw View | Raw edit | More topic actions
Topic revision: r16 - 2004-03-10 - PeterThoeny
 
  • Learn about TWiki  
  • Download TWiki
This site is powered by the TWiki collaboration platform Powered by Perl Hosted by OICcam.com Ideas, requests, problems regarding TWiki? Send feedback. Ask community in the support forum.
Copyright © 1999-2017 by the contributing authors. All material on this collaboration platform is the property of the contributing authors.