Regarding AsciiDoctor and long lines

[Sergio Carlavilla]

On Fri, 12 Feb 2021 at 18:16, Sergio Carlavilla <carlavilla at freebsd.org>
wrote:

> On Fri, 12 Feb 2021 at 18:09, Daniel Ebdrup Jensen <debdrup at freebsd.org>
> wrote:
>
>> On Fri, Feb 12, 2021 at 03:09:35PM +0100, Sergio Carlavilla wrote:
>> >On Fri, 12 Feb 2021 at 13:45, Marc Fonvieille <blackend at freebsd.org>
>> wrote:
>> >
>> >> Le 10.02.2021 17:03, Daniel Ebdrup Jensen a écrit :
>> >> > Yeah, I'm perfectly fine with doing it like how manual pages work,
>> ie.
>> >> > the one-sentence-per-line workflow, if I understand it.
>> >> >
>> >>
>> >> One sentence per line makes the read of diff/commit logs really
>> >> difficult.  I gave up reading the commit logs because of that.
>> >> It's really a pain to find what changed without even talking about the
>> >> edition of a long non-wrapped line in an editor.
>> >> Some languages are very verbose, so we would end with very long lines.
>> >> For a such change seems so backward.
>> >>
>> >> > I'll be re-working the handbook/x11 chapter to that at some point. :)
>> >> >
>> >>
>> >> Please don't.
>> >>
>> >> --
>> >> Marc
>> >>
>> >Hi,
>> >
>> >I know that this approach it’s causing some confusion with the diffs
>> tools.
>> >But instead of using a different way that recommended from the
>> AsciiDoctor
>> >team I think we should try to focus on getting a solution in the diff
>> tools.
>> >
>> >Maybe we can talk with the AsciiDoctor team.
>> >
>> >Bye.
>>
>> Hi folks,
>>
>> Marc does have a point, which I think is quite valid. A lot of people do
>> reviews of code in the email they're sent, where - at least for the
>> commits, it's inlined - and pursuant to discussions about this
>> elsewhere, that doesn't seem likely to be changing any time soon.
>>
>> If diffs were attachments with the text/x-patch or text/x-diff
>> mime-type, it'd be up to peoples MUA and possibly their .mailcap as to
>> how it should be opened, but that's not something that's doable with the
>> current setup.
>>
>> So I do think wrapping to 72 columns is the better option here, if we
>> want to retain the broadest review possibilities.
>>
>> Yours,
>> Daniel Ebdrup Jensen
>>
> Hi,
>
> Ok, if we use this approach.
>
> What are we gonna do with:
>
> Headings
> Unordered list
> Ordered list
> Images
> Include macro
> AsciiDoc variables
> Custom macros
>
> And I need to test classes and links.
>
> Bye.
>
> Hi,

I think the doceng team should pronounce about this.

IMHO, use the 72 characters per line would be a problem in the future.

Bye.