RE: next emacs version?

[Drew Adams]

> >> checking (string-match directory-listing-before-filename-regexp 
> >> <wellcraftedteststring>) might work at least as well for
> >> the problem at hand.
> 
> > Ugh. It could be done, but as I said earlier:
> 
> >>> FWIW, the regexp in question,
> >>> `directory-listing-before-filename-regexp', is
> >>> among the hairiest I've come across (have a look
> >>> - quite amusing), and I don't think it's a good idea to
> >>> try to test against that value.
> 
> The test I propose above is not to test the value of
> directory-listing-before-filename-regexp but its behavior.
> Basically: figure out the bug that the change was intended to fix, and
> then use the thing that triggered the bug as the string to pass to
> string-match (presumably the match will succeed in one case 
> and fail in the other).

Double-ugh, in that case.

That would involve my code with the bug-fix code (logic). It would impose
complexity, obscurity, and possibly an additional maintenance (evolution)
burden.

My code is pretty much unrelated to the bug fix code - it just uses the regexp
for font-locking. I don't even explicitly call any function that uses the
regexp.

This is all I'm doing. This is an entry in font-lock-keywords. It fontifies (1)
the date+time and also (2) the file name (w/o suffix):

(list dired-move-to-filename-regexp  ; Hairy regexp
      (if (or (not (fboundp 'version<))
              (version< emacs-version "23.2"))
          (list 1 'diredp-date-time t t)
        (list 2 'diredp-date-time t t)) ; Date/time
      (list "\\(.+\\)$" nil nil   ; File w/o suffix
            (list 0 diredp-file-name 'keep t)))

The #5597 bug fix was this: "Use stricter matching for iso-style dates, to avoid
false matches with date-like filenames (Bug#5597)."

I might be misunderstanding what you're suggesting. Feel free to show explicitly
what you have in mind, based on the specifics of my use case.

According to bug #5597, a file name that would provoke the (unfixed) bug would
be "~/2010-02-18\ foo". How would you pass that to `string-match'? Would you
wrap that call with `condition-case' to see if an error is raised? Is that your
idea? 

Is the following what you are suggesting?

(list dired-move-to-filename-regexp  ; Hairy regexp
      (if (condition-case nil
              (string-match
               dired-move-to-filename-regexp
               "-rw-rw-rw- 1 10 2010-04-01 2010-04-01 foo"))
             (error nil))
          (list 1 'diredp-date-time t t)
        (list 2 'diredp-date-time t t)) ; Date/time
      (list "\\(.+\\)$" nil nil   ; File w/o suffix
            (list 0 diredp-file-name 'keep t)))

I'm not sure what the 2nd arg to `string-match' should be here. The 2nd arg I
used is no doubt wrong. It does _not_ fail to match in versions (that support
ISO dates in Dired) prior to the bug fix.

In fact, in `emacs -Q' on Windows at least (which uses `ls-lisp'), I cannot even
reproduce the bug (e.g. in 23.1). I can create a file named "2010-04-01 foo"; it
appears fine in Dired (including mouse-face); and RET visits it just fine.

So for the moment what I think you're suggesting sounds like a can of worms. But
I'd like to learn what you really meant.