RE: next emacs version?

["Drew Adams" <drew.adams@oracle.com>]

> >>> That would involve my code with the bug-fix code (logic).
> >>
> >> Not at all.  It simply amounts to writing the unit-test that checks
> >> whether the bug is fixed: (string-match <regexp> 
> >> <problematic-dired-line>) It's simple and robust.
> 
> > That's precisely what I mean by involving my code with the bug-fix
> > code: adding a unit-test for an unrelated bug fix in the middle of
> > font-lock keywords. Extra code-coupling.
> 
> > *Why* the regexp is the way it is (better support for file 
> > names that include ISO dates, or whatever) is unimportant for
> > the font-lock code logic. That code should not care how the
> > regexp does its job of matching a date and file-name or which
> > formats are currently supported. All that the font-lock code
> > cares about is picking up the correct regexp group for the
> > date+time info.
> 
> Now that you say what you want, I can even agree that there's a better
> solution which is to just check what you want:
> 
>    (list dired-move-to-filename-regexp
>          (let ((test "<some random dired line>"))
>            (when (string-match dired-move-to-filename-regexp test)
>              (list
>               (cond
>                ((equal (match-string 2 test) "<the line's date>") 2)
>                ((equal (match-string 1 test) "<the line's date>") 1))
>               'diredp-date-time t t)))
>            (list 1 'diredp-date-time t t))
>          (list "\\(.+\\)$" nil nil   ; File w/o suffix
>                (list 0 diredp-file-name 'keep t)))
> 
> You could even loop through all submatches to find the one 
> which matches the date.

Yes, that code gets closer to expressing the real requirement. It gets away from
the bug and the bug-fix, which have no business being in this font-lock code.

My point before was that trying to manifest the bug in order to choose the
proper code path would be misguided and fragile (if it even worked in all
cases), especially since the bug is platform-dependent.