Code clean-up

I've looked over that and it seems okay (I didn't know about the below convention, but I figure it's correct).

-        db_insert('actions')
-          ->fields(array(
+        db_insert('actions')->fields(array(

Patch passes too.

Needs retesting due to #335122: Test clean HEAD after every commit.

Cool. I've committed this. Nice clean-up! Setting back to active now for the next file.

I asked sun to remove the DBTNG hunks because we kind of have a standard (mostly from Crell asking me "what do you think about x vs. y" periodically over the course of the past 3 months) that these changes would break. I agree this standard could likely be improved, and it must certainly be documented. Let's follow-up on the coding standards group on g.d.o and hash this out, then make a series of code clean-up patches that make all DBTNG conform to this standard, whatever it ends up being.

This is good stuff and makes batch.inc fairly legible, which is awesome considering I don't know anyone but yched who knows this stuff very well currently. :)

 If the user did not visit any JavaScript-enabled page during her
+ * browser session so far, she gets the non-JavaScript version.

We should avoid the use of gendered pronouns (male or female). See #75594: Removal of gender-specific pronouns from core. Perhaps something like, "If no JavaScript-enabled page has been visited during the current user's browser session, the non-JavaScript version is returned."

+    // If the current batch set is completed, browse through the remaining sets,
+    // executing 'control sets' (stored form submit handlers) along the way,
+    // which in turn might insert new batch sets - until we find a set that
+    // contains operations.

That is a very very very VERY long sentence. :) Can you chuck a period in there somewhere?

+ * Shutdown function; store the current batch data for the next request in the database.

That is 88 chars. Needs to be shortened up (sun suggested dropping "in the database" which sounds fine to me).

Thks sun. I *really* tried to make things as clear as I could, but batch.inc *is* complex indeed, and maybe my english came short too.

+ * This sets the page title, and initializes the batch and error messages.
-  // The first batch set gets to set the page title and the initialization and

Some info is lost here. The point is that a batched processing may contain several independent 'sets of operations' (if several calls to batch_set() have been made, e.g in diferent submit handlers for a form, or if a batched op itself does a batch_set() - rare, but might happen). Those 'sets' are processed sequentially.
In JS mode, the batch process page is displayed only once and updated through AHAH requests, so only the first set gets to define the page title. Titles specified by the subsequent set are not displayed.

+ * Only safe strings should be passed to batch_set().

Maybe we need to remove that now that #242873: make drupal_set_title() use check_plain() by default. got in ?

- * Advance batch processing for 1 second (or process the whole batch if it
- * was not set for progressive execution - e.g forms submitted by drupal_execute).
+ * Process next phase in a batch.
+ *
+ * If the batch was marked for progressive execution (default) and exceeded an
+ * execution time of 1 second, it will continue with the next operation of the
+ * same batch phase.

Incorrect. Progressive mode is : execute as many ops as you can until you exceeded 1 second processing time, then break and report.progress.
I'm not sure the 'batch phase' terminology is a good thing.

-      // Remove the operation and clear the sandbox.
+      // Remove the current operations and clear the sandbox.

The singular should be kept - only 1 operation is removed.

- * Move execution to the next batch set if any, executing the stored
- * form _submit handlers along the way (thus possibly inserting
- * additional batch sets).
+ * Retrieve next set in batch.
+ *
+ * This walks through all defined sets in a batch, starting from the current
+ * set, and executes any form_submit callbacks in subsequent sets, which may
+ * add further sets to the batch.

New version is less accurate. We don't walk through *all* sets, we walk through sets until we find one with real operations.
"executes any form_submit callbacks in subsequent sets" is ambiguous; I understand : "it executes them in subsequent sets", which has no meaning.
"Submit handler" vs "submit callback" : unless I'm mistaken, FAPI uses the term "submit handler".

That's a different task, but the file registry should now let us get rid of the $batch['file'] thing.

Very nice. :) Committed batch.inc code clean-up to HEAD.

(bolding so it's easier to pick out in a quick scan.)

Marking back to active. :)

subscribing.