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 16:09:23 -0700 Message-ID: References: <56D10E2523764AC98D99CEBC55DBAD93@us.oracle.com><83iq8sigyq.fsf@gnu.org><83d3z0i3nu.fsf@gnu.org><911BA1D06CEB4306924D0069BA2D3DFF@us.oracle.com><83bpeki18a.fsf@gnu.org> <85D696D9907C42A389AA65E4BC83CDD7@us.oracle.com> 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 1269126583 2316 80.91.229.12 (20 Mar 2010 23:09:43 GMT) X-Complaints-To: usenet@dough.gmane.org NNTP-Posting-Date: Sat, 20 Mar 2010 23:09:43 +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 Sun Mar 21 00:09:38 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 1Nt7nV-0002dU-Gq for ged-emacs-devel@m.gmane.org; Sun, 21 Mar 2010 00:09:37 +0100 Original-Received: from localhost ([127.0.0.1]:52975 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nt7nU-0007ql-WF for ged-emacs-devel@m.gmane.org; Sat, 20 Mar 2010 19:09:37 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1Nt7nO-0007pZ-St for emacs-devel@gnu.org; Sat, 20 Mar 2010 19:09:30 -0400 Original-Received: from [140.186.70.92] (port=35419 helo=eggs.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1Nt7nM-0007oR-TD for emacs-devel@gnu.org; Sat, 20 Mar 2010 19:09:30 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.69) (envelope-from ) id 1Nt7nL-0002pK-8H for emacs-devel@gnu.org; Sat, 20 Mar 2010 19:09:28 -0400 Original-Received: from rcsinet11.oracle.com ([148.87.113.123]:40791) by eggs.gnu.org with esmtp (Exim 4.69) (envelope-from ) id 1Nt7nL-0002pE-3B; Sat, 20 Mar 2010 19:09:27 -0400 Original-Received: from acsinet15.oracle.com (acsinet15.oracle.com [141.146.126.227]) by rcsinet11.oracle.com (Switch-3.4.2/Switch-3.4.2) with ESMTP id o2KN9Nig017750 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=OK); Sat, 20 Mar 2010 23:09:25 GMT Original-Received: from acsmt353.oracle.com (acsmt353.oracle.com [141.146.40.153]) by acsinet15.oracle.com (Switch-3.4.2/Switch-3.4.1) with ESMTP id o2KLsKEt020768; Sat, 20 Mar 2010 23:09:22 GMT Original-Received: from abhmt001.oracle.com by acsmt355.oracle.com with ESMTP id 97730631269126560; Sat, 20 Mar 2010 16:09:20 -0700 Original-Received: from dradamslap1 (/24.5.179.75) by default (Oracle Beehive Gateway v4.0) with ESMTP ; Sat, 20 Mar 2010 16:09:20 -0700 X-Mailer: Microsoft Office Outlook 11 Thread-Index: AcrId8cS+Lm4dbiIQx2Ki2OtJt7uGAAACi8A In-Reply-To: X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5579 X-Source-IP: acsmt353.oracle.com [141.146.40.153] X-Auth-Type: Internal IP X-CT-RefId: str=0001.0A090202.4BA555A3.0094: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:122388 Archived-At: >> 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 ) > 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. (I see, BTW, that I should not have mentioned condition-case in my mail - dunno what I was thinking there.) This is presumably what you're suggesting for the font-lock keyword entry: (list dired-move-to-filename-regexp (if (string-match ; Date/time dired-move-to-filename-regexp ) (list 2 '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))) It's not obvious to me what the string should be. I tried this, based on the bug #5597 report, which says that a file named "~/2010-02-18\ foo" causes the unfixed (i.e. old) regexp not to match: "-rw-rw-rw- 1 10 2010-04-01 2010-02-18 foo" But that in fact _matches_ the old regexp as well, i.e., in versions before the fix (Emacs 20.7, 21.3.1, 22.3, 23.1, 23.1.92). And of course there's a possibility that the regexp might match even in the bugged case, but match in the wrong way. None of that is called out in the bug history, so it would require further investigation (with an extremely hairy regexp). So you can see one manifestation of the added complication already: getting the unit test right. And as I said, I cannot even reproduce the bug itself on Windows, starting with emacs -Q, in any release that I have. That seems to indicate that the bug (and hence your approach) might be platform-specific. (Or perhaps the bug report and fix description are not clear.) Whereas a simple `emacs-version' test has to work (since the fix is in only in newer versions), code that addresses the bug case directly will do the wrong thing on any platforms where the bug was not manifested. The buggy file name can only serve to identify which regexp is which if in fact one of the regexps (the old one) is buggy on the current platform. To fix it further (assuming such platform-dependence), I would need to then investigate all platforms and add platform tests to the embedded unit-test code. And if the problem was not that the regexp didn't match but that it matched in the wrong way... Such an approach is not clean and sound, IMO. It means unnecessary code-coupling, which is unhealthy: mixing in bug-case unit-test code with the font-lock code, which is logically unrelated. Coding that way and maintaining the code then requires understanding the bug and the fix. At the very least, a WTF comment would need to be added so that anyone reading the code would have some idea what was going on. Again, if you think I misunderstand, please clarify. Thx.