Re: [Docutils-users] literal inclusions: fileformat handling

[David G. <go...@py...>]

> On 2009-10-25, David Goodger wrote:
>   > (Note that docutils.statemachine.string2lines
>   > also converts hard tabs to spaces

On Sun, Oct 25, 2009 at 08:02, Guenter Milde <mi...@us...> wrote:
>   and strips trailing whitespace,

You're not going to argue that there's a use case for trailing
whitespace, are you?
(0.5 ;-)

>   > which was discussed recently in the "release 0.6" thread. I'm not
>   > convinced that keeping hard tabs is anything but a kludge. Keeping hard
>   > tabs as in r6135 may be a mistake.)
>
>   We had this discussion already.

I know. I mentioned so ("which was discussed recently" above).

>   I repeat that there is a use case for keeping hard tabs in literal
>   inclusions:

The use case seems to me to be flimsy at best -- it is grasping for
some/any possible use of hard tabs. Keeping the hard tabs feels wrong
to me somehow. For example, what happens to the hard tabs when the
Writer (output format) cannot handle them properly? But since it
requires an explicit action (:tab-width: < 0), (ab)users of this
(mis)feature would only have themselves to blame for any consequences.

>> I don't think any conversion is necessary. Either handle with
>> universal-newlines text mode (as in (a) above) or process the same way
>> as the main document. I think the latter may be the better solution.
>
> My preference is a)
> because it uses the standard Python way to normalize line endings (fast
> and clean).
>
> I can also live with b)
> (patch is ready)
>
> or c),

+0 on (a).

> if we agree to let ``tab_width < 0`` signify "keep-tabs"

-0. I don't care enough to argue further.

> and maybe also
> "keep trailing (non line-ending) whitespace" in
> docutils.statemachine.string2lines().

... so no use case yet, but you are going to argue in that direction.

-1. No way. That's hypergeneralization, and is just wrong.

-- 
David Goodger <http://python.net/~goodger>