At line 28 changed one line |
=== well, alinea === |
== well, alinea ! == |
At line 32 changed one line |
Thanks for paying attention. Plan to write an extensive explaination on newline / paragraph problematic. Try anyway to synthesize my point of view here for you -- and as a stub (rough? proper word?). |
Thanks for paying attention. I Plan to write an extensive doc on that newline / paragraph problem. I'll try anyway to synthesize my point of view here for you -- and as a stub (rough? proper word?). |
At line 34 changed one line |
(//foreword :// I recently discovered the [[ChangeLinebreakMarkupProposal]] which is a rather long list of points, but imo nevertheless doesn't really address all aspects of the problem. Or inverses priorities, letting technics before use. In fact, I would say that techncians, which obviously we all are, should let their opinion after users' ones, for they are not the target public of such a tool as wikitext -- weird rules aren't a problem for them and they have other means.) |
//foreword : I recently discovered the [[ChangeLinebreakMarkupProposal]] which is a rather long list of points, but (imo) nevertheless doesn't really address all aspects of the problem. Or inverses priorities, letting technics before use. In fact, I would say that techncians, what obviously we all are, should let their opinion after users' ones, for they (techos) are not the target public of such a tool as wikitext -- weird rules aren't a major problem for them and they have other means.// |
At line 36 changed 2 lines |
First, I introduced "alinea" as a plain to to avoid confusion both with "line" (possible confusion : logical line, paragraph, broken line, visual line, wrapped line) and "paragraph" (confusions with the ordinary sense i.e. a type of alinea, and with <p>...</p>). So "alinea" means paragraph-level elements, thus including list item, header, table row... And it means only that. Note that alineas are the only explicit structural elements marked in creole, their tags beeing = * # | and (nothing). A page is a sequence of alineas.\\ |
//lexical note :// '¶' is called "alinea" in germanic languages, but has other weird names in other languages ("pied-de-mouche" = "fly-foot" in french ;-)). '§' is called "paragraph sign" in romanic languages and germanic ones except english. "alinea" has a sense close to "paragraph" at least in french and dutch : (free translation from wikitionnaire.fr) \\ |
First, I introduced "alinea" as a keyword to avoid confusion both with "line" (possible confusions : logical line, paragraph, broken line, visual line, wrapped line) and "paragraph" (confusions with the ordinary sense i.e. a type of alinea, and with <p>...</p>). So "alinea" means paragraph-level elements, including list item, header, table row... And it means only that. Note that alinea is the only explicit structural element marked in creole ; the tags beeing = * # | and (nothing). A page is a sequence of alineas.\\ |
|
<lexical search> '¶' is called "alinea" in germanic languages, but has other weird names in other languages ("pied-de-mouche" = "fly-foot" in french ;-)). '§' is called "paragraph sign" in romanic languages and germanic ones except english. "alinea" has a sense close to "paragraph" at least in french and dutch : (free translation from wikitionnaire.fr) \\ |
At line 39 changed one line |
If you find a better word or overall way to avoid confusion, I will be pleased. Or we run for standard wiki jargon definitions of both "paragraph" (extension of the meaning to all paragraph level element types) and (restriction to ligical lines). I would be pleased to welcome clear and strandard words. Also for newline, new line, like break, etc... |
If you find a better word or overall way to avoid confusion, I will be pleased. Or we run for standard wiki jargon definitions of both "paragraph" (extension of the meaning to all paragraph level element types) and (restriction to ligical lines). I would be pleased to welcome clear and strandard words. Also for newline, new line, like break, etc... </lexical search> ;-) |
At line 41 changed 3 lines |
A newline may have such functions : |
# if ignored : nothing\\ |
Present rule in creole for regular paragraphs only. |
Now, to the point. A newline may have such functions : |
# if ignored : none\\ |
This is the present rule in creole for regular paragraphs only. |
At line 45 changed one line |
Doesn't happen in Creole. |
This doesn't happen in Creole. |
At line 47 changed one line |
Present rule in creole for all other alinea types. |
This is the present rule in creole for all other alinea types. |
At line 49 changed one line |
First, there's an evident lack of consistency. As a user, I wondered why a newline worked "normally" for lists, not for regular paragraphs. Also note that the simple newline (introducing or not a new paragraph) is from far the most used formatting mark! |
First, there's an evident lack of consistency : as a user, I wonder why a newline works "as expected" for lists, not for regular paragraphs. Also note that the simple new line (introducing or not a new paragraph) is from far the most used formatting mark! |
At line 51 changed 2 lines |
Second, how can we accept such a major difference between the source and displayed text? Confusion for sure. This breaks the prominent rule that source & display are as similar as possible, so that one can write naturally, even not well knowing markup and predict the output.\\ |
If this were not so relevant, we should adopt another markup for tables, e.g. one cell per line, to allow for much better layout. |
Second, how can we accept such a major difference between the source and displayed texts ? Confusion for sure. This breaks the prominent rule that source & display texts be as similar as possible, so that one can write rather naturally, even not well knowing markup, and still more or less predict the output.\\ |
If this were not relevant, we should adopt another markup for tables, e.g. one cell per line, to allow for much better layout. |
At line 54 changed 2 lines |
Moreover, what does the user/author expect? Either case 1 or case 2. Then comes a big issue about choosing the one or the other, as well as several ways and interpretations of the various alternatives.\\ |
Anyway I hold on the fact that at least & and in all cases the simple character value of a newline should be preversed. |
Moreover, what does the user/author expect ? Either case #2 or case #3. Then only comes the issue about choosing the one or the other, as well as several ways and interpretations of the various alternatives.\\ |
We may choose not to give a tag value value to newline, as end of paragraph. Anyway I hold on the fact that at least its simple character value should be preversed. |
It also makes the rule more consistent with the case of headers, list items and table rows. |
At line 57 changed 2 lines |
It also makes the rule more consistent with the case of headers, list items and table rows. In case #2, I would accept with pleasure |
* either a paragraph start character like for all other alinea type (like § ¶ _ or whitespace, never mind), |
If case #2 would be agreed, I would accept with pleasure |
* either a paragraph start character like for all other alinea types (like § ¶ _ or whitespace, never mind), |
At line 60 changed one line |
This solution is probably better vusually, in source text. But it is less consistent and may lead to a slightly different semantic (more about that later). |
This solution is probably visually better, I mean in source text. But it's less consistent and may lead to a slightly different semantic (more about that later). |
At line 62 changed one line |
I welcome all objections about that, especially |
I fully admit all objections about that, especially |
At line 67 added one line |
But it does not seem important enough to me. |
At line 66 changed one line |
(pleased to have expressed it), denis alias [[spir]] |
pleased to have expressed it, thank you for the opportunity\\ |
denis alias [[spir]] |
At line 73 added one line |
---- |
At line 77 added 13 lines |
{{{ |
[denis :] John, I fully agree with that, including that kind of choice |
& above the ID specification. As I tried to explain, |
the major problem is not that a newline doesn't introduce a paragraph, |
so to produce a vertical spacing on rendered text, for instance. |
Rather that it doesn't do anything :-( |
Which in not what a writer expects : *why* did s/he hit the bl**** key ?. |
Which is not what is shown in the edit window. |
Which is not what happens in all other writing contexts. |
In other words, a newline must be either an end-of-line /mark/ (=<br>) |
or a end-of-line /tag/ (=<p>). |
}}} |
|
At line 92 added 20 lines |
{{{ |
[denis] No. There's no magic ;-) ! The language syntax / lexicon pattern is a |
closed field, we are limited to a few possibilities. |
The aim is to try and choose the most intuitive, clear & consistent one. |
Now, we may be tempted to introduce an alternative & more expressive syntax |
for 'rich' tables. For instance : |
||[row 1 format]|| |
|[cell 1 format] text | |
|[cell 2 format] text | |
||[row 2 format]|| |
|[cell 1 format] text | |
|[cell 2 format] text | |
where format is optionnal and text holds whatever you like, up to a full page. |
But the points are that it would confuse users because of |
(1) 2 syntactic forms for tables (the simple, visual, one must be kept) |
(2) a layout that doesn't match rendered text. |
(3) complexity |
Now, imho, creole's low level of expressivity is a second-rank pb compared to that #*?$! misleading newline swallowing ;-) |
}}} |
|
At line 114 added 29 lines |
{{{ |
[denis] Well, hard for me to introduce that in few words. |
First, let's admit that a newline is preserved as a normal character, |
i.e. it would start a new line (which should be rare : bad practice). |
Then, how to express a new (regular) paragraph instead ? |
If a paragraph-start tag, similar to '*' for a list item, is not welcome, |
then remains the blank-line = double newline solution. Good. |
|
But there is a difference between a start tag and a blank line : |
the latter is rather (or more) a separator both in source and displayed texts. |
Think at lists for instance : a start tag is not a separator. |
Do you agree with that ? |
If yes, then you can imagine that this blank line will often be used rather |
as a page (sub-)section separator than as a paragraph end or start tag. |
Thus introducing a new level of text visual & semantic structure. |
You see what I mean ? You may not agree ! |
This must not be bad, I rather like that idea. In traditionnal layout and |
typography, horrors like horizontal rules(*) hardly exist ;-). |
Rather semantic separation is shown with blank space and/or nice symbols |
like [[wikipedia:asterism]] which don't break the _text flow_. |
We can also keep the best of both worlds, by introducing a paragraph start |
*and* replacing h_rules by blank lines. It looks like your proposal above? |
We can also do that even if a newline starts a paragraph |
(and line break is marked with escape or \\), as you said, it's not either-or. |
Of course, successive blank lines would be merged. |
|
(*) Also not clear whether h_rules start super-sections or sub-sections, no ? |
}}} |
|
At line 145 added 2 lines |
Thank's again for giving me the opportunity to dig further... --[[spir]] |
|
At line 152 added 12 lines |
|
{{{ |
[denis] If I understand well, what you mean is that line breaks are permitted |
inside lists. Yes. I must have been rather unclear, as it is not what I was |
talking about. What I meant is that for any paragraph-level element |
(what I call an alinea : list item , table row, header), |
a newline ends that element, which means that the newline is processed |
(1) as a simple character to start a new line (2) as a tag. |
While the same newline is ignored only in the case of a regular paragraph |
of simple text. A behaviour that I don't find coherent. |
In other words, why don't you need a blank line between list items ? |
}}} |