Bug 179547

Comment 1 Kyu Lee 2007-03-27 11:32:15 EDT

Created attachment 62110 [details]
screen shot

Comment 2 Andrew Overholt 2008-09-30 14:17:44 EDT

Tentatively setting 1.0 target.

Comment 3 Andrew Overholt 2009-01-13 13:59:58 EST

Unsetting milestone.  Perhaps target in 0.2.  Please assign to yourself if you pick this up.

Comment 4 Charley Wang 2009-12-22 16:23:38 EST

Created attachment 154946 [details]
Use SingleLineRule to sort out file names

Proposed patch. Used SingleLineRule with delimiters of "\t*" and ":" instead of GnuFileEntryRule. Nothing appears to break in some testing, and should cause no colour oddities for most people.

Comment 5 Phil Muldoon 2010-01-05 02:41:04 EST

The patch looks fine to me.

Comment 6 Jeff Johnston 2010-01-05 11:10:57 EST

(In reply to comment #4)
> Created an attachment (id=154946) [details]
> Use SingleLineRule to sort out file names
> 
> Proposed patch. Used SingleLineRule with delimiters of "\t*" and ":" instead of
> GnuFileEntryRule. Nothing appears to break in some testing, and should cause no
> colour oddities for most people.

Unfortunately, this breaks another feature.  The GnuFileEntryRule supports multiple files specified over multiple lines using comma separators.  It would be better to modify the rule to fix this problem.

Comment 7 Charley Wang 2010-01-13 11:10:03 EST

Created attachment 155997 [details]
Patch for colourization

Modify the GNU file entry rule to return fileToken only if:
1) the line is a valid file entry/is part of a valid multi-line file entry
2) the line terminates with a ',' or ':'

I will attach a screenshot to demonstrate the test cases I've run.

Comment 8 Charley Wang 2010-01-13 11:12:27 EST

Created attachment 155998 [details]
Test cases for the proposed colourization patch

Test cases for the modified GNUFileEntryRule

Comment 9 Jeff Johnston 2010-01-19 12:02:28 EST

(In reply to comment #7)
> Created an attachment (id=155997) [details]
> Patch for colourization
> 
> Modify the GNU file entry rule to return fileToken only if:
> 1) the line is a valid file entry/is part of a valid multi-line file entry
> 2) the line terminates with a ',' or ':'
> 
> I will attach a screenshot to demonstrate the test cases I've run.

This fix has problems.  An entry sometimes has a function or method specifier which occurs after the file name and starts with an open parentheses, then some characters, a closed parentheses, then the colon.  For example,

   * a.c (myfunc): Fix typo

Your change sees the whitespace after the file name and doesn't match a.c as a file name.

The given entry is in error with respect to GNU Changelog format.  According to the GNU Coding Standards:

"An entry should have an asterisk, the name of the changed file, and then in parentheses the name of the changed functions, variables or whatever, followed by a colon. Then describe the changes you made to that function or variable."

We extend that by allowing multiple files to be specified with comma separators and allowing this across multiple lines.

A straight comment like the one in the bug example should not start with an asterisk.  It should just be a line.  For example,

2009-12-12  Jeff Johnston  <jjohnstn@redhat.com>

    Rewriting to use IEEE parsing.

    * parser.c: Removed.
    * ieeeparser.c: New file.

To get the error example to act as expected, you need to verify that either a colon or comma is next (what you already have) OR you have to create an intermediate state whereby you keep reading to verify there is white-space followed by the open parenthesis (e.g. like how the "started" variable is used).

If this proves too difficult, it would not be unreasonable to say that the formatter will treat characters after the asterisk as a file name and close this bug as INVALID.

Comment 10 Jeff Johnston 2010-05-07 19:11:02 EDT

Closing as invalid.