On Mar 29, 3:30 pm, The Editor <[email protected]> wrote:
> On Sun, Mar 29, 2009 at 9:22 AM, Markus <[email protected]> wrote:
>
> > Hi,
>
> > Am I right that BoltWire adds an empty line after a code block?
>
> Technically, no. But if there is a line return after the </code>, it
> will be preserved. We could change that behavior, by simply changing
> markups.php line 18 to
>
> MarkUp('pre', 'code', '/&lt;code>(.*?)&lt;\/code>\n?/se',
> 'BOLTMcode("$1", "code")');  // <code>

Thank you, Dan!

The previous behavior seems a bit counterintuitive. Please, have a
look at these examples and the potential solution at the end:

1)

Wiki:
<code> ... code ... </code> ... text ...

HTML:
<div class='code'> ... code ... </div> ... text ...

Output:
code
text

This user likely expected to write inline code but got a line break.

2)

Wiki:
<code> ... code ... </code>
... text ...

HTML:
div class='code'> ... code ... </div><br />... text ...

Output:
code
(empty line)
text

This user likely expected to put text in the line after code but got
an empty line.

3)

Wiki:
<code> ... code ... </code>

... text ...

HTML:
<p><div class='code'> ... code ... </div></p>
<p>... text ...</p>

Output:
code
text

This user either expected to make two paragraphs and is now happy, or
unhappy if he expected an empty line (though this guy would expect
lots of empty lines since he missed that an empty line in wiki markup
yields a new paragraph).

In 1) the user wonders how to achieve inline code.

In 2) no empty line brought an empty line

In 3) an empty line brought no empty line.

Your modified code does not touch 1), fixes 2), but in 3) the user who
expected a new paragraph now gets an empty line.

Is there good reason against using the same behavior for <code> as for
<color>? <color> allows inline styling, gives no empty line in 2) and
the expected new paragraph in 3).

Interestingly, the behavior for <box> differs:

1) <box>... code ...</box> ... text ...
-> Line break (or div break).

2) <box> ... code ... </box>
... text ...
-> New paragraph. (Why?)

3) <box> ... code ... </box>

... text ...
-> vspace (why?) and a new paragraph.

So, what's best?!

Regards, Markus


>
> > If so, I'd rather suggest not to add it because it is easier to create
> > an empty line than to remove it.
>
> Agreed.
>
> > Just to think about: Would it be nice to be able to configure the size
> > of the edit text field from within site.config? I assume the majority
> > of users would prefer more than 16 rows by default.
>
> This is certainly an option. Another is to do it in code.snippets (as
> that would not require any core code change).
>
> Just put in code.snippets
>
> cols: 50
> rows: 30
>
> Then change the forms to
>
> rows: $$rows
> cols: $$cols
>
> I'd probably prefer to keep the core (default) simple. But an advanced
> user could do this easily (not tested). The other option of course is
> just to edit action.edit
>
> Cheers,
> Dan
--~--~---------~--~----~------------~-------~--~----~
You received this message because you are subscribed to the Google Groups 
"BoltWire" group.
To post to this group, send email to [email protected]
To unsubscribe from this group, send email to 
[email protected]
For more options, visit this group at 
http://groups.google.com/group/boltwire?hl=en
-~----------~----~----~----~------~----~------~--~---

Reply via email to