From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: "Drew Adams" Newsgroups: gmane.emacs.devel Subject: RE: next emacs version? Date: Sat, 20 Mar 2010 13:29:03 -0700 Message-ID: <85D696D9907C42A389AA65E4BC83CDD7@us.oracle.com> References: <56D10E2523764AC98D99CEBC55DBAD93@us.oracle.com><83iq8sigyq.fsf@gnu.org><83d3z0i3nu.fsf@gnu.org><911BA1D06CEB4306924D0069BA2D3DFF@us.oracle.com><83bpeki18a.fsf@gnu.org> NNTP-Posting-Host: lo.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit X-Trace: dough.gmane.org 1269117073 6265 80.91.229.12 (20 Mar 2010 20:31:13 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 20 Mar 2010 20:31:13 +0000 (UTC) Cc: 'Eli Zaretskii' , emacs-devel@gnu.org To: "'Stefan Monnier'" Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Mar 20 21:31:08 2010 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([199.232.76.165]) by lo.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1Nt5K4-0007TZ-Oq for ged-emacs-devel@m.gmane.org; Sat, 20 Mar 2010 21:31:05 +0100 Original-Received: from localhost ([127.0.0.1]:55980 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nt5K3-0003yE-DB for ged-emacs-devel@m.gmane.org; Sat, 20 Mar 2010 16:31:03 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nt5JS-0003q7-Km for emacs-devel@gnu.org; Sat, 20 Mar 2010 16:30:26 -0400 Original-Received: from [140.186.70.92] (port=57363 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nt5JQ-0003pS-D7 for emacs-devel@gnu.org; Sat, 20 Mar 2010 16:30:25 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nt5JO-0003f6-Qr for emacs-devel@gnu.org; Sat, 20 Mar 2010 16:30:24 -0400 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:55569) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nt5JO-0003ev-JE; Sat, 20 Mar 2010 16:30:22 -0400 Original-Received: from rcsinet13.oracle.com (rcsinet13.oracle.com [148.87.113.125]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2KKUJ0M017855 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Mar 2010 20:30:21 GMT Original-Received: from acsmt354.oracle.com (acsmt354.oracle.com [141.146.40.154]) by rcsinet13.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2KKUF0s026017; Sat, 20 Mar 2010 20:30:18 GMT Original-Received: from abhmt021.oracle.com by acsmt355.oracle.com with ESMTP id 102652731269116941; Sat, 20 Mar 2010 13:29:01 -0700 Original-Received: from dradamslap1 (/24.5.179.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Mar 2010 13:29:01 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrIYRHUXbs0ayloQ+GzQ7uf/ggfiwAAF2yg In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt354.oracle.com [141.146.40.154] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090208.4BA5305B.0038:SCFMA4539814,ss=1,fgs=0 X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.6 (newer, 3) X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:122383 Archived-At: > >> checking (string-match directory-listing-before-filename-regexp > >> ) 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.