Add a newline after a LineBreak to writers?

Add a newline after a LineBreak to writers?

[Tim Lin]

[-- Attachment #1.1: Type: text/plain, Size: 3205 bytes --]

I'm using the line-block construct extensively fro writing pseudocode. It 
usually works great, but boy does the rendered output look ugly. Here's an 
example of what one of my typical algorithms can end up looking in LaTeX:

\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\\texttt{\ 
2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ a\ comment}\texttt{\ 
3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\\texttt{\ 
4.}~~\textbf{repeat}~until~convergence\\\texttt{\ 
5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\ 
6.}~~~~~~~~$\sigma \leftarrow 0$\\\texttt{\ 
7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\ 
8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\\texttt{\ 
9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} 
\phi_j$\\\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\\texttt{12.}~~~~~~~~$\phi_i 
\leftarrow \frac 1 {a_{ii}} (b_i - 
\sigma)$\\\texttt{13.}~~~~\textbf{end}~($i$-loop)\\\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat)

It's serviceable, but really hard to play with for a human. The HTML writer 
doesn't far much better. I realize that line-block are a special case where 
the usage of LineBreak can easily get out of control.

I wonder if it's better to add a newline after each LineBreak inline 
element. I'm really just targeting line-blocks, but as they don't have 
their own block-level type the only alternative is to change LineBreak 
behavior. The above example would then look like this:

\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\
\texttt{\ 2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ a\ 
comment}
\texttt{\ 3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\
\texttt{\ 4.}~~\textbf{repeat}~until~convergence\\
\texttt{\ 
5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\
\texttt{\ 6.}~~~~~~~~$\sigma \leftarrow 0$\\
\texttt{\ 
7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\
\texttt{\ 8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\
\texttt{\ 9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} \phi_j$\\
\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\
\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\
\texttt{12.}~~~~~~~~$\phi_i \leftarrow \frac 1 {a_{ii}} (b_i - \sigma)$\\
\texttt{13.}~~~~\textbf{end}~($i$-loop)\\
\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat)

I can't really think of any negative ramification off the top of my head. 
I'd appreciate any help thinking about whether this would break anything.

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/b25e52ed-107c-4f32-a128-b9b68c149ce4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 4302 bytes --]

Re: Add a newline after a LineBreak to writers?

[John MacFarlane]

I think this is a good idea.  (But maybe we should make it sensitive to `--no-wrap`, and omit the newline if `--no-wrap`?)

+++ Tim Lin [Feb 03 15 17:46 ]:
>I'm using the line-block construct extensively fro writing pseudocode. It
>usually works great, but boy does the rendered output look ugly. Here's an
>example of what one of my typical algorithms can end up looking in LaTeX:
>
>\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\\texttt{\
>2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ a\ comment}\texttt{\
>3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\\texttt{\
>4.}~~\textbf{repeat}~until~convergence\\\texttt{\
>5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\
>6.}~~~~~~~~$\sigma \leftarrow 0$\\\texttt{\
>7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\
>8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\\texttt{\
>9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij}
>\phi_j$\\\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\\texttt{12.}~~~~~~~~$\phi_i
>\leftarrow \frac 1 {a_{ii}} (b_i -
>\sigma)$\\\texttt{13.}~~~~\textbf{end}~($i$-loop)\\\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat)
>
>It's serviceable, but really hard to play with for a human. The HTML writer
>doesn't far much better. I realize that line-block are a special case where
>the usage of LineBreak can easily get out of control.
>
>I wonder if it's better to add a newline after each LineBreak inline
>element. I'm really just targeting line-blocks, but as they don't have
>their own block-level type the only alternative is to change LineBreak
>behavior. The above example would then look like this:
>
>\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\
>\texttt{\ 2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ a\
>comment}
>\texttt{\ 3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\
>\texttt{\ 4.}~~\textbf{repeat}~until~convergence\\
>\texttt{\
>5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\
>\texttt{\ 6.}~~~~~~~~$\sigma \leftarrow 0$\\
>\texttt{\
>7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\
>\texttt{\ 8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\
>\texttt{\ 9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} \phi_j$\\
>\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\
>\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\
>\texttt{12.}~~~~~~~~$\phi_i \leftarrow \frac 1 {a_{ii}} (b_i - \sigma)$\\
>\texttt{13.}~~~~\textbf{end}~($i$-loop)\\
>\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat)
>
>I can't really think of any negative ramification off the top of my head.
>I'd appreciate any help thinking about whether this would break anything.
>
>-- 
>You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/b25e52ed-107c-4f32-a128-b9b68c149ce4%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

Re: Add a newline after a LineBreak to writers?

[Tim Lin]

[-- Attachment #1.1: Type: text/plain, Size: 4663 bytes --]

The no wrap thing sounds sensible, although I really have no idea whether 
more people expect the whole block to be unwrapped or just the individual 
lines.

Personally I would expect `--no-wrap` output to be useful for editing 
without needing text reflowing functionality. With that assumption, 
unwrapping individual lines but breaking at the LineBreaks seems to me to 
be the most friendly behavior for editing.
 

On Wednesday, 4 February 2015 09:57:18 UTC-8, John MacFarlane wrote:
>
> I think this is a good idea.  (But maybe we should make it sensitive to 
> `--no-wrap`, and omit the newline if `--no-wrap`?) 
>
> +++ Tim Lin [Feb 03 15 17:46 ]: 
> >I'm using the line-block construct extensively fro writing pseudocode. It 
> >usually works great, but boy does the rendered output look ugly. Here's 
> an 
> >example of what one of my typical algorithms can end up looking in LaTeX: 
> > 
> >\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\\texttt{\ 
> >2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ a\ 
> comment}\texttt{\ 
> >3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\\texttt{\ 
> >4.}~~\textbf{repeat}~until~convergence\\\texttt{\ 
> >5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\ 
>
> >6.}~~~~~~~~$\sigma \leftarrow 0$\\\texttt{\ 
> >7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\ 
>
> >8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\\texttt{\ 
> >9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} 
> >\phi_j$\\\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\\texttt{12.}~~~~~~~~$\phi_i 
>
> >\leftarrow \frac 1 {a_{ii}} (b_i - 
> >\sigma)$\\\texttt{13.}~~~~\textbf{end}~($i$-loop)\\\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat) 
>
> > 
> >It's serviceable, but really hard to play with for a human. The HTML 
> writer 
> >doesn't far much better. I realize that line-block are a special case 
> where 
> >the usage of LineBreak can easily get out of control. 
> > 
> >I wonder if it's better to add a newline after each LineBreak inline 
> >element. I'm really just targeting line-blocks, but as they don't have 
> >their own block-level type the only alternative is to change LineBreak 
> >behavior. The above example would then look like this: 
> > 
> >\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\ 
> >\texttt{\ 2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ 
> a\ 
> >comment} 
> >\texttt{\ 3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\ 
> >\texttt{\ 4.}~~\textbf{repeat}~until~convergence\\ 
> >\texttt{\ 
> >5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\ 
> >\texttt{\ 6.}~~~~~~~~$\sigma \leftarrow 0$\\ 
> >\texttt{\ 
> >7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\ 
>
> >\texttt{\ 8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\ 
> >\texttt{\ 9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} \phi_j$\\ 
> >\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\ 
> >\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\ 
> >\texttt{12.}~~~~~~~~$\phi_i \leftarrow \frac 1 {a_{ii}} (b_i - \sigma)$\\ 
> >\texttt{13.}~~~~\textbf{end}~($i$-loop)\\ 
> >\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat) 
>
> > 
> >I can't really think of any negative ramification off the top of my head. 
> >I'd appreciate any help thinking about whether this would break anything. 
> > 
> >-- 
> >You received this message because you are subscribed to the Google Groups 
> "pandoc-discuss" group. 
> >To unsubscribe from this group and stop receiving emails from it, send an 
> email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. 
> >To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org 
> <javascript:>. 
> >To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pandoc-discuss/b25e52ed-107c-4f32-a128-b9b68c149ce4%40googlegroups.com. 
>
> >For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/eef791a5-f76f-4e98-a2bc-0e63c79bc7db%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 6649 bytes --]

Re: Add a newline after a LineBreak to writers?

[John MacFarlane]

OK, let's just make it insensitive to `--no-wrap`, with a line break either way.

+++ Tim Lin [Feb 04 15 17:42 ]:
>The no wrap thing sounds sensible, although I really have no idea whether
>more people expect the whole block to be unwrapped or just the individual
>lines.
>
>Personally I would expect `--no-wrap` output to be useful for editing
>without needing text reflowing functionality. With that assumption,
>unwrapping individual lines but breaking at the LineBreaks seems to me to
>be the most friendly behavior for editing.
>
>
>On Wednesday, 4 February 2015 09:57:18 UTC-8, John MacFarlane wrote:
>>
>> I think this is a good idea.  (But maybe we should make it sensitive to
>> `--no-wrap`, and omit the newline if `--no-wrap`?)
>>
>> +++ Tim Lin [Feb 03 15 17:46 ]:
>> >I'm using the line-block construct extensively fro writing pseudocode. It
>> >usually works great, but boy does the rendered output look ugly. Here's
>> an
>> >example of what one of my typical algorithms can end up looking in LaTeX:
>> >
>> >\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\\texttt{\
>> >2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ a\
>> comment}\texttt{\
>> >3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\\texttt{\
>> >4.}~~\textbf{repeat}~until~convergence\\\texttt{\
>> >5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\
>>
>> >6.}~~~~~~~~$\sigma \leftarrow 0$\\\texttt{\
>> >7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\
>>
>> >8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\\texttt{\
>> >9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij}
>> >\phi_j$\\\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\\texttt{12.}~~~~~~~~$\phi_i
>>
>> >\leftarrow \frac 1 {a_{ii}} (b_i -
>> >\sigma)$\\\texttt{13.}~~~~\textbf{end}~($i$-loop)\\\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat)
>>
>> >
>> >It's serviceable, but really hard to play with for a human. The HTML
>> writer
>> >doesn't far much better. I realize that line-block are a special case
>> where
>> >the usage of LineBreak can easily get out of control.
>> >
>> >I wonder if it's better to add a newline after each LineBreak inline
>> >element. I'm really just targeting line-blocks, but as they don't have
>> >their own block-level type the only alternative is to change LineBreak
>> >behavior. The above example would then look like this:
>> >
>> >\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\
>> >\texttt{\ 2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\
>> a\
>> >comment}
>> >\texttt{\ 3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\
>> >\texttt{\ 4.}~~\textbf{repeat}~until~convergence\\
>> >\texttt{\
>> >5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\
>> >\texttt{\ 6.}~~~~~~~~$\sigma \leftarrow 0$\\
>> >\texttt{\
>> >7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\
>>
>> >\texttt{\ 8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\
>> >\texttt{\ 9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} \phi_j$\\
>> >\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\
>> >\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\
>> >\texttt{12.}~~~~~~~~$\phi_i \leftarrow \frac 1 {a_{ii}} (b_i - \sigma)$\\
>> >\texttt{13.}~~~~\textbf{end}~($i$-loop)\\
>> >\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat)
>>
>> >
>> >I can't really think of any negative ramification off the top of my head.
>> >I'd appreciate any help thinking about whether this would break anything.
>> >
>> >--
>> >You received this message because you are subscribed to the Google Groups
>> "pandoc-discuss" group.
>> >To unsubscribe from this group and stop receiving emails from it, send an
>> email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>.
>> >To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org
>> <javascript:>.
>> >To view this discussion on the web visit
>> https://groups.google.com/d/msgid/pandoc-discuss/b25e52ed-107c-4f32-a128-b9b68c149ce4%40googlegroups.com.
>>
>> >For more options, visit https://groups.google.com/d/optout.
>>
>>
>
>-- 
>You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
>To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
>To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/eef791a5-f76f-4e98-a2bc-0e63c79bc7db%40googlegroups.com.
>For more options, visit https://groups.google.com/d/optout.

Re: Add a newline after a LineBreak to writers?

[Tim Lin]

[-- Attachment #1.1: Type: text/plain, Size: 5861 bytes --]

all right, will get something going tonight

On Wednesday, 4 February 2015 19:52:52 UTC-8, John MacFarlane wrote:
>
> OK, let's just make it insensitive to `--no-wrap`, with a line break 
> either way. 
>
> +++ Tim Lin [Feb 04 15 17:42 ]: 
> >The no wrap thing sounds sensible, although I really have no idea whether 
> >more people expect the whole block to be unwrapped or just the individual 
> >lines. 
> > 
> >Personally I would expect `--no-wrap` output to be useful for editing 
> >without needing text reflowing functionality. With that assumption, 
> >unwrapping individual lines but breaking at the LineBreaks seems to me to 
> >be the most friendly behavior for editing. 
> > 
> > 
> >On Wednesday, 4 February 2015 09:57:18 UTC-8, John MacFarlane wrote: 
> >> 
> >> I think this is a good idea.  (But maybe we should make it sensitive to 
> >> `--no-wrap`, and omit the newline if `--no-wrap`?) 
> >> 
> >> +++ Tim Lin [Feb 03 15 17:46 ]: 
> >> >I'm using the line-block construct extensively fro writing pseudocode. 
> It 
> >> >usually works great, but boy does the rendered output look ugly. 
> Here's 
> >> an 
> >> >example of what one of my typical algorithms can end up looking in 
> LaTeX: 
> >> > 
> >> >\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\\texttt{\ 
> >> >2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ a\ 
> >> comment}\texttt{\ 
> >> >3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\\texttt{\ 
> >> >4.}~~\textbf{repeat}~until~convergence\\\texttt{\ 
> >> 
> >5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\ 
>
> >> 
> >> >6.}~~~~~~~~$\sigma \leftarrow 0$\\\texttt{\ 
> >> 
> >7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\ 
>
> >> 
> >> >8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\\texttt{\ 
> >> >9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} 
> >> 
> >\phi_j$\\\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\\texttt{12.}~~~~~~~~$\phi_i 
>
> >> 
> >> >\leftarrow \frac 1 {a_{ii}} (b_i - 
> >> 
> >\sigma)$\\\texttt{13.}~~~~\textbf{end}~($i$-loop)\\\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat) 
>
> >> 
> >> > 
> >> >It's serviceable, but really hard to play with for a human. The HTML 
> >> writer 
> >> >doesn't far much better. I realize that line-block are a special case 
> >> where 
> >> >the usage of LineBreak can easily get out of control. 
> >> > 
> >> >I wonder if it's better to add a newline after each LineBreak inline 
> >> >element. I'm really just targeting line-blocks, but as they don't have 
> >> >their own block-level type the only alternative is to change LineBreak 
> >> >behavior. The above example would then look like this: 
> >> > 
> >> >\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\ 
> >> >\texttt{\ 2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ 
> is\ 
> >> a\ 
> >> >comment} 
> >> >\texttt{\ 3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\ 
> >> >\texttt{\ 4.}~~\textbf{repeat}~until~convergence\\ 
> >> >\texttt{\ 
> >> 
> >5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\ 
> >> >\texttt{\ 6.}~~~~~~~~$\sigma \leftarrow 0$\\ 
> >> >\texttt{\ 
> >> 
> >7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\ 
>
> >> 
> >> >\texttt{\ 8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\ 
> >> >\texttt{\ 9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} 
> \phi_j$\\ 
> >> >\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\ 
> >> >\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\ 
> >> >\texttt{12.}~~~~~~~~$\phi_i \leftarrow \frac 1 {a_{ii}} (b_i - 
> \sigma)$\\ 
> >> >\texttt{13.}~~~~\textbf{end}~($i$-loop)\\ 
> >> 
> >\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat) 
>
> >> 
> >> > 
> >> >I can't really think of any negative ramification off the top of my 
> head. 
> >> >I'd appreciate any help thinking about whether this would break 
> anything. 
> >> > 
> >> >-- 
> >> >You received this message because you are subscribed to the Google 
> Groups 
> >> "pandoc-discuss" group. 
> >> >To unsubscribe from this group and stop receiving emails from it, send 
> an 
> >> email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. 
> >> >To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org 
> >> <javascript:>. 
> >> >To view this discussion on the web visit 
> >> 
> https://groups.google.com/d/msgid/pandoc-discuss/b25e52ed-107c-4f32-a128-b9b68c149ce4%40googlegroups.com. 
>
> >> 
> >> >For more options, visit https://groups.google.com/d/optout. 
> >> 
> >> 
> > 
> >-- 
> >You received this message because you are subscribed to the Google Groups 
> "pandoc-discuss" group. 
> >To unsubscribe from this group and stop receiving emails from it, send an 
> email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. 
> >To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org 
> <javascript:>. 
> >To view this discussion on the web visit 
> https://groups.google.com/d/msgid/pandoc-discuss/eef791a5-f76f-4e98-a2bc-0e63c79bc7db%40googlegroups.com. 
>
> >For more options, visit https://groups.google.com/d/optout. 
>
>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/b115520b-6af7-4fae-b95d-50a759c2ef5d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 9016 bytes --]

Re: Add a newline after a LineBreak to writers?

[Ophir Lifshitz]

[-- Attachment #1.1: Type: text/plain, Size: 6190 bytes --]

Just wondering, was this the only discussion prior to 
https://github.com/jgm/pandoc/pull/1925 landing?

Thanks.

On Thursday, February 5, 2015 at 12:08:40 AM UTC-5, Tim Lin wrote:
>
> all right, will get something going tonight
>
> On Wednesday, 4 February 2015 19:52:52 UTC-8, John MacFarlane wrote:
>>
>> OK, let's just make it insensitive to `--no-wrap`, with a line break 
>> either way. 
>>
>> +++ Tim Lin [Feb 04 15 17:42 ]: 
>> >The no wrap thing sounds sensible, although I really have no idea 
>> whether 
>> >more people expect the whole block to be unwrapped or just the 
>> individual 
>> >lines. 
>> > 
>> >Personally I would expect `--no-wrap` output to be useful for editing 
>> >without needing text reflowing functionality. With that assumption, 
>> >unwrapping individual lines but breaking at the LineBreaks seems to me 
>> to 
>> >be the most friendly behavior for editing. 
>> > 
>> > 
>> >On Wednesday, 4 February 2015 09:57:18 UTC-8, John MacFarlane wrote: 
>> >> 
>> >> I think this is a good idea.  (But maybe we should make it sensitive 
>> to 
>> >> `--no-wrap`, and omit the newline if `--no-wrap`?) 
>> >> 
>> >> +++ Tim Lin [Feb 03 15 17:46 ]: 
>> >> >I'm using the line-block construct extensively fro writing 
>> pseudocode. It 
>> >> >usually works great, but boy does the rendered output look ugly. 
>> Here's 
>> >> an 
>> >> >example of what one of my typical algorithms can end up looking in 
>> LaTeX: 
>> >> > 
>> >> >\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\\texttt{\ 
>> >> >2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ is\ a\ 
>> >> comment}\texttt{\ 
>> >> >3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\\texttt{\ 
>> >> >4.}~~\textbf{repeat}~until~convergence\\\texttt{\ 
>> >> 
>> >5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\ 
>>
>> >> 
>> >> >6.}~~~~~~~~$\sigma \leftarrow 0$\\\texttt{\ 
>> >> 
>> >7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\\texttt{\ 
>>
>> >> 
>> >> >8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\\texttt{\ 
>> >> >9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} 
>> >> 
>> >\phi_j$\\\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\\texttt{12.}~~~~~~~~$\phi_i 
>>
>> >> 
>> >> >\leftarrow \frac 1 {a_{ii}} (b_i - 
>> >> 
>> >\sigma)$\\\texttt{13.}~~~~\textbf{end}~($i$-loop)\\\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat) 
>>
>> >> 
>> >> > 
>> >> >It's serviceable, but really hard to play with for a human. The HTML 
>> >> writer 
>> >> >doesn't far much better. I realize that line-block are a special case 
>> >> where 
>> >> >the usage of LineBreak can easily get out of control. 
>> >> > 
>> >> >I wonder if it's better to add a newline after each LineBreak inline 
>> >> >element. I'm really just targeting line-blocks, but as they don't 
>> have 
>> >> >their own block-level type the only alternative is to change 
>> LineBreak 
>> >> >behavior. The above example would then look like this: 
>> >> > 
>> >> >\texttt{\ 1.}~\textbf{Inputs}:~variables~$A, b$\\ 
>> >> >\texttt{\ 2.}~\textbf{Output}:~$\phi$~~~~~~~~~~~~~~~~\texttt{//this\ 
>> is\ 
>> >> a\ 
>> >> >comment} 
>> >> >\texttt{\ 3.}~Choose~an~initial~guess~$\phi$~to~the~solution\\ 
>> >> >\texttt{\ 4.}~~\textbf{repeat}~until~convergence\\ 
>> >> >\texttt{\ 
>> >> 
>> >5.}~~~~\textbf{for}~$i$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\ 
>> >> >\texttt{\ 6.}~~~~~~~~$\sigma \leftarrow 0$\\ 
>> >> >\texttt{\ 
>> >> 
>> >7.}~~~~~~~~\textbf{for}~$j$~\textbf{from}~1~\textbf{until}~$n$~\textbf{do}\\ 
>>
>> >> 
>> >> >\texttt{\ 8.}~~~~~~~~~~~~\textbf{if}~$j \ne i$~\textbf{then}\\ 
>> >> >\texttt{\ 9.}~~~~~~~~~~~~~~~$\sigma \leftarrow \sigma + a_{ij} 
>> \phi_j$\\ 
>> >> >\texttt{10.}~~~~~~~~~~~~\textbf{end~if}\\ 
>> >> >\texttt{11.}~~~~~~~~\textbf{end}~($j$-loop)\\ 
>> >> >\texttt{12.}~~~~~~~~$\phi_i \leftarrow \frac 1 {a_{ii}} (b_i - 
>> \sigma)$\\ 
>> >> >\texttt{13.}~~~~\textbf{end}~($i$-loop)\\ 
>> >> 
>> >\texttt{14.}~~~~check~if~convergence~is~reached\\\texttt{15.}~\textbf{end}~(repeat) 
>>
>> >> 
>> >> > 
>> >> >I can't really think of any negative ramification off the top of my 
>> head. 
>> >> >I'd appreciate any help thinking about whether this would break 
>> anything. 
>> >> > 
>> >> >-- 
>> >> >You received this message because you are subscribed to the Google 
>> Groups 
>> >> "pandoc-discuss" group. 
>> >> >To unsubscribe from this group and stop receiving emails from it, 
>> send an 
>> >> email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org <javascript:>. 
>> >> >To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFFw@public.gmane.org 
>> >> <javascript:>. 
>> >> >To view this discussion on the web visit 
>> >> 
>> https://groups.google.com/d/msgid/pandoc-discuss/b25e52ed-107c-4f32-a128-b9b68c149ce4%40googlegroups.com. 
>>
>> >> 
>> >> >For more options, visit https://groups.google.com/d/optout. 
>> >> 
>> >> 
>> > 
>> >-- 
>> >You received this message because you are subscribed to the Google 
>> Groups "pandoc-discuss" group. 
>> >To unsubscribe from this group and stop receiving emails from it, send 
>> an email to pandoc-discus...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org 
>> >To post to this group, send email to pandoc-...-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org 
>> >To view this discussion on the web visit 
>> https://groups.google.com/d/msgid/pandoc-discuss/eef791a5-f76f-4e98-a2bc-0e63c79bc7db%40googlegroups.com. 
>>
>> >For more options, visit https://groups.google.com/d/optout. 
>>
>>

-- 
You received this message because you are subscribed to the Google Groups "pandoc-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email to pandoc-discuss+unsubscribe-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To post to this group, send email to pandoc-discuss-/JYPxA39Uh5TLH3MbocFF+G/Ez6ZCGd0@public.gmane.org
To view this discussion on the web visit https://groups.google.com/d/msgid/pandoc-discuss/5919c781-f48e-4453-8c99-e2456c43b877%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[-- Attachment #1.2: Type: text/html, Size: 9025 bytes --]

Re: Add a newline after a LineBreak to writers?

[John MacFarlane]

+++ Ophir Lifshitz [Jun 18 15 10:31 ]:
>   Just wondering, was this the only discussion prior to
>   https://github.com/jgm/pandoc/pull/1925 landing?
>   Thanks.

Yes.  I didn't really see a downside to the proposed change,
and nobody else objected to it.