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