On 13 Feb 2015 12:25, Karel Zak wrote: > On Fri, Feb 13, 2015 at 10:33:23AM +0000, Sami Kerola wrote: > > On 13 February 2015 at 09:21, Karel Zak <kzak@xxxxxxxxxx> wrote: > > > On Thu, Feb 12, 2015 at 10:21:48PM -0500, Dale R. Worley wrote: > > >> I don't particularly like colorization. But technically, it seems to me > > >> that what is needed is a systematic way for the user to indicate his > > >> colorization preferences to *all* utilities. And a corresponding way > > >> for the system to provide defaults for those user preferences. > > >> > > >> > > >> Only when there is a systematic framework for colorization will all the > > >> programs allow colorizing to be configured. > > > > > > It would be possible to create a shared library from our lib/colors.c > > > to support terminal-colors.d/... :-) > > > > Or add the needed to ncurses. Isn't that better than adding a new > > library? > > you want to link programs like dmesg, gcc or ls with ncurses monster? > > The another story is that ncurses provides completely abstract layer > for colors and I didn't found a way how to use it together with color > escape sequences. This is reason why for example cfdisk supports only > enable/disable terminal-colors.d feature, but no schemes to specify > colors. this is why ncurses has the ability to split its lib into a smaller libtinfo. you get all the logic for detecting terminal capabilities without all the rest of the ncurses layers. for people who do want to kill colors across the board, they can use a different TERM that does not support them. forcing people to duplicate that in a new database seems wrong to me. -mike
Attachment:
signature.asc
Description: Digital signature
