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: Mon, 19 Oct 2020 08:25:12 -0700 (PDT) Message-ID: References: <87lfg2zm90.fsf@gmx.de> 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="16158"; 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 Mon Oct 19 17:32:28 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 1kUX99-000442-Sy for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 17:32:27 +0200 Original-Received: from localhost ([::1]:44156 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUX98-0002jM-UJ for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 11:32:26 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:44562) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUX2L-0005He-4C for emacs-devel@gnu.org; Mon, 19 Oct 2020 11:25:25 -0400 Original-Received: from aserp2120.oracle.com ([141.146.126.78]:43626) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUX2H-0004Ai-F4; Mon, 19 Oct 2020 11:25:24 -0400 Original-Received: from pps.filterd (aserp2120.oracle.com [127.0.0.1]) by aserp2120.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09JFEebU059150; Mon, 19 Oct 2020 15:25:14 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 : references : in-reply-to : content-type : content-transfer-encoding; s=corp-2020-01-29; bh=rS2WiMfvJAvcyXCm/wnfeuQMBqYEa9W5uNYOOZwQefw=; b=EcoUN4X1w5X/95bqfIQzMHK6BZaZ4JSP2KU82tsZ/+b7/MICRUEtVgnRo66e7Q4Vh5yL p1p5YFRPpfeFVoINiT229VufeQHrBnlZ2ocP9Hg7cy9FAFcoS2iaPc50iCtvxDm8JQeM zaFGaNM+7CjRYrRp6UyqSmXV0fhFfC9p1CkQR3d5gvPQy9osyBiaJnE3ts8mr+pvyZL0 5Hq0xjwTRclIPP7KWb3HGxLTatSij9liomE9aDypmP7xtM1yBz2juiRl4YNWcOKdrBTZ eLSTfhfAbdYVROqhQ5jhLVzwlTXNo15GP6GARgV+f5d6EcTuNMTCGVKnhNNRNKOA0DTo yw== Original-Received: from aserp3030.oracle.com (aserp3030.oracle.com [141.146.126.71]) by aserp2120.oracle.com with ESMTP id 347rjkp4aj-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=FAIL); Mon, 19 Oct 2020 15:25:14 +0000 Original-Received: from pps.filterd (aserp3030.oracle.com [127.0.0.1]) by aserp3030.oracle.com (8.16.0.42/8.16.0.42) with SMTP id 09JFFwhO061146; Mon, 19 Oct 2020 15:25:14 GMT Original-Received: from aserv0121.oracle.com (aserv0121.oracle.com [141.146.126.235]) by aserp3030.oracle.com with ESMTP id 348a6m1g17-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Mon, 19 Oct 2020 15:25:14 +0000 Original-Received: from abhmp0020.oracle.com (abhmp0020.oracle.com [141.146.116.26]) by aserv0121.oracle.com (8.14.4/8.13.8) with ESMTP id 09JFPDEM004344; Mon, 19 Oct 2020 15:25:13 GMT In-Reply-To: <87lfg2zm90.fsf@gmx.de> 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 malwarescore=0 mlxlogscore=999 bulkscore=0 spamscore=0 adultscore=0 suspectscore=0 mlxscore=0 phishscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190107 X-Proofpoint-Virus-Version: vendor=nai engine=6000 definitions=9778 signatures=668682 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 mlxscore=0 mlxlogscore=999 bulkscore=0 spamscore=0 priorityscore=1501 impostorscore=0 lowpriorityscore=0 phishscore=0 suspectscore=0 clxscore=1015 adultscore=0 malwarescore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2009150000 definitions=main-2010190107 Received-SPF: pass client-ip=141.146.126.78; envelope-from=drew.adams@oracle.com; helo=aserp2120.oracle.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 11:16:41 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, 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:258124 Archived-At: > > 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. >=20 > Yes. But to be fair, the docstring of directory-files-no-dot-files-regexp > didn't promise to return any kind of match data. Using it was just using > an undocumented side effect. Sure. It's just a regexp. Its value says what it's good for. > > 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.) >=20 > I believe this statement was rather for the different instances of > regexps over the code, all of them claiming to match just "." and > "..". And some of them might have been wrong. My reading of that statement was that the new regexp was somehow more correct than the old one, at least for the occurrences in the code. I asked how/where it was more correct. But in this current thread Stefan has mentioned that it is more correct in that it matches also file names containing newline chars. So far, that's the only indication I've seen of how the new is more correct than the old. (Aside from whether/how it might be more correct, the new is no doubt quicker.) > > [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.] >=20 > I've fixed the docstrings of directory-files-no-dot-files-regexp, > directory-files and directory-files-and-attributes. Cool. Thanks for that.