Hi,
On Sun, 7 May 2006, Junio C Hamano wrote:
> [...] Probably a reasonable convention would be to define the config
> file format to be something like this:
>
> <comment that applies to the section>
> [section]
> <comment that applies to the variable stands on
> its own before the variable>
> variable [= value] <comment that applies to the
> fact the variable is set to
> this particular value starts
> on the same line as the
> "variable = value" thing>
>
> - when a variable is reset to another value, remove the
> "value comment";
> - when a variable disappears, remove "variable comment";
> - when a section disappears, remove "section comment";
> - otherwise leave the comment intact.
>
> Then we could tell the user the rule is like above, and tell
> them to structure the file with comments that way, if they ever
> want to edit the file by hand.
>
> Now if we wanted to do something like the above, I suspect that
> it would be easier and less error prone to first scan the config
> file, note what appears where, and do the processing in-core,
> and then write the results out, perhaps using data structures
> like these:
>
> struct config_section {
> char *pre_comment;
> char *name; /* e.g. "core" */
> struct config_section *next; /* next section */
> struct config_var *vars; /* pointer to the first one */
> };
> struct config_var {
> char *pre_comment;
> char *name;
> char *value; /* "existence" bool may have NULL,
> * otherwise probably a string "= value"
> */
> char *value_comment;
> struct config_var *next; /* pointer to the next one
> * in the section
> */
> };
>
> Obviously, data structures like these would make it even easier
> if we decide we do _not_ care about comments (we would just lose
> x_comment fields, parse the thing and write the resulting list
> out).
Sounds very reasonable.
Ciao,
Dscho
-
: send the line "unsubscribe git" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html