[pmwiki-users] Planning for 2.2.0

[Marc Cooper]

Joachim Durchholz said...
> Marc Cooper schrieb:
> > Joachim Durchholz said...
> >> Marc Cooper schrieb:
> >>> I'd not heard of this, but its advocation of markup treating a line 
> >>> break as a line break is enough to having me running a mile from it.
>  >>
> >> Why?
> >> Actually I found that attractive.
> > 
> > Because writers and typesetters use line breaks in their text for their 
> > own purposes, but do not require the text to be presented with those 
> > line breaks.
> 
> Sure, there are constructs where I want to have line breaks. (Longish, 
> deeply structured directives etc.)

When typesetting, a line (of text) has no correlation to a sentence or 
any other grammatical construct. How you choose to configure your editor 
for your preferred viewing purposes is your choice.

It's very important in this discussion not to confuse viewing the markup 
with viewing the result of the markup. WYSINWYG is an attempt at 
correlating the two.
 
> For stretches of word-wrapped texts, I once made efforts to put each 
> "semantic unit" (sentence or group of words that have significant 
> meaning) on its own line, to facilitate version control - and found that 
> the gain was minimal (because changing a unit would all too often affect 
> neighbouring units, too), but the result was more difficult to read.

I can imagine. Many folk don't use word-wrap at all - the editor line 
breaks at an approximate width. For version control, this makes 
the diffs useful.
 
> So it might depend on context whether line breaks should be significant.

Oh for sure, but we are talking wiki markup here.

> In YAML, they even allow the author to choose.

Always a good thing - as long as it doesn't introduce extra work.

> There's markup for text 
> blocks with significant line breaks, and markup for text blocks with 
> insignificant line breaks. I don't know whether such a thing would be 
> useful in PmWiki, but it's at least an interesting approach :-)

It depends. Taking the cut and paste example I mentioned: if it were not 
possible to cut and paste some arbitrary - but lengthy - text and insert 
it into PmWiki without change, and for the text not to be rendered as it 
is now, then I for one wouldn't be here :-)
 
>  > Wiki markup - like HTML and (La)TeX - are, in effect,
> > typesetting languages.
> 
> Agreed.
> 
> > Also, consider performing a copy and paste from one tool to another 
> > where this crazy rule applied.
> 
> Don't consider something "crazy" just because you didn't understand what 
> it's good for.

Pot, kettle, black. I'll call it for what it is, and until you know 
better, you don't know whether I understand the idea or not.

>  > You would have to re-edit the pasted text
> > to correct all the line breaks.
> 
> Yup. That's what I currently have to do when importing mails into 
> PmWiki. Or texts that I wrote in my text editor.

Then, I suspect that you are either using the wrong tools, or not using 
the tools to the best of their ability. I can go both ways in my editor 
with the stroke of a key.
 
> Face it, outside of wikis, line breaks are often significant in most 
> contexts.

This is not true at all; the world of publishing relies on it not being 
true. In any case, I can cite HTML (and friends), almost all programming 
languages, all typographical tools to refute your claim.

In fact, it would be more correct to say that line breaks are 
insignificant in most (text) contexts except in WYSINWYG tools. And, as 
I mentioned above, that is because they are an attempt to directly 
correlate markup and its final result. As a typographical method, this 
simplifies producing results for the unskilled, but one must remember 
that it is a limited subset of the typographical domain.

> While wikis are text formatting languages

No, they are typographical tools; in the sense that they render content 
to the author's demands. Wiki markup is not a text formatting tool; 
although text formatting is a subset of what it does.

There is a difference between typography and text formatting.

> they try to be *simple*

The markup should be as simple as possible and no less - to paraphrase 
someone.

> and appeal to people who don't carefully distinguish between 
> content and form (because they don't have to), and for these, making 
> line breaks insignificant is just a pain in the a**.

You are making a sweeping generalisation in the first part of your 
sentence that is incorrect. Clearly, there are folk who have simple, 
basic needs that use wikis, just as there are those who wish to use them 
in more demanding ways.

For those who have only had exposure to visual text editing tools, I 
suspect that a line break not representing a line break might seem a 
little strange, but, for anyone else, it is a necessity.

Let me put it another way: you - as an advocate of line break = line 
break - happily use PmWiki's syntax, but would prefer Creole's syntax. 
but I, quite simply, could not use Creole's syntax. While it might 
"improve" text editing - as you perceive it - it breaks the typography 
and is thus useless to me.

> > I'll send you the text of a novel on which to perform this task and I
> > wager that you'll have changed your view before the end of chapter
> > one.
> 
> Nope, I'm going to write a script for that task :-)

That's a good demonstration of the inappropriate use of tools. The 
current setup requires no tools, but Creole's syntax necessitates the 
building of tools to perform a very basic task.
 
> And I'd seriously recommend tool support for this kind of task.

I don't need it, because I'm already using my tools correctly. I don't 
need to break typography to perform my text editing.

The reason I used that example was to invite you to imagine the tasks 
involved in typesetting content of the scale of a book - just a novel, 
not a technical book, which is far more demanding. If you can't imagine 
it, then download an example from Gutenberg and try it. You'll soon find 
the tools that you need and why line break = line break makes your task 
unimaginably awful.

> It may 
> not be 100% perfect, but if I have to correct something at the end of 
> every paragraph, it still did 90% of the chore.

Bzzt! You lose. I can take the text of a novel and have it typeset for 
proofing in minutes. It will be 100% perfect - well, I might need to 
force the odd page break, but 90% would create hours of work.
 
> > In addition, interpreting line breaks in this way would create a problem 
> > with editors with hard text widths.
> 
> Oh, get a life.

Ah, you've resorted to insults. Seems like I've won the debate before I 
started this post.

> Even Notepad doesn't work that way (if it ever did). 

Notepad is a toy. It's functional, but in a very limited domain.

> Even Big Blue machines come with Linux, or at least a Posix-conformant 
> file system, so these systems aren't as intimately tied to fixed-length 
> records as they used to be ten years ago.

What you don't know is that it's very common to work with text widths 
that force a new line. set textwidth=72 in vim, for example. For visual 
use, the block/paragraph can easily be reformatted with a simple command 
- my email client does the same thing. (These are not fixed-length 
records, btw, which is a very different thing.)

As I said, it's a question of using the appropriate tools and using them 
in the right way. Breaking typography to cover up for the inappropriate 
use of tools is the wrong direction.

> Sure, you might still encounter sites with "legacy" toolchains that 
> limit line lengths. But even these can use a tool to convert between 
> conventions.

Oh, I never said that swapping between formats isn't easy - it's 
trivial. But that is something entirely different to attributing 
semantic meaning to a line break. Once you do that, you can't undo it. 
That's the heart of the problem. That's why it's the wrong thing to do.

> > Other than WYSINWYG apps, writing tools don't behave in this way.
> 
> Which tools? I haven't encountered one of this kind in years, so I'm 
> genuinely curious.

All typographical tools - any half decent editor can, of course, be 
configured to behave any which way. As I said, don't confuse text 
editing with typography.

-- 
Best,
Marc