On 26/01/15 18:04, Assaf Gordon wrote: > Hello Pádraig, > > On Jan 25, 2015, at 6:13, Pádraig Brady <[email protected]> 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
