Re: seq feature: print letters

[Pádraig Brady]

On 26/01/15 18:04, Assaf Gordon wrote:
> Hello Pádraig,
> 
> On Jan 25, 2015, at 6:13, Pádraig Brady <address@hidden> wrote:
> 
>> On 25/01/15 05:10, Assaf Gordon wrote:
>>> <...>
> 
>>> I'm thinking that perhaps it would be better not to include this in 
>>> 'coreutils', and instead put it in another, separate project.
>>> This way, there's no worries about adding bloat to coreutils, while being 
>>> more flexible in adding other features (like additional character sets from 
>>> latest unicode).
>>
>> I'm not sure. I was considering this for the release of coreutils
>> after the imminent 8.24 one.  I'm thinking V9 will start linking
>> various utils to libunistring, and doing so in seq may not be much
>> of a stretch.
>>
> 
> If it's still up for inclusion in the next version, then that's great.
> 
> My thoughts were that within the 'coreutils' context, every additional 
> feature will always be evaluated as a trade-off for extra bloat.
> Where as outside 'coreutils', adding more features could be easier, and bloat 
> will be less of an issue (as in - if someone wanted these features, he/she 
> will explicitly install the program).
> 
> I was thinking of features like:
> 1. adding more unicode blocks (even exotic ones, like 'runes', 'dingbats', 
> 'braille', etc.)
> 2. adding more alphabet categories (i.g. not just the indexed letters, but 
> auxiliary letters, or upper-case/lower-case letters, or different letter 
> glyphs for languages that have them)
> 3. Adding a text generator to create dummy text with a given alphabet

That does sound like it's getting out of scope for seq