Checking Current Colors

Is there currently any way to read what color is currently selected? I.e. You set the background color to yellow, and text color to blue, and you are writing a function to write text with certain colors then switch it back? How would you know the original color settings? term.setBackgroundColor(color) and term.setTextColor(color) keep the same color until you change it. Maybe you could add something like term.readBackgroundColor() and term.readTextColor().

What do you think? Sorry if it's a bit poorly worded.

Why not just set it to whatever you need it to be when you write?

Look, if you want text for emphasis, you're probably going to want a different color, or if you're highlighting something you want to change the background color. Let's say this is a modular function intended to be used in any program that uses colors. Right now, I'm thinking of a Firewolf page that utilizes this function, writeColor(text,textColor,backColor). The function would be like this, hypothetically:

function writeColor(text,textColor,backColor)
  local oldColorText = term.readTextColor()
  local oldColorBack = term.readBackgroundColor()
  term.setTextColor(textColor)
  term.setBackgroundColor(backColor)
  io.write(text)
  term.setTextColor(oldColorText)
  term.setBackgroundColor(oldColorBack)
end

It resets the colors for you.

The page:

term.setTextColor(colors.blue)
cWrite("Hello, and ")
writeColor("welcome ",colors.red,colors.black)
write("to the web page!")

P.S. Sorry if my FireScripting (or whatever it's called) is a bit not up to scratch.

If you don't make assumptions about text and background color elsewhere in the code, other things changing the colors do not present problems.

Hmm. I see. Perhaps when terminating programs because of the colors that stay after you quit a color program nevermind about that. I still feel it might be useful.

I don't wanna start a whole thing, but this "you should just always set before writing" mindset bugs me too, here and in other places where cc has no get methods for setable properties. It was drilled into me - by a combination of education and actual experience - that side effects of functions should be minimized, which is what the OP was clearly wanting to do when they posted this. Yes, ultimately you accomplish the same thing if you always explicitly set the state to what you need before any action, but - and maybe it's just me - code is cleaner, easier to work with, and more efficient if it does the opposite, always cleans up any changes to the state actually made during the execution of a given bit of code, rather than attempting to fix every possible change any other code might or might not have made before doing anything. So given how trivial adding get accessors for this kind of thing is, it would be highly appreciated by me, and at least SOME others, if get() methods were provided here and in all the other misc places in ComputerCraft that they are not provided.

Dan likes his one way functions, I doubt this will change any time soon (it has been requested before). Personally though, I don't see the real issue in the CC environment, considering you should just assume you're the only program running at any one time. If this was a multi program environment, then sure, but it isn't. If someone is making a multi program environment, then this is something they should deal with - and they can deal with it fine from within Lua.

it's more than just an inter-program issue, side effects are something I think about at the function level within a given program - might call a method which is not about printing, but in running it might encounter an error which causes it to print the error message to a status area in red, and then return to the calling code. without the ability in that error message printing function to restore the color after printing the error message, any code that does printing and calls any function which may generate an error must explicitly set the color again before doing any more printing. My expectations are not high that I'll get the feature regardless, it's just something that irks me, because the simple addition would facilitate good coding practices and their absence forces bad ones.

True, I guess that is one reason. I didn't think about error changing the colour. You do have to consider that if an error is called, it is usually fatal to the program anyway - and if it isn't, you've caught it so you're in control of the printing from that point on anyway.

All of this can be handled locally in your code. What you state as "bad practice" isn't actually bad practice in an environment where you are expected to be the only program running.

How to do this: (NOTE that I use term.getBackgroundColor and term.getTextColor as they fit in more)
1. Make a program called 'term' and in it type this:

textColor = colors.white
bgColor = colors.black
oldSetText = term.setTextColor
oldSetBg = term.setBackgroundColor
function setTextColor(color)
  textColor = color
  oldSetText(color)
end
function setBackgroundColor(color)
  bgColor = color
  oldSetBg(color)
end
function getTextColor()
  return textColor
end
function getBackgroundColor()
  return bgColor
end

2. Make a startup program and type this:

os.loadAPI("term")

3. ????

4. PROFIT!

term.setBackground/TextColor could return the old colour, instead of adding new functions.

immibis, on 06 January 2013 - 02:52 PM said:

term.setBackground/TextColor could return the old colour, instead of adding new functions.

That was my exact suggestion. Dan200 answered me it is not needed. (cannot find quote, forgot where it was, sorry)

Sebra, on 06 January 2013 - 11:45 PM said:

immibis, on 06 January 2013 - 02:52 PM said:

term.setBackground/TextColor could return the old colour, instead of adding new functions.

That was my exact suggestion. Dan200 answered me it is not needed. (cannot find quote, forgot where it was, sorry)

Even though it's probably no more than 4 lines of code? (save old value, return it, x2 because there are two functions)

With your "god" status you can ask him yourself ;)/>
While it possible within lua (with function interception) …

Plus may be additional 4 or 8 lines for monitors and 4 lines for printer.