Eli> The code doesn't use any regular expressions, it uses exact text Eli> comparison (strcmp and the like).
It must take account of the context in some way: section names can appear elsewhere in the dir file. I am not saying that this problem is unsolvable in theory. I am saying that it is so error prone that bugs will always be present, and the annoyance factor of the bugs is very high if there's no global regeneration. Eli> In a nutshell, the program reads the entire DIR file into memory, Eli> builds the data structure that reflects what's in the menu Eli> (i.e. all the sections and the menu items found in each section), Eli> then sorts each section alphabetically and adds the new entries in Eli> the right place in each section specified in the Info file or the Eli> command line. Then it produces a new DIR file from the data Eli> structure built in memory. Well, this is both better and worse than I thought. Better, because no slicing, but worse, because parsing the whole file amplifies the parsing problem. Eli> FWIW, I don't see any show-stoppers for now, nothing that a bunch Eli> of options cannot resolve. If we have options that leave everybody Eli> happy, we should be able to merge, don't you think? I'd be happy with an option that regenerates the dirfile from the info files. Would the GNU side accept such an option? -- A true pessimist won't be discouraged by a little success. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
