[buildd-tools-devel] Bug#765886: Bug#765886: Bug#765886: Bug#765886: sbuild: [PATCH] Replaced all unicode-printed chars with plain ASCII

[Lennart Sorensen]

On Mon, Oct 05, 2015 at 07:27:20PM +0200, Johannes Schauer wrote:
> unfortunately this is not a very hard argument as "readability" is quite a
> subjective measure. What do you think would let us get a more quantifiable
> argument in this direction?

I have no idea if anything could make that quantifiable.

> Auto-detecting whether the system supports unicode or not and then using the
> according variant would not help here. sbuild is probably only run on Debian or
> derivatives which handle unicode characters just fine for a long time, so the
> result would probably be that the characters would always be used in the build
> logs. But this would defeat the main purpose to *not* use unicode characters.
> See the next paragraph.

Yes runtime detection is the wrong time to detect it.  Predicting the
future for where it will be viewed would be an impressive feat.

> Then please explain the use case to me.
> 
> I don't have a degree in art but this:
> 
> ┌──────────────────────────────────────────────────────────────────────────────┐
> │ Update chroot                                                                │
> └──────────────────────────────────────────────────────────────────────────────┘
> 
> looks close enough to my eyes to this:
> 
> +------------------------------------------------------------------------------+
> | Update chroot                                                                |
> +------------------------------------------------------------------------------+
> 
> That I don't see the argument. Are we really talking about a solid line looking
> better than a dashed line here?

Nothing else in a build log ever looks like the sbuild boxes.  They stand
out nicely as a result.  I can't say that standing out really is ever
particularly necessary as a use case though.

> On the other hand, there are actual arguments against it:
> 
>  - using unicode characters is not strictly required here (as it would be for a
>    program handling international script)

It certainly isn't required.

>  - the sbuild log might be used outside of Debian in a world where not yet
>    everybody can process non-ASCII characters (this is the reason why we don't
>    want to autodetect whether the system running sbuild can do unicode)

Certainly detecting the environment does NOT tell you about the
environment that will be viewing the log.

Now gcc certainly does change the output of error messages and such to
use fancy quotes and the like when it detects unicode support in the
environment it us running under.  Is that causing issues too then?

>  - if one wants to search for the headers (with command line tools or in
>    editors) then (at least with my keyboard) it is easier to search for
>    "-------" than to type "──────────"

True, although searching for the pretty box would almost certainly only
match the output of sbuild.

>  - it is not the place of a program that just builds packages in a chroot to
>    enforce unicode support on all the tools and users that handle its logs

That is a fair argument.

> Agreed, if it was just because I don't like unicode then that would be no
> reason to throw it away. But you might've missed the actual arguments *against*
> using unicode characters in bug #665847. For your convenience I have listed
> them again above.

It would seem the only way to keep pretty boxes and make things usable in
all cases would be an explicit sbuild config to choose one or the other,
which complicates the code, so that is probably not worthwhile.

I guess it is bye bye for the pretty boxes.

-- 
Len Sorensen