how does the binding and digesting work in AngularJS?

One thing that sets apart AngularJS from other JavaScript-MVC frameworks is it's ability to echo bound values from JavaScript into HTML using bindings. Angular does this "automatically" when you assign any value to the $scope variable.

But how automatic is this? Sometimes, Angular won't pick up on the change so I need to call $scope.$apply() or $scope.$digest() to inform angular to pickup the change. Sometimes when I run either of those methods then it throws an error and says that a digest is already in progress.

Since the bindings (anything inside {{ }} braces or ng-attributes) are echoed with eval then does this mean that Angular is constantly polling the $scope object to look for changes and then performing an eval to push those changes to the DOM/HTML? Or has AngularJS somehow figured out the use magic variables which fire events which are triggered when a variable value changes or is assigned? I've never heard of it being fully supported by all browsers, so I doubt it.

How does AngularJS keep track of it's bindings and scope variables?

In addition to the documentation section found by Mark I think we can try to enumerate all possible sources of change.

1. User interaction with HTML inputs ('text', 'number', 'url', 'email', 'radio', 'checkbox'). AngularJS has inputDirective. 'text', 'number', 'url' and 'email' inputs bind listener handler for 'input' or 'keydown' events. Listener handler calls scope.$apply. 'radio' and 'checkbox' bind similar handler for click event.
2. User interaction with select element. AngularJS has selectDirective with similar behavior on 'change' event.
3. Periodical changes using $timeout service that also do $rootScope.$apply().
4. eventDirectives (ngClick, etc) also use scope.$apply.
5. $http also uses $rootScope.$apply().
6. Changes outside AngularJS world should use scope.$apply as you know.

As you found out it's not polling, but using it's internal execution loop so that's why you need to use $apply() or $digest() to kick things into motion.

Miško's explanation is quite thorough, but the bit missing is that Angular is just trying to make $scope get back to a clear internal state whenever anything happens within its own context. This might take quite some bouncing around between model states, so that's also why you can't rely on $watch() firing only once and also why you should be careful with manually setting up relations between models or you'll end up in endless circular refreshes.