www.digitalmars.com         C & C++   DMDScript  

digitalmars.D - Template version of ANSI color code lib useful?

reply Shriramana Sharma writes:
Hello. I prepared a utility/library to output ANSI escape codes 
for terminal text attributes with capabilities as advertised at 
https://sites.google.com/site/jamadagni/files/temp/textattr-usage.html. (AFAIK
this set of capabilities does not exist already in any existing package.)

This was first written in D and ported with much effort to C. 
This is the utility/library I refer to at 
http://forum.dlang.org/post/n6362a$1t7u$1 digitalmars.com.

Now I would prefer to keep the single C source and just write a 
thin D wrapper to call the C library because C is also callable 
from many other languages (and people can write wrappers for 
their favourite one).

However the only disadvantage (as discussed in the above thread) 
is that the C library function is not CTFE-able in D and thus I 
cannot write a D template in the wrapper to evaluate the colour 
codes at compile time.

On the other hand, I am not sure whether it is really useful to 
evaluate colour codes at compile time because it is tantamount to 
hardcoding them, and this means that any program using the 
library is not able to switch off colour output at will if stdout 
is not connected to a terminal.

If the library is only called at runtime, I am able to add a 
boolean switch to just make the library always output an empty 
string for all calls effectively switching off colour code output 
which is useful when stdout is not a terminal.

My question: do people agree that there is not much point in 
enabling CTFE of colour codes?
Oct 14
next sibling parent reply Adam D. Ruppe <destructionator gmail.com> writes:
On Saturday, 14 October 2017 at 14:35:53 UTC, Shriramana Sharma 
wrote:
 Hello. I prepared a utility/library to output ANSI escape codes 
 for terminal text attributes with capabilities as advertised at 
 https://sites.google.com/site/jamadagni/files/temp/textattr-usage.html. (AFAIK
this set of capabilities does not exist already in any existing package.)
My terminal.d works with most that stuff.
 My question: do people agree that there is not much point in 
 enabling CTFE of colour codes?
I think it is worthless - color output must be a runtime decision to handle non-terminals or even terminals that don't support color output.
Oct 14
parent Shriramana Sharma writes:
On Saturday, 14 October 2017 at 14:51:12 UTC, Adam D. Ruppe wrote:
 My terminal.d works with most that stuff.
Yes I did look into existing solutions. Mainly my desire was not to work in D alone but something available at command line and as a library for shell-scripts and other languages too.
 I think it is worthless - color output must be a runtime 
 decision to handle non-terminals or even terminals that don't 
 support color output.
Thank you for that most candid reply!
Oct 14
prev sibling parent reply Petar Kirov [ZombineDev] <petar.p.kirov gmail.com> writes:
On Saturday, 14 October 2017 at 14:35:53 UTC, Shriramana Sharma 
wrote:
 Hello. I prepared a utility/library to output ANSI escape codes 
 for terminal text attributes with capabilities as advertised at 
 https://sites.google.com/site/jamadagni/files/temp/textattr-usage.html. (AFAIK
this set of capabilities does not exist already in any existing package.)

 This was first written in D and ported with much effort to C. 
 This is the utility/library I refer to at 
 http://forum.dlang.org/post/n6362a$1t7u$1 digitalmars.com.

 Now I would prefer to keep the single C source and just write a 
 thin D wrapper to call the C library because C is also callable 
 from many other languages (and people can write wrappers for 
 their favourite one).

 However the only disadvantage (as discussed in the above 
 thread) is that the C library function is not CTFE-able in D 
 and thus I cannot write a D template in the wrapper to evaluate 
 the colour codes at compile time.

 On the other hand, I am not sure whether it is really useful to 
 evaluate colour codes at compile time because it is tantamount 
 to hardcoding them, and this means that any program using the 
 library is not able to switch off colour output at will if 
 stdout is not connected to a terminal.

 If the library is only called at runtime, I am able to add a 
 boolean switch to just make the library always output an empty 
 string for all calls effectively switching off colour code 
 output which is useful when stdout is not a terminal.

 My question: do people agree that there is not much point in 
 enabling CTFE of colour codes?
Why not simply add extern (C) wrappers for your D code? I see no point of using C, unless you want to be portable to arcane architectures. With this approach you'll have both the portability of C and the advantages of using D.
Oct 14
parent Shriramana Sharma writes:
On Saturday, 14 October 2017 at 17:17:41 UTC, Petar Kirov 
[ZombineDev] wrote:
 Why not simply add extern (C) wrappers for your D code? I see 
 no point of using C, unless you want to be portable to arcane 
 architectures.
 With this approach you'll have both the portability of C and 
 the advantages of using D.
Yes I admit this idea hadn't occurred to me earlier.
Oct 14