From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: empty-directory predicate, native implementation Date: Thu, 15 Oct 2020 07:53:15 +0200 Message-ID: References: <83y2ka18t7.fsf@gnu.org> <87y2kaj799.fsf@gmx.de> <83blh60wgr.fsf@gnu.org> <87h7qxjh7g.fsf@gmx.de> <878sc8kgy8.fsf@gmx.de> <87imbcls71.fsf@gmx.de> <83eem0zt0b.fsf@gnu.org> <87k0vsrd6m.fsf@gmx.de> <83a6wozs7h.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1150"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Michael Albinus , emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Oct 15 07:54:19 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 1kSwDT-0000CN-Dv for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Oct 2020 07:54:19 +0200 Original-Received: from localhost ([::1]:55954 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kSwDS-0001fp-Eh for ged-emacs-devel@m.gmane-mx.org; Thu, 15 Oct 2020 01:54:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:48020) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSwCZ-0001F7-DP for emacs-devel@gnu.org; Thu, 15 Oct 2020 01:53:23 -0400 Original-Received: from mail-vi1eur05olkn2071.outbound.protection.outlook.com ([40.92.90.71]:27842 helo=EUR05-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kSwCW-00084y-TO; Thu, 15 Oct 2020 01:53:22 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=S9i0NRWRLilfDm1Bgbk8z5MlyKjUCtQkY5Tq4zOjcFitlOaAouWrJXfWCkapbQ7iSrmYTZpqAwMn599WoaP2qIMZw+ESJ1/KAXQizHwmTBeoZT/vFUc10GMItMvn9AZZPQ4p9avoKCAJEYhjFZTGRsf1BCRaKBoyeO9AquxvrM0iHGWGOdD7CYvEOBEp9XOX0YPLA4P9Bx+XVokoXVfW70wj4VYYxZ3IIn6RIuDxG+8dRDRWo30jGdHEuaSTtk7OzgFs9vx7xdtZ78kNzrtestq10bsZiG7wrmMxJcN8nIfNlu3PwC7tmTk4cS2Jc6tLKtqudC7YqvcjlMMia6LDRA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aTfr9FsLMhXy7pfFL4wKfURQs2psj5NDpbu7L7j45js=; b=ib7EoV7p4i5jCHY4qfgSzsycya0JGCB5iNqwRgSb8fBLg+djiiYdVnUxsMdLebqB4MR7bRn68bCFBKsTb/cBbvS/JmtUU5Xv819W4R4jAfu+LfgkkxX5QQga/FCSWHINzp2runJ94/IKpwvocH0hLu+/pRWt2I4OfNzIKofYObo7IluWioYnliJVQpYgikA21ZQz58Blc9SE+plaOOohoCd/pSS0MIaHCeKfHFf4i4YMZaIf4fJqx38rZispv8BvvI+YqT0BHfdyi+ZVGHenVeNxtO4ZIsS9KaEYPb6dJ4N8Ko7vRtqqQ/UjD82tWLwbil1ZbmnXs9f/2QSVbBdeZA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=aTfr9FsLMhXy7pfFL4wKfURQs2psj5NDpbu7L7j45js=; b=UcPqQlgW4UEm/soF+7m+9XSvNSBaEAbvlB/WcrYevqdf/IOBr9NfgAESwQYEWJWwll5/7tVXDrqFg6TXrZHwV/ueIEGdwJZsOQ57TJ1662LLME9LUZZ52LJLfUs6hI18KOxA4o1AHPy47wTp1jU/O2tGH484W+KSpAFR0NDJAloW1ctyFMMxA4nBeqxgyd13XuHk++X8/P/LYwZK8nY+vS+lpQEmzH3YCqaUMoeLANcWE0AnZPxwLXfdGQ6VeZ3FvpVxYwRnsl8tcs0JLHewVrl7ZHqBaJ5eozdDO8pkdsy6jdIoIQVQ7xrnjy3y1G9AQ+KjXb1aO9Nlibcp0AxRqA== Original-Received: from AM6EUR05FT040.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::44) by AM6EUR05HT065.eop-eur05.prod.protection.outlook.com (2a01:111:e400:fc11::225) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Thu, 15 Oct 2020 05:53:17 +0000 Original-Received: from VI1PR06MB4526.eurprd06.prod.outlook.com (2a01:111:e400:fc11::43) by AM6EUR05FT040.mail.protection.outlook.com (2a01:111:e400:fc11::421) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Thu, 15 Oct 2020 05:53:17 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:7FA56A48275809F02BA2C4B57CB47F2FC6B6217A856A9522BAFBEF298DCF0324; UpperCasedChecksum:EFA43FE6E01A2F2F71A726E14B909BFA9EEACC1AD5BE6B20F90BE6138F2097AC; SizeAsReceived:7968; Count:46 Original-Received: from VI1PR06MB4526.eurprd06.prod.outlook.com ([fe80::b547:51cd:16c5:4487]) by VI1PR06MB4526.eurprd06.prod.outlook.com ([fe80::b547:51cd:16c5:4487%7]) with mapi id 15.20.3455.031; Thu, 15 Oct 2020 05:53:16 +0000 In-Reply-To: <83a6wozs7h.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 14 Oct 2020 19:29:38 +0300") X-TMN: [7vHyizOVIYo2UlKNxne2ggNgpmzmyxci] X-ClientProxiedBy: AM6PR04CA0001.eurprd04.prod.outlook.com (2603:10a6:20b:92::14) To VI1PR06MB4526.eurprd06.prod.outlook.com (2603:10a6:803:ac::17) X-Microsoft-Original-Message-ID: <87ft6gdohg.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (90.230.29.56) by AM6PR04CA0001.eurprd04.prod.outlook.com (2603:10a6:20b:92::14) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Thu, 15 Oct 2020 05:53:16 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 46 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 2235c0c7-66c0-48d5-7f9e-08d870ce9c68 X-MS-TrafficTypeDiagnostic: AM6EUR05HT065: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: KpJuokxlHR8m64tKS73WwmTOW4Drfvd6jHE6fB2mqbnKMjbmCR1X9sjbtsKkEEwFm4OrxeGBE3a9Y4e1xCYkNuiMhS2IdbhYul4PI5/wNi4NKBBVlEeEQQZ8MBW9cwn3VBTR8AZkW+55YZaPGvagKLwGYeADZZ657DzfBOI7WCNJhvHPN/8EpOVqL8VXwP2M1OpflgIyRj/TCEwPsICayg== X-MS-Exchange-AntiSpam-MessageData: aGDhk7ytilF6agxP0dP1CZcBKXJfZJxDOkUO0Z4U21nzGoxjjHEAm1yzjNdzl5zW//doIgsH0kfXjP40S8Cr/yIN8ZEXAvk4kBfoxwLh9ocTSz8MU8FvW1oODSb1KlxtwenIkwRC/8aSmKpKjlI1Aw== X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-Network-Message-Id: 2235c0c7-66c0-48d5-7f9e-08d870ce9c68 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 15 Oct 2020 05:53:16.9479 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: AM6EUR05FT040.eop-eur05.prod.protection.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Anonymous X-MS-Exchange-CrossTenant-FromEntityHeader: Internet X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM6EUR05HT065 Received-SPF: pass client-ip=40.92.90.71; envelope-from=arthur.miller@live.com; helo=EUR05-VI1-obe.outbound.protection.outlook.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/15 01:53:17 X-ACL-Warn: Detected OS = Windows NT kernel [generic] [fuzzy] X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, MSGID_FROM_MTA_HEADER=0.001, RCVD_IN_DNSWL_NONE=-0.0001, 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:257703 Archived-At: --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Michael Albinus >> Cc: arthur.miller@live.com, emacs-devel@gnu.org >> Date: Wed, 14 Oct 2020 18:21:21 +0200 >> >> Eli Zaretskii writes: >> >> > I think 0 doesn't make much sense, so we might as well not support >> > that at all. >> >> In general, I agree. Calling directory-files with COUNT being 0, >> literally, doesn't make sense. But COUNT could be the result of some >> arithmetics, and instead urging the caller to test it, we could simply >> return nil. Which is correct, reading nil as the empty list. >> >> And it doesn't cost us anything. > > I'm okay with interpreting "don't support" as "return nil". Attached is patch which return nil early. I was thinking a bit when it would be useful to return length; the only thing I come up is to maybe allocate some structure, a vector or something based on how many files there are without really carying about files. In case there are many such objects, there would be lots of list the lisp system does not care about, and GC will have to work a lot unnecessary, but i think it is probably very rare case if not very artifical, so nil is just fine for the most use-cases. --=-=-= Content-Type: text/x-patch Content-Disposition: attachment; filename=dired.c.patch Content-Description: dired.c.patch --- src/dired.c 2020-10-15 07:43:02.633804624 +0200 +++ ../dired4.c 2020-10-15 07:42:01.358574645 +0200 @@ -17,7 +17,6 @@ You should have received a copy of the GNU General Public License along with GNU Emacs. If not, see . */ - #include #include @@ -165,8 +164,19 @@ Lisp_Object directory_files_internal (Lisp_Object directory, Lisp_Object full, Lisp_Object match, Lisp_Object nosort, bool attrs, - Lisp_Object id_format) + Lisp_Object id_format, Lisp_Object return_count) { + ptrdiff_t ind = 0, last = 0; + + /* check count first for early exit */ + if (FIXNATP(return_count)) + { + last = XFIXNAT(return_count); + + if (!last) + return Qnil; + } + if (!NILP (match)) CHECK_STRING (match); @@ -267,6 +277,13 @@ else finalname = name; + if (FIXNATP(return_count)) + { + if (ind == last) + break; + ind ++; + } + list = Fcons (attrs ? Fcons (finalname, fileattrs) : finalname, list); } @@ -287,8 +304,7 @@ return list; } - -DEFUN ("directory-files", Fdirectory_files, Sdirectory_files, 1, 4, 0, +DEFUN ("directory-files", Fdirectory_files, Sdirectory_files, 1, 5, 0, doc: /* Return a list of names of files in DIRECTORY. There are three optional arguments: If FULL is non-nil, return absolute file names. Otherwise return names @@ -296,9 +312,14 @@ If MATCH is non-nil, mention only file names that match the regexp MATCH. If NOSORT is non-nil, the list is not sorted--its order is unpredictable. Otherwise, the list returned is sorted with `string-lessp'. - NOSORT is useful if you plan to sort the result yourself. */) + NOSORT is useful if you plan to sort the result yourself. +If COUNT is non-nil, the function will return max of COUNT and length + files, where length is number of files in the directory. Order + in which files are returned is not guaranteed and is file system and + OS dependent. COUNT has to be an integral number in interval + [1,COUNT]. If 0 files are requested the function will return nil. */) (Lisp_Object directory, Lisp_Object full, Lisp_Object match, - Lisp_Object nosort) + Lisp_Object nosort, Lisp_Object count) { directory = Fexpand_file_name (directory, Qnil); @@ -306,34 +327,40 @@ call the corresponding file name handler. */ Lisp_Object handler = Ffind_file_name_handler (directory, Qdirectory_files); if (!NILP (handler)) - return call5 (handler, Qdirectory_files, directory, - full, match, nosort); + return call6 (handler, Qdirectory_files, directory, + full, match, nosort, count); - return directory_files_internal (directory, full, match, nosort, false, Qnil); + return directory_files_internal (directory, full, match, nosort, + false, Qnil, count); } DEFUN ("directory-files-and-attributes", Fdirectory_files_and_attributes, - Sdirectory_files_and_attributes, 1, 5, 0, - doc: /* Return a list of names of files and their attributes in DIRECTORY. + Sdirectory_files_and_attributes, 1, 6, 0, doc + : /* Return a list of names of files and their attributes in DIRECTORY. Value is a list of the form: - ((FILE1 . FILE1-ATTRS) (FILE2 . FILE2-ATTRS) ...) +((FILE1 . FILE1-ATTRS) (FILE2 . FILE2-ATTRS) ...) where each FILEn-ATTRS is the attributes of FILEn as returned by `file-attributes'. This function accepts four optional arguments: If FULL is non-nil, return absolute file names. Otherwise return names - that are relative to the specified directory. +that are relative to the specified directory. If MATCH is non-nil, mention only file names that match the regexp MATCH. If NOSORT is non-nil, the list is not sorted--its order is unpredictable. - NOSORT is useful if you plan to sort the result yourself. +NOSORT is useful if you plan to sort the result yourself. ID-FORMAT specifies the preferred format of attributes uid and gid, see `file-attributes' for further documentation. On MS-Windows, performance depends on `w32-get-true-file-attributes', -which see. */) - (Lisp_Object directory, Lisp_Object full, Lisp_Object match, - Lisp_Object nosort, Lisp_Object id_format) +which see. +If COUNT is non-nil, the function will return max of COUNT and length + files, where length is number of files in the directory. Order + in which files are returned is not guaranteed and is file system and + OS dependent. COUNT has to be an integral number in interval + [1,COUNT]. If 0 files are requested the function will return nil. */) +(Lisp_Object directory, Lisp_Object full, Lisp_Object match, + Lisp_Object nosort, Lisp_Object id_format, Lisp_Object count) { directory = Fexpand_file_name (directory, Qnil); @@ -342,11 +369,11 @@ Lisp_Object handler = Ffind_file_name_handler (directory, Qdirectory_files_and_attributes); if (!NILP (handler)) - return call6 (handler, Qdirectory_files_and_attributes, - directory, full, match, nosort, id_format); + return call7 (handler, Qdirectory_files_and_attributes, + directory, full, match, nosort, id_format, count); return directory_files_internal (directory, full, match, nosort, - true, id_format); + true, id_format, count); } --=-=-=--