If the inline styling was correct, but rendered wrongly, I expect that it isn't the inline styling but a hierarchially higher level style command. BTW, in line styling should take precedene.

Extra return characters (or their lack) shouldn't matter unless it is enclosed in <PRE> tags.

I wouldn't try any kind of over the counter medicines just for this. Depends on when you went to sleep. Three o clock may not be late night but very early morning. If you had a full quota of sleep, then you should wake up refreshed. In such a case, this might be the best time to code. Is it happening all the time? Try to recall any specific conditions when you went to sleep. Might give a clue.

All the best.

It is an interesting question. It has been a while since I've thought about it, but my view is this:

1) Exceptional conditions are not the same thing as error handling (ie, categorizing errors is not the correct way to categorize exceptions). An exceptional condition is any state that is atypical at a particular point in the code.

There are some classes of errors that can be handled more elegantly at the place where they are detected. For example, zero value errors can sometimes be handled by simply returning, because even if the zero value is unexpected, this (non)behaviour is consistent with how the function would work had the zero value been normal.

Likewise, there are rare circumstances where an exception mechanism is a more elegant way of handling a normal but infrequent condition. For example, the end of file might be done through an exception.

I use exceptions where they would be more elegant than other forms of control flow. This happens when the exception condition relates to a function that is not the one which detects the condition, and there is no sensible action that can be taken locally.

2) I would distinguish only two types of exceptional state; expected ones and unexpected ones. Expected ones roughly correspond to your first two types of errors (input errors and external circumstances). Unexpected ones roughly correspond to your second two (programmer errors and hardware errors).

Handling expected exceptional states (whether with a language exception feature or in some other way) is not a problem; just pick the most elegant way of handling them, since one knows the behaviour that is required.

Handling unexpected exceptional states is trickier. By definition if the state is unexpected, it is not clear what the behaviour should be, however it is handled.

Some code just throws an exception anyway, in the hope that the parent functions somewhere will know what to do! But this can be disastrous; an example is the Ariane 5 failure, where the reuse of old Ariane 4 code in a new physical context tripped an unhandled exception, causing the (redundant) computer systems to all crash.

My feeling is that unexpected states should generate debug output, so that at least such issues can be examined during testing. But it is not always clear what should happen in a non-test situation. It may be that a fail-safe mode is required (as in an ABS system in a car), or it may be that the code should just continue (as in a word processor where you don't want to exit and lose the document just because the spelling checker had a problem).

It is also not clear where the unexpected state should be checked (eg using asserts). The easiest is to do so at the entry and exit of a function. But there may also be intermediate points where it makes sense to check for certain conditions or invariants. To do this thoroughly is not trivial, and still relies upon subsequent and comprehensive testing.

you are lucky you didn't copy word document contents LOL, it would take much more time to clean that mess

lol where do you live, CoderMan?
you mean -45 C? :0

I noticed a while ago that the term 'global warming' doesn't get used much anymore. It's all 'climate change'.

I also got referred to this recently. A UK celebrity (Real one, not manufactured!) who seems to have fallen foul of his non PC views....

I personally don't like how people use Artificial Intelligence.

Artificial Intelligence does what it's told and programmed to do. Generally designed to simulate something that seems intelligent.

However! Actual Intelligence will think for it self AND learn from its experiences. The closest thing we have to this is Neural Networks.

Now when you put Actual Intelligence into an Artificial Body designed to mimic something living would be an Android.

As for Life, its nothing more than a biological machine that's able to grow using pieces from the environment and using chemical processes, reproduce, and adapt generation-ally to its environment. I suppose you could also create a robot that does this with materials other than carbon as well as without Actual Intelligence.


Anyway, back to the AI born in RAM. If it's a freak of nature and a Ghost in the machine with a computer simply booted with power running to it, then yes that would be Actual Intelligence.

Try some melatonin. It is one of the feel good substances produced by the body. You mat be lacking enough of it. I had the problem and that's what my Dr.
suggested to me. Think of dopamine or Seratonin. Get at most vitamin stores.
If it works you can pay me back with an answer to fixing a monitor that is refreshing to fast. Just kidding guys. Just kidding.

all the time...
what are you "hacking"?

how real.
people create AI and people create these games and most of them see no connection between it.
/me remembers The Matrix and Terminator

++++++

Love it! :-)

I know what you mean. That's why I like java too. JavaFX (kind of scripting language) might be useful too.

why?
who speaks latin anymore?

Just downloaded, compiled, and installed. A couple of "issues":

1) For the requirements, need to add libgpod-devel to build the man pages.
2) I might be missing something else, because I get this error in regard
to the man pages:
zcat: /usr/share/man/man1/minmenu.1.gz: not in gzip format
zcat: /usr/share/man/man1/minmenu-edit.1.gz: not in gzip format
3) It would be real nice (for me almost critical), that if you press the ESC
key in a child-menu, it goes back to the parent menu instead of exiting
the menu all together.
4) Look-and-feel: It would be nice if you could "highlight" the selection
in stead of underline. i.e.: Screen is white text on blue background /
Selection is blue text with a white (or cyan) highlight.

Other that these - you are heading in the right direction. This is the only
program I could find for linux with this capability.