* On Friday 2005-11-18 at 14:05:26 +0000, Julian Foad wrote: > * Maybe have a look at my patch (attached) and combine the best of your and > my changes. (Sorry, I should have sent this earlier rather than trying to > "finish" it first.)
Merged. Much of the GREP_COLORS stuff was rewritten in the meanwhile, though; it was getting too big and inscrutable for an unstructured paragraph. Note that "Erase in Line to Right" is not EL, only "Erase in Line" is and "to Right" is just one of its specializations. "bce" and "back_color_erase" (both lowercase) are the case-sensitive names of a terminfo capability; try "infocmp -1a" and "infocmp -L1a" to see if your terminal defines it. > (I'm tempted also to suggest an alternative: "Just commit it all and then > we'll move ahead from there." But that would be defeatist.) I have chosen to work on the actual documentation first, and to get it out early for review, rather than working on a ChangeLog entry right away. That doesn't mean there won't be one. It's forthcoming, but please have a look at the generally reworked structure of both man and info documentation in the meantime, just in case you'd prefer to have some of the general changes reverted anyways. Since this is a big rework with lots of text blocks moving around anyway, it's a rare occasion to make some source-code formatting changes. Except in the big dropped-in license sections, I have made sure that every sentence ends a source-code line. This way, when smaller changes are made in the future, whole paragraphs are not reformatted for a single sentence modification and the extent of changed lines in the diff output will be limited to that sentence. This is traditional practice with *roff input, and a good practice for TeX input as well. > First thing I noticed: in the manual (grep.1), > I see you added back-ticks I replaced them all. > change the mentions of "octet" (which were added recently) > to "byte" for consistency; I reverted them all. Had I had the choice, I would have put the correct "octet" everywhere, but it's impossible given that "byte" already occurs in a long option name. Even on hardware with a 1-bit byte (such as TI's TMS processors), the C compiler is likely to define an 8-bit char, and the Unix file-content API to really be defined in terms of octets, even if pointed to by void (not char) pointers; one would only notice when casting pointers to unsigned int that they have three more least-significant bits than usual, but seldom does clean code have a legitimate reason to manipulate that directly.
