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: Mon, 19 Oct 2020 16:01:38 +0200 Message-ID: References: <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> <87sgafq2e2.fsf@gmx.de> <87h7qvptm3.fsf@gmx.de> <871rhxp8we.fsf@gmx.de> <87k0vnoio5.fsf@gmx.de> <87d01ezlo0.fsf@gmx.de> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13422"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , 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 16:04:00 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 1kUVlX-0003Jo-F9 for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 16:03:59 +0200 Original-Received: from localhost ([::1]:36228 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kUVlW-0000kC-C9 for ged-emacs-devel@m.gmane-mx.org; Mon, 19 Oct 2020 10:03:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:51318) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kUVjZ-000883-BK for emacs-devel@gnu.org; Mon, 19 Oct 2020 10:02:00 -0400 Original-Received: from mail-oln040092066054.outbound.protection.outlook.com ([40.92.66.54]:1614 helo=EUR01-VE1-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 1kUVjR-0001OL-EI; Mon, 19 Oct 2020 10:01:56 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=mMNSPN1cn6UkLaOMfT2g5AUYpTS1RhbLXUe7k3YZf8ZUeb3NJHw6A5k02JhDdTKrjFMDogRabddkcJSQqDl1LK9Z4wnTsN3ekBv0x1wfpmfRG55sTNL65IqZ4L6Kw+wMLNsaY0D9dCvDbMg1trQZN2fibEqPDqIkal+OChs3S8A6F5RJ0WpK1erYiLNHgvbz3P4pJ7XMmPzMfoP3N9O9T7fDUYizRo0/G8oyVLKnLdemSOB+2zXfIR3jcvfPqW4FwKcFIQtJ+X38tYSIIkhrpuxwtM8McgtRCZwrxDh6iTVd316b3l3VyPQwvM4p/KO+Bt5K9tNVZH1agfs2k8st3w== 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=pZR9HScxYfiQBWHyyFwgGwVFCOPeWfQ51QsF/XOWh8Y=; b=b+oGRZYDW3oN0eFYfsdVMgbpYudFxqePgmG+4AIuZ9jInkeo+Yt2CxUpd3EWB4XNEp1MdqdhE8dFqJ4Qgwffr2mY3NpPPfKEjnZtROrVmqzx/yyO++o2JHfI3gyirASOszXs1lmPctvxyzVbkaohPyXL4/1XEm+r+WssyTuEE6Cyt9/1u22CdTzix/u4gCNyz2MrkF9eluiXFpk8hih+NCPVKLnkh7hX4BQrqob+VyHVaa5YDoVVPnd9O1TJV2ozIGvmZdpX9lwWgt4I6LzTe9fkVZYmwwQUrv1Rp3KZoKXKE3/6eVLJhuOYj2Y5gWefU6soGSEpkoFiMrsjbGQ1Bg== 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=pZR9HScxYfiQBWHyyFwgGwVFCOPeWfQ51QsF/XOWh8Y=; b=BXCFGBLzJRClHVCxhYsD/hRJPC04SqOVe45oRtHWdeUYoFN5zkaTCxaErqFDK/cukfhbAt/4tKRnWm+FKcGevUB+lNHX5PWIRqRGjPjzOoREuioFj6dj2B9xxEzJBdhbMTpiEqEh2ghn/cViZdqjDDtFBwp11TslSonzP8z3JAvt3etV+jlZ3Q6GS7OgNmkseKR7IEs2WYGyUhODHszUzMji6mBF/80hqju6LL7HlgyI9EsNfCgV8Sq+KdnQGAhRfiR3RKkCY3BaKS4r1moiYlyjFchPAhiTIpqyT0uVgRwQCJ3YyXJ3v9v8iYvmHX1OdXOabQF4aT4UwnTg55vE0Q== Original-Received: from DB5EUR01FT054.eop-EUR01.prod.protection.outlook.com (2a01:111:e400:7e1a::47) by DB5EUR01HT113.eop-EUR01.prod.protection.outlook.com (2a01:111:e400:7e1a::270) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21; Mon, 19 Oct 2020 14:01:39 +0000 Original-Received: from VI1PR06MB4526.eurprd06.prod.outlook.com (2a01:111:e400:7e1a::4a) by DB5EUR01FT054.mail.protection.outlook.com (2a01:111:e400:7e1a::389) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Mon, 19 Oct 2020 14:01:39 +0000 X-IncomingTopHeaderMarker: OriginalChecksum:E96FE95ABA0BDBDD5EFCCAE31E8FC3F92EC0399B45561CEA38B9E85E2CECA39C; UpperCasedChecksum:18F951B6C87CE89E5628D6DCDC6071C8D33D7B833413CFC08668817B7FE7FEA4; SizeAsReceived:8446; Count:46 Original-Received: from VI1PR06MB4526.eurprd06.prod.outlook.com ([fe80::187b:196a:cb2d:adf1]) by VI1PR06MB4526.eurprd06.prod.outlook.com ([fe80::187b:196a:cb2d:adf1%5]) with mapi id 15.20.3477.028; Mon, 19 Oct 2020 14:01:39 +0000 In-Reply-To: <87d01ezlo0.fsf@gmx.de> (Michael Albinus's message of "Mon, 19 Oct 2020 10:04:31 +0200") X-TMN: [f7jmB2k0T+44vRD3PH/uUhqLuUF2Nj3u] X-ClientProxiedBy: AM6P194CA0105.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:8f::46) To VI1PR06MB4526.eurprd06.prod.outlook.com (2603:10a6:803:ac::17) X-Microsoft-Original-Message-ID: <87eelu2u2l.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 Original-Received: from pascal.homepc (90.230.29.56) by AM6P194CA0105.EURP194.PROD.OUTLOOK.COM (2603:10a6:209:8f::46) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.3477.21 via Frontend Transport; Mon, 19 Oct 2020 14:01:38 +0000 X-MS-PublicTrafficType: Email X-IncomingHeaderCount: 46 X-EOPAttributedMessage: 0 X-MS-Office365-Filtering-Correlation-Id: 53f5ddd4-13ba-4b05-e568-08d874377ff0 X-MS-TrafficTypeDiagnostic: DB5EUR01HT113: X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: F2+Kckt7qfylRYeohSSh1aaSNKb1oRRVEJqAN4SGJ3A9DUlN0zHLF7pb6smZkLXV7dqg41azt3gu64z3FMK2caHLHS3k6Y+Dq93l2qXn1xNyHUV1OQCp3QCuDOvKxjRyKecIQllB2pJJoc8q8xvGEo/XKMT2DZ9SPw3YgkANFd1dj8e/KcAmUZlhMoY8ex0LEhAVh/2oFdRJPwf8PrHa5g== X-MS-Exchange-AntiSpam-MessageData: tWhPSnyhiPyZFEyuHmKx74ycOMOfXJXdhUt25rek9OQYPu76ziUstmD05+oI0RnoD0xC8SikjmHD5Xq2YFPPwgA3vixuWny7hTc60a4yTnr55+jC3uhxlQ5bu4XNXep3W2k5fpm3NfQrKCcSv+b/eQ== X-OriginatorOrg: live.com X-MS-Exchange-CrossTenant-Network-Message-Id: 53f5ddd4-13ba-4b05-e568-08d874377ff0 X-MS-Exchange-CrossTenant-OriginalArrivalTime: 19 Oct 2020 14:01:39.8108 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-AuthSource: DB5EUR01FT054.eop-EUR01.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: DB5EUR01HT113 Received-SPF: pass client-ip=40.92.66.54; envelope-from=arthur.miller@live.com; helo=EUR01-VE1-obe.outbound.protection.outlook.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/10/19 10:01:44 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:258113 Archived-At: Michael Albinus writes: > Arthur Miller writes: > > Hi Arthur, > >>> What's wrong using FIXNATP and XFIXNAT everywhere? >> >> If we return nil for 0 count, then it make sense to return nil for >> negative count too? > > *Any* non-nil COUNT, which is not a natural number, is handled as it > were nil. That's what my proposal for the docstring tries to say ("If > COUNT is a natural number ..."). Yes, that is how I interpreted it; just wanted to confirm. >> XFIXNAT will turn it negative num into some big int. >> I thought first it is fine, but after second thought I don't think it is >> best thing to do. >> >> if (FIXNUMP(return_count)) >> { >> last = XFIXNUM(return_count); >> >> if (last < 1) >> return Qnil; >> } >> >> This works better. > > But if you use FIXNATP instead of FIXNUMP, there's no problem at all. I tryed, but it discards negative numbers - from lisp.h: INLINE bool FIXNATP (Lisp_Object x) { return FIXNUMP (x) && 0 <= XFIXNUM (x); } This discards negative numbers, which then leaves last = 0, which results later in all files returned. Either I have to add another test or use FIXNUM. Or do I missinterpret the code? With fixnum negative numbers are catched unless they are bignumbers. FIXNATP uses under the hood FIXNUMP, so check for FIXNUMP is cheaper too. >>>> --- a/lisp/net/tramp-adb.el >>>> +++ b/lisp/net/tramp-adb.el >>>> @@ -312,7 +312,7 @@ tramp-adb-handle-directory-files-and-attributes >>>> (copy-tree >>>> (with-tramp-file-property >>>> v localname (format "directory-files-and-attributes-%s-%s-%s-%s" >>>> - full match id-format nosort) >>>> + full match id-format nosort count) >> I did that first, but then decided to skip count in format and forgot >> to delete the count from the argument list. I didn't know how format was >> used so I didn't want to mess with it; but if it is only for the name, >> then it is maybe useful? > > Well, the name is used for caches. If we want to use the cache also for > a non-nil COUNT, we must use it also for the cache entry. Yes, I will add the count to format. >>>> diff --git a/lisp/net/tramp.el b/lisp/net/tramp.el >>>> index 6d44ad23ad..a99af70196 100644 >>>> --- a/lisp/net/tramp.el >>>> +++ b/lisp/net/tramp.el >>>> +(defun tramp-handle-directory-files (directory &optional full match >>>> + nosort count) >>> >>> This fits into one line (80 chars). >> It is 81 chars so Emacs breaks the line. I can call it num, saves 2 chars. > > It's not important. But in my Emacs, the closing parenthesis is at > position 80, IIRC :-) Ha :-) Mine was 81. Emacs ways are strange sometimes. Anyway, I changed to 'num' - 2 chars off! :D