From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.devel Subject: RE: empty-directory predicate, native implementation Date: Sun, 18 Oct 2020 14:13:43 -0700 (PDT) Message-ID: Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="21191"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , Arthur Miller , emacs-devel@gnu.org To: Michael Albinus Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sun Oct 18 23:14:51 2020 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1kUG0x-0005Pa-Ig for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Oct 2020 23:14:51 +0200 Original-Received: from localhost ([::1]:53728 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUG0w-0006X5-Id for ged-emacs-devel@m.gmane-mx.org; Sun, 18 Oct 2020 17:14:50 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44496) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUG0F-00067e-47 for emacs-devel@gnu.org; Sun, 18 Oct 2020 17:14:07 -0400 Original-Received: from aserp2130.oracle.com ([141.146.126.79]:56372) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUG09-0005lz-QZ; Sun, 18 Oct 2020 17:14:06 -0400 Original-Received: from pps.filterd (aserp2130.oracle.com [127.0.0.1]) by aserp2130.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09IL5Iqj117409; Sun, 18 Oct 2020 21:13:48 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=mime-version : message-id : date : from : sender : to : cc : subject : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=pVKZ2ZlAE9P1thHC+hP4rHEBSNstdpPqwK5xUujNhdY=; b=ki9JxRt3B+N7uGFZvsBJcO3CTsp8O6k1BuIKFaYQkZbG10A1dEmzNxf9CC/ZVifgQsWt QtZrZe0eF5IDbaAkpLCcKCMB/hacaHOimaIxC4b8Jkrz4ryiB/HkXQAQLkNunm1fnKj8 G+QBsUnwdol3XriJEb3/rqtAmBDkD2mYFZBz4rTsUKmg0FdMtDFGTzUNC9N7xOke3Xta GZ4HCF73co7XgzWrc0SgxZ/AWQt13FrBwKekEvKb4fZxtbExgoGVMpu15jKt4E2kzB0U HeZoLlSIzxGnUpiTiY8JVUV+S6AQHwDTW7VwQiGHj2GWxh0/KG4DYfYsT/QJmtQvPQG4 9A== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by aserp2130.oracle.com with ESMTP id 347p4ak1nv-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Sun, 18 Oct 2020 21:13:48 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09IL4mDH155059; Sun, 18 Oct 2020 21:13:47 GMT Original-Received: from aserv0122.oracle.com (aserv0122.oracle.com [141.146.126.236]) by userp3030.oracle.com with ESMTP id 348ahu9hew-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 18 Oct 2020 21:13:47 +0000 Original-Received: from abhmp0013.oracle.com (abhmp0013.oracle.com [141.146.116.19]) by aserv0122.oracle.com (8.14.4/8.14.4) with ESMTP id 09ILDio8006407; Sun, 18 Oct 2020 21:13:44 GMT X-Priority: 3 X-Mailer: Oracle Beehive Extensions for Outlook 2.0.1.9.1 (1003210) [OL 16.0.5056.0 (x86)] X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9778 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 adultscore=0 phishscore=0 bulkscore=0 malwarescore=0 spamscore=0 mlxlogscore=999 mlxscore=0 suspectscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010180168 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9778 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 suspectscore=0 priorityscore=1501 clxscore=1015 malwarescore=0 mlxscore=0 bulkscore=0 lowpriorityscore=0 phishscore=0 adultscore=0 mlxlogscore=999 impostorscore=0 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010180168 Received-SPF: pass client-ip=141.146.126.79; envelope-from=drew.adams@oracle.com; helo=aserp2130.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/18 17:13:53 X-ACL-Warn: Detected OS = Linux 3.1-3.10 [fuzzy] X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIMWL_WL_HIGH=-0.001, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:258066 Archived-At: > > `directory-files-no-dot-files-regexp' was added to Emacs 23. > > Its value then was the same as that of `diredp-re-no-dot': > > "^\\([^.]\\|\\.\\([^.]\\|\\..\\)\\).*". The value was > > changed in Emacs 27, to "[^.]\\|\\.\\.\\.". > > > > For my purposes (Dired) I want the former, not the latter, > > so `diredp-re-no-dot' remains the former. The two behave > > quite differently. > > > > See https://urldefense.com/v3/__https://lists.gnu.org/archive/html/emac= s- > devel/2020- > 04/msg00764.html__;!!GqivPVa7Brio!PWSpyl3EDfFC2LKEXIP7mdNKcGl6HzDDLwE2SFO= WdxS > ZaQ3phv5AVvVuUb-CN6kG$ >=20 > FTR, I have also problems to understand how the current value of > directory-files-no-dot-files-regexp works. But I fail to find a case > where it is wrong. >=20 > (string-match directory-files-no-dot-files-regexp ".") =3D> nil > (string-match directory-files-no-dot-files-regexp "..") =3D> nil > (string-match directory-files-no-dot-files-regexp ".a") =3D> 1 > (string-match directory-files-no-dot-files-regexp "..a") =3D> 2 >=20 > Could you pls give me an example which shows the problem with that > constant? In case there is, I'll lobby for your request in the given > message :-) Dunno. And perhaps I misspoke in saying they behave quite differently. They _can_ behave quite differently, depending on how they're used. And frankly I think that the only current Dired+ uses of the regexp don't depend on the difference, as they all just pass it to `directory-files' as the MATCH arg. And in that case the new regexp is just as usable. In general, the difference between the two is this, AFAICT: the old one (which is the one still used by Dired+) matches the complete file name (the nondirectory part), whereas the new one matches only enough of it to distinguish the . and .. cases. IOW, what's different, AFAICS, is the match data: the match. So if you use the regexp only with `string-match-p' (which doesn't care about the match data), or if you use it only with `directory-files', then there's no real difference in the effect. But if you use it for some context where the matched parts are important, that is, where the match-data matters, then there's a big difference. Perhaps in the past I used the regexp also for purposes of grabbing the matched part(s). I don't recall. I didn't complain about Emacs changing the value of the variable - no lobbying is needed. What I said was that "it's not clear to me" why people were claiming that the new regexp is "more correct" than the old one. (No one ever responded to that, explaining in what way the old one was somehow incorrect.) Paul's mail responding to my mail in that emacs-devel thread says, BTW: As Drew's comments make evident, the doc string is unclear. It should be something like 'Regexp that matches part of a nonempty string if the string is ^^^^^^^^^^^^ neither "." nor "..".' But I couldn't find where in that thread I said that. Anyway, I've said it now. The old regexp matches all chars in the nondir part of the file name. The new regexp doesn't. The match data for the old regexp gives you the matched name. But no, that's not needed for `directory-file-names'. ___ [BTW, neither manual nor doc string for `directory-files' says what MATCH is matched against, other than "file names". But apparently it's matched only against the nondirectory part of file names, even if FULL is non-nil.]