From unknown Sat Sep 20 01:11:45 2025 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-Mailer: MIME-tools 5.509 (Entity 5.509) Content-Type: text/plain; charset=utf-8 From: bug#62621 <62621@debbugs.gnu.org> To: bug#62621 <62621@debbugs.gnu.org> Subject: Status: 29.0.60; uniquify can't make buffers unique based on things other than filename Reply-To: bug#62621 <62621@debbugs.gnu.org> Date: Sat, 20 Sep 2025 08:11:45 +0000 retitle 62621 29.0.60; uniquify can't make buffers unique based on things o= ther than filename reassign 62621 emacs submitter 62621 Spencer Baugh severity 62621 normal thanks From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 13:37:43 2023 Received: (at submit) by debbugs.gnu.org; 2 Apr 2023 17:37:43 +0000 Received: from localhost ([127.0.0.1]:42558 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj1eB-0002e5-9B for submit@debbugs.gnu.org; Sun, 02 Apr 2023 13:37:43 -0400 Received: from lists.gnu.org ([209.51.188.17]:52922) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj1e8-0002du-Vl for submit@debbugs.gnu.org; Sun, 02 Apr 2023 13:37:42 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pj1e8-0000bb-PF for bug-gnu-emacs@gnu.org; Sun, 02 Apr 2023 13:37:40 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pj1e5-0000vh-LN for bug-gnu-emacs@gnu.org; Sun, 02 Apr 2023 13:37:40 -0400 From: Spencer Baugh To: bug-gnu-emacs@gnu.org Subject: 29.0.60; uniquify can't make buffers unique based on things other than filename Date: Sun, 02 Apr 2023 13:37:36 -0400 Message-ID: MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=64.215.233.18; envelope-from=sbaugh@janestreet.com; helo=mxout5.mail.janestreet.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-Spam-Score: -1.4 (-) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -2.4 (--) I have a lot of buffers visiting files with the same basename, in directory paths which have long meaningless numeric identifiers. This means that with uniquify, I get buffers named things like: foo, foo, foo This is not much better than foo<1>, foo<2>, foo<3> for me. What would be great is if uniquify could use things other than the filename when making unique buffer names. For example, project-name from project.el is something that *is* unique for these files, because of my custom project.el integration. Then I'd get something like: foo, foo, foo However, uniquify is currently not customizable in this way. Could we add support for including additional attributes into the things which uniquify will use? Then I could add project-name as one of those attributes in my configuration, and I'd be happy. I would be happy to implement this feature in uniquify myself, if this is an interesting feature for upstream. Or if you'd prefer some other approach, I'd be happy to hear it and I can implement it. In GNU Emacs 29.0.60 (build 3, x86_64-pc-linux-gnu, X toolkit, cairo version 1.15.12, Xaw scroll bars) of 2023-03-13 built on igm-qws-u22796a Repository revision: e759905d2e0828eac4c8164b09113b40f6899656 Repository branch: emacs-29 Windowing system distributor 'The X.Org Foundation', version 11.0.12011000 System Description: CentOS Linux 7 (Core) Configured using: 'configure --with-x-toolkit=lucid --with-modules --with-gif=ifavailable' Configured features: CAIRO DBUS FREETYPE GLIB GMP GNUTLS GSETTINGS HARFBUZZ JPEG JSON LIBSELINUX LIBXML2 MODULES NOTIFY INOTIFY PDUMPER PNG RSVG SECCOMP SOUND SQLITE3 THREADS TIFF TOOLKIT_SCROLL_BARS X11 XDBE XIM XINPUT2 XPM LUCID ZLIB Important settings: value of $LANG: en_US.UTF-8 locale-coding-system: utf-8-unix From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 13:56:59 2023 Received: (at 62621) by debbugs.gnu.org; 2 Apr 2023 17:56:59 +0000 Received: from localhost ([127.0.0.1]:42609 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj1wp-0003UH-FJ for submit@debbugs.gnu.org; Sun, 02 Apr 2023 13:56:59 -0400 Received: from eggs.gnu.org ([209.51.188.92]:33438) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj1wl-0003Tx-Qq for 62621@debbugs.gnu.org; Sun, 02 Apr 2023 13:56:57 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pj1wf-0004CQ-O5; Sun, 02 Apr 2023 13:56:49 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=HME1xggYo2VzEnIhPPEzWIYWOx43Af+hYzFgh3mf3rI=; b=K9hVxGRPZ1tG MFNTDU7TQ5FFUAW93MdAVIhYrz8XGLx+tsGvzGE4bQi5kgulVi/DHAcJihQ/SBjCPt+w0LYk8cs2S JAvhqpKJTZHtlaB9Nh3ywAI6scYKosnXZ/Jbz1kEv8L5j9B4qNnXtugXzzNwYHntNQ9YcBJVR5pFH dd8Zctrqv6KWlOxwgy3Ko2aSwN09lxqg+LDV8XBmmpC/UGoktHVy1STskVQLbfrdYD2Chr0G+noiP ZnBRQMlmcmRXtmVuJK41zz0z4ghNjxUm+sSJH5dUrgOcaZDdq3U+oa3iDVsorIrH44oA+oOGWVnRg 9p0iZD9emVCPvjupN6iXIw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1pj1wf-0004PN-BN; Sun, 02 Apr 2023 13:56:49 -0400 Date: Sun, 02 Apr 2023 20:57:08 +0300 Message-Id: <83fs9iw4jv.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Sun, 02 Apr 2023 13:37:36 -0400) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Sun, 02 Apr 2023 13:37:36 -0400 > > > I have a lot of buffers visiting files with the same basename, in > directory paths which have long meaningless numeric identifiers. This > means that with uniquify, I get buffers named things like: > > foo, foo, foo > > This is not much better than foo<1>, foo<2>, foo<3> for me. > > What would be great is if uniquify could use things other than the > filename when making unique buffer names. > > For example, project-name from project.el is something that *is* > unique for these files, because of my custom project.el integration. > Then I'd get something like: > > foo, foo, foo > > However, uniquify is currently not customizable in this way. Could we > add support for including additional attributes into the things which > uniquify will use? Then I could add project-name as one of those > attributes in my configuration, and I'd be happy. > > I would be happy to implement this feature in uniquify myself, if this > is an interesting feature for upstream. Sounds like a useful feature indeed, provided that the customization will allow more or less arbitrary uniquification, not just by project names. Also, please keep in mind that a single project could have files named the same in different directories. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 14:25:53 2023 Received: (at 62621) by debbugs.gnu.org; 2 Apr 2023 18:25:54 +0000 Received: from localhost ([127.0.0.1]:42634 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj2On-0004IG-Lm for submit@debbugs.gnu.org; Sun, 02 Apr 2023 14:25:53 -0400 Received: from relay4-d.mail.gandi.net ([217.70.183.196]:34695) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj2Oj-0004Hw-RB for 62621@debbugs.gnu.org; Sun, 02 Apr 2023 14:25:52 -0400 Received: (Authenticated sender: juri@linkov.net) by mail.gandi.net (Postfix) with ESMTPSA id CABD7E0004; Sun, 2 Apr 2023 18:25:42 +0000 (UTC) From: Juri Linkov To: Spencer Baugh Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: (Spencer Baugh's message of "Sun, 02 Apr 2023 13:37:36 -0400") Organization: LINKOV.NET References: Date: Sun, 02 Apr 2023 21:25:08 +0300 Message-ID: <86y1najg57.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 62621 Cc: 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > However, uniquify is currently not customizable in this way. Could we > add support for including additional attributes into the things which > uniquify will use? Then I could add project-name as one of those > attributes in my configuration, and I'd be happy. This was discussed recently in bug#59502, but I don't remember why the patch was never applied. From debbugs-submit-bounces@debbugs.gnu.org Sun Apr 02 18:00:01 2023 Received: (at 62621) by debbugs.gnu.org; 2 Apr 2023 22:00:02 +0000 Received: from localhost ([127.0.0.1]:42891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj5k1-0004JG-4p for submit@debbugs.gnu.org; Sun, 02 Apr 2023 18:00:01 -0400 Received: from mx0b-00069f02.pphosted.com ([205.220.177.32]:52866) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pj5jy-0004J7-Lr for 62621@debbugs.gnu.org; Sun, 02 Apr 2023 17:59:59 -0400 Received: from pps.filterd (m0246630.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.17.1.19/8.17.1.19) with ESMTP id 332LvsHQ014721; Sun, 2 Apr 2023 21:59:57 GMT DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.com; h=from : to : cc : subject : date : message-id : references : in-reply-to : content-type : content-transfer-encoding : mime-version; s=corp-2022-7-12; bh=iEufQneYdUexB5zhQnT92trRko8boRaSJXE2jmbecUE=; b=YK4lbAxthcJtq8dCWDS0UpEqxl3F3f/pGx/zFzparpl5rC92AAtZvziGWuBCNLzz/P2F yqeEVIiy+AyahRBTAnYKsUUR0bHxjexXcbH/baermsHBB0IgdgyraPPM8STPPIphrfRg aGjRAY7JcRg1OD2IAix2Ymc4YgxMyIZm02cXfVkj7GDa/Sd/b3gYQX3TCnsWy5GUXwjF lYp9gEFw4JY9HWtOUXFIAJ6z4eFXEv/e5yeBt7QU2H4KYhoUEYdT02Mkiq30KJmxbefR nJQkorxs5WhyHhLMrZBHWHFxzLRPeoeXUjAovwwREMUfHbLJw8nrbpBb0uWiIPdfCG7B 6A== Received: from iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (iadpaimrmta03.appoci.oracle.com [130.35.103.27]) by mx0b-00069f02.pphosted.com (PPS) with ESMTPS id 3ppb1dhuc7-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 02 Apr 2023 21:59:57 +0000 Received: from pps.filterd (iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com [127.0.0.1]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (8.17.1.19/8.17.1.19) with ESMTP id 332GfLSq027857; Sun, 2 Apr 2023 21:59:56 GMT Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) by iadpaimrmta03.imrmtpd1.prodappiadaev1.oraclevcn.com (PPS) with ESMTPS id 3pptum666t-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Sun, 02 Apr 2023 21:59:56 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=lZXhz+N11tr7kVhxMa0oOIBiDR/ats6A7nRLC/tdsDtczB7rtyY5Q6cIYcYWEUxC5K+jApyissxUsCdjUSDrHdEyDxwpgePLtFjYjjXU0bsN6yW+9U4QAkpptyajmi8BdlOxWIlxyj9N7GRGcXthWl5XfOa4+cmqfeNdL0NF+uc909pvZbNdr5P2icLx4WRCuQXgWDich9iY+KyiztQs4+oVNvjQZB5TkMcvtvsjVE24VVbza5zuaI1mUfu/v7Dpo3K/o7NQcjuRRHu+VjmpuKHNo3ck8RFtfU/nHgMBMgRwyaUpsU+IzT2BEgPNQm+WaWRY1RzdH1/jD7x7sxmvzg== 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-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=iEufQneYdUexB5zhQnT92trRko8boRaSJXE2jmbecUE=; b=MKhpRBXcDuhP7t8koSLNgwMgkbDIXAAI6OLOxsj4xbL/3oxBpOV6qqa6NxYu3PzVIbry4nJsnUwEPfeE87e/PlG+3a6s7dNBbZYM1ib9ztkiE8veSJuAey4+Anvo6gmlwntPOhV9LoAUvHLQeh5q9xeQfCql7w9qkS+6aHoaTCMynfK10vaA/Wuzp5S28j/eOKA9Xa92AhquHlG92GNAn2VU22tY1NA/zJ0eVsPFnoWaYWb9WbNmlxNVo7I8Eugpr067Y+LJNIzIKGhVb523x5IVS9sYpSEmg5Sb2dsAUHeTt2fTEp+d1dhjlZi9xtT94aqy6TGHgv6duE+eEXfpEg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=oracle.com; dmarc=pass action=none header.from=oracle.com; dkim=pass header.d=oracle.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=oracle.onmicrosoft.com; s=selector2-oracle-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=iEufQneYdUexB5zhQnT92trRko8boRaSJXE2jmbecUE=; b=g+SAqcbF6ug1xKMo689NXC/IWaU/8VAuL7htff0klTPK9ulbZsbRoHflWYlClrPrNEbFDDnAyBvOyabT5u1K0Dwqsk7EoP5q4TyPH0PbSOncnQr4DgW4B8WouQbe/ADtUsTLJMKUcFBVXIeQORhUCvMjTIrKrUGSzmgioyrTir4= Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by PH7PR10MB7696.namprd10.prod.outlook.com (2603:10b6:510:2e5::18) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6254.30; Sun, 2 Apr 2023 21:59:54 +0000 Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::a995:2ae5:2745:24ff]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::a995:2ae5:2745:24ff%5]) with mapi id 15.20.6254.028; Sun, 2 Apr 2023 21:59:53 +0000 From: Drew Adams To: Eli Zaretskii , Spencer Baugh Subject: RE: [External] : bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Thread-Topic: [External] : bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Thread-Index: AQHZZY0JBd1kKJa9506ASK5mQc/5NK8YihJQ Date: Sun, 2 Apr 2023 21:59:52 +0000 Message-ID: References: <83fs9iw4jv.fsf@gnu.org> In-Reply-To: <83fs9iw4jv.fsf@gnu.org> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SJ0PR10MB5488:EE_|PH7PR10MB7696:EE_ x-ms-office365-filtering-correlation-id: 1b7bcfdc-632d-4905-27a8-08db33c59680 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: lTryuRbqIX9EMgHrPhA8N0fgbGxX0F9obhgdkq2Hfpp8PWGwwmeMBzuMsTLvfuzsmGb8ZA6h0XWbpaGwgwhA56mkqesYaHp04yCn7wT2vy2YtN7SxMo5P4P2/x/tAMbfVThohqp2eK+pLINlB4/qDRlzhIjJ2iaWCweMLbXBu9YmoNqsaVmaoDpgrYZeJgSf/iEIOWPrtR1xrbzsmCrqBeTZeITXFnaDtj50YZrCWQyKmFWNQkPJifHANO81Tls4SwVqNvLWFa01ZsyTdl4KonfGaPo05It6QbjhMuVnMjHI5gxFCunvU8tpdMTrUVTbET/1nfBBQWJknh75Tn3zzvbq+2kobVqBBtRO7TfLXTvWKvasXvLTY89JHiC5CwQz3JZh4qKlmhAopTXGwtvcwSaIo4iXgJeuzsgNrYeOnWGNtgWBYcMWXZ0G2WLSsFJiOAWYwCkqsIB0Pq9Z3AvZ59p1d7rFzmr/bneXqiSvCEsPFWejYmo9DoMugRLVK7W3052/HBL3sNT2fFL0DPMu182ADRDO2p+ckK9uaKScfS/NHGGnbF2QhMN+rQryo9wQEGyEX6tVlQxlmglQ5eAZ8oIGP+HzPCjljSLBrSuzBWdMxWoQAc1ov6IICkX9WR30 x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:SJ0PR10MB5488.namprd10.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(366004)(346002)(396003)(39860400002)(376002)(136003)(451199021)(55016003)(4326008)(8676002)(66556008)(66476007)(76116006)(66446008)(64756008)(66946007)(478600001)(110136005)(316002)(52536014)(8936002)(44832011)(5660300002)(122000001)(41300700001)(38100700002)(186003)(7696005)(71200400001)(9686003)(6506007)(26005)(86362001)(33656002)(2906002)(38070700005)(66899021); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?us-ascii?Q?t29KLxoLvDZZ8u31A42imfXtlvhVf+94LgnuQwT3WPK7CwKsDHCaOEkGgKQu?= =?us-ascii?Q?c1OGOhEP2Fl75N3wiuPcW/nP5kNvCcIsShYxKWmEqbFmiHVZfZ9ogNCffclN?= =?us-ascii?Q?oIZ88rAnzv552icHrQD9byfPgeAZKmGRFjnYu2wOjxSoSyyYfi61uCTgQyXf?= =?us-ascii?Q?KD+oa17jPuqFA/JDMIoQNouiZ+AyGWWI4X/gGofs2Hv9Ciw4KConKJ2CgCAK?= =?us-ascii?Q?eLzXr1kxxtrfqisIGacL+vamqMoCO5fIb+BMJwcYbBBUrd2FwPSTJQOnGLRi?= =?us-ascii?Q?lTjMUXAnFNDndJ457LE3Slq3CJ02cNo7CJowINSPhzmvZ6M9J5gSvAYgseeq?= =?us-ascii?Q?KtP2UKsd2h44DKNsaJwUCgg/Ltf6/LyBv+Y9tTYgzIrwEF0e+z0Pe4dtVYco?= =?us-ascii?Q?OWzLpUbVrkFcLO9dlIDyIv+yANxpRj3KZ0HIeRC3PfLK3gudbAIUaveRvsXJ?= =?us-ascii?Q?vpOTgdj4a7de/dcYJ5nMF0QULbw7ntUanC4HXIPi/oIYS/c/aegi2TyQsvg9?= =?us-ascii?Q?j2fZHRJE1C2xU0P2D6XeUra6ZdikeiUSVga3fMv5A3NR7RYIWHjOTTGxRaq9?= =?us-ascii?Q?ZsWdl2CcdxZb49z04JE9B2t3zSUQ3hRpfOaFYILZqkNCjhYGl+myeRAtLwXP?= =?us-ascii?Q?xciYI3Fd2NmEngLQzDXfx6R/vUGxQgWN9DVYRxHgssS4W/7QaFxvO26yLiLt?= =?us-ascii?Q?Sxy1FfKQTe290+U6PmIy4eqSfUS+LZUO0EYK2AW8anduW7kuN9Y0ouj56N3C?= =?us-ascii?Q?USXF6u71zw6xyohhMuxmaYaZT49kENT/Qi+gzM04SuHM+O5DXIzrylC5+Sr3?= =?us-ascii?Q?H26NotBoGLfbzzP0U9/aMnYGQPJLPNxfUsyR9ejEF9iiKwnfxMjMYajWqqmC?= =?us-ascii?Q?DxNFz/3b6VWCaCd269DdwrXiLbrHSXOxnLxt1o1wXMkl+sqvRPQAVelzCGaK?= =?us-ascii?Q?d2JUueoFHJZwEXcJxIVfSqB7gAxiXTCVsvf9+hYAZRop9BsxddXOfvJVIpwC?= =?us-ascii?Q?XentDC7LmUfivyHjtFmeCyn/jmNQuOXby2lTkdX1GI5bPb4QD+yH6pYRPjD9?= =?us-ascii?Q?bVZRbLwAonH2gfvAlMSDhALEBVsVc31UzR8hAl4nILwz+I/Mm1hl4cw8py2L?= =?us-ascii?Q?pdDcCvM8dPzLvyVD2aznpHJDW0EUZWJ7Lmw722eTl78h4aZFlTjEYGbsM6yM?= =?us-ascii?Q?XdNn0AVVyBCQI8L6WCi1w6Umn82aWJ7+aT9aDb6uJMDJ1VHnylw8EflPGA1F?= =?us-ascii?Q?bgxEvMmDA+vJS8LY9vl+RCMNd6nQH9GVlc/f7nVPgx7Le6HYz60b8eeLAix7?= =?us-ascii?Q?ivx0HVa7QZFGFmIjmUA056h8YcsmxoPKDsK+mXxAKO9ocHBtEpPg9B7rcUs4?= =?us-ascii?Q?gvvissa7/YozdJC2mrcCgwc3epsE79K7+Okry7KVAnWM1dnZYnLOxEhb5jQ1?= =?us-ascii?Q?UzsVWfcBeWD4Aaui4wmGWXgfEWosLU8ptuwdWZOMdMbOgMRVCe5BGBcwgKHK?= =?us-ascii?Q?JUqRb4qmW1m15lVYAjeH8+f/DL03Nf86AzbjFfjSI+nxcLr2w9W+QLSNlAos?= =?us-ascii?Q?1kqQ9+LOjDC9VRJEUX6Qk7UuG+/T6tQhemYrelH8?= Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-ExternalHop-MessageData-0: Q0lnxuCFvCEjBtO6cWg0k4bLzGWufmO6iaYZF0TupEFaG9EO3u6sqHt28ipJsmnfrPKkhooJ+J07hfrj1K8w0s3/vMl360BM6YahTEizUH+C1wIgH297aTsJ5IL/CrJipQ8WKUhfsJhMX/u4joJE8E+gWcHVjCRN7jRJ280l3W+YeTxCVj7XOBNxXy4NkSwamOTJSg2AWROOFr0Tx0aecRNvewPuJK9GMyoNvERXcglC3rM+V72Aa4oSzWul3tzJNR5butjDLH6WhPMVvkvReA3UA4Nte92aO9oLgmYtDQouh0Sy3MK9TsLYzcNBYqePfU3mpNJButXApxs7G8OMKs5HFO/tRR5tAT1k3Udn0siMAZhT9S3Z63G1ilZUoW+p/Y6TuNA+srCK7WuQ1x3UweRyS21j6af3RoispLyMEGa4B+apBJ9Q/jTMioB8bbJpk+60VD1/Ge5h5ueOvkyRSn+3IRhrUGcINaXvHzBXy+Vk4Aw71PqZXhlOodYbUev1ymB4B7CCllfuYNNVq/+jkBsD+vpzHdGLzKA3XkSn/3bwN11QmZU57jiyfqQK1pjWRxuPFIBK/IUaGDgsNngPBYVKYYo9Hkhg1E1JV+akz9vD9mRGSBBo+/25/2WmCau0YjHY+3LJtY2bW1e57f9oiap1D5JZbq4+PAuoiv09p+QJ7jH5lmpHSJoYscahbod60+3DEoAxW1KKMbMWMvk2eRKCwtXKJYKR06Rh71FmD3sp2kBzOi86mf75G+rJnsacycQRYgHd8tswpR2mHd9xYgedQwWfrYjlHchSAFOsDfdJ6XaMogcoOEIi1Y6SQZQ2 X-OriginatorOrg: oracle.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SJ0PR10MB5488.namprd10.prod.outlook.com X-MS-Exchange-CrossTenant-Network-Message-Id: 1b7bcfdc-632d-4905-27a8-08db33c59680 X-MS-Exchange-CrossTenant-originalarrivaltime: 02 Apr 2023 21:59:52.9509 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 4e2c6054-71cb-48f1-bd6c-3a9705aca71b X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: iyv/M9Sz7yzQ3lbOP0LhqC8FZo5Fdjh88tCQKHLOqK/4/nuWRnK97hnx96xOW4sUpR6NcGs/GahhcaVoNeaDMg== X-MS-Exchange-Transport-CrossTenantHeadersStamped: PH7PR10MB7696 X-Proofpoint-Virus-Version: vendor=baseguard engine=ICAP:2.0.254,Aquarius:18.0.942,Hydra:6.0.573,FMLib:17.11.170.22 definitions=2023-03-31_07,2023-03-31_01,2023-02-09_01 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 spamscore=0 mlxscore=0 malwarescore=0 mlxlogscore=999 adultscore=0 phishscore=0 suspectscore=0 bulkscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2303200000 definitions=main-2304020185 X-Proofpoint-GUID: nY583QalvD92WTu08GeM6BNa3diAJIGS X-Proofpoint-ORIG-GUID: nY583QalvD92WTu08GeM6BNa3diAJIGS X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 62621 Cc: "62621@debbugs.gnu.org" <62621@debbugs.gnu.org> X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > > However, uniquify is currently not customizable in this way. Could we > > add support for including additional attributes into the things which > > uniquify will use? Then I could add project-name as one of those > > attributes in my configuration, and I'd be happy. > > > > I would be happy to implement this feature in uniquify myself, if this > > is an interesting feature for upstream. >=20 > Sounds like a useful feature indeed, provided that the customization > will allow more or less arbitrary uniquification, not just by project > names. Also, please keep in mind that a single project could have > files named the same in different directories. +1. _____ Off the top of my head (not thought through)... User-definable, e.g., based on some defcustom choice combinations; i.e., different name pieces that can contribute to the overall name. The current behavior of using the dir-name pieces could be one such choice, which could then be combined with other choices. =20 `file-attributes' values (at least some of them) could also be candidates for such combinations. Or useful abbreviations of file-attribute values; e.g., use a relative last- number instead of a full last- value, to reflect just recency, not bothering about what the absolute values are. Ability to assign arbitrary labels (one or more "tags") to a given buffer would be good as another combining choice. In addition, as an alternative maybe a user-defined function value to compute the overall name. ____ Anyway, any enhancement at all that might be made wrt the naming would be welcome. From debbugs-submit-bounces@debbugs.gnu.org Fri Apr 14 12:08:44 2023 Received: (at 62621) by debbugs.gnu.org; 14 Apr 2023 16:08:44 +0000 Received: from localhost ([127.0.0.1]:47400 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnLye-0008OK-1e for submit@debbugs.gnu.org; Fri, 14 Apr 2023 12:08:44 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:39787) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1pnLyc-0008O1-M3 for 62621@debbugs.gnu.org; Fri, 14 Apr 2023 12:08:43 -0400 From: Spencer Baugh To: 62621@debbugs.gnu.org Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: (Spencer Baugh's message of "Sun, 02 Apr 2023 13:37:36 -0400") References: Date: Fri, 14 Apr 2023 12:08:37 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) FWIW, here is the (unpolished) patch I'm currently using. This is correct but it's not what I think the final form of this should look like. For better or for worse, I have now Deeply Understood uniquify, and I have various ideas for things to do to fix bugs in it and simplify it and add new features... see bug#62732 for my first step. (Which adds tests, even!) After some of those, then I can do this bug. One sneak peak of a feature which I think I can manage to add with some improvements to uniquify.el: a user customization which causes a new behavior in read-buffer, so that when it's running on a subset of buffers (by passing PREDICATE), it reads buffer names which are only uniquified among that subset. (So the buffer names will be shorter when that doesn't cause ambiguity). This would be really cool for project-switch-to-buffer, so that if you have two projects working on the same source repo with the same files open, you don't have to see the extra uniquify cruft at the start of the buffer name when you just want to look at buffers in a single project. diff --git a/lisp/uniquify.el b/lisp/uniquify.el index dee9ecba2ea..53b39920820 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -210,8 +210,8 @@ uniquify-rationalize-file-buffer-names (with-current-buffer newbuf (setq uniquify-managed nil)) (when dirname (setq dirname (expand-file-name (directory-file-name dirname))) - (let ((fix-list (list (uniquify-make-item base dirname newbuf - nil dirname))) + (let ((fix-list (list (let ((dirname (uniquify-buffer-file-name newbuf dirname))) + (uniquify-make-item base dirname newbuf nil dirname)))) items) (dolist (buffer (buffer-list)) (when (and (not (and uniquify-ignore-buffers-re @@ -258,20 +258,26 @@ uniquify-rationalize-file-buffer-names (uniquify-rationalize fix-list)))) ;; uniquify's version of buffer-file-name; result never contains trailing slash -(defun uniquify-buffer-file-name (buffer) +(require 'project) +(defun uniquify-buffer-file-name (buffer &optional dirname) "Return name of directory, file BUFFER is visiting, or nil if none. Works on ordinary file-visiting buffers and buffers whose mode is mentioned in `uniquify-list-buffers-directory-modes', otherwise returns nil." (with-current-buffer buffer - (let ((filename - (or buffer-file-name - (if (memq major-mode uniquify-list-buffers-directory-modes) - list-buffers-directory)))) - (when filename - (directory-file-name - (file-name-directory - (expand-file-name - (directory-file-name filename)))))))) + (let* ((filename + (or buffer-file-name + (if (memq major-mode uniquify-list-buffers-directory-modes) + list-buffers-directory))) + (dir (or dirname + (directory-file-name + (file-name-directory + (expand-file-name + (directory-file-name filename))))))) + (if-let (pr (project-current nil dir)) + (let* ((pr-dir (project-root pr)) + (pr-rel (file-relative-name dir pr-dir))) + (file-name-concat pr-dir (project-name pr) pr-rel)) + dir)))) (defun uniquify-rerationalize-w/o-cb (fix-list) "Re-rationalize the buffers in FIX-LIST, but ignoring `current-buffer'." From debbugs-submit-bounces@debbugs.gnu.org Thu Jul 13 18:52:02 2023 Received: (at 62621) by debbugs.gnu.org; 13 Jul 2023 22:52:02 +0000 Received: from localhost ([127.0.0.1]:41031 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK5AH-0001Pn-HH for submit@debbugs.gnu.org; Thu, 13 Jul 2023 18:52:02 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:22566) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qK5AF-0001PZ-39 for 62621@debbugs.gnu.org; Thu, 13 Jul 2023 18:52:00 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: cc:content-type:from:subject:to; s=s1; bh=j9W7o9LoxT49Sd6PfOT/HEtNW2deZHAoNgaMzf+YK0Y=; b=THb/gvyy10Jy0wY7765EfBVTU+0RAG7j+4AbQ+j/IJ27/C7VYSHrWSWFSAT7rVL9Qg74 8wpQu1IqrYQHtYrP/ssigLM4tX/CKq0dOAfyUT9Byr0nJFnWl+PlS1dLYcjwDjRZa9+leg Hn88sji/M2PtKkW9YaH2nJaJTQt4XAoRamybNH4kAgZ7VSgYx40GqVidKr4kReQOLG4NqO Jnbx+e4KCgaysrpk1I6bKyZlzigS9Mkr++Tp7tK6Y4NgZG58oDqzsKVhZefz6yXDJ6A5cQ OT/LxAJKPISKkLp0ShwdN3Wx9knxzdHWPdWmHYKySNhPuikSd2w/PYtRADd7TKFA== Received: by filterdrecv-66949dbc98-kr5j5 with SMTP id filterdrecv-66949dbc98-kr5j5-1-64B08009-11 2023-07-13 22:51:53.146931397 +0000 UTC m=+5526724.228198610 Received: from earth.catern.com (unknown) by geopod-ismtpd-6 (SG) with ESMTP id tIPr5OszTqObLDs9XZG2gg Thu, 13 Jul 2023 22:51:53.079 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=janestreet.com Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id B02446251B; Thu, 13 Jul 2023 18:51:52 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: (Spencer Baugh's message of "Sun, 02 Apr 2023 13:37:36 -0400") References: Date: Thu, 13 Jul 2023 22:51:53 +0000 (UTC) Message-ID: <87bkgfjugn.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbKpzxVmZqFHjWqdI9nIX+?= =?us-ascii?Q?wIEy5NAo8tkwAYZY9kBO95Wd7d+MRGz1tTbFtSM?= =?us-ascii?Q?sylqri6SXjRYlI6vumQo29CAk7kuF0LFLwuqj7r?= =?us-ascii?Q?HOEhExBLvnWyudMygC4UW3uXc0dBhZDyP7uSiDz?= =?us-ascii?Q?NZ51V=2FFN4lDji8=2F5GoDfVTvqIKVrDgW1wgQ=3D=3D?= To: Spencer Baugh X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit OK, after resolving bug#62732, now at last my nice and short patch for this feature. I've thought quite a bit about how to make this configurable, and I think just letting people write their own arbitrary transformation functions, as I do in this patch, is what we should provide. Making things any more modular is fairly difficult. Packages can come along and provide other fancy functions if they like. --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Support-transforming-the-dirname-used-by-uniquify.patch >From 5e6260951b31fbd9da826cc2ff56bfbecdbbe7eb Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sun, 9 Jul 2023 22:21:03 -0400 Subject: [PATCH] Support transforming the dirname used by uniquify By transforming the dirname, we can add additional information to use during uniquifying. A basic one: uniquifying buffer names based on the project name. * lisp/progmodes/project.el (project-uniquify-dirname-transform): Add. * lisp/uniquify.el (uniquify-dirname-transform-default) (uniquify-dirname-transform): Add. (bug#62621) (uniquify-rationalize-file-buffer-names, uniquify-buffer-file-name): Use uniquify-dirname-transform. * test/lisp/uniquify-tests.el (uniquify-home, uniquify-project-transform): Add tests. --- lisp/progmodes/project.el | 12 ++++++++++++ lisp/uniquify.el | 22 +++++++++++++++++----- test/lisp/uniquify-tests.el | 33 +++++++++++++++++++++++++++++++++ 3 files changed, 62 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index 03ed966cc45..11fa93fb70d 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1887,5 +1887,17 @@ project-switch-project (let ((project-current-directory-override dir)) (call-interactively command)))) +;;;###autoload +(defun project-uniquify-dirname-transform (dirname) + "Include `project-name' in DIRNAME if in a project." + (if-let (proj (project-current nil dirname)) + (let ((root (project-root proj))) + (expand-file-name + (file-name-concat + (file-name-directory root) + (project-name proj) + (file-relative-name dirname root)))) + dirname)) + (provide 'project) ;;; project.el ends here diff --git a/lisp/uniquify.el b/lisp/uniquify.el index d1ca455b673..bd49346da45 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -168,6 +168,16 @@ uniquify-list-buffers-directory-modes That means that when `buffer-file-name' is set to nil, `list-buffers-directory' contains the name of the directory which the buffer is visiting.") +(defcustom uniquify-dirname-transform #'identity + "A function to transform the dirname used to uniquify a buffer. + +It takes a single argument: the directory of the buffer. It +should return a string filename (which does not need to actually +exist in the filesystem) to use for uniquifying the buffer name." + :type '(choice (function-item :tag "Don't change the dirname" identity) + function) + :group 'uniquify) + ;;; Utilities ;; uniquify-fix-list data structure @@ -209,7 +219,8 @@ uniquify-rationalize-file-buffer-names ;; this buffer. (with-current-buffer newbuf (setq uniquify-managed nil)) (when dirname - (setq dirname (expand-file-name (directory-file-name dirname))) + (setq dirname (funcall uniquify-dirname-transform + (expand-file-name (directory-file-name dirname)))) (let ((fix-list (list (uniquify-make-item base dirname newbuf nil))) items) @@ -268,10 +279,11 @@ uniquify-buffer-file-name (if (memq major-mode uniquify-list-buffers-directory-modes) list-buffers-directory)))) (when filename - (directory-file-name - (file-name-directory - (expand-file-name - (directory-file-name filename)))))))) + (funcall uniquify-dirname-transform + (directory-file-name + (file-name-directory + (expand-file-name + (directory-file-name filename))))))))) (defun uniquify-rerationalize-w/o-cb (fix-list) "Re-rationalize the buffers in FIX-LIST, but ignoring `current-buffer'." diff --git a/test/lisp/uniquify-tests.el b/test/lisp/uniquify-tests.el index abd61fa3504..e533c4b644c 100644 --- a/test/lisp/uniquify-tests.el +++ b/test/lisp/uniquify-tests.el @@ -88,6 +88,21 @@ uniquify-dirs '("a/dir/" "b/dir/"))) (mapc #'kill-buffer bufs))))) +(ert-deftest uniquify-home () + "uniquify works, albeit confusingly, in the presence of directories named \"~\"" + (let (bufs) + (save-excursion + (push (find-file-noselect "~") bufs) + (push (find-file-noselect "./~") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("~" "~<>"))) + (push (find-file-noselect "~/foo") bufs) + (push (find-file-noselect "./~/foo") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("foo<~>" "foo" "~" "~<>"))) + (while bufs + (kill-buffer (pop bufs)))))) + (ert-deftest uniquify-rename-to-dir () "Giving a buffer a name which matches a directory doesn't rename the buffer" (let ((uniquify-buffer-name-style 'forward) @@ -125,5 +140,23 @@ uniquify-space-prefix (should (equal (buffer-name) "| foo")) (kill-buffer))) +(require 'project) +(ert-deftest uniquify-project-transform () + "`project-uniquify-dirname-transform' works" + (let ((uniquify-dirname-transform #'project-uniquify-dirname-transform) + (project-vc-name "foo1/bar") + bufs) + (save-excursion + (should (file-exists-p "../README")) + (push (find-file-noselect "../README") bufs) + (push (find-file-noselect "other/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README"))) + (push (find-file-noselect "foo2/bar/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README" "README"))) + (while bufs + (kill-buffer (pop bufs)))))) + (provide 'uniquify-tests) ;;; uniquify-tests.el ends here -- 2.41.0 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 02:29:31 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 06:29:31 +0000 Received: from localhost ([127.0.0.1]:41375 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKCJ1-0002N5-FQ for submit@debbugs.gnu.org; Fri, 14 Jul 2023 02:29:31 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41684) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKCIz-0002Mq-3Y for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 02:29:30 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKCIs-0006Wo-5V; Fri, 14 Jul 2023 02:29:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=NtVQudwRVoEpLCyfvNvMkTADGHZvg+NtmFAoLkgQaEU=; b=Hhb1QoTnCIFX 3d1qtEd1q1oZLghCUqdj3Yw71FBtJBnCjij6qrsWPBOFevy++13S4PAmOev8Y31ThM3odFN4a4r4q WAva/SQW/FcdeQQTcEyhTFkxuRRAKZXaJ19cUbt4xFuLMVgKxfwcKH3wPy7YdCjJhab/firNHmLMI ANbXeXzg1iJOJQSAAFS06PPOAUvLgr+Xrg/zim6GoXpO7ODI/9DrCAV8WmzkOjXTqU+QuQ5oGlhod RPZKihF0zJb7vbfSIaX9gVjoD7+OlIXRIQk5RCJ/m1aMQCQRL/JRVvtO3lXvrUGpYCOodQQYoAQKI zQCXxnamocZhV2jr5K73Sg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKCIr-00007v-Hp; Fri, 14 Jul 2023 02:29:21 -0400 Date: Fri, 14 Jul 2023 09:29:38 +0300 Message-Id: <83edlb3t0t.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <87bkgfjugn.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 62621@debbugs.gnu.org > From: sbaugh@catern.com > Date: Thu, 13 Jul 2023 22:51:53 +0000 (UTC) > > I've thought quite a bit about how to make this configurable, and I > think just letting people write their own arbitrary transformation > functions, as I do in this patch, is what we should provide. Making > things any more modular is fairly difficult. Packages can come along > and provide other fancy functions if they like. If there are a couple of simpler alternatives which could be offered via simple symbolic values, we should not force everyone to write functions, IMNSHO. IOW, we should NOT immediately generalize to functions only because such generalization could make sense in some use cases. Repeat after me: Use options whose values are functions are hard on our users, because they require them to be Lisp programmers. > +(defcustom uniquify-dirname-transform #'identity > + "A function to transform the dirname used to uniquify a buffer. "Function to transform buffer's `default-directory' for uniquifying its name." > +It takes a single argument: the directory of the buffer. It > +should return a string filename (which does not need to actually > +exist in the filesystem) to use for uniquifying the buffer name." > + :type '(choice (function-item :tag "Don't change the dirname" identity) > + function) > + :group 'uniquify) The :version tag is missing. Also, the doc string should state that the default is to use the buffer's default-directory without any transformations. It should also include a link to uniquify-buffer-file-name, so that users could consult the uniquify facilities if they need to. Thanks. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 07:28:21 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 11:28:21 +0000 Received: from localhost ([127.0.0.1]:41553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKGyD-0002U2-CL for submit@debbugs.gnu.org; Fri, 14 Jul 2023 07:28:21 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:24500) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKGyB-0002Tq-At for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 07:28:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=0NS7kmnE9Eh+LJQVcwdlt9eukrEWyeg9ocLimQut0zI=; b=fPABbRnrwHsMcJYpa0d8nlhh9QPeldXqnoVn5yw5tmlhHLSrsfPs+0UVHQxrM0aBNT1p A+zFSdeDwj9urnJ3+P1O7MGM+7yqrFXm3csjuF5Uj3BmU7tUtpBCelXAbGjZiAwdDCl0Nm QqEtBbV+oSb7pKv33uaYSolTzjUFvdFcTS1hvRr64fyOhkn03Tcx6TVt+4N19Z04EtYLiJ YtDeqfUvJdt/8pr0iQ1SBh0d13GbwquNnTe5EVWAFwCZB1jlVxfvBOa8yirJCTXQdfD7ko aLckrtwuNFTgUu2zyRg8GgYaKy1ZtFLbfZ4RHVDyUopTwY/vXMrsosF7k4iIZ4Hw== Received: by filterdrecv-66949dbc98-5ngqz with SMTP id filterdrecv-66949dbc98-5ngqz-1-64B1314D-3E 2023-07-14 11:28:13.806860986 +0000 UTC m=+5572100.012180766 Received: from earth.catern.com (unknown) by geopod-ismtpd-17 (SG) with ESMTP id 9WXds7hwQ-aTiMFr0xfMQQ Fri, 14 Jul 2023 11:28:13.723 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id 439B36015A; Fri, 14 Jul 2023 07:28:13 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <83edlb3t0t.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 09:29:38 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> Date: Fri, 14 Jul 2023 11:28:13 +0000 (UTC) Message-ID: <878rbika0i.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbKhmPFO2bOv8z2OPgy3wh?= =?us-ascii?Q?loo146+vvWaLq54tPmHwdGf99zgAk1uJvMxBd25?= =?us-ascii?Q?80QqjDosBa4+AaxSRMsFfrutsxxf3X7jCN+0m4v?= =?us-ascii?Q?WGznGSFnN0r5hdkgMQQUSqaN+B3txwLa+jCjaNU?= =?us-ascii?Q?dSGDE=2FbaCbFsaC6lsmd9gUiW9cGnTl8GUSw=3D=3D?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> Cc: 62621@debbugs.gnu.org >> From: sbaugh@catern.com >> Date: Thu, 13 Jul 2023 22:51:53 +0000 (UTC) >> >> I've thought quite a bit about how to make this configurable, and I >> think just letting people write their own arbitrary transformation >> functions, as I do in this patch, is what we should provide. Making >> things any more modular is fairly difficult. Packages can come along >> and provide other fancy functions if they like. > > If there are a couple of simpler alternatives which could be offered > via simple symbolic values, we should not force everyone to write > functions, IMNSHO. IOW, we should NOT immediately generalize to > functions only because such generalization could make sense in some > use cases. Repeat after me: Use options whose values are functions > are hard on our users, because they require them to be Lisp > programmers. I agree, and I'm happy to change it to use a simple symbolic value 'project instead for the transform I wrote, but I'm not sure how best to handle the dependencies: uniquify.el is in loadup.el, is it OK for it to rely on project-uniquify-dirname-transform being autoloaded? >> +(defcustom uniquify-dirname-transform #'identity >> + "A function to transform the dirname used to uniquify a buffer. > > "Function to transform buffer's `default-directory' for uniquifying its name." Unfortunately, this isn't quite right. uniquify never uses default-directory, counterintuitively - by default, it uses the directory of buffer-file-name, which can differ from default-directory. >> +It takes a single argument: the directory of the buffer. It >> +should return a string filename (which does not need to actually >> +exist in the filesystem) to use for uniquifying the buffer name." >> + :type '(choice (function-item :tag "Don't change the dirname" identity) >> + function) >> + :group 'uniquify) > > The :version tag is missing. > > Also, the doc string should state that the default is to use the > buffer's default-directory without any transformations. It should > also include a link to uniquify-buffer-file-name, so that users could > consult the uniquify facilities if they need to. Will include that in the next version. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 08:01:56 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 12:01:57 +0000 Received: from localhost ([127.0.0.1]:41569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHUf-0005sY-DG for submit@debbugs.gnu.org; Fri, 14 Jul 2023 08:01:56 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:57024) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHUc-0005sK-J2 for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 08:01:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKHUW-0005X9-GZ; Fri, 14 Jul 2023 08:01:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jQ0Sy2SrQS7Sql6G+kkdTihAvJzNmwaP4bYT7UHydqM=; b=b0gjNMXv1hn4 rBt8L+Q9axMpYncVspBKfRSE9ElbPw4ifGjuThYhXgF4wltV5Qp2AgkPgZBa68nsEik6EDX0kMZXj 4+xhFWg+MO19T92jw7IxFYyHYJccSo5BdXe3QWBl5MI2mzY5MPpFRMh5qCfePixCWLVm1vZ2CaNgh 19UKz9ykefaBfMQeQ75vtjRF6wkcMmRXKOtHoFhPrbgu4Q5PLXvGf9jxPTGwLTLnZRy8KUyhsSrRF /LIrbupm1sQS1f3E3plB7cux1jEhEar2zYGulafh3PyQ6y4JVGDSotKI443mp+clANnmQjya6pQM5 92olJhi+2zsDpr5Fb0uUWw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKHUR-0000GP-Mv; Fri, 14 Jul 2023 08:01:44 -0400 Date: Fri, 14 Jul 2023 15:01:58 +0300 Message-Id: <83h6q6g0qx.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <878rbika0i.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sbaugh@catern.com > Date: Fri, 14 Jul 2023 11:28:13 +0000 (UTC) > Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org > > Eli Zaretskii writes: > > > If there are a couple of simpler alternatives which could be offered > > via simple symbolic values, we should not force everyone to write > > functions, IMNSHO. IOW, we should NOT immediately generalize to > > functions only because such generalization could make sense in some > > use cases. Repeat after me: Use options whose values are functions > > are hard on our users, because they require them to be Lisp > > programmers. > > I agree, and I'm happy to change it to use a simple symbolic value > 'project instead for the transform I wrote, but I'm not sure how best to > handle the dependencies: uniquify.el is in loadup.el, is it OK for it to > rely on project-uniquify-dirname-transform being autoloaded? I don't understand the difficulty. If the function value could be defined in uniquify.el, why cannot a symbolic value be defined there? If the symbolic values are specific to project, simply let-bind uniquify-dirname-transform to the value of the appropriate project.el defcustom when project.el calls uniquify. > >> +(defcustom uniquify-dirname-transform #'identity > >> + "A function to transform the dirname used to uniquify a buffer. > > > > "Function to transform buffer's `default-directory' for uniquifying its name." > > Unfortunately, this isn't quite right. uniquify never uses > default-directory, counterintuitively - by default, it uses the > directory of buffer-file-name, which can differ from default-directory. That's a minor issue, just use "buffer's directory" instead. But I wonder why uniquify does something counterintuitive like that. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 08:20:09 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 12:20:09 +0000 Received: from localhost ([127.0.0.1]:41591 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHmL-0006T2-18 for submit@debbugs.gnu.org; Fri, 14 Jul 2023 08:20:09 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:54033) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHmJ-0006SW-Bh for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 08:20:08 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <83h6q6g0qx.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 15:01:58 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> Date: Fri, 14 Jul 2023 08:20:02 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: sbaugh@catern.com >> Date: Fri, 14 Jul 2023 11:28:13 +0000 (UTC) >> Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org >> >> Eli Zaretskii writes: >> >> > If there are a couple of simpler alternatives which could be offered >> > via simple symbolic values, we should not force everyone to write >> > functions, IMNSHO. IOW, we should NOT immediately generalize to >> > functions only because such generalization could make sense in some >> > use cases. Repeat after me: Use options whose values are functions >> > are hard on our users, because they require them to be Lisp >> > programmers. >> >> I agree, and I'm happy to change it to use a simple symbolic value >> 'project instead for the transform I wrote, but I'm not sure how best to >> handle the dependencies: uniquify.el is in loadup.el, is it OK for it to >> rely on project-uniquify-dirname-transform being autoloaded? > > I don't understand the difficulty. If the function value could be > defined in uniquify.el, why cannot a symbolic value be defined there? I don't understand your question :) Here's concretely the diff I would apply. This makes uniquify.el mention a function from project.el. Is that OK? diff --git a/lisp/uniquify.el b/lisp/uniquify.el index bd49346da45..4783830b184 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -168,14 +168,10 @@ uniquify-list-buffers-directory-modes That means that when `buffer-file-name' is set to nil, `list-buffers-directory' contains the name of the directory which the buffer is visiting.") -(defcustom uniquify-dirname-transform #'identity - "A function to transform the dirname used to uniquify a buffer. - -It takes a single argument: the directory of the buffer. It -should return a string filename (which does not need to actually -exist in the filesystem) to use for uniquifying the buffer name." - :type '(choice (function-item :tag "Don't change the dirname" identity) - function) +(defcustom uniquify-dirname-transform nil + "How to transform the dirname used to uniquify a buffer." + :type '(choice (const :tag "Don't change the dirname" nil) + (const :tag "Include project-name when uniquifying" 'project)) :group 'uniquify) ;;; Utilities @@ -279,11 +275,14 @@ uniquify-buffer-file-name (if (memq major-mode uniquify-list-buffers-directory-modes) list-buffers-directory)))) (when filename - (funcall uniquify-dirname-transform - (directory-file-name - (file-name-directory - (expand-file-name - (directory-file-name filename))))))))) + (funcall + (cond ((not uniquify-dirname-transform) #'identity) + ((eq uniquify-dirname-transform 'project) #'project-uniquify-dirname-transform) + (t (error "bad uniquify-dirname-transform: %s" uniquify-dirname-transform))) + (directory-file-name + (file-name-directory + (expand-file-name + (directory-file-name filename))))))))) (defun uniquify-rerationalize-w/o-cb (fix-list) "Re-rationalize the buffers in FIX-LIST, but ignoring `current-buffer'." > If the symbolic values are specific to project, simply let-bind > uniquify-dirname-transform to the value of the appropriate project.el > defcustom when project.el calls uniquify. These customizations are in effect all the time, not just when the user is calling a project.el command. e.g. rename-buffer triggers uniquify. >> >> +(defcustom uniquify-dirname-transform #'identity >> >> + "A function to transform the dirname used to uniquify a buffer. >> > >> > "Function to transform buffer's `default-directory' for uniquifying its name." >> >> Unfortunately, this isn't quite right. uniquify never uses >> default-directory, counterintuitively - by default, it uses the >> directory of buffer-file-name, which can differ from default-directory. > > That's a minor issue, just use "buffer's directory" instead. > > But I wonder why uniquify does something counterintuitive like that. I assume it's something like "default-directory changes (such as by M-x cd) shouldn't change the buffer name too". Although personally I would be totally fine with cd changing the buffer name... The fact that uniquify doesn't use default-directory also means it's unable to uniquify buffers which aren't visiting files, which can be annoying. For example, if uniquify used default-directory then it could uniquify *compilation* buffers for different projects, renaming them based on the directory. But because it can't, every package has to come up with their own special buffer-renaming scheme... include project.el. I could add support for making uniquify use default-directory instead, if that's interesting. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 08:28:52 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 12:28:52 +0000 Received: from localhost ([127.0.0.1]:41640 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHum-0006oB-4d for submit@debbugs.gnu.org; Fri, 14 Jul 2023 08:28:52 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:37220) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKHuj-0006nu-J9 for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 08:28:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKHud-0006P0-M9; Fri, 14 Jul 2023 08:28:43 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mNGyzjGbtwW2arPQpm30RipHjc4HmwG9xmPFNCXaGDU=; b=XvnZTsTpU9U5 +NF1jO/N4e2M5MIAaMOPbhKNafhcYyulPgmdmXlvH0S9fK/pQJE+EujI3agjZzmf8JcfdurHHgC25 phyq9JhsABcxhklfsofShnMC4UTNZt128bI8V4y/AI143KcMurxifQJRLT95uOzAA7y4lElcosToi SsElDT8Zh67pZOYNxzUG+unfe5hHRRxQ8vxEeWB485Ygk2EF/R6dItlj2GNyaTMwiMnBluQbGz633 EjBtXr8Od5zfqF2k++7CAvd6S4WijxpiHp1wwVDsFpZDIUK3GiFYHOpXWGaMS+QCqpLNdoDaWLVq1 VQre8qsN6wEpX5MWHTHmbA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKHud-0007D1-2d; Fri, 14 Jul 2023 08:28:43 -0400 Date: Fri, 14 Jul 2023 15:29:02 +0300 Message-Id: <83edlafzht.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Fri, 14 Jul 2023 08:20:02 -0400) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: sbaugh@catern.com, 62621@debbugs.gnu.org > Date: Fri, 14 Jul 2023 08:20:02 -0400 > > Eli Zaretskii writes: > > >> I agree, and I'm happy to change it to use a simple symbolic value > >> 'project instead for the transform I wrote, but I'm not sure how best to > >> handle the dependencies: uniquify.el is in loadup.el, is it OK for it to > >> rely on project-uniquify-dirname-transform being autoloaded? > > > > I don't understand the difficulty. If the function value could be > > defined in uniquify.el, why cannot a symbolic value be defined there? > > I don't understand your question :) > > Here's concretely the diff I would apply. This makes uniquify.el mention a > function from project.el. Is that OK? No. > > If the symbolic values are specific to project, simply let-bind > > uniquify-dirname-transform to the value of the appropriate project.el > > defcustom when project.el calls uniquify. > > These customizations are in effect all the time, not just when the user > is calling a project.el command. e.g. rename-buffer triggers uniquify. Then you can set the buffer-local value of uniquify-dirname-transform in the project.el buffers. Would that solve the problem? > >> Unfortunately, this isn't quite right. uniquify never uses > >> default-directory, counterintuitively - by default, it uses the > >> directory of buffer-file-name, which can differ from default-directory. > > > > That's a minor issue, just use "buffer's directory" instead. > > > > But I wonder why uniquify does something counterintuitive like that. > > I assume it's something like "default-directory changes (such as by M-x > cd) shouldn't change the buffer name too". default-directory of a file-visiting buffer doesn't change. > The fact that uniquify doesn't use default-directory also means it's > unable to uniquify buffers which aren't visiting files Exactly. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 08:46:08 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 12:46:08 +0000 Received: from localhost ([127.0.0.1]:41674 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKIBT-0007W0-MN for submit@debbugs.gnu.org; Fri, 14 Jul 2023 08:46:08 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:60969) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKIBR-0007VB-GO for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 08:46:06 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <83edlafzht.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 15:29:02 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> Date: Fri, 14 Jul 2023 08:46:00 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: sbaugh@catern.com, 62621@debbugs.gnu.org >> Date: Fri, 14 Jul 2023 08:20:02 -0400 >> >> Eli Zaretskii writes: >> >> >> I agree, and I'm happy to change it to use a simple symbolic value >> >> 'project instead for the transform I wrote, but I'm not sure how best to >> >> handle the dependencies: uniquify.el is in loadup.el, is it OK for it to >> >> rely on project-uniquify-dirname-transform being autoloaded? >> > >> > I don't understand the difficulty. If the function value could be >> > defined in uniquify.el, why cannot a symbolic value be defined there? >> >> I don't understand your question :) >> >> Here's concretely the diff I would apply. This makes uniquify.el mention a >> function from project.el. Is that OK? > > No. I figured. So now you see the issue with the symbolic approach. If the defcustom just takes a function, though, that solves the dependency issue. Because the user's config handles taking the function from project.el and putting it in the variable from uniquify.el. >> > If the symbolic values are specific to project, simply let-bind >> > uniquify-dirname-transform to the value of the appropriate project.el >> > defcustom when project.el calls uniquify. >> >> These customizations are in effect all the time, not just when the user >> is calling a project.el command. e.g. rename-buffer triggers uniquify. > > Then you can set the buffer-local value of uniquify-dirname-transform > in the project.el buffers. Would that solve the problem? The buffers it should affect are all file-visiting buffers. project.el doesn't currently have any code which runs for every new buffer. I guess we've considered adding that, but I'm not sure this is a good reason... >> >> Unfortunately, this isn't quite right. uniquify never uses >> >> default-directory, counterintuitively - by default, it uses the >> >> directory of buffer-file-name, which can differ from default-directory. >> > >> > That's a minor issue, just use "buffer's directory" instead. >> > >> > But I wonder why uniquify does something counterintuitive like that. >> >> I assume it's something like "default-directory changes (such as by M-x >> cd) shouldn't change the buffer name too". > > default-directory of a file-visiting buffer doesn't change. I don't think that's true. If I open ~/.emacs.d/init.el then (cd "/") then default-directory in that file-visiting buffer is / instead of ~/.emacs.d >> The fact that uniquify doesn't use default-directory also means it's >> unable to uniquify buffers which aren't visiting files > > Exactly. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 09:50:51 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 13:50:51 +0000 Received: from localhost ([127.0.0.1]:41744 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJC7-0001Wl-5m for submit@debbugs.gnu.org; Fri, 14 Jul 2023 09:50:51 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33168) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJC4-0001WP-Nq for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 09:50:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKJBy-0002dA-TT; Fri, 14 Jul 2023 09:50:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=wTNRDFtYiyiacBB5//l7GcCUk5uof3W+PN+b2dXwJhE=; b=YDqA5oHbp+7b VbUrUN9q+FSi7hX/V8iK8+7heqcupoFIxTIdsSxzU7eSm2h9NgR+lS/wb659ztcI7tXGIQtDFLAs0 Gulm47Y849keSGFdVwTLebpF9OHR7xLKGe/fHpctRlP6vOgurkvxgHH69Iv3XCKZFhkT4iTx4kUzC PojfHiv81abcn1hzjVx7uRw6Qz+VB6U1XWkXFTbuFHKYANqMfA26Ul/eh/13yMQM+QnpWXQuoSA4y G6vIPKZd9ccOvZtnv+w+6f0Gg4U3+NJ8ICu12Eyz+19oDsA8hXbHz6fP2s3nRZsqPQRmGWBoKqQe0 G4zMwPFFdArY2QcoJhrNLg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKJBy-000819-DS; Fri, 14 Jul 2023 09:50:42 -0400 Date: Fri, 14 Jul 2023 16:51:01 +0300 Message-Id: <83bkgefvp6.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Fri, 14 Jul 2023 08:46:00 -0400) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: sbaugh@catern.com, 62621@debbugs.gnu.org > Date: Fri, 14 Jul 2023 08:46:00 -0400 > > > Eli Zaretskii writes: > > >> Here's concretely the diff I would apply. This makes uniquify.el mention a > >> function from project.el. Is that OK? > > > > No. > > I figured. So now you see the issue with the symbolic approach. No, I don't. Not a significant problem, anyway, and not why it's different from using a function. > If the defcustom just takes a function, though, that solves the > dependency issue. Because the user's config handles taking the function > from project.el and putting it in the variable from uniquify.el. Ease of implementation is an important factor, but the ease of using Emacs takes precedence. So saying that some implementation alternative should be taken only because it is easier is not a winning argument. And I don't really understand how this will work in practice: if the user-defined function is supposed to be in effect only for buffers under project.el, how is this different from using symbols? > >> > If the symbolic values are specific to project, simply let-bind > >> > uniquify-dirname-transform to the value of the appropriate project.el > >> > defcustom when project.el calls uniquify. > >> > >> These customizations are in effect all the time, not just when the user > >> is calling a project.el command. e.g. rename-buffer triggers uniquify. > > > > Then you can set the buffer-local value of uniquify-dirname-transform > > in the project.el buffers. Would that solve the problem? > > The buffers it should affect are all file-visiting buffers. project.el > doesn't currently have any code which runs for every new buffer. I > guess we've considered adding that, but I'm not sure this is a good > reason... I'm sure this can be resolved, quite easily, actually. So I don't think I understand what you are trying to say here. > > default-directory of a file-visiting buffer doesn't change. > > I don't think that's true. If I open ~/.emacs.d/init.el then (cd "/") > then default-directory in that file-visiting buffer is / instead of > ~/.emacs.d You can shoot yourself in the foot if you like, but why would you? Anyway, are we still trying to reach some goal, or are we just trying to counter each other's arguments? From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 10:14:48 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 14:14:48 +0000 Received: from localhost ([127.0.0.1]:43128 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJZH-0002jz-L3 for submit@debbugs.gnu.org; Fri, 14 Jul 2023 10:14:48 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:46139) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKJZF-0002jh-7H for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 10:14:45 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <83bkgefvp6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 16:51:01 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <83bkgefvp6.fsf@gnu.org> Date: Fri, 14 Jul 2023 10:14:39 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: sbaugh@catern.com, 62621@debbugs.gnu.org >> Date: Fri, 14 Jul 2023 08:46:00 -0400 >>=20 >>=20 >> Eli Zaretskii writes: >>=20 >> >> Here's concretely the diff I would apply. This makes uniquify.el men= tion a >> >> function from project.el. Is that OK? >> > >> > No. >>=20 >> I figured. So now you see the issue with the symbolic approach. > > No, I don't. Not a significant problem, anyway, and not why it's > different from using a function. > >> If the defcustom just takes a function, though, that solves the >> dependency issue. Because the user's config handles taking the function >> from project.el and putting it in the variable from uniquify.el. > > Ease of implementation is an important factor, but the ease of using > Emacs takes precedence. So saying that some implementation > alternative should be taken only because it is easier is not a winning > argument. I agree. > And I don't really understand how this will work in practice: if the > user-defined function is supposed to be in effect only for buffers > under project.el, The transform is supposed to be in effect for all buffers, and internally it runs some code to decide whether to change the buffer name. > how is this different from using symbols? I can't contrast that to "using symbols" because I just don't understand what you mean by "using symbols". Is the diff I posted what you mean by "using symbols", or did you mean something else? >> >> > If the symbolic values are specific to project, simply let-bind >> >> > uniquify-dirname-transform to the value of the appropriate project.= el >> >> > defcustom when project.el calls uniquify. >> >>=20 >> >> These customizations are in effect all the time, not just when the us= er >> >> is calling a project.el command. e.g. rename-buffer triggers uniquif= y. >> > >> > Then you can set the buffer-local value of uniquify-dirname-transform >> > in the project.el buffers. Would that solve the problem? >>=20 >> The buffers it should affect are all file-visiting buffers. project.el >> doesn't currently have any code which runs for every new buffer. I >> guess we've considered adding that, but I'm not sure this is a good >> reason... > > I'm sure this can be resolved, quite easily, actually. So I don't > think I understand what you are trying to say here. > >> > default-directory of a file-visiting buffer doesn't change. >>=20 >> I don't think that's true. If I open ~/.emacs.d/init.el then (cd "/") >> then default-directory in that file-visiting buffer is / instead of >> ~/.emacs.d > > You can shoot yourself in the foot if you like, but why would you? I agree this is fairly useless but (info "(emacs) File Names") at least mentions using M-x cd in the context of file-visiting buffers: When you visit a file, Emacs sets =E2=80=98default-directory=E2=80=99 in= the visiting buffer to the directory of its file. When you create a new buffer that is not visiting a file, via a command like =E2=80=98C-x b=E2=80=99, its def= ault directory is usually copied from the buffer that was current at the time (*note Select Buffer::). You can use the command =E2=80=98M-x pwd=E2=80=99= to see the value of =E2=80=98default-directory=E2=80=99 in the current buffer. The co= mmand =E2=80=98M-x cd=E2=80=99 prompts for a directory=E2=80=99s name, and sets the buffer=E2= =80=99s =E2=80=98default-directory=E2=80=99 to that directory (doing this does not = change the buffer=E2=80=99s file name, if any). Nevertheless, I would be happy to make uniquify use default-directory instead, it will change how this behaves but it's probably OK. I can do that in a separate bug. > Anyway, are we still trying to reach some goal, or are we just trying > to counter each other's arguments? I'm not trying to counter your arguments, I just don't understand what you mean by "using symbols". I'm happy to have the configuration be symbol-based but you said "No." to the approach I posted and I don't know what other approach you are envisioning. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 12:44:44 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 16:44:44 +0000 Received: from localhost ([127.0.0.1]:43354 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKLuO-0006sn-JO for submit@debbugs.gnu.org; Fri, 14 Jul 2023 12:44:44 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:44285) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKLuN-0006sY-4I for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 12:44:43 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id CD19020003; Fri, 14 Jul 2023 16:44:35 +0000 (UTC) From: Juri Linkov To: Spencer Baugh Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: (Spencer Baugh's message of "Fri, 14 Jul 2023 08:20:02 -0400") Organization: LINKOV.NET References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> Date: Fri, 14 Jul 2023 19:31:23 +0300 Message-ID: <86bkgetqf0.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, Eli Zaretskii , 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > The fact that uniquify doesn't use default-directory also means it's > unable to uniquify buffers which aren't visiting files, which can be > annoying. For example, if uniquify used default-directory then it could > uniquify *compilation* buffers for different projects, renaming them > based on the directory. But because it can't, every package has to come > up with their own special buffer-renaming scheme... include project.el. Why couldn't uniquify use default-directory? It would be nice to have such buffer names based on default-directory: *compilation* *compilation* From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 13:30:41 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 17:30:41 +0000 Received: from localhost ([127.0.0.1]:43399 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKMcq-00089f-Ol for submit@debbugs.gnu.org; Fri, 14 Jul 2023 13:30:41 -0400 Received: from s.wrqvwxzv.outbound-mail.sendgrid.net ([149.72.154.232]:42120) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKMcm-00089P-W1 for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 13:30:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=subject:in-reply-to:from:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=he/8hjQflZuetn/9ILdeKNorjOOFHviJaQgtCigCOKo=; b=LWYhGRfpAGVJh6RHmii/SCxwyWYUHmj68f8iLvbnovB8g0eFW9lmJxmVrFA2afWG7IkS onATuBjOhQxFraPZLkcNKxeCKUi0qNoWJNWFN7kYmDgNkuWjM+4PM1GmnA0ZM9elOVHDse tvCaK9+RwSE6/LF0ntUErzulAHg4IetxxeS3RFEuswUg62N1I5TeDHeK5vLSZDykMhk++H jMTktkRkDHSruli26aA1cpVjtQcDTxztiIW7fKICUjdZXljf2AJcE5h+HK2+VA861R15vA 7ES+GXOaQA5czSN8KCDSX88zp/oeA24DTw1LREbEkeMVJdHWZHqXlYUP4/h8YyXA== Received: by filterdrecv-d7bbbc8bf-pmdv4 with SMTP id filterdrecv-d7bbbc8bf-pmdv4-1-64B18637-4F 2023-07-14 17:30:31.283571712 +0000 UTC m=+5593837.780735373 Received: from earth.catern.com (unknown) by geopod-ismtpd-0 (SG) with ESMTP id OEELLXARQc2X3tHEkVPuSw Fri, 14 Jul 2023 17:30:31.243 +0000 (UTC) Date: Fri, 14 Jul 2023 17:30:31 +0000 (UTC) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Message-ID: <5007b602-5827-40ae-a7a8-e9394cdc4155@email.android.com> X-Android-Message-ID: <5007b602-5827-40ae-a7a8-e9394cdc4155@email.android.com> In-Reply-To: <86bkgetqf0.fsf@mail.linkov.net> From: Spencer Baugh Importance: Normal X-Priority: 3 X-MSMail-Priority: Normal MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?GW3oCMoYnalRiojMOuLzE6x2H5kORXvlCdz1UwQVRMVT4fbh9ODEfCogOe74cO?= =?us-ascii?Q?rI4e0V+MFZgakz9Re5a6=2FCgmMCNZrHG0uP5B=2F0M?= =?us-ascii?Q?CwKvTR6MpOTJ1qXxHd7FE6Mru7FTdQzN1vZFq9U?= =?us-ascii?Q?ik76x9S50KH1F9j+aV=2FEDgWLJl5NT7zIiQQ06Ft?= =?us-ascii?Q?QKnkhr2sGdAiNHdL7+nfDAVBsXDripd4RJtEuvt?= =?us-ascii?Q?5fKcezYUN9pnUZUtPgVv9BtjyJPFoMcO18ZSiN?= To: Juri Linkov X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/html; charset=us-ascii Content-Transfer-Encoding: base64 X-Spam-Score: 1.7 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: On Jul 14, 2023 12:31, Juri Linkov wrote: > The fact that uniquify doesn't use default-directory also means it's > unable to uniquify buffers which aren't visiting files, which can be > annoying. For example, if uniquify used default-director [...] Content analysis details: (1.7 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [149.72.154.232 listed in wl.mailspike.net] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.1 MIME_HTML_ONLY BODY: Message only has text/html MIME parts 0.0 HTML_MESSAGE BODY: HTML included in message 0.0 MIME_BASE64_TEXT RAW: Message text disguised using base64 encoding 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders 0.6 HTML_MIME_NO_HTML_TAG HTML-only message, but there is no HTML tag -0.0 T_SCC_BODY_TEXT_LINE No description available. 1.0 MALF_HTML_B64 Malformatted base64-encoded HTML content X-Debbugs-Envelope-To: 62621 Cc: Spencer Baugh , Eli Zaretskii , 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.7 (/) PGRpdiBkaXI9J2F1dG8nPjxkaXY+PGJyPjxkaXYgY2xhc3M9ImdtYWlsX2V4dHJhIj48YnI+PGRp diBjbGFzcz0iZ21haWxfcXVvdGUiPk9uIEp1bCAxNCwgMjAyMyAxMjozMSwgSnVyaSBMaW5rb3Yg Jmx0O2p1cmlAbGlua292Lm5ldCZndDsgd3JvdGU6PGJyIHR5cGU9ImF0dHJpYnV0aW9uIj48Ymxv Y2txdW90ZSBjbGFzcz0icXVvdGUiIHN0eWxlPSJtYXJnaW46MCAwIDAgLjhleDtib3JkZXItbGVm dDoxcHggI2NjYyBzb2xpZDtwYWRkaW5nLWxlZnQ6MWV4Ij48cCBkaXI9Imx0ciI+Jmd0OyBUaGUg ZmFjdCB0aGF0IHVuaXF1aWZ5IGRvZXNuJ3QgdXNlIGRlZmF1bHQtZGlyZWN0b3J5IGFsc28gbWVh bnMgaXQncwo8YnI+CiZndDsgdW5hYmxlIHRvIHVuaXF1aWZ5IGJ1ZmZlcnMgd2hpY2ggYXJlbid0 IHZpc2l0aW5nIGZpbGVzLCB3aGljaCBjYW4gYmUKPGJyPgomZ3Q7IGFubm95aW5nLiZuYnNwOyBG b3IgZXhhbXBsZSwgaWYgdW5pcXVpZnkgdXNlZCBkZWZhdWx0LWRpcmVjdG9yeSB0aGVuIGl0IGNv dWxkCjxicj4KJmd0OyB1bmlxdWlmeSAqY29tcGlsYXRpb24qIGJ1ZmZlcnMgZm9yIGRpZmZlcmVu dCBwcm9qZWN0cywgcmVuYW1pbmcgdGhlbQo8YnI+CiZndDsgYmFzZWQgb24gdGhlIGRpcmVjdG9y eS4mbmJzcDsgQnV0IGJlY2F1c2UgaXQgY2FuJ3QsIGV2ZXJ5IHBhY2thZ2UgaGFzIHRvIGNvbWUK PGJyPgomZ3Q7IHVwIHdpdGggdGhlaXIgb3duIHNwZWNpYWwgYnVmZmVyLXJlbmFtaW5nIHNjaGVt ZS4uLiBpbmNsdWRlIHByb2plY3QuZWwuCjxicj4KCjxicj4KV2h5IGNvdWxkbid0IHVuaXF1aWZ5 IHVzZSBkZWZhdWx0LWRpcmVjdG9yeT8mbmJzcDsgSXQgd291bGQgYmUgbmljZSB0byBoYXZlCjxi cj4Kc3VjaCBidWZmZXIgbmFtZXMgYmFzZWQgb24gZGVmYXVsdC1kaXJlY3Rvcnk6Cjxicj4KCjxi cj4KJm5ic3A7ICpjb21waWxhdGlvbiombHQ7cHJvamVjdC0xJmd0Owo8YnI+CiZuYnNwOyAqY29t cGlsYXRpb24qJmx0O3Byb2plY3QtMiZndDs8L3A+PC9ibG9ja3F1b3RlPjwvZGl2PjwvZGl2Pjwv ZGl2PjxkaXYgZGlyPSJhdXRvIj5JJ2xsIGdpdmUgaXQgYSB0cnkgc29vbiwgdGhhdCB3b3VsZCBp bmRlZWQgYmUgdmVyeSBuaWNlLjwvZGl2PjxkaXYgZGlyPSJhdXRvIj48ZGl2IGNsYXNzPSJnbWFp bF9leHRyYSI+PGRpdiBjbGFzcz0iZ21haWxfcXVvdGUiPjxibG9ja3F1b3RlIGNsYXNzPSJxdW90 ZSIgc3R5bGU9Im1hcmdpbjowIDAgMCAuOGV4O2JvcmRlci1sZWZ0OjFweCAjY2NjIHNvbGlkO3Bh ZGRpbmctbGVmdDoxZXgiPjxwIGRpcj0ibHRyIj4KPGJyPgo8L3A+CjwvYmxvY2txdW90ZT48L2Rp dj48YnI+PC9kaXY+PC9kaXY+PC9kaXY+ From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 15:10:12 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 19:10:12 +0000 Received: from localhost ([127.0.0.1]:43528 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKOB9-0002KN-R6 for submit@debbugs.gnu.org; Fri, 14 Jul 2023 15:10:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:56902) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKOB8-0002K8-1j for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 15:10:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKOB2-0006Id-Jt; Fri, 14 Jul 2023 15:10:04 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=CQVfheXo1sgKiuLxR0Wga2vPvPtbRkPCqLNzCjBzOe0=; b=BEDEYBtz6tCk BGLcerxAEp9f5ixGTQcwq1jLV7j1M2mg8T3M838rAHbUH6GF5dFb27Q8jF6AjS0ZLheOaZmS+yQjb alJDuFUyvmzE38rIMboDX1+J1hpUPJxndL4bNRVw8eh9lphD2PHj8VMPzFHwb3JFbMmgNqEkCHYaf xYX87eJ17GdPAyjSOpMPwsziClFifXkhs5wljcm89GlNrxxiLc9aRrYTzTUlriPN0CCqYCbsNWUPb 1KF/AYzV3+ACBXegn8H6SGQiMjvUuYyU948aUI/azxTZMWqgc02PcK25fmKsUyBhl05wfJ6w0icKL GJfHcuo0uA6dTdJfg71gpw==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKOB2-0007Mf-3k; Fri, 14 Jul 2023 15:10:04 -0400 Date: Fri, 14 Jul 2023 22:10:24 +0300 Message-Id: <83r0pae2cf.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Fri, 14 Jul 2023 10:14:39 -0400) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <83bkgefvp6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: sbaugh@catern.com, 62621@debbugs.gnu.org > Date: Fri, 14 Jul 2023 10:14:39 -0400 > > Eli Zaretskii writes: > > > And I don't really understand how this will work in practice: if the > > user-defined function is supposed to be in effect only for buffers > > under project.el, > > The transform is supposed to be in effect for all buffers, and > internally it runs some code to decide whether to change the buffer > name. Still unclear why you thought functions can do what other values cannot. > > how is this different from using symbols? > > I can't contrast that to "using symbols" because I just don't understand > what you mean by "using symbols". It means the defcustom's value is a symbol, like 'numbered or 'append-directory, not a function. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 14 15:15:58 2023 Received: (at 62621) by debbugs.gnu.org; 14 Jul 2023 19:15:58 +0000 Received: from localhost ([127.0.0.1]:43533 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKOGj-0002Sr-LS for submit@debbugs.gnu.org; Fri, 14 Jul 2023 15:15:58 -0400 Received: from s.wrqvtbkv.outbound-mail.sendgrid.net ([149.72.123.24]:26828) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKOGi-0002Sb-3y for 62621@debbugs.gnu.org; Fri, 14 Jul 2023 15:15:56 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=catern.com; h=from:subject:in-reply-to:references:mime-version:to:cc:content-type: content-transfer-encoding:cc:content-type:from:subject:to; s=s1; bh=Es0R5G0nZ13bvJb6x8M4CY0JUAUrjQuLRl+GKVCRIN0=; b=0JYoheiTnVGVRM+Rt1u/kulWKxjlveA/jIHwcp8YvZAfKSUwyf9QRZvhUfg4bU/s2KV5 mWNSZcPCuZ+MQElNUbSmARFUR5sjGoIIBeGDThW0mbUyF0HeZFB75ar1C2146LqTVYjkLR t6jOWy88aOiD1PTfNbj4qNiLI71/2c9wFuC4gayl9O8LJqGd6UA6hF2L9O8KX0xO62nBQG HKSKPwz1DUcUEHby3IymAkBdx4rPlGr1/mqK7b2+qzu1vvXDI1ZJCf+VDX9J/GZQsxR4Y6 goUsRL+wIdSVFaFh8ZRNvcRCZoKVxBQEt47nBjM2GgSz8SQ0tJruJ42JUd9JdivA== Received: by filterdrecv-77869f68cc-qgx7h with SMTP id filterdrecv-77869f68cc-qgx7h-1-64B19EE6-1D 2023-07-14 19:15:50.333340867 +0000 UTC m=+5600378.515587964 Received: from earth.catern.com (unknown) by geopod-ismtpd-34 (SG) with ESMTP id a0CanELaQcubGAHYZZDHdQ Fri, 14 Jul 2023 19:15:50.242 +0000 (UTC) X-Comment: SPF check N/A for local connections - client-ip=::1; helo=localhost; envelope-from=sbaugh@catern.com; receiver=gnu.org Received: from localhost (localhost [IPv6:::1]) by earth.catern.com (Postfix) with ESMTPSA id BA0E76015A; Fri, 14 Jul 2023 15:15:49 -0400 (EDT) From: sbaugh@catern.com Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <83r0pae2cf.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 14 Jul 2023 22:10:24 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <83bkgefvp6.fsf@gnu.org> <83r0pae2cf.fsf@gnu.org> Date: Fri, 14 Jul 2023 19:15:50 +0000 (UTC) Message-ID: <875y6mjod6.fsf@catern.com> User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 X-SG-EID: =?us-ascii?Q?ZgbRq7gjGrt0q=2FPjvxk7wM0yQFRdOkTJAtEbkjCkHbJoc2ZEPHc2VTTjSuGMrP?= =?us-ascii?Q?tnwhmjwdcpJTbPeNcvktjJMNr=2FfEmo5cyI0ZuoU?= =?us-ascii?Q?=2F9laNGNpHSSHKugFoakwAhO3C81FC3wODBdsaQM?= =?us-ascii?Q?hkmawEEpzcDpJJLKop7LhBlMwMyDJWHp52k+P52?= =?us-ascii?Q?=2FYBOYmHmCS5qALZ5q4lKTagRD7r+fRJRycA=3D=3D?= To: Eli Zaretskii X-Entity-ID: d/0VcHixlS0t7iB1YKCv4Q== Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-Spam-Score: 1.2 (+) X-Spam-Report: Spam detection software, running on the system "debbugs.gnu.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see the administrator of that system for details. Content preview: Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: sbaugh@catern.com, 62621@debbugs.gnu.org >> Date: Fri, 14 Jul 2023 10:14:39 -0400 >> >> Eli Zaretskii writes: >> >> > And I don't r [...] Content analysis details: (1.2 points, 10.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- 1.2 RCVD_IN_BL_SPAMCOP_NET RBL: Received via a relay in bl.spamcop.net [Blocked - see ] -0.0 SPF_PASS SPF: sender matches SPF record 0.0 SPF_HELO_NONE SPF: HELO does not publish an SPF Record 0.0 RCVD_IN_MSPIKE_H3 RBL: Good reputation (+3) [149.72.123.24 listed in wl.mailspike.net] 0.0 UNPARSEABLE_RELAY Informational: message has unparseable relay lines 0.0 RCVD_IN_MSPIKE_WL Mailspike good senders -0.0 T_SCC_BODY_TEXT_LINE No description available. X-Debbugs-Envelope-To: 62621 Cc: Spencer Baugh , 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.2 (/) Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: sbaugh@catern.com, 62621@debbugs.gnu.org >> Date: Fri, 14 Jul 2023 10:14:39 -0400 >> >> Eli Zaretskii writes: >> >> > And I don't really understand how this will work in practice: if the >> > user-defined function is supposed to be in effect only for buffers >> > under project.el, >> >> The transform is supposed to be in effect for all buffers, and >> internally it runs some code to decide whether to change the buffer >> name. > > Still unclear why you thought functions can do what other values > cannot. > >> > how is this different from using symbols? >> >> I can't contrast that to "using symbols" because I just don't understand >> what you mean by "using symbols". > > It means the defcustom's value is a symbol, like 'numbered or > 'append-directory, not a function. Yes. But how would you implement it so that setting the defcustom to 'project causes the project-uniquify-dirname-transform logic to be used by uniquify.el, without mentioning project-uniquify-dirname-transform or other project functions in uniquify.el? From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 01:42:30 2023 Received: (at 62621) by debbugs.gnu.org; 15 Jul 2023 05:42:30 +0000 Received: from localhost ([127.0.0.1]:43813 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKY34-0003c7-3o for submit@debbugs.gnu.org; Sat, 15 Jul 2023 01:42:30 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:33042) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKY31-0003bs-AI for 62621@debbugs.gnu.org; Sat, 15 Jul 2023 01:42:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKY2t-0003yP-0Z; Sat, 15 Jul 2023 01:42:19 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=jV+zAJwROfVnETAsOFcxmaqvIUB78NkrrA2MeqkfY/8=; b=sJnBkPTgokaI zR6UDiMouIJ9WSrcnaOQ6Hw6PFg626ITYcHoT/W7P8EHjIRqHOhLT0H6bxGpdGXRw9abgiS8AMxNc DgtTVtbQXvWqbdR22QUF/TvaaYJatCOixTfZSHlIPW6O1sYj+rD+hxCHISzLVlTwr+KQf5ieBzFVy yd36jEDaUB99M5EZsqlYtigthW5xhQuoYj91zyidiBW6iwMJVamazo41uLK6aaC8Ugn8k3epgIL8d W++rbWUDG9WkZHu8jBMTh3+LcZIpckuGicT7oHhmxkOSUPXvKEEdmDskVvj+RHt2QFK1UXRDvBSkq XtuFxs8NPVUbD3na4pBF2Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKY2M-0003Re-54; Sat, 15 Jul 2023 01:41:47 -0400 Date: Sat, 15 Jul 2023 08:42:06 +0300 Message-Id: <83pm4teno1.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com In-Reply-To: <875y6mjod6.fsf@catern.com> (sbaugh@catern.com) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <83bkgefvp6.fsf@gnu.org> <83r0pae2cf.fsf@gnu.org> <875y6mjod6.fsf@catern.com> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: sbaugh@catern.com > Date: Fri, 14 Jul 2023 19:15:50 +0000 (UTC) > Cc: Spencer Baugh , 62621@debbugs.gnu.org > > Eli Zaretskii writes: > > >> I can't contrast that to "using symbols" because I just don't understand > >> what you mean by "using symbols". > > > > It means the defcustom's value is a symbol, like 'numbered or > > 'append-directory, not a function. > > Yes. But how would you implement it so that setting the defcustom to > 'project causes the project-uniquify-dirname-transform logic to be used > by uniquify.el, without mentioning project-uniquify-dirname-transform or > other project functions in uniquify.el? You can use autoloading, for example. Or explicitly (require 'project) when that value is seen. Or any number of other solutions we have for such situations. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 15 02:20:29 2023 Received: (at 62621) by debbugs.gnu.org; 15 Jul 2023 06:20:29 +0000 Received: from localhost ([127.0.0.1]:43874 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKYdp-0007Oe-80 for submit@debbugs.gnu.org; Sat, 15 Jul 2023 02:20:29 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:48494) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qKYdn-0007OR-Dg for 62621@debbugs.gnu.org; Sat, 15 Jul 2023 02:20:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKYdh-00088t-EE; Sat, 15 Jul 2023 02:20:21 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=1C5Dty+K4cQwhlU+eviuAIqzS84DsmuXxybl5dtI0pw=; b=Ep5Q2UxwadHy gpMwphtuvluvsbwB+r1ahzIBq+EaN+22d4W/Vxy/MkpTMGMZ4hAjFQEf4OZBzcxh/cmzD7YNvtXzS j6AHIgx7E/mDMGhXNr2rrULCZrW0tKRPxq07yCH/cWO5eTPQOphCkeOjgHu4d5ROa1tS7jp/7CjXd iHzSxeqrgxQJIiD3bLuQQi74WagnpD+kX7jmnPu+pU7CC826v2PUIYsRabcgCsWvi3Ev56YiBU+y7 3wqvLA8P5fRrZj5Cl9csM+ZKbe+vzl6wmEQbh+wOIPGtgecFZWM5EK0HRvA20yyWubH1Kqo++uNN2 j4MGehMhMbMqqDhYWnCjGA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qKYdg-00074J-Us; Sat, 15 Jul 2023 02:20:21 -0400 Date: Sat, 15 Jul 2023 09:20:41 +0300 Message-Id: <83bkgdelvq.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@catern.com, sbaugh@janestreet.com In-Reply-To: <83pm4teno1.fsf@gnu.org> (message from Eli Zaretskii on Sat, 15 Jul 2023 08:42:06 +0300) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <83bkgefvp6.fsf@gnu.org> <83r0pae2cf.fsf@gnu.org> <875y6mjod6.fsf@catern.com> <83pm4teno1.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org > Date: Sat, 15 Jul 2023 08:42:06 +0300 > From: Eli Zaretskii > > > From: sbaugh@catern.com > > Date: Fri, 14 Jul 2023 19:15:50 +0000 (UTC) > > Cc: Spencer Baugh , 62621@debbugs.gnu.org > > > > Yes. But how would you implement it so that setting the defcustom to > > 'project causes the project-uniquify-dirname-transform logic to be used > > by uniquify.el, without mentioning project-uniquify-dirname-transform or > > other project functions in uniquify.el? > > You can use autoloading, for example. Or explicitly > (require 'project) when that value is seen. Or any > number of other solutions we have for such situations. Or even add a setter to this new defcustom which would set the uniquify variable to a project-specific function, and you already had that situation solved, right? IOW, we have a lot of possible solutions for this kind of problems, just select one of them. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 17 20:20:09 2023 Received: (at 62621) by debbugs.gnu.org; 18 Jul 2023 00:20:09 +0000 Received: from localhost ([127.0.0.1]:51209 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLYRl-0005LN-0S for submit@debbugs.gnu.org; Mon, 17 Jul 2023 20:20:09 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:38379) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLYRi-0005Kk-7a for 62621@debbugs.gnu.org; Mon, 17 Jul 2023 20:20:08 -0400 Received: from compute3.internal (compute3.nyi.internal [10.202.2.43]) by mailout.west.internal (Postfix) with ESMTP id 58C6E3200930; Mon, 17 Jul 2023 20:19:59 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute3.internal (MEProxy); Mon, 17 Jul 2023 20:19:59 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689639598; x=1689725998; bh=oRuxflrtY1uGGTnnIjzcLWmbMZYvheYIUH2 KQOhY1bI=; b=LHQAN6pUn6Ac2j3nhwgdZ6XFQo9Izj9J4km2oHES44zC3b4RpJy Ji+G9i3tqdM+FCUuRyEKG1VSa3R02I6PymsLRVAwqDHNVzY5WvDQizeXW1ikDX8J Me8aNeRELr2u5304ZOtoyFdE8iRyn0aTO9ur4L+USF01KJp6BRDp6QKxP1WCHZ3k 1srEEQq92/x9KwVU5UVUOWXICJMysHKq7Qc48kXwYXv8qJgpKHlmI+MuR8ROHoGC wqrcuLIb/83vf9qw969r5diEEyeR5qjx34js/tC+Zmdjob3b58GQ7/DsS7pmNCXF GXf7LEyrzcYBn7QOXvNogWDiW45r5gisMng== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689639598; x=1689725998; bh=oRuxflrtY1uGGTnnIjzcLWmbMZYvheYIUH2 KQOhY1bI=; b=fLsDDtXbazLEJtHOhYCgL4aLSsPs/lGWseHxJTqnR9PK4P0PFtQ otD/UeyJ2SxRGPj6Hc9B/sOThmU9y4wU/8subLGdqNG788gLCZDyYow+MuFtUjPq cQkmULtOE/TIp05UB0nZ1/3BrzeIR1Ka5mGBBiGkI8hQn0aaC0FSk7nR6NecabT+ +mYEg0q/7D97Y8kUpZ1ZI9KXyFxdD5TCg/PF8owPswkT5t9Tc9/jPV8WrGOjnckx bnQBPykl5b6l3IY3ytmL46UhK3AvuR38DRHQPmF+twGqqKbBS8KXsh2Ty47f55cS oSnGuHfYmVeZ1EgH7BFDm/8LQCeGGXwoeuA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeefgdeffecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jul 2023 20:19:57 -0400 (EDT) Message-ID: <1bf9b290-9942-650c-1328-c9f40dcca256@gutov.dev> Date: Tue, 18 Jul 2023 03:19:54 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename To: sbaugh@catern.com, Eli Zaretskii References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <83bkgefvp6.fsf@gnu.org> <83r0pae2cf.fsf@gnu.org> <875y6mjod6.fsf@catern.com> Content-Language: en-US From: Dmitry Gutov In-Reply-To: <875y6mjod6.fsf@catern.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 62621 Cc: Spencer Baugh , 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 14/07/2023 22:15, sbaugh@catern.com wrote: >>>> how is this different from using symbols? >>> I can't contrast that to "using symbols" because I just don't understand >>> what you mean by "using symbols". >> It means the defcustom's value is a symbol, like 'numbered or >> 'append-directory, not a function. > Yes. But how would you implement it so that setting the defcustom to > 'project causes the project-uniquify-dirname-transform logic to be used > by uniquify.el, without mentioning project-uniquify-dirname-transform or > other project functions in uniquify.el? Yeah, that sounds odd to me too. If we allow symbolic values in a defcustom, somewhere in the same package there has to be a mapping between the symbols and the functions corresponding to them. Which would have to refer to a function from project.el in this case. Of course, we could alternatively have some sort of registry for third-party code to jack into upon loading or etc, but that sounds like a massive overkill for this case. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 17 20:34:22 2023 Received: (at 62621) by debbugs.gnu.org; 18 Jul 2023 00:34:22 +0000 Received: from localhost ([127.0.0.1]:51215 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLYfU-0005g4-G2 for submit@debbugs.gnu.org; Mon, 17 Jul 2023 20:34:22 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:41633) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLYfP-0005fm-M8 for 62621@debbugs.gnu.org; Mon, 17 Jul 2023 20:34:19 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.west.internal (Postfix) with ESMTP id 8BDD23200994; Mon, 17 Jul 2023 20:34:09 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Mon, 17 Jul 2023 20:34:09 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689640449; x=1689726849; bh=Zwl2QplMMZVj6oajcNZeC//ylWGpyzK9Jgl i/1Q7HlY=; b=Eh0L61VZzPIgB3N9ICr20rbaqMtxpyKWF25HOrLGVd0ZJGaGaHq zhTOeHgHatbO/MIh+5CT6HX8i8prpibe1p0jS1/LgRQFltHekRJ6GeILqD41SZNO zqfKYHZgAs7EXl0kLWUe3sYpDr7T0oFcHUcDhBiZL5QlRxKoB+vmd+g2nllIslMq EvbXpg+9FNKW5Y7Oub9ziaVE4kdg9E7DMXowphu6ycQX/qTVTE/Gy/ccr9OdSxLA l9R17uimwPSRv3DavSDcpATqcj5mqKDo/tudo8DMY2xGyy5K/211OjBwn3DtgBws 83A+4ysrXK0xBmUQgRv+emdOM/o+S/5uWtA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689640449; x=1689726849; bh=Zwl2QplMMZVj6oajcNZeC//ylWGpyzK9Jgl i/1Q7HlY=; b=Qsl86Xr7owTzEhJIGpQ2JbWN68tCKXeoWXaLrQU7oiKHHddg+OY d9nXOmMpHc/MfoKV53Xqqv3P+5mUs8pPF90remEWocwcXWQPQ+eg5Mu8qlpTStBb 0NleyiO+TNRCp8QWogLMwjg5s+dKK43Qn4v75WIiid/BD74zphtXB05P3i0Nj/bt 5CIEO/S6zEtNIt8kJW0oAPl8vr8ARKPihSzLMBquF4z9KPaS6m+vGuOZ66jrbY1c /9h1PLBWo+5SeLq8lzBfz4tnybUsm2+JdnuptH1s2hz3dXIOBXZdfAyAvODq+eUK ePfQVu9mZL86vDxQmuFHvNb+xKJoOfHdbxw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeefgdefjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jul 2023 20:34:07 -0400 (EDT) Message-ID: <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> Date: Tue, 18 Jul 2023 03:34:06 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Content-Language: en-US To: Eli Zaretskii , sbaugh@catern.com References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83edlb3t0t.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 14/07/2023 09:29, Eli Zaretskii wrote: > IOW, we should NOT immediately generalize to > functions only because such generalization could make sense in some > use cases. I agree with that statement. When only one or two behaviors can be needed or foreseen, there's no hard need to make the option open-ended (which it becomes when it can be set to a function). This case, however, looks more like an exception to my eye. Similar to save-some-buffers-default-predicate where extensibility makes sense. And if you also wanted to avoid a direct reference to project-* in uniquify.el, that's another argument in favor of extensibility. > Repeat after me: Use options whose values are functions > are hard on our users, because they require them to be Lisp > programmers. That doesn't have to be the case. If the defcustom's docstring mentions several functions that can be used, and the :type widget includes them as well, the user can decide to switch to any of them without writing any Lisp (or having to understand the implementations). Examples: the aforementioned save-some-buffers-default-predicate, or project-prompter, or xref-history-storage, and so on. From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 17 21:37:53 2023 Received: (at 62621) by debbugs.gnu.org; 18 Jul 2023 01:37:53 +0000 Received: from localhost ([127.0.0.1]:51271 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLZez-0007F9-Dt for submit@debbugs.gnu.org; Mon, 17 Jul 2023 21:37:53 -0400 Received: from wout3-smtp.messagingengine.com ([64.147.123.19]:51897) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLZew-0007Eu-QO for 62621@debbugs.gnu.org; Mon, 17 Jul 2023 21:37:52 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 7DC11320093A; Mon, 17 Jul 2023 21:37:44 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Mon, 17 Jul 2023 21:37:44 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689644264; x=1689730664; bh=ZpBd87DzZ/Ct2RWFnGCrA+NRQpOoQCzy8Mm vxL/2jHQ=; b=brdOqQE7zR7mh31GIzM24h1hGocTWhZDmmeRyZD7sKXuRi0ZmsI v9gn6MoFHTCls/HphMHjUpPolAoli1k6BI08/E5T5eV/U/xS/GWic4fUNosuAN+x cK5PCzjEBZ7CrRc6b+zyfSUvEHhI/v1fOH+N4Jgn9B8apTG3d4SAePv0KCAE2eDe 4F7dXgYBCWNutkFkEzkoCd6JlRBcdft+BdJ1FtV96RYcfWtWR8+Ux/DanyIUJyvX PCq7h0oL2yNDqVMnKrnbfqcnWxikqmRO85Ulmw/Qus+1ldDERo+U2BeJISBsiOWi H5ZUmUFy7COMnRxR44Son26vkeMjxsHCkwA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689644264; x=1689730664; bh=ZpBd87DzZ/Ct2RWFnGCrA+NRQpOoQCzy8Mm vxL/2jHQ=; b=gNuWoH5hWugFCiCZi92Bp0EGZdG5A2nko3izw42FeqDIMmcHJFV nhzN7cXVd7bp+hcoDwqT5ntrc4KfwbDbtaBSTdbHsFsz211w5XItxE6oxSUA7RlY TFssD2ztwwHpiQxMDU+p9zAwF4Bx2ShVsyjP7qrK0EY7viJvqF4jLr89HpW1NTir 2Msqpn1GRD1/XHf02Dbk41jCxASezCxENshjGfNR15OvfxTC8ANttcfiIax9YhFG ZGSK5LIx6d/z/59g4VoQIuw9/eHOljFnS7nVk7EF6LGSDA/Ej05cxioCj93VqFpE xw++at6UQl/KbfOXlpJcmZrhSXOC0Cec/jg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeefgdegkecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpefhuedtkeevgeegteetkeefjeffgeduudduhfeuveelfedtffffgeegiedvvdej leenucffohhmrghinhepghhnuhdrohhrghenucevlhhushhtvghrufhiiigvpedtnecurf grrhgrmhepmhgrihhlfhhrohhmpegumhhithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 17 Jul 2023 21:37:42 -0400 (EDT) Message-ID: <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> Date: Tue, 18 Jul 2023 04:37:41 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Content-Language: en-US To: Spencer Baugh , Eli Zaretskii References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 14/07/2023 15:46, Spencer Baugh wrote: >>>> If the symbolic values are specific to project, simply let-bind >>>> uniquify-dirname-transform to the value of the appropriate project.el >>>> defcustom when project.el calls uniquify. >>> These customizations are in effect all the time, not just when the user >>> is calling a project.el command. e.g. rename-buffer triggers uniquify. >> Then you can set the buffer-local value of uniquify-dirname-transform >> in the project.el buffers. Would that solve the problem? > The buffers it should affect are all file-visiting buffers. project.el > doesn't currently have any code which runs for every new buffer. I > guess we've considered adding that, but I'm not sure this is a good > reason... I'm not sure every project.el user will want this particular behavior anyway. project-switch-buffer is handy, but personally, I still most often use 'C-x b'. But there definitely is demand for this option, as evidenced by the previously mentioned bug#59502, as well as this (unexpectedly, years-old) thread: https://lists.gnu.org/archive/html/emacs-devel/2021-03/msg00083.html Speaking of those, do you think it would be feasible to also offer these tweaks (as options, or for particular buffers): - Make the presence of the buffer name mandatory. As shown in the examples in bug#59502, it could be useful to always see in buffers like *eshell* produced by project-eshell. Or project-vc-dir, for example. - Hide the parent directory from the uniquification logic (only keeping the project name). So that, for example, if I call 'M-x project-eshell' and then 'C-u M-x project-eshell', the generated buffer names would not try to use the parent segment to uniquify, and just stay as /*eshell* and /*eshell-2*. There is currently some bespoke logic for naming these particular buffers, but if we could move to uniquify (and obey its custom vars), that would probably be an improvement. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 18 07:07:28 2023 Received: (at 62621) by debbugs.gnu.org; 18 Jul 2023 11:07:28 +0000 Received: from localhost ([127.0.0.1]:51679 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLiYB-00063c-Q2 for submit@debbugs.gnu.org; Tue, 18 Jul 2023 07:07:28 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:60698) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLiY9-00063N-0w for 62621@debbugs.gnu.org; Tue, 18 Jul 2023 07:07:26 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLiY1-0000jj-1H; Tue, 18 Jul 2023 07:07:17 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=ro5jZb24+LVKF5son9VFkHe8WytfHuth/mhp0UfTfDY=; b=iwNYH9VzJFHk KYtvtewERdsaz0ACQiV8K5Ix51S/dcgFpW4ofpXgf1OinpcIij5LooYf6bnmJIwnXcWIDkRphre68 J9T+tHlsHRYlyE0Ln10Y5LsaZg75nN8gkSlOc4LMs4ABekTVk8imQ0sutyNFv1geee1Z8/gwA6GE5 NBDmD4Wu0UXy0f8fqbm85e+REkC9LO6Prhq3dyy3fVIZ1Vkxx2Qu23S3IdVK1y7oQYDcRq50woKSF 4DoakWksPHnMdENvPJBpZtwW4vYkliWO9E6AvOI47FVy3yRTC3f8Zi/kPmSeA4wfYtPEMwxqKYQ1r QMYg2Zi+HqUwMkmBcQ9V9w==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qLiXk-0005YZ-OG; Tue, 18 Jul 2023 07:07:16 -0400 Date: Tue, 18 Jul 2023 14:07:29 +0300 Message-Id: <83mszt7a1a.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> (message from Dmitry Gutov on Tue, 18 Jul 2023 03:34:06 +0300) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Tue, 18 Jul 2023 03:34:06 +0300 > Cc: sbaugh@janestreet.com, 62621@debbugs.gnu.org > From: Dmitry Gutov > > > Repeat after me: Use options whose values are functions > > are hard on our users, because they require them to be Lisp > > programmers. > > That doesn't have to be the case. If the defcustom's docstring mentions > several functions that can be used, and the :type widget includes them > as well, the user can decide to switch to any of them without writing > any Lisp (or having to understand the implementations). But that was not so in this particular case. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 18 12:03:34 2023 Received: (at 62621) by debbugs.gnu.org; 18 Jul 2023 16:03:34 +0000 Received: from localhost ([127.0.0.1]:54029 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLnAk-0000XJ-2i for submit@debbugs.gnu.org; Tue, 18 Jul 2023 12:03:34 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:33021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLnAh-0000Wq-Cc for 62621@debbugs.gnu.org; Tue, 18 Jul 2023 12:03:32 -0400 From: Spencer Baugh To: Dmitry Gutov Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> (Dmitry Gutov's message of "Tue, 18 Jul 2023 04:37:41 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> Date: Tue, 18 Jul 2023 12:03:26 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, Eli Zaretskii , 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 14/07/2023 15:46, Spencer Baugh wrote: >>>>> If the symbolic values are specific to project, simply let-bind >>>>> uniquify-dirname-transform to the value of the appropriate project.el >>>>> defcustom when project.el calls uniquify. >>>> These customizations are in effect all the time, not just when the user >>>> is calling a project.el command. e.g. rename-buffer triggers uniquify. >>> Then you can set the buffer-local value of uniquify-dirname-transform >>> in the project.el buffers. Would that solve the problem? >> The buffers it should affect are all file-visiting buffers. project.el >> doesn't currently have any code which runs for every new buffer. I >> guess we've considered adding that, but I'm not sure this is a good >> reason... > > I'm not sure every project.el user will want this particular behavior > anyway. project-switch-buffer is handy, but personally, I still most > often use 'C-x b'. > > But there definitely is demand for this option, as evidenced by the > previously mentioned bug#59502, as well as this (unexpectedly, > years-old) thread: > https://lists.gnu.org/archive/html/emacs-devel/2021-03/msg00083.html > > Speaking of those, do you think it would be feasible to also offer > these tweaks (as options, or for particular buffers): > > - Make the presence of the buffer name mandatory. As shown in the > examples in bug#59502, it could be useful to always see in buffers > like *eshell* produced by project-eshell. Or project-vc-dir, for > example. (I assume you mean "make the presence of the project name mandatory") I think there is a good solution to this which was not mentioned in bug#59502 only add the project name (or dirname or whatever) to the buffer when that's necessary to give the buffer a unique name. That reduces overhead when working only with one project, and neatly fits in to how uniquify already works for file-visiting buffers. To do this, I think we'd need to change commands to use a function other than get-buffer-create when accessing e.g. *xref* or *eshell*, which like create-file-buffer gets a chance to uniquify the buffer name. It's a bit tricky though: we want commands to access and reuse existing a project-specific buffer if there is one, but commands doesn't know the name of that buffer so can't find it that way. find-file has solved this same problem ages ago, of reusing an existing buffer if we find-file a buffer-file-name which is already open. I think we may need something similar for non-file-visiting buffers. Maybe some kind of mechanism to find a buffer with basename "*eshell*" whose default-directory contains our current default-directory? Kind of a "locate-dominating-buffer"? > - Hide the parent directory from the uniquification logic (only > keeping the project name). So that, for example, if I call 'M-x > project-eshell' and then 'C-u M-x project-eshell', the generated > buffer names would not try to use the parent segment to uniquify, > and just stay as /*eshell* and > /*eshell-2*. There is currently some bespoke logic for > naming these particular buffers, but if we could move to uniquify > (and obey its custom vars), that would probably be an improvement. Hm, so if two *eshell* buffers are in the same project, they should first be uniquified from other *eshell* buffers by adding the project name, and then uniquified from each other by adding numbers to the end of the buffer name. I think I can implement this pretty easily in uniquify.el: if a set of conflicting buffers all have the same dirname, then resolve the conflict by adding numbers to the end. (Actually I was a bit surprised to realize that uniquify wasn't doing this already, but I guess it's because it previously has only worked for file-visiting buffers, which as I mentioned above are kept unique by buffer-file-name, so there can't be conflicts between two buffer names if you include their entire buffer-file-name in the buffer name.) --- Incidentally, another feature which I've been thinking about at the intersection of project.el and uniquify.el: We could rerun uniquify on project-buffers in a mode where it just outputs sufficiently unique names without actually renaming the buffers, and then use that in project-switch-to-buffer. So then when picking the buffer, you are picking from buffer names which are unique *in that specific project*. It's otherwise kind of annoying to me that project-switch-to-buffer includes a bunch of long disambiguating paths in the buffer names even though the buffer names aren't actually ambiguous in that command. Does that sound interesting? I, like you, usually use C-x b. But I think this feature would make C-x p b much nicer and competitive with C-x b. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 18 13:55:27 2023 Received: (at 62621) by debbugs.gnu.org; 18 Jul 2023 17:55:27 +0000 Received: from localhost ([127.0.0.1]:54236 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLov0-00067k-Nl for submit@debbugs.gnu.org; Tue, 18 Jul 2023 13:55:27 -0400 Received: from relay7-d.mail.gandi.net ([217.70.183.200]:40863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLouy-00067U-3T for 62621@debbugs.gnu.org; Tue, 18 Jul 2023 13:55:25 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 3573C20002; Tue, 18 Jul 2023 17:55:15 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> (Dmitry Gutov's message of "Tue, 18 Jul 2023 04:37:41 +0300") Organization: LINKOV.NET References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> Date: Tue, 18 Jul 2023 20:51:19 +0300 Message-ID: <86wmyx5crs.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 62621 Cc: Spencer Baugh , Eli Zaretskii , 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) > - Hide the parent directory from the uniquification logic (only keeping the > project name). So that, for example, if I call 'M-x project-eshell' and > then 'C-u M-x project-eshell', the generated buffer names would not try > to use the parent segment to uniquify, and just stay as > /*eshell* and /*eshell-2*. Often a project name in the buffer name is needed not for purposes of generating a unique buffer name, but for permanent indication which project a file/non-file buffer belongs to. In such cases indeed a parent directory makes no sense, but still uniquification is required for buffers inside the same project, e.g. /*eshell*<1> /*eshell*<2> So here are 2 styles combined: one for top-level project names produced by project.el, and another style for the same project by uniquify.el (in this case 'post-forward-angle-brackets'). From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 18 22:23:07 2023 Received: (at 62621) by debbugs.gnu.org; 19 Jul 2023 02:23:07 +0000 Received: from localhost ([127.0.0.1]:54578 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLwqJ-0004uQ-3T for submit@debbugs.gnu.org; Tue, 18 Jul 2023 22:23:07 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:52865) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLwqF-0004tf-O0 for 62621@debbugs.gnu.org; Tue, 18 Jul 2023 22:23:06 -0400 Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 805D55C00E1; Tue, 18 Jul 2023 22:22:58 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute4.internal (MEProxy); Tue, 18 Jul 2023 22:22:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689733378; x=1689819778; bh=oXWb4y/DqkPcviUQkyB0XWqxsAgE8BvrA47 QSRzIBLI=; b=Rbrn1U1PubEalpF07FY3cGrvuM/TAIYOn468BLy7WJ2Vhj0BimT vTpyfVRhPbKdm3gTKhA4TDrqTiWlPdxL8h3D7sI+7ncl9+x00yQJrNq3alGTA1Kj NOEaF+dHQWWvu1hTVo20DusHRei64uAmpKpSxCrqNI5soFu3RMt00VxWKs/cyu75 +ZxOyit2u4lQxh2MwNz0w+djSAcZZamAmojyu+Iss/+6UhcvIsWMXHEOb5jeTyI0 Oq67oIYZBgnGDuorsXc9lfx/DnXaPBFjDjnBecWJicyUCfZvOFfGsnYWxPD0OXFD gTSqNiLj7Ir0rPHIeDHO4BvGMVRQJd52nLw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689733378; x=1689819778; bh=oXWb4y/DqkPcviUQkyB0XWqxsAgE8BvrA47 QSRzIBLI=; b=rw9B8Ck0GbvqAiN28Op1KGMdMIBAZmdWwN6OAq2k/t2Jvk/gSiG QMjKum0A0KEJYM/vVrdRZs97hSHGoRABLW5oc0YU3KYa8Zgwu+CJ1G7vaqS6OZ4U X9wD/1lU7N5B6Vt98jNy4gbh712P0ORItDQPhqP4Jr66W0A7Q4I2x8M2mn2vVEJb YWsE5JNbq8FDxg0qFXqtNtkahOOwb8jzTp4+xmpSY4RTyJFqMyFiRaJ0hbOI326S y1Z/y7V00bENkD5EB3OD9GBfzdITTA66skVE7DD+MDV4rFOtoa5JoOq6Y7faOAag K4p9sxQDFoOIFhvoBuhtjyVx1yG1jdM1C5g== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeehgdehiecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 Jul 2023 22:22:57 -0400 (EDT) Message-ID: <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> Date: Wed, 19 Jul 2023 05:22:56 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Content-Language: en-US To: Eli Zaretskii References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> From: Dmitry Gutov In-Reply-To: <83mszt7a1a.fsf@gnu.org> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 18/07/2023 14:07, Eli Zaretskii wrote: >> Date: Tue, 18 Jul 2023 03:34:06 +0300 >> Cc:sbaugh@janestreet.com,62621@debbugs.gnu.org >> From: Dmitry Gutov >> >>> Repeat after me: Use options whose values are functions >>> are hard on our users, because they require them to be Lisp >>> programmers. >> That doesn't have to be the case. If the defcustom's docstring mentions >> several functions that can be used, and the :type widget includes them >> as well, the user can decide to switch to any of them without writing >> any Lisp (or having to understand the implementations). > But that was not so in this particular case. That's easy to fix, as long as you don't have additional objections to that approach. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 18 22:25:09 2023 Received: (at 62621) by debbugs.gnu.org; 19 Jul 2023 02:25:09 +0000 Received: from localhost ([127.0.0.1]:54583 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLwsG-0004xY-M8 for submit@debbugs.gnu.org; Tue, 18 Jul 2023 22:25:09 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:36383) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLwsE-0004wu-4V for 62621@debbugs.gnu.org; Tue, 18 Jul 2023 22:25:07 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 0EF155C00E1; Tue, 18 Jul 2023 22:25:01 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 18 Jul 2023 22:25:01 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689733501; x=1689819901; bh=qsdrfbAHvfZJa8OEFWL+WXJctVwLfbGG2YN yMyLXy/U=; b=ipl01pYrx5+/6UVk2rouhxN2mdDoozJqL8U2ZH05bgPBO15kBJM xsH3LAjKkoOdIg4lTss22EyhVWRxUCtCE26eL9CVNljbJ1vJJtxNi7EvE2eXnZWV V2Pai3zOpjpK78lcVyXyjcFLHLHz8gPeG0r2VXye2ScbQPpSdGJWdRpXmWWuFCbE /en5qx4gFOOkbpoc7IbMofDfK44lYtnPv6dgElTTCrbtC6ujywoV7hrxirQKMC5+ 40HyWaOoZTELTssY8MyAYB2NJ3+HpHUnLFDkpRcTN0a/IWFIbpGiMbINl85QkSuF auwlvqf0s4GvKA4UpGO8p/xAKEXL6E2eUrA== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689733501; x=1689819901; bh=qsdrfbAHvfZJa8OEFWL+WXJctVwLfbGG2YN yMyLXy/U=; b=pfGaxmlflVhOQgwvSbkYxz4NK3qYQepfk3YiCyNgkxl3cnQJlDG wdTflwWtOL9BCDiKTO9vMRtpCv/jFTGkVRxt3ycQ2ddyp69QpA12MJzZWy5M0LKs DR5Oy975j8bvb0GCJWmozGs1XE85XeawNCVas6If6/pyL4BxbS+8IDFfJF8ERxZ0 Rb0bADyckL9ZH25go6gQEMJI43ue4bRXOxHwSSsincJP6/4uF/XbbrHnnKO4y1Mf 5U7ulBPiWWDerJiScBA9sZKpfzO0tx12H5TMyFyLf9WPdffLLlSZ5NfSmMAbXYRq +XLQBKobOntt7eFFTL80XiDA3sJu1Y9Bqfw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeehgdehjecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 Jul 2023 22:24:59 -0400 (EDT) Message-ID: <41ac58ab-2d6b-223d-39c4-8844ec6019c1@gutov.dev> Date: Wed, 19 Jul 2023 05:24:58 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Content-Language: en-US To: Juri Linkov References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> <86wmyx5crs.fsf@mail.linkov.net> From: Dmitry Gutov In-Reply-To: <86wmyx5crs.fsf@mail.linkov.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 62621 Cc: Spencer Baugh , Eli Zaretskii , 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 18/07/2023 20:51, Juri Linkov wrote: >> - Hide the parent directory from the uniquification logic (only keeping the >> project name). So that, for example, if I call 'M-x project-eshell' and >> then 'C-u M-x project-eshell', the generated buffer names would not try >> to use the parent segment to uniquify, and just stay as >> /*eshell* and /*eshell-2*. > Often a project name in the buffer name is needed not for purposes > of generating a unique buffer name, but for permanent indication > which project a file/non-file buffer belongs to. That's what I was thinking of as well. I suppose, the question is, though, which place in the code should make that decision, and which one should be in change of formatting the buffer's name. > In such cases indeed a parent directory makes no sense, > but still uniquification is required for buffers inside > the same project, e.g. > > /*eshell*<1> > /*eshell*<2> > > So here are 2 styles combined: one for top-level project names > produced by project.el, and another style for the same project > by uniquify.el (in this case 'post-forward-angle-brackets'). ...which is a bit untidy at the moment. From debbugs-submit-bounces@debbugs.gnu.org Tue Jul 18 22:47:56 2023 Received: (at 62621) by debbugs.gnu.org; 19 Jul 2023 02:47:57 +0000 Received: from localhost ([127.0.0.1]:54614 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLxEK-0005XD-CX for submit@debbugs.gnu.org; Tue, 18 Jul 2023 22:47:56 -0400 Received: from out5-smtp.messagingengine.com ([66.111.4.29]:34449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qLxEH-0005WH-0x for 62621@debbugs.gnu.org; Tue, 18 Jul 2023 22:47:55 -0400 Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id F03B75C0046; Tue, 18 Jul 2023 22:47:47 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 18 Jul 2023 22:47:47 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gutov.dev; h=cc :cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1689734867; x=1689821267; bh=kgvHy1PFwkJpCTqIOn84WQwT/l+WqeikHYX qequYAZw=; b=e926B1naI1ZdMJ1NBHXJhz/e5Js0P444q79aRV4XfURZulfaoZl mmRQ0mavGLpbuvbgybqh6RR/fK+I3aSMnzlVNs94FVaC3ofKZmJIG1LnRsuGKBa3 1Px9N+dKnikaiQKC6AgrTR5SfbacYrsS2NVjigUs1SqJ3oFUydEqmWau0Cn0i+G6 vR+e+VYx2T8vuB0qKbCoC+y38TiLdK1SzuiMdkCWWRBJT42IjWBOlH43r/JF3ltu qHSGBe8bOVwldYYhkv1Fdx7R/ZyW4nSZzYf7b3aJOn0Ei+c3gyfUHgO2gwy51lbh BsiNf0RMjwx3ntF9W0qjfVUswbyRgyaRf4Q== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; t= 1689734867; x=1689821267; bh=kgvHy1PFwkJpCTqIOn84WQwT/l+WqeikHYX qequYAZw=; b=XA+NQwfBUtchRHShW/yv0W6fDIWABKPZIwFHbBGn8j2mJH8u8Xl jNcFEScJRQrcetIdt4K6MnU2HkFU+XM7cyrMCqCvGZs8UBFZlC/6Aofy3Q8U1KVq IiTn0d1xp4m4SIF9zqFoTrP7ygBm3ULYwIKokuCKoRTtqQqMOvsktnkcnt5uPymD 6IkLRwCLZRQZKPM5SFtPuxr6l89wpw9RG1daEnNqZEMxuaHGBSYoVWebGvA8lxAl 3uymRCLi2bcoj9/7nnhTi/oqT30SVlpJLUvskBeJV75IFCRryvvYYgRzOyUjeEdp hs9IyzwkXLDoDS3ZksjuTdCgT9zHUG7SM1A== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedviedrgeehgdeivdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefkffggfgfuvfevfhfhjggtgfesthejredttdefjeenucfhrhhomhepffhmihht rhihucfiuhhtohhvuceoughmihhtrhihsehguhhtohhvrdguvghvqeenucggtffrrghtth gvrhhnpeeigfetveehveevffehledtueekieeikeeufeegudfgfeeghfdulefgfeevledv veenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhrohhmpegumh hithhrhiesghhuthhovhdruggvvh X-ME-Proxy: Feedback-ID: i0e71465a:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Tue, 18 Jul 2023 22:47:46 -0400 (EDT) Message-ID: <56b526dc-3244-e3cf-75db-5cce527c0096@gutov.dev> Date: Wed, 19 Jul 2023 05:47:45 +0300 MIME-Version: 1.0 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:102.0) Gecko/20100101 Thunderbird/102.13.0 Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename Content-Language: en-US To: Spencer Baugh References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> From: Dmitry Gutov In-Reply-To: Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, Eli Zaretskii , 62621@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) On 18/07/2023 19:03, Spencer Baugh wrote: >> Speaking of those, do you think it would be feasible to also offer >> these tweaks (as options, or for particular buffers): >> >> - Make the presence of the buffer name mandatory. As shown in the >> examples in bug#59502, it could be useful to always see in buffers >> like *eshell* produced by project-eshell. Or project-vc-dir, for >> example. > > (I assume you mean "make the presence of the project name mandatory") Ah yes, sorry. > I think there is a good solution to this which was not mentioned in > bug#59502 only add the project name (or dirname or whatever) to the > buffer when that's necessary to give the buffer a unique name.> That > reduces overhead when working only with one project, and neatly fits in > to how uniquify already works for file-visiting buffers. We never talked about such an option. It's a little less obvious, but might indeed fit in more smoothly for both project and non-project use cases (and I also often work on just one project). Something to consider, though: if I am in a project A, and a project B has an eshell buffer and project A does not, 'C-x b' won't tell me that that eshell is in project B. But ideally, it should, I suppose. This might have been the original reasoning to simply include the project name in those buffers' names. > To do this, I think we'd need to change commands to use a function other > than get-buffer-create when accessing e.g. *xref* or *eshell*, which > like create-file-buffer gets a chance to uniquify the buffer name. > > It's a bit tricky though: we want commands to access and reuse existing > a project-specific buffer if there is one, but commands doesn't know the > name of that buffer so can't find it that way. find-file has solved > this same problem ages ago, of reusing an existing buffer if we > find-file a buffer-file-name which is already open. I think we may need > something similar for non-file-visiting buffers. > > Maybe some kind of mechanism to find a buffer with basename "*eshell*" > whose default-directory contains our current default-directory? Kind of > a "locate-dominating-buffer"? Well... a straightforward way would be to have some public function in uniquify which, given a set of name components, would construct the supposed buffer name and see whether one exists. And/or return the newest one that matches (if there are several, sequentially enumerated). But I suppose uniquify doesn't have to be enabled in every session. So a higher-level function could be added to the core. It's hard to decouple this idea from using uniquify, though, so I'm not sure what we'd call it. Alternatively, we'd just check every time whether uniquify is on, and have two different code paths for yes and no. >> - Hide the parent directory from the uniquification logic (only >> keeping the project name). So that, for example, if I call 'M-x >> project-eshell' and then 'C-u M-x project-eshell', the generated >> buffer names would not try to use the parent segment to uniquify, >> and just stay as /*eshell* and >> /*eshell-2*. There is currently some bespoke logic for >> naming these particular buffers, but if we could move to uniquify >> (and obey its custom vars), that would probably be an improvement. > > Hm, so if two *eshell* buffers are in the same project, they should > first be uniquified from other *eshell* buffers by adding the project > name, and then uniquified from each other by adding numbers to the end > of the buffer name. I wonder how that's going to play with existing user expectations. Like, if there are no projects, then a regular parent directory name will be used, right? And currently eshell buffer names don't include that at all. But maybe they should?.. Anyway, if the new behavior is opt-in, there won't be a cause for complaint. > I think I can implement this pretty easily in uniquify.el: if a set of > conflicting buffers all have the same dirname, then resolve the conflict > by adding numbers to the end. Yes, I suppose if directory names are equal, it doesn't make sense to prepend further name components -- a number makes more sense. > (Actually I was a bit surprised to realize that uniquify wasn't doing > this already, but I guess it's because it previously has only worked for > file-visiting buffers, which as I mentioned above are kept unique by > buffer-file-name, so there can't be conflicts between two buffer names > if you include their entire buffer-file-name in the buffer name.) True enough. > Incidentally, another feature which I've been thinking about at the > intersection of project.el and uniquify.el: We could rerun uniquify on > project-buffers in a mode where it just outputs sufficiently unique > names without actually renaming the buffers, and then use that in > project-switch-to-buffer. So then when picking the buffer, you are > picking from buffer names which are unique *in that specific project*. > It's otherwise kind of annoying to me that project-switch-to-buffer > includes a bunch of long disambiguating paths in the buffer names even > though the buffer names aren't actually ambiguous in that command. > > Does that sound interesting? I, like you, usually use C-x b. But I > think this feature would make C-x p b much nicer and competitive with > C-x b. That does sound interesting! And actually, when initially reading a message from this thread, I thought it was about something like that. It could be implemented by altering the buffers' completion table, I suppose. But I'm not sure how much of uniquify's code could be reused there. Or the performance characteristics of re-running uniquification every time a buffer name is read. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 19 02:57:46 2023 Received: (at 62621) by debbugs.gnu.org; 19 Jul 2023 06:57:46 +0000 Received: from localhost ([127.0.0.1]:54810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM185-0003tv-Qa for submit@debbugs.gnu.org; Wed, 19 Jul 2023 02:57:46 -0400 Received: from relay3-d.mail.gandi.net ([217.70.183.195]:36003) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM182-0003te-O2 for 62621@debbugs.gnu.org; Wed, 19 Jul 2023 02:57:44 -0400 Received: by mail.gandi.net (Postfix) with ESMTPSA id 50C3A60002; Wed, 19 Jul 2023 06:57:33 +0000 (UTC) From: Juri Linkov To: Dmitry Gutov Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <56b526dc-3244-e3cf-75db-5cce527c0096@gutov.dev> (Dmitry Gutov's message of "Wed, 19 Jul 2023 05:47:45 +0300") Organization: LINKOV.NET References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <878rbika0i.fsf@catern.com> <83h6q6g0qx.fsf@gnu.org> <83edlafzht.fsf@gnu.org> <4abafd65-fad0-f723-9bd1-e6e2a77bb837@gutov.dev> <56b526dc-3244-e3cf-75db-5cce527c0096@gutov.dev> Date: Wed, 19 Jul 2023 09:56:55 +0300 Message-ID: <86a5vs2xu0.fsf@mail.linkov.net> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/30.0.50 (x86_64-pc-linux-gnu) MIME-Version: 1.0 Content-Type: text/plain X-GND-Sasl: juri@linkov.net X-Spam-Score: -0.7 (/) X-Debbugs-Envelope-To: 62621 Cc: Spencer Baugh , Eli Zaretskii , 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.7 (-) >> Incidentally, another feature which I've been thinking about at the >> intersection of project.el and uniquify.el: We could rerun uniquify on >> project-buffers in a mode where it just outputs sufficiently unique >> names without actually renaming the buffers, and then use that in >> project-switch-to-buffer. So then when picking the buffer, you are >> picking from buffer names which are unique *in that specific project*. >> It's otherwise kind of annoying to me that project-switch-to-buffer >> includes a bunch of long disambiguating paths in the buffer names even >> though the buffer names aren't actually ambiguous in that command. >> Does that sound interesting? I, like you, usually use C-x b. But I >> think this feature would make C-x p b much nicer and competitive with >> C-x b. > > That does sound interesting! And actually, when initially reading a message > from this thread, I thought it was about something like that. > > It could be implemented by altering the buffers' completion table, > I suppose. But I'm not sure how much of uniquify's code could be reused > there. Or the performance characteristics of re-running uniquification > every time a buffer name is read. It could be implemented the same way as project--read-file-cpd-relative removes common-parent-directory from absolute filenames. From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 19 08:14:40 2023 Received: (at 62621) by debbugs.gnu.org; 19 Jul 2023 12:14:40 +0000 Received: from localhost ([127.0.0.1]:55131 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM64m-0006dY-B2 for submit@debbugs.gnu.org; Wed, 19 Jul 2023 08:14:40 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:35270) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM64j-0006dH-8V for 62621@debbugs.gnu.org; Wed, 19 Jul 2023 08:14:39 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qM64a-0006eJ-Lp; Wed, 19 Jul 2023 08:14:28 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=oqxVucXuF/6y13SL+3PF8v7qxEdEONjBXIXPu3iYIDk=; b=B1VagZyLBL8T RnQDtYAf1Qnvt4IzHhDa5mYeETqGn+fdRE+9XFYvwFCmZdxuMG+qb6z28tUzhrwUM3OQqzS6+9enX rvYEDdj2k/69AGF1ixaO5SsKCPqw8Tes8RqLr4u1Nd/kGsSpPgcPoY09Ea+9SLEV8RPQLOMn4YOnL J9PttQdAPIKhRMYeHjwn9enAMrgdtDly7dVHifDtn4L37p8QxIOqOiRdAKClEJYu8cKll4JidE1Xl rBVKO4+w11rUlI151849WJS31hQymY3AmM+m01yqjWJecASAyw8VDp6y2KxU/SOREqpdx/cg1a5OR Hxj59zZcjHvZ1FUl6xMe/Q==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qM64Y-0008DB-Aq; Wed, 19 Jul 2023 08:14:28 -0400 Date: Wed, 19 Jul 2023 15:14:56 +0300 Message-Id: <838rbc5c8v.fsf@gnu.org> From: Eli Zaretskii To: Dmitry Gutov In-Reply-To: <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> (message from Dmitry Gutov on Wed, 19 Jul 2023 05:22:56 +0300) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: sbaugh@catern.com, 62621@debbugs.gnu.org, sbaugh@janestreet.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Date: Wed, 19 Jul 2023 05:22:56 +0300 > Cc: sbaugh@catern.com, sbaugh@janestreet.com, 62621@debbugs.gnu.org > From: Dmitry Gutov > > On 18/07/2023 14:07, Eli Zaretskii wrote: > >> Date: Tue, 18 Jul 2023 03:34:06 +0300 > >> Cc:sbaugh@janestreet.com,62621@debbugs.gnu.org > >> From: Dmitry Gutov > >> > >>> Repeat after me: Use options whose values are functions > >>> are hard on our users, because they require them to be Lisp > >>> programmers. > >> That doesn't have to be the case. If the defcustom's docstring mentions > >> several functions that can be used, and the :type widget includes them > >> as well, the user can decide to switch to any of them without writing > >> any Lisp (or having to understand the implementations). > > But that was not so in this particular case. > > That's easy to fix, as long as you don't have additional objections to > that approach. I'd need to see the fix first, because I don't think I have a clear idea of what you have in mind. (My objections, btw, where very minor and of pure usability nature. Frankly, I'm surprised such a simple and more-or-less agreed-upon comment got such a long thread of discussing various loosely-related issues.) From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 19 08:31:10 2023 Received: (at 62621) by debbugs.gnu.org; 19 Jul 2023 12:31:10 +0000 Received: from localhost ([127.0.0.1]:55156 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM6Kj-00075U-Tu for submit@debbugs.gnu.org; Wed, 19 Jul 2023 08:31:10 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:48717) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM6Kf-00074o-I2 for 62621@debbugs.gnu.org; Wed, 19 Jul 2023 08:31:09 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <838rbc5c8v.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 19 Jul 2023 15:14:56 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> Date: Wed, 19 Jul 2023 08:31:00 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: Dmitry Gutov , 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> Date: Wed, 19 Jul 2023 05:22:56 +0300 >> Cc: sbaugh@catern.com, sbaugh@janestreet.com, 62621@debbugs.gnu.org >> From: Dmitry Gutov >> >> On 18/07/2023 14:07, Eli Zaretskii wrote: >> >> Date: Tue, 18 Jul 2023 03:34:06 +0300 >> >> Cc:sbaugh@janestreet.com,62621@debbugs.gnu.org >> >> From: Dmitry Gutov >> >> >> >>> Repeat after me: Use options whose values are functions >> >>> are hard on our users, because they require them to be Lisp >> >>> programmers. >> >> That doesn't have to be the case. If the defcustom's docstring mentions >> >> several functions that can be used, and the :type widget includes them >> >> as well, the user can decide to switch to any of them without writing >> >> any Lisp (or having to understand the implementations). >> > But that was not so in this particular case. >> >> That's easy to fix, as long as you don't have additional objections to >> that approach. > > I'd need to see the fix first, because I don't think I have a clear > idea of what you have in mind. > > (My objections, btw, where very minor and of pure usability nature. > Frankly, I'm surprised such a simple and more-or-less agreed-upon > comment got such a long thread of discussing various loosely-related > issues.) Like this: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Support-transforming-the-dirname-used-by-uniquify.patch >From 7fcbc7499809134104bb5dbde206094d85f48806 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sun, 9 Jul 2023 22:21:03 -0400 Subject: [PATCH] Support transforming the dirname used by uniquify By transforming the dirname, we can add additional information to use during uniquifying. A basic one: uniquifying buffer names based on the project name. * lisp/progmodes/project.el (project-uniquify-dirname-transform): Add. * lisp/uniquify.el (uniquify-dirname-transform-default) (uniquify-dirname-transform): Add. (bug#62621) (uniquify-rationalize-file-buffer-names, uniquify-buffer-file-name): Use uniquify-dirname-transform. * test/lisp/uniquify-tests.el (uniquify-home, uniquify-project-transform): Add tests. --- lisp/progmodes/project.el | 12 ++++++++++++ lisp/uniquify.el | 25 ++++++++++++++++++++----- test/lisp/uniquify-tests.el | 33 +++++++++++++++++++++++++++++++++ 3 files changed, 65 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index d482cc24d70..78f9fb410c1 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1835,5 +1835,17 @@ project-switch-project (let ((project-current-directory-override dir)) (call-interactively command)))) +;;;###autoload +(defun project-uniquify-dirname-transform (dirname) + "Include `project-name' in DIRNAME if in a project." + (if-let (proj (project-current nil dirname)) + (let ((root (project-root proj))) + (expand-file-name + (file-name-concat + (file-name-directory root) + (project-name proj) + (file-relative-name dirname root)))) + dirname)) + (provide 'project) ;;; project.el ends here diff --git a/lisp/uniquify.el b/lisp/uniquify.el index d1ca455b673..328f85bf32f 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -168,6 +168,19 @@ uniquify-list-buffers-directory-modes That means that when `buffer-file-name' is set to nil, `list-buffers-directory' contains the name of the directory which the buffer is visiting.") +(defcustom uniquify-dirname-transform #'identity + "Function to transform buffer's directory for uniquifying its name. + +It takes a single argument: the directory of the buffer. It +should return a string filename (which does not need to actually +exist in the filesystem) to use for uniquifying the buffer name." + :type '(choice (function-item :tag "Don't change the dirname" identity) + (function-item :tag "Include project name in dirname" + #'project-uniquify-dirname-transform) + function) + :version "30.1" + :group 'uniquify) + ;;; Utilities ;; uniquify-fix-list data structure @@ -209,7 +222,8 @@ uniquify-rationalize-file-buffer-names ;; this buffer. (with-current-buffer newbuf (setq uniquify-managed nil)) (when dirname - (setq dirname (expand-file-name (directory-file-name dirname))) + (setq dirname (funcall uniquify-dirname-transform + (expand-file-name (directory-file-name dirname)))) (let ((fix-list (list (uniquify-make-item base dirname newbuf nil))) items) @@ -268,10 +282,11 @@ uniquify-buffer-file-name (if (memq major-mode uniquify-list-buffers-directory-modes) list-buffers-directory)))) (when filename - (directory-file-name - (file-name-directory - (expand-file-name - (directory-file-name filename)))))))) + (funcall uniquify-dirname-transform + (directory-file-name + (file-name-directory + (expand-file-name + (directory-file-name filename))))))))) (defun uniquify-rerationalize-w/o-cb (fix-list) "Re-rationalize the buffers in FIX-LIST, but ignoring `current-buffer'." diff --git a/test/lisp/uniquify-tests.el b/test/lisp/uniquify-tests.el index abd61fa3504..e533c4b644c 100644 --- a/test/lisp/uniquify-tests.el +++ b/test/lisp/uniquify-tests.el @@ -88,6 +88,21 @@ uniquify-dirs '("a/dir/" "b/dir/"))) (mapc #'kill-buffer bufs))))) +(ert-deftest uniquify-home () + "uniquify works, albeit confusingly, in the presence of directories named \"~\"" + (let (bufs) + (save-excursion + (push (find-file-noselect "~") bufs) + (push (find-file-noselect "./~") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("~" "~<>"))) + (push (find-file-noselect "~/foo") bufs) + (push (find-file-noselect "./~/foo") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("foo<~>" "foo" "~" "~<>"))) + (while bufs + (kill-buffer (pop bufs)))))) + (ert-deftest uniquify-rename-to-dir () "Giving a buffer a name which matches a directory doesn't rename the buffer" (let ((uniquify-buffer-name-style 'forward) @@ -125,5 +140,23 @@ uniquify-space-prefix (should (equal (buffer-name) "| foo")) (kill-buffer))) +(require 'project) +(ert-deftest uniquify-project-transform () + "`project-uniquify-dirname-transform' works" + (let ((uniquify-dirname-transform #'project-uniquify-dirname-transform) + (project-vc-name "foo1/bar") + bufs) + (save-excursion + (should (file-exists-p "../README")) + (push (find-file-noselect "../README") bufs) + (push (find-file-noselect "other/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README"))) + (push (find-file-noselect "foo2/bar/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README" "README"))) + (while bufs + (kill-buffer (pop bufs)))))) + (provide 'uniquify-tests) ;;; uniquify-tests.el ends here -- 2.39.3 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 19 09:25:33 2023 Received: (at 62621) by debbugs.gnu.org; 19 Jul 2023 13:25:33 +0000 Received: from localhost ([127.0.0.1]:55204 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM7BM-0008UN-HX for submit@debbugs.gnu.org; Wed, 19 Jul 2023 09:25:33 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:46292) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qM7BH-0008U5-Rk for 62621@debbugs.gnu.org; Wed, 19 Jul 2023 09:25:31 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qM7BB-0005sI-Vu; Wed, 19 Jul 2023 09:25:22 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=fewcWfc2UdiKUBVkE+PP99EjXhMKtpE/Mco4wAH2uYY=; b=CdtcOB7MQDFm MoHpbgQcFA7F6iwGU1yGc1urthFk2JzcgcqQFkwvg4Gs6p13+RF9TQWTvQgW34LSf3p5cpwMj128q w6LOPF2gtrcsoX2pEN97c3Xo0OLcKawrmT6+m08m4TU4C5RaLO8BixKphyBgYgLKAmhep9Yp13yRY kKQLt80auugovf1lKppouLLbiaXDOQq36aIKk8qF1P+aR8Fy+kbOF2/FNVU+KCG5vSLAnDBlBjTcN T33DwRDXdABVdVTeqcT/m3309xLuvWcD97AVfI5De7hxRJ8sAu4FKkSKiAwq7FucroY2bRZd3Kqyk tcRssPlWnOvMYq4pP+zVIA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qM7BA-0006S3-V7; Wed, 19 Jul 2023 09:25:21 -0400 Date: Wed, 19 Jul 2023 16:25:52 +0300 Message-Id: <83v8eg3ue7.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Wed, 19 Jul 2023 08:31:00 -0400) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: Dmitry Gutov , sbaugh@catern.com, 62621@debbugs.gnu.org > Date: Wed, 19 Jul 2023 08:31:00 -0400 > > >> >>> Repeat after me: Use options whose values are functions > >> >>> are hard on our users, because they require them to be Lisp > >> >>> programmers. > >> >> That doesn't have to be the case. If the defcustom's docstring mentions > >> >> several functions that can be used, and the :type widget includes them > >> >> as well, the user can decide to switch to any of them without writing > >> >> any Lisp (or having to understand the implementations). > >> > But that was not so in this particular case. > >> > >> That's easy to fix, as long as you don't have additional objections to > >> that approach. > > > > I'd need to see the fix first, because I don't think I have a clear > > idea of what you have in mind. > > > > (My objections, btw, where very minor and of pure usability nature. > > Frankly, I'm surprised such a simple and more-or-less agreed-upon > > comment got such a long thread of discussing various loosely-related > > issues.) > > Like this: Thanks, but it still falls short of what Dmitry described above: the doc string doesn't "mention several functions that can be used". > +(defcustom uniquify-dirname-transform #'identity > + "Function to transform buffer's directory for uniquifying its name. > + > +It takes a single argument: the directory of the buffer. It > +should return a string filename (which does not need to actually > +exist in the filesystem) to use for uniquifying the buffer name." Please read this carefully and try to put yourself in the shoes of a user who needs to make sense out of this description. The immediate question I had is what does "transforming a buffer's directory" have to do with "uniquifying the buffer name"? Uniquifying a buffer's name is not about its directory, at least not in general. IOW, the starting point of this description is too "inside" the implementation. From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 21 09:34:38 2023 Received: (at 62621) by debbugs.gnu.org; 21 Jul 2023 13:34:38 +0000 Received: from localhost ([127.0.0.1]:60939 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMqHF-0001ZZ-SG for submit@debbugs.gnu.org; Fri, 21 Jul 2023 09:34:38 -0400 Received: from mxout2.mail.janestreet.com ([38.105.200.79]:37145) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMqHB-0001Z5-Sk for 62621@debbugs.gnu.org; Fri, 21 Jul 2023 09:34:35 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <83v8eg3ue7.fsf@gnu.org> (Eli Zaretskii's message of "Wed, 19 Jul 2023 16:25:52 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> <83v8eg3ue7.fsf@gnu.org> Date: Fri, 21 Jul 2023 09:34:28 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: Dmitry Gutov , sbaugh@catern.com, 62621@debbugs.gnu.org >> Date: Wed, 19 Jul 2023 08:31:00 -0400 >> >> >> >>> Repeat after me: Use options whose values are functions >> >> >>> are hard on our users, because they require them to be Lisp >> >> >>> programmers. >> >> >> That doesn't have to be the case. If the defcustom's docstring mentions >> >> >> several functions that can be used, and the :type widget includes them >> >> >> as well, the user can decide to switch to any of them without writing >> >> >> any Lisp (or having to understand the implementations). >> >> > But that was not so in this particular case. >> >> >> >> That's easy to fix, as long as you don't have additional objections to >> >> that approach. >> > >> > I'd need to see the fix first, because I don't think I have a clear >> > idea of what you have in mind. >> > >> > (My objections, btw, where very minor and of pure usability nature. >> > Frankly, I'm surprised such a simple and more-or-less agreed-upon >> > comment got such a long thread of discussing various loosely-related >> > issues.) >> >> Like this: > > Thanks, but it still falls short of what Dmitry described above: the > doc string doesn't "mention several functions that can be used". > >> +(defcustom uniquify-dirname-transform #'identity >> + "Function to transform buffer's directory for uniquifying its name. >> + >> +It takes a single argument: the directory of the buffer. It >> +should return a string filename (which does not need to actually >> +exist in the filesystem) to use for uniquifying the buffer name." > > Please read this carefully and try to put yourself in the shoes of a > user who needs to make sense out of this description. The immediate > question I had is what does "transforming a buffer's directory" have > to do with "uniquifying the buffer name"? Uniquifying a buffer's name > is not about its directory, at least not in general. IOW, the > starting point of this description is too "inside" the implementation. OK, how about this? --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Support-transforming-the-dirname-used-by-uniquify.patch >From d5d909040b04bd8d6265d5f19eb3610b6d3d87d8 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sun, 9 Jul 2023 22:21:03 -0400 Subject: [PATCH] Support transforming the dirname used by uniquify By transforming the dirname, we can add additional information to use during uniquifying. A basic one: uniquifying buffer names based on the project name. * lisp/progmodes/project.el (project-uniquify-dirname-transform): Add. * lisp/uniquify.el (uniquify-dirname-transform-default) (uniquify-dirname-transform): Add. (bug#62621) (uniquify-rationalize-file-buffer-names, uniquify-buffer-file-name): Use uniquify-dirname-transform. * test/lisp/uniquify-tests.el (uniquify-home, uniquify-project-transform): Add tests. --- lisp/progmodes/project.el | 12 ++++++++++++ lisp/uniquify.el | 38 ++++++++++++++++++++++++++++++++----- test/lisp/uniquify-tests.el | 33 ++++++++++++++++++++++++++++++++ 3 files changed, 78 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index d482cc24d70..78f9fb410c1 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1835,5 +1835,17 @@ project-switch-project (let ((project-current-directory-override dir)) (call-interactively command)))) +;;;###autoload +(defun project-uniquify-dirname-transform (dirname) + "Include `project-name' in DIRNAME if in a project." + (if-let (proj (project-current nil dirname)) + (let ((root (project-root proj))) + (expand-file-name + (file-name-concat + (file-name-directory root) + (project-name proj) + (file-relative-name dirname root)))) + dirname)) + (provide 'project) ;;; project.el ends here diff --git a/lisp/uniquify.el b/lisp/uniquify.el index d1ca455b673..eec5aefc803 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -168,6 +168,32 @@ uniquify-list-buffers-directory-modes That means that when `buffer-file-name' is set to nil, `list-buffers-directory' contains the name of the directory which the buffer is visiting.") +(defcustom uniquify-dirname-transform #'identity + "Function to transform buffer's directory for uniquifying its name. + +When `uniquify-buffer-name-style' is non-nil, if a buffer's name +would be the same as some other buffer, then components from the +buffer's directory name are added to the buffer's name until the +buffer's name is unique. + +By default, uniquifying only adds components from the buffer's +directory name. If you set this variable to +`project-uniquify-dirname-transform', slash-separated components +from `project-name' will also be added to the buffer's name when +buffers from two different projects would otherwise have the same +name. + +To include your own custom details in the unique buffer name, set +this variable to a function taking a single argument, the +buffer's directory, and returning a file name (which does not +need to actually exist in the filesystem) to use components from." + :type '(choice (function-item :tag "Don't change the dirname" identity) + (function-item :tag "Include project name in dirname" + #'project-uniquify-dirname-transform) + function) + :version "30.1" + :group 'uniquify) + ;;; Utilities ;; uniquify-fix-list data structure @@ -209,7 +235,8 @@ uniquify-rationalize-file-buffer-names ;; this buffer. (with-current-buffer newbuf (setq uniquify-managed nil)) (when dirname - (setq dirname (expand-file-name (directory-file-name dirname))) + (setq dirname (funcall uniquify-dirname-transform + (expand-file-name (directory-file-name dirname)))) (let ((fix-list (list (uniquify-make-item base dirname newbuf nil))) items) @@ -268,10 +295,11 @@ uniquify-buffer-file-name (if (memq major-mode uniquify-list-buffers-directory-modes) list-buffers-directory)))) (when filename - (directory-file-name - (file-name-directory - (expand-file-name - (directory-file-name filename)))))))) + (funcall uniquify-dirname-transform + (directory-file-name + (file-name-directory + (expand-file-name + (directory-file-name filename))))))))) (defun uniquify-rerationalize-w/o-cb (fix-list) "Re-rationalize the buffers in FIX-LIST, but ignoring `current-buffer'." diff --git a/test/lisp/uniquify-tests.el b/test/lisp/uniquify-tests.el index abd61fa3504..e533c4b644c 100644 --- a/test/lisp/uniquify-tests.el +++ b/test/lisp/uniquify-tests.el @@ -88,6 +88,21 @@ uniquify-dirs '("a/dir/" "b/dir/"))) (mapc #'kill-buffer bufs))))) +(ert-deftest uniquify-home () + "uniquify works, albeit confusingly, in the presence of directories named \"~\"" + (let (bufs) + (save-excursion + (push (find-file-noselect "~") bufs) + (push (find-file-noselect "./~") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("~" "~<>"))) + (push (find-file-noselect "~/foo") bufs) + (push (find-file-noselect "./~/foo") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("foo<~>" "foo" "~" "~<>"))) + (while bufs + (kill-buffer (pop bufs)))))) + (ert-deftest uniquify-rename-to-dir () "Giving a buffer a name which matches a directory doesn't rename the buffer" (let ((uniquify-buffer-name-style 'forward) @@ -125,5 +140,23 @@ uniquify-space-prefix (should (equal (buffer-name) "| foo")) (kill-buffer))) +(require 'project) +(ert-deftest uniquify-project-transform () + "`project-uniquify-dirname-transform' works" + (let ((uniquify-dirname-transform #'project-uniquify-dirname-transform) + (project-vc-name "foo1/bar") + bufs) + (save-excursion + (should (file-exists-p "../README")) + (push (find-file-noselect "../README") bufs) + (push (find-file-noselect "other/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README"))) + (push (find-file-noselect "foo2/bar/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README" "README"))) + (while bufs + (kill-buffer (pop bufs)))))) + (provide 'uniquify-tests) ;;; uniquify-tests.el ends here -- 2.39.3 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Fri Jul 21 10:37:15 2023 Received: (at 62621) by debbugs.gnu.org; 21 Jul 2023 14:37:15 +0000 Received: from localhost ([127.0.0.1]:34366 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMrFq-0003gD-V5 for submit@debbugs.gnu.org; Fri, 21 Jul 2023 10:37:15 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:47204) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qMrFk-0003fw-RC for 62621@debbugs.gnu.org; Fri, 21 Jul 2023 10:37:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMrFf-0000iJ-1O; Fri, 21 Jul 2023 10:37:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=mu/YFOz4RfSHF1tIQgKgkKIr9mHyfO3jILbHS0VAqFc=; b=Qln6gwqM0wn5 k3pddqx/KI385gzc8e7ISiA7K8cEod8H/nYY4xxgukduUrOVd2Sjr1kLsuUJk2CaHNyfNpEn78yWR zm4rqMFkkzhqiirfaJ/kgBMnDQXrBVvJIkP00Al4TeWiMbfpQGXQZWd9cwV0FJZhN/zrObv9hPqh2 yoMUQpydLDbxx3TMQ6f6rhaXj1Z+M261mgMkxcTfDkuuf69F5IiuAPsPokLs5IVdpnf8t+NC6pg0W dsLAYgvRbewvi0AAhCjnfyFN6eTN+IXYcYwDMuXHrCjFCOw/bh0r1IhKSD9KNGpjC/bKRJ7yQn22v 2+5RC6/hWpYK2r3+F/YT8g==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qMrFe-0002Pz-Gz; Fri, 21 Jul 2023 10:37:02 -0400 Date: Fri, 21 Jul 2023 17:37:37 +0300 Message-Id: <83a5vpbaa6.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Fri, 21 Jul 2023 09:34:28 -0400) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> <83v8eg3ue7.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com > Date: Fri, 21 Jul 2023 09:34:28 -0400 > > > Thanks, but it still falls short of what Dmitry described above: the > > doc string doesn't "mention several functions that can be used". > > > >> +(defcustom uniquify-dirname-transform #'identity > >> + "Function to transform buffer's directory for uniquifying its name. > >> + > >> +It takes a single argument: the directory of the buffer. It > >> +should return a string filename (which does not need to actually > >> +exist in the filesystem) to use for uniquifying the buffer name." > > > > Please read this carefully and try to put yourself in the shoes of a > > user who needs to make sense out of this description. The immediate > > question I had is what does "transforming a buffer's directory" have > > to do with "uniquifying the buffer name"? Uniquifying a buffer's name > > is not about its directory, at least not in general. IOW, the > > starting point of this description is too "inside" the implementation. > > OK, how about this? The explanation of what project-uniquify-dirname-transform does should in its doc string, not in the doc string of uniquify-dirname-transform (which should refer to the former, and that is enough). The doc string of uniquify-dirname-transform should mention at least 'identity' as the default (what you wrote does that, but without mentioning the function's name), otherwise this still falls short of what Dmitry described. And the last two paragraphs of the doc string of uniquify-dirname-transform should be more-or-less reversed: first describe the default, and that using some function other than 'identity' can affect the result, then describe project-uniquify-dirname-transform as one such non-default transform. From debbugs-submit-bounces@debbugs.gnu.org Sat Jul 22 14:00:39 2023 Received: (at 62621) by debbugs.gnu.org; 22 Jul 2023 18:00:39 +0000 Received: from localhost ([127.0.0.1]:37549 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNGuE-0005es-N8 for submit@debbugs.gnu.org; Sat, 22 Jul 2023 14:00:39 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:45039) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qNGuC-0005ee-1s for 62621@debbugs.gnu.org; Sat, 22 Jul 2023 14:00:37 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: <83a5vpbaa6.fsf@gnu.org> (Eli Zaretskii's message of "Fri, 21 Jul 2023 17:37:37 +0300") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> <83v8eg3ue7.fsf@gnu.org> <83a5vpbaa6.fsf@gnu.org> Date: Sat, 22 Jul 2023 14:00:30 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Eli Zaretskii writes: >> From: Spencer Baugh >> Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com >> Date: Fri, 21 Jul 2023 09:34:28 -0400 >> >> > Thanks, but it still falls short of what Dmitry described above: the >> > doc string doesn't "mention several functions that can be used". >> > >> >> +(defcustom uniquify-dirname-transform #'identity >> >> + "Function to transform buffer's directory for uniquifying its name. >> >> + >> >> +It takes a single argument: the directory of the buffer. It >> >> +should return a string filename (which does not need to actually >> >> +exist in the filesystem) to use for uniquifying the buffer name." >> > >> > Please read this carefully and try to put yourself in the shoes of a >> > user who needs to make sense out of this description. The immediate >> > question I had is what does "transforming a buffer's directory" have >> > to do with "uniquifying the buffer name"? Uniquifying a buffer's name >> > is not about its directory, at least not in general. IOW, the >> > starting point of this description is too "inside" the implementation. >> >> OK, how about this? > > The explanation of what project-uniquify-dirname-transform does should > in its doc string, not in the doc string of uniquify-dirname-transform > (which should refer to the former, and that is enough). > > The doc string of uniquify-dirname-transform should mention at least > 'identity' as the default (what you wrote does that, but without > mentioning the function's name), otherwise this still falls short of > what Dmitry described. > > And the last two paragraphs of the doc string of > uniquify-dirname-transform should be more-or-less reversed: first > describe the default, and that using some function other than > 'identity' can affect the result, then describe > project-uniquify-dirname-transform as one such non-default transform. OK, how about this? --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Support-transforming-the-dirname-used-by-uniquify.patch >From 30b6cf1961b89f12e54adeae9035036696807a38 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sun, 9 Jul 2023 22:21:03 -0400 Subject: [PATCH] Support transforming the dirname used by uniquify By transforming the dirname, we can add additional information to use during uniquifying. A basic one: uniquifying buffer names based on the project name. * lisp/progmodes/project.el (project-uniquify-dirname-transform): Add. * lisp/uniquify.el (uniquify-dirname-transform-default) (uniquify-dirname-transform): Add. (bug#62621) (uniquify-rationalize-file-buffer-names, uniquify-buffer-file-name): Use uniquify-dirname-transform. * test/lisp/uniquify-tests.el (uniquify-home, uniquify-project-transform): Add tests. --- lisp/progmodes/project.el | 12 ++++++++++++ lisp/uniquify.el | 37 ++++++++++++++++++++++++++++++++----- test/lisp/uniquify-tests.el | 33 +++++++++++++++++++++++++++++++++ 3 files changed, 77 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index d482cc24d70..78f9fb410c1 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1835,5 +1835,17 @@ project-switch-project (let ((project-current-directory-override dir)) (call-interactively command)))) +;;;###autoload +(defun project-uniquify-dirname-transform (dirname) + "Include `project-name' in DIRNAME if in a project." + (if-let (proj (project-current nil dirname)) + (let ((root (project-root proj))) + (expand-file-name + (file-name-concat + (file-name-directory root) + (project-name proj) + (file-relative-name dirname root)))) + dirname)) + (provide 'project) ;;; project.el ends here diff --git a/lisp/uniquify.el b/lisp/uniquify.el index d1ca455b673..af00c95663d 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -168,6 +168,31 @@ uniquify-list-buffers-directory-modes That means that when `buffer-file-name' is set to nil, `list-buffers-directory' contains the name of the directory which the buffer is visiting.") +(defcustom uniquify-dirname-transform #'identity + "Function to transform buffer's directory for uniquifying its name. + +If `uniquify-buffer-name-style' is non-nil and a buffer's name +would be the same as some other buffer, then components from the +buffer's directory name are added to the buffer's name until the +buffer's name is unique. + +This function is used to transform the buffer's directory name +before the uniquifying process, allowing the unique buffer name +to include components from other sources. The default is +`identity', so only the buffer's directory name is used for +uniquifying. This function is called with the buffer's directory +name and should return a file name (which does not need to +actually exist in the filesystem) to use components from. + +To include components from `project-name', set this variable to +`project-uniquify-dirname-transform'." + :type '(choice (function-item :tag "Don't change the dirname" identity) + (function-item :tag "Include project name in dirname" + #'project-uniquify-dirname-transform) + function) + :version "30.1" + :group 'uniquify) + ;;; Utilities ;; uniquify-fix-list data structure @@ -209,7 +234,8 @@ uniquify-rationalize-file-buffer-names ;; this buffer. (with-current-buffer newbuf (setq uniquify-managed nil)) (when dirname - (setq dirname (expand-file-name (directory-file-name dirname))) + (setq dirname (funcall uniquify-dirname-transform + (expand-file-name (directory-file-name dirname)))) (let ((fix-list (list (uniquify-make-item base dirname newbuf nil))) items) @@ -268,10 +294,11 @@ uniquify-buffer-file-name (if (memq major-mode uniquify-list-buffers-directory-modes) list-buffers-directory)))) (when filename - (directory-file-name - (file-name-directory - (expand-file-name - (directory-file-name filename)))))))) + (funcall uniquify-dirname-transform + (directory-file-name + (file-name-directory + (expand-file-name + (directory-file-name filename))))))))) (defun uniquify-rerationalize-w/o-cb (fix-list) "Re-rationalize the buffers in FIX-LIST, but ignoring `current-buffer'." diff --git a/test/lisp/uniquify-tests.el b/test/lisp/uniquify-tests.el index abd61fa3504..e533c4b644c 100644 --- a/test/lisp/uniquify-tests.el +++ b/test/lisp/uniquify-tests.el @@ -88,6 +88,21 @@ uniquify-dirs '("a/dir/" "b/dir/"))) (mapc #'kill-buffer bufs))))) +(ert-deftest uniquify-home () + "uniquify works, albeit confusingly, in the presence of directories named \"~\"" + (let (bufs) + (save-excursion + (push (find-file-noselect "~") bufs) + (push (find-file-noselect "./~") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("~" "~<>"))) + (push (find-file-noselect "~/foo") bufs) + (push (find-file-noselect "./~/foo") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("foo<~>" "foo" "~" "~<>"))) + (while bufs + (kill-buffer (pop bufs)))))) + (ert-deftest uniquify-rename-to-dir () "Giving a buffer a name which matches a directory doesn't rename the buffer" (let ((uniquify-buffer-name-style 'forward) @@ -125,5 +140,23 @@ uniquify-space-prefix (should (equal (buffer-name) "| foo")) (kill-buffer))) +(require 'project) +(ert-deftest uniquify-project-transform () + "`project-uniquify-dirname-transform' works" + (let ((uniquify-dirname-transform #'project-uniquify-dirname-transform) + (project-vc-name "foo1/bar") + bufs) + (save-excursion + (should (file-exists-p "../README")) + (push (find-file-noselect "../README") bufs) + (push (find-file-noselect "other/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README"))) + (push (find-file-noselect "foo2/bar/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README" "README"))) + (while bufs + (kill-buffer (pop bufs)))))) + (provide 'uniquify-tests) ;;; uniquify-tests.el ends here -- 2.39.3 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Mon Jul 24 15:18:32 2023 Received: (at 62621) by debbugs.gnu.org; 24 Jul 2023 19:18:32 +0000 Received: from localhost ([127.0.0.1]:44097 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qO14h-0003IJ-Pe for submit@debbugs.gnu.org; Mon, 24 Jul 2023 15:18:32 -0400 Received: from mxout5.mail.janestreet.com ([64.215.233.18]:46449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qO14f-0003I5-1U for 62621@debbugs.gnu.org; Mon, 24 Jul 2023 15:18:30 -0400 From: Spencer Baugh To: Eli Zaretskii Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename In-Reply-To: (Spencer Baugh's message of "Sat, 22 Jul 2023 14:00:30 -0400") References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> <83v8eg3ue7.fsf@gnu.org> <83a5vpbaa6.fsf@gnu.org> Date: Mon, 24 Jul 2023 15:18:23 -0400 Message-ID: User-Agent: Gnus/5.13 (Gnus v5.13) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain Spencer Baugh writes: > Eli Zaretskii writes: >>> From: Spencer Baugh >>> Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com >>> Date: Fri, 21 Jul 2023 09:34:28 -0400 >>> >>> > Thanks, but it still falls short of what Dmitry described above: the >>> > doc string doesn't "mention several functions that can be used". >>> > >>> >> +(defcustom uniquify-dirname-transform #'identity >>> >> + "Function to transform buffer's directory for uniquifying its name. >>> >> + >>> >> +It takes a single argument: the directory of the buffer. It >>> >> +should return a string filename (which does not need to actually >>> >> +exist in the filesystem) to use for uniquifying the buffer name." >>> > >>> > Please read this carefully and try to put yourself in the shoes of a >>> > user who needs to make sense out of this description. The immediate >>> > question I had is what does "transforming a buffer's directory" have >>> > to do with "uniquifying the buffer name"? Uniquifying a buffer's name >>> > is not about its directory, at least not in general. IOW, the >>> > starting point of this description is too "inside" the implementation. >>> >>> OK, how about this? >> >> The explanation of what project-uniquify-dirname-transform does should >> in its doc string, not in the doc string of uniquify-dirname-transform >> (which should refer to the former, and that is enough). >> >> The doc string of uniquify-dirname-transform should mention at least >> 'identity' as the default (what you wrote does that, but without >> mentioning the function's name), otherwise this still falls short of >> what Dmitry described. >> >> And the last two paragraphs of the doc string of >> uniquify-dirname-transform should be more-or-less reversed: first >> describe the default, and that using some function other than >> 'identity' can affect the result, then describe >> project-uniquify-dirname-transform as one such non-default transform. > > OK, how about this? Oops, that one didn't include the updated project-uniquify-dirname-transform docstring. The right patch now: --=-=-= Content-Type: text/x-patch Content-Disposition: inline; filename=0001-Support-transforming-the-dirname-used-by-uniquify.patch >From 39e508c96ddf6bc5361542aa030f199193329fe0 Mon Sep 17 00:00:00 2001 From: Spencer Baugh Date: Sun, 9 Jul 2023 22:21:03 -0400 Subject: [PATCH] Support transforming the dirname used by uniquify By transforming the dirname, we can add additional information to use during uniquifying. A basic one: uniquifying buffer names based on the project name. * lisp/progmodes/project.el (project-uniquify-dirname-transform): Add. * lisp/uniquify.el (uniquify-dirname-transform-default) (uniquify-dirname-transform): Add. (bug#62621) (uniquify-rationalize-file-buffer-names, uniquify-buffer-file-name): Use uniquify-dirname-transform. * test/lisp/uniquify-tests.el (uniquify-home, uniquify-project-transform): Add tests. --- lisp/progmodes/project.el | 17 +++++++++++++++++ lisp/uniquify.el | 37 ++++++++++++++++++++++++++++++++----- test/lisp/uniquify-tests.el | 33 +++++++++++++++++++++++++++++++++ 3 files changed, 82 insertions(+), 5 deletions(-) diff --git a/lisp/progmodes/project.el b/lisp/progmodes/project.el index d482cc24d70..36c1005aef5 100644 --- a/lisp/progmodes/project.el +++ b/lisp/progmodes/project.el @@ -1835,5 +1835,22 @@ project-switch-project (let ((project-current-directory-override dir)) (call-interactively command)))) +;;;###autoload +(defun project-uniquify-dirname-transform (dirname) + "Include `project-name' in DIRNAME if in a project. + +If you set `uniquify-dirname-transform' to this function, +slash-separated components from `project-name' will be added to +the buffer's name when buffers from two different projects would +otherwise have the same name." + (if-let (proj (project-current nil dirname)) + (let ((root (project-root proj))) + (expand-file-name + (file-name-concat + (file-name-directory root) + (project-name proj) + (file-relative-name dirname root)))) + dirname)) + (provide 'project) ;;; project.el ends here diff --git a/lisp/uniquify.el b/lisp/uniquify.el index d1ca455b673..af00c95663d 100644 --- a/lisp/uniquify.el +++ b/lisp/uniquify.el @@ -168,6 +168,31 @@ uniquify-list-buffers-directory-modes That means that when `buffer-file-name' is set to nil, `list-buffers-directory' contains the name of the directory which the buffer is visiting.") +(defcustom uniquify-dirname-transform #'identity + "Function to transform buffer's directory for uniquifying its name. + +If `uniquify-buffer-name-style' is non-nil and a buffer's name +would be the same as some other buffer, then components from the +buffer's directory name are added to the buffer's name until the +buffer's name is unique. + +This function is used to transform the buffer's directory name +before the uniquifying process, allowing the unique buffer name +to include components from other sources. The default is +`identity', so only the buffer's directory name is used for +uniquifying. This function is called with the buffer's directory +name and should return a file name (which does not need to +actually exist in the filesystem) to use components from. + +To include components from `project-name', set this variable to +`project-uniquify-dirname-transform'." + :type '(choice (function-item :tag "Don't change the dirname" identity) + (function-item :tag "Include project name in dirname" + #'project-uniquify-dirname-transform) + function) + :version "30.1" + :group 'uniquify) + ;;; Utilities ;; uniquify-fix-list data structure @@ -209,7 +234,8 @@ uniquify-rationalize-file-buffer-names ;; this buffer. (with-current-buffer newbuf (setq uniquify-managed nil)) (when dirname - (setq dirname (expand-file-name (directory-file-name dirname))) + (setq dirname (funcall uniquify-dirname-transform + (expand-file-name (directory-file-name dirname)))) (let ((fix-list (list (uniquify-make-item base dirname newbuf nil))) items) @@ -268,10 +294,11 @@ uniquify-buffer-file-name (if (memq major-mode uniquify-list-buffers-directory-modes) list-buffers-directory)))) (when filename - (directory-file-name - (file-name-directory - (expand-file-name - (directory-file-name filename)))))))) + (funcall uniquify-dirname-transform + (directory-file-name + (file-name-directory + (expand-file-name + (directory-file-name filename))))))))) (defun uniquify-rerationalize-w/o-cb (fix-list) "Re-rationalize the buffers in FIX-LIST, but ignoring `current-buffer'." diff --git a/test/lisp/uniquify-tests.el b/test/lisp/uniquify-tests.el index abd61fa3504..e533c4b644c 100644 --- a/test/lisp/uniquify-tests.el +++ b/test/lisp/uniquify-tests.el @@ -88,6 +88,21 @@ uniquify-dirs '("a/dir/" "b/dir/"))) (mapc #'kill-buffer bufs))))) +(ert-deftest uniquify-home () + "uniquify works, albeit confusingly, in the presence of directories named \"~\"" + (let (bufs) + (save-excursion + (push (find-file-noselect "~") bufs) + (push (find-file-noselect "./~") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("~" "~<>"))) + (push (find-file-noselect "~/foo") bufs) + (push (find-file-noselect "./~/foo") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("foo<~>" "foo" "~" "~<>"))) + (while bufs + (kill-buffer (pop bufs)))))) + (ert-deftest uniquify-rename-to-dir () "Giving a buffer a name which matches a directory doesn't rename the buffer" (let ((uniquify-buffer-name-style 'forward) @@ -125,5 +140,23 @@ uniquify-space-prefix (should (equal (buffer-name) "| foo")) (kill-buffer))) +(require 'project) +(ert-deftest uniquify-project-transform () + "`project-uniquify-dirname-transform' works" + (let ((uniquify-dirname-transform #'project-uniquify-dirname-transform) + (project-vc-name "foo1/bar") + bufs) + (save-excursion + (should (file-exists-p "../README")) + (push (find-file-noselect "../README") bufs) + (push (find-file-noselect "other/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README"))) + (push (find-file-noselect "foo2/bar/README") bufs) + (should (equal (mapcar #'buffer-name bufs) + '("README" "README" "README"))) + (while bufs + (kill-buffer (pop bufs)))))) + (provide 'uniquify-tests) ;;; uniquify-tests.el ends here -- 2.39.3 --=-=-=-- From debbugs-submit-bounces@debbugs.gnu.org Wed Jul 26 11:17:47 2023 Received: (at 62621) by debbugs.gnu.org; 26 Jul 2023 15:17:48 +0000 Received: from localhost ([127.0.0.1]:49856 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOgGp-0003T7-HT for submit@debbugs.gnu.org; Wed, 26 Jul 2023 11:17:47 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:52066) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qOgGn-0003Sv-O7 for 62621@debbugs.gnu.org; Wed, 26 Jul 2023 11:17:46 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qOgGh-0002e0-Mw; Wed, 26 Jul 2023 11:17:39 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=kPBY5D2kGX3H3P0nQxnXY3vkvMWRw/B/xZJIat6czF8=; b=M/znbAJN5VcC k+j488KANsxmofjabQUQZTMDDc1FibLH/U1zTaOmSTwsPEgczjPVWCACV3OH/zZ04kFBznDM3/3V4 jCMYtBaKEmPx6wjX6PDpZhg5+i9bAo3xpQk7RlpkqE/r0+WMDtKknUZ6U4tVOOBTPzEQjfZYa6xJP +/VpZD5UhFwrb8hwbIeU2uPdkDj9am6pm8sE7YtYh1XwL4soYgrk/F+0wqxLeCGfN7H6OvrojwC+A hNFGpfuAcYJNvrbn0Ud5DRA1fw5ml3cSMaNnj8+5/lg8BN+6zqhN+3QnT5XutKlHUU3zeVPeG+dGp Qk6nfhjV02O+dNz3QroVBA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qOgGg-0008FO-QP; Wed, 26 Jul 2023 11:17:39 -0400 Date: Wed, 26 Jul 2023 18:18:25 +0300 Message-Id: <83cz0eog5a.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Mon, 24 Jul 2023 15:18:23 -0400) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> <83v8eg3ue7.fsf@gnu.org> <83a5vpbaa6.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com > Date: Mon, 24 Jul 2023 15:18:23 -0400 > > > OK, how about this? > > Oops, that one didn't include the updated > project-uniquify-dirname-transform docstring. The right patch now: Thanks, installed, with some minor changes as followup. The new test uniquify-home fails for me on MS-Windows: Test uniquify-home backtrace: signal(ert-test-failed (((should (equal (mapcar #'buffer-name bufs) ert-fail(((should (equal (mapcar #'buffer-name bufs) '("~" "~< (if (unwind-protect (setq value-27 (apply fn-25 args-26)) (setq form (let (form-description-29) (if (unwind-protect (setq value-27 (apply (let ((value-27 'ert-form-evaluation-aborted-28)) (let (form-descrip (let* ((fn-25 #'equal) (args-26 (condition-case err (let ((signal-ho (save-excursion (setq bufs (cons (find-file-noselect "~") bufs)) (se (let (bufs) (save-excursion (setq bufs (cons (find-file-noselect "~" (closure (t) nil (let (bufs) (save-excursion (setq bufs (cons (find- ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test ert-run-test(#s(ert-test :name uniquify-home :documentation "uniquif ert-run-or-rerun-test(#s(ert--stats :selector (not ...) :tests [... ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp)))) ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n command-line-1(("-L" ";." "-l" "ert" "-l" "lisp/uniquify-tests.el" " command-line() normal-top-level() Test uniquify-home condition: (ert-test-failed ((should (equal (mapcar ... bufs) '("~" "~<>"))) :form (equal ("~" "nonexistent") ("~" "~<>")) :value nil :explanation (list-elt 0 (arrays-of-different-length 1 7 "~" "~" first-mismatch-at 1)))) The idea of the test is not clear to me, so I cannot tell what could be the reasons. Feel free to ask me to test changes or ask questions about what happens on this Windows system while running the test. From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 03 04:00:45 2023 Received: (at 62621) by debbugs.gnu.org; 3 Aug 2023 08:00:46 +0000 Received: from localhost ([127.0.0.1]:50736 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRTGH-0006fw-6d for submit@debbugs.gnu.org; Thu, 03 Aug 2023 04:00:45 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:41506) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRTGF-0006Nd-2j for 62621@debbugs.gnu.org; Thu, 03 Aug 2023 04:00:43 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRTG9-0002VE-Ci; Thu, 03 Aug 2023 04:00:37 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=aSZ6Q76Zpo3NTQdl+rPXqnq1ATm2x6IdZbZD61SlR84=; b=VFk6MoSyIaMh 6yJ4Y1BEBiY+KZvxB/6g1sNAhyqdhumNPYMsrGi3+gmMvkbSeIdiwjM9M069O4DS86cz2VuAzE96+ Wf5B/lliIQBtrUBj8EtTBwr1VXCIQ4wMImPNFPW6tD0XNiM98Sz3qIbdc8Tigjz8z5yF7s7XPB17R 0yHwLuGVmt9iSdSdnMdiAlHZ+lnkvTXB9RBLIpLkMlIeCGdk4ZcrEW+/LptAGH/K2bPX4wkXlofCG 8fQXDDq2lbPXu8sfgAlY3Jo9i3KCnEBkOddFbFReuItWq9vrWQbvXy16nTeRHOYHRSdJDD2em9BLl 7obwigEliLie31qR9iUcaA==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRTG5-0003gt-Ns; Thu, 03 Aug 2023 04:00:37 -0400 Date: Thu, 03 Aug 2023 11:00:43 +0300 Message-Id: <83v8dwy2qc.fsf@gnu.org> From: Eli Zaretskii To: sbaugh@janestreet.com In-Reply-To: <83cz0eog5a.fsf@gnu.org> (message from Eli Zaretskii on Wed, 26 Jul 2023 18:18:25 +0300) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> <83v8eg3ue7.fsf@gnu.org> <83a5vpbaa6.fsf@gnu.org> <83cz0eog5a.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621 Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Ping! Can this test failure be fixed, please? > Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com > Date: Wed, 26 Jul 2023 18:18:25 +0300 > From: Eli Zaretskii > > > From: Spencer Baugh > > Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com > > Date: Mon, 24 Jul 2023 15:18:23 -0400 > > > > > OK, how about this? > > > > Oops, that one didn't include the updated > > project-uniquify-dirname-transform docstring. The right patch now: > > Thanks, installed, with some minor changes as followup. > > The new test uniquify-home fails for me on MS-Windows: > > Test uniquify-home backtrace: > signal(ert-test-failed (((should (equal (mapcar #'buffer-name bufs) > ert-fail(((should (equal (mapcar #'buffer-name bufs) '("~" "~< > (if (unwind-protect (setq value-27 (apply fn-25 args-26)) (setq form > (let (form-description-29) (if (unwind-protect (setq value-27 (apply > (let ((value-27 'ert-form-evaluation-aborted-28)) (let (form-descrip > (let* ((fn-25 #'equal) (args-26 (condition-case err (let ((signal-ho > (save-excursion (setq bufs (cons (find-file-noselect "~") bufs)) (se > (let (bufs) (save-excursion (setq bufs (cons (find-file-noselect "~" > (closure (t) nil (let (bufs) (save-excursion (setq bufs (cons (find- > ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test > ert-run-test(#s(ert-test :name uniquify-home :documentation "uniquif > ert-run-or-rerun-test(#s(ert--stats :selector (not ...) :tests [... > ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil > ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp)))) > ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco > eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n > command-line-1(("-L" ";." "-l" "ert" "-l" "lisp/uniquify-tests.el" " > command-line() > normal-top-level() > Test uniquify-home condition: > (ert-test-failed > ((should (equal (mapcar ... bufs) '("~" "~<>"))) :form > (equal ("~" "nonexistent") ("~" "~<>")) :value nil > :explanation > (list-elt 0 > (arrays-of-different-length 1 7 "~" "~" > first-mismatch-at 1)))) > > The idea of the test is not clear to me, so I cannot tell what could > be the reasons. Feel free to ask me to test changes or ask questions > about what happens on this Windows system while running the test. > > > > From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 03 07:54:47 2023 Received: (at 62621) by debbugs.gnu.org; 3 Aug 2023 11:54:47 +0000 Received: from localhost ([127.0.0.1]:50989 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRWuh-0002S6-Do for submit@debbugs.gnu.org; Thu, 03 Aug 2023 07:54:47 -0400 Received: from mxout1.mail.janestreet.com ([38.105.200.78]:47757) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRWuc-0002Rr-6P for 62621@debbugs.gnu.org; Thu, 03 Aug 2023 07:54:42 -0400 Received: from mail-ej1-f69.google.com ([209.85.218.69]) by mxgoog2.mail.janestreet.com with esmtps (TLS1.3:TLS_AES_128_GCM_SHA256:128) (Exim 4.96) id 1qRWuW-00BD1V-1n for 62621@debbugs.gnu.org; Thu, 03 Aug 2023 07:54:32 -0400 Received: by mail-ej1-f69.google.com with SMTP id a640c23a62f3a-978a991c3f5so62165266b.0 for <62621@debbugs.gnu.org>; Thu, 03 Aug 2023 04:54:32 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=janestreet.com; s=google; t=1691063672; x=1691668472; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=Lm12sEKIPqDaJfYXCprs9JpyQINhat4RLCHHpHIYvHE=; b=uFdc5mmNS0zX7evrS46M51Bx1U/Gtm+4fa6iOXgHipvSWjaFWIBXO31XRuPsyTwD6a 2i0eM6Pml3Gii2zgZul6kTArsV3it78Gp4jibhV4/3aoUMzEjrhy3V6KBmA4bWgrraMp aeuveGFhiSses3o+a7HR/aJM6CQ8Ek0niXssg= X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1691063672; x=1691668472; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=Lm12sEKIPqDaJfYXCprs9JpyQINhat4RLCHHpHIYvHE=; b=LTM86BvwDC0GxcrcjJui+xbFmmrXXzpyMT6YBk+Ev4jFI7wI5VCIpUI15HjyBlcdsD BzWFNeKcb3Zb5Gc8mSfVwKtIjrko+801LGIaUP9DypSxo6B470dWP12QzQ1Hq9byg4qk udVSfqw4RQa3ZGm0YffB9gFaFcpwj7l/FbfVnhvXjfOhTtR2l/Y+4lm+hs0XIrb0vvC5 mKd9sIb27HZeW/h81psBz7FnH1psYXsTwtTDvaxaDOGyfF51sf34+QRP8F6HJxJAqlDH hA+h9D8Q8+WCmJWYm0F7GsdpSc49isCuaIdY5W4/do3TH6j0ETc1zF0aPVCvbbXK9n0L /dug== X-Gm-Message-State: ABy/qLYvtsVsH7zw1N9zKEoqmmVuvdtJXnm3LyDkvh4UaeBOVCFgQERc 6OpbrzsHUO48hPk8w/dNK1/oCgqn5QH4lWutacMcbh+DWTASVR2k/D4/xp6EdBJYRC6DBvxP34F tsk2/cNSJGQoJ/SVcC1nEYeZ/NtAMjw== X-Received: by 2002:a17:906:84:b0:99b:bf8d:b7e1 with SMTP id 4-20020a170906008400b0099bbf8db7e1mr7192466ejc.17.1691063672135; Thu, 03 Aug 2023 04:54:32 -0700 (PDT) X-Google-Smtp-Source: APBJJlG+o2tFso35Z+sr3gn1IK57W3TPrB2egjQ0+vYtP2uksa1B/uqhCTdlvmfgPzFGuKHSVAsSKV3SGnX37CFffUw= X-Received: by 2002:a17:906:84:b0:99b:bf8d:b7e1 with SMTP id 4-20020a170906008400b0099bbf8db7e1mr7192456ejc.17.1691063671802; Thu, 03 Aug 2023 04:54:31 -0700 (PDT) MIME-Version: 1.0 References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> <83v8eg3ue7.fsf@gnu.org> <83a5vpbaa6.fsf@gnu.org> <83cz0eog5a.fsf@gnu.org> <83v8dwy2qc.fsf@gnu.org> In-Reply-To: <83v8dwy2qc.fsf@gnu.org> From: Spencer Baugh Date: Thu, 3 Aug 2023 07:54:22 -0400 Message-ID: Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename To: Eli Zaretskii Content-Type: multipart/alternative; boundary="0000000000007363cc06020371e1" X-Spam-Score: -0.0 (/) X-Debbugs-Envelope-To: 62621 Cc: Dmitry Gutov , 62621@debbugs.gnu.org, Spencer Baugh X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000007363cc06020371e1 Content-Type: text/plain; charset="UTF-8" On reflection that specific test case is of dubious value, and since it's failing on Windows it means the behavior isn't even consistent anyway. So just delete it. On Thu, Aug 3, 2023, 04:00 Eli Zaretskii wrote: > Ping! Can this test failure be fixed, please? > > > Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com > > Date: Wed, 26 Jul 2023 18:18:25 +0300 > > From: Eli Zaretskii > > > > > From: Spencer Baugh > > > Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com > > > Date: Mon, 24 Jul 2023 15:18:23 -0400 > > > > > > > OK, how about this? > > > > > > Oops, that one didn't include the updated > > > project-uniquify-dirname-transform docstring. The right patch now: > > > > Thanks, installed, with some minor changes as followup. > > > > The new test uniquify-home fails for me on MS-Windows: > > > > Test uniquify-home backtrace: > > signal(ert-test-failed (((should (equal (mapcar #'buffer-name bufs) > > ert-fail(((should (equal (mapcar #'buffer-name bufs) '("~" "~< > > (if (unwind-protect (setq value-27 (apply fn-25 args-26)) (setq form > > (let (form-description-29) (if (unwind-protect (setq value-27 (apply > > (let ((value-27 'ert-form-evaluation-aborted-28)) (let (form-descrip > > (let* ((fn-25 #'equal) (args-26 (condition-case err (let ((signal-ho > > (save-excursion (setq bufs (cons (find-file-noselect "~") bufs)) (se > > (let (bufs) (save-excursion (setq bufs (cons (find-file-noselect "~" > > (closure (t) nil (let (bufs) (save-excursion (setq bufs (cons (find- > > ert--run-test-internal(#s(ert--test-execution-info :test #s(ert-test > > ert-run-test(#s(ert-test :name uniquify-home :documentation "uniquif > > ert-run-or-rerun-test(#s(ert--stats :selector (not ...) :tests [... > > ert-run-tests((not (or (tag :unstable) (tag :nativecomp))) #f(compil > > ert-run-tests-batch((not (or (tag :unstable) (tag :nativecomp)))) > > ert-run-tests-batch-and-exit((not (or (tag :unstable) (tag :nativeco > > eval((ert-run-tests-batch-and-exit '(not (or (tag :unstable) (tag :n > > command-line-1(("-L" ";." "-l" "ert" "-l" "lisp/uniquify-tests.el" " > > command-line() > > normal-top-level() > > Test uniquify-home condition: > > (ert-test-failed > > ((should (equal (mapcar ... bufs) '("~" "~<>"))) :form > > (equal ("~" "nonexistent") ("~" "~<>")) :value nil > > :explanation > > (list-elt 0 > > (arrays-of-different-length 1 7 "~" "~" > > first-mismatch-at 1)))) > > > > The idea of the test is not clear to me, so I cannot tell what could > > be the reasons. Feel free to ask me to test changes or ask questions > > about what happens on this Windows system while running the test. > > > > > > > > > --0000000000007363cc06020371e1 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On reflection that specific test case is of dubious = value, and since it's failing on Windows it means the behavior isn'= t even consistent anyway. So just delete it.

On Thu, Aug 3, 2023, 04:00 Eli Za= retskii <eliz@gnu.org> wrote:
=
Ping!=C2=A0 Can this test failure be f= ixed, please?

> Cc: dmitry@gutov.dev, 62621@debbugs.gnu.org, sbaugh@catern.com=
> Date: Wed, 26 Jul 2023 18:18:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>
>
> > From: Spencer Baugh <sbaugh@janestreet.com>
> > Cc: dmitry@gutov.dev,=C2=A0 62621@debbugs.gnu.org,=C2=A0= = sbaugh@catern.com
> > Date: Mon, 24 Jul 2023 15:18:23 -0400
> >
> > > OK, how about this?
> >
> > Oops, that one didn't include the updated
> > project-uniquify-dirname-transform docstring.=C2=A0 The right pat= ch now:
>
> Thanks, installed, with some minor changes as followup.
>
> The new test uniquify-home fails for me on MS-Windows:
>
>=C2=A0 =C2=A0Test uniquify-home backtrace:
>=C2=A0 =C2=A0 =C2=A0signal(ert-test-failed (((should (equal (mapcar #&#= 39;buffer-name bufs)
>=C2=A0 =C2=A0 =C2=A0ert-fail(((should (equal (mapcar #'buffer-name = bufs) '("~<test>" "~<
>=C2=A0 =C2=A0 =C2=A0(if (unwind-protect (setq value-27 (apply fn-25 arg= s-26)) (setq form
>=C2=A0 =C2=A0 =C2=A0(let (form-description-29) (if (unwind-protect (set= q value-27 (apply
>=C2=A0 =C2=A0 =C2=A0(let ((value-27 'ert-form-evaluation-aborted-28= )) (let (form-descrip
>=C2=A0 =C2=A0 =C2=A0(let* ((fn-25 #'equal) (args-26 (condition-case= err (let ((signal-ho
>=C2=A0 =C2=A0 =C2=A0(save-excursion (setq bufs (cons (find-file-noselec= t "~") bufs)) (se
>=C2=A0 =C2=A0 =C2=A0(let (bufs) (save-excursion (setq bufs (cons (find-= file-noselect "~"
>=C2=A0 =C2=A0 =C2=A0(closure (t) nil (let (bufs) (save-excursion (setq = bufs (cons (find-
>=C2=A0 =C2=A0 =C2=A0ert--run-test-internal(#s(ert--test-execution-info = :test #s(ert-test
>=C2=A0 =C2=A0 =C2=A0ert-run-test(#s(ert-test :name uniquify-home :docum= entation "uniquif
>=C2=A0 =C2=A0 =C2=A0ert-run-or-rerun-test(#s(ert--stats :selector (not = ...) :tests [...
>=C2=A0 =C2=A0 =C2=A0ert-run-tests((not (or (tag :unstable) (tag :native= comp))) #f(compil
>=C2=A0 =C2=A0 =C2=A0ert-run-tests-batch((not (or (tag :unstable) (tag := nativecomp))))
>=C2=A0 =C2=A0 =C2=A0ert-run-tests-batch-and-exit((not (or (tag :unstabl= e) (tag :nativeco
>=C2=A0 =C2=A0 =C2=A0eval((ert-run-tests-batch-and-exit '(not (or (t= ag :unstable) (tag :n
>=C2=A0 =C2=A0 =C2=A0command-line-1(("-L" ";." "= ;-l" "ert" "-l" "lisp/uniquify-tests.el"= "
>=C2=A0 =C2=A0 =C2=A0command-line()
>=C2=A0 =C2=A0 =C2=A0normal-top-level()
>=C2=A0 =C2=A0Test uniquify-home condition:
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(ert-test-failed
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 ((should (equal (mapcar ... bufs) '(&qu= ot;~<test>" "~<>"))) :form
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(equal ("~" "nonexistent"= ;) ("~<test>" "~<>")) :value nil
>=C2=A0 =C2=A0 =C2=A0 =C2=A0:explanation
>=C2=A0 =C2=A0 =C2=A0 =C2=A0(list-elt 0
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0(arrays-o= f-different-length 1 7 "~" "~<test>"
>=C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 = =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2=A0 =C2= =A0 =C2=A0 =C2=A0first-mismatch-at 1))))
>
> The idea of the test is not clear to me, so I cannot tell what could > be the reasons.=C2=A0 Feel free to ask me to test changes or ask quest= ions
> about what happens on this Windows system while running the test.
>
>
>
>
--0000000000007363cc06020371e1-- From debbugs-submit-bounces@debbugs.gnu.org Thu Aug 03 10:05:12 2023 Received: (at 62621-done) by debbugs.gnu.org; 3 Aug 2023 14:05:12 +0000 Received: from localhost ([127.0.0.1]:52632 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRYwx-0006iZ-Um for submit@debbugs.gnu.org; Thu, 03 Aug 2023 10:05:12 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:50440) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qRYwv-0006iI-99 for 62621-done@debbugs.gnu.org; Thu, 03 Aug 2023 10:05:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRYwp-0006z1-07; Thu, 03 Aug 2023 10:05:03 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=8a0kUAPky64x8tZPzofVUK0aTDJ/TSxvvF8oOZk26DE=; b=VFtD75wWnh/J jWXAZAzhuFV/HMR1KhPIEQLg526bwUg4J3JA+/gZg/Yuc6i1a5GNBG+xFPGh5NQlMqHyiJYZC25Dc X+0WnLSDEunWWFr1I+DrivgPpEegnq3DFIe7edcxVQ/QlMHbIZq5WY2YwYTZM0YNdM3fTL1O3Q9aE CJf58T3HBlCb5ZV2u3SjnVCwAKfd9RXW4wbUgxY8e8V/DbCvzsCSppG5dHOUSvCHtCgsLO6jSscaX Kg6KDxGpfjobZ2jXazYTUp425YDumuq1PIjjrQAuxw1LhHy/oDW/vwmYvulmOE/MGm5pEcMX6Ni8W 3OJPwCIyhqukSTLBdZ3Tsg==; Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qRYwn-0007za-Gf; Thu, 03 Aug 2023 10:05:02 -0400 Date: Thu, 03 Aug 2023 17:05:10 +0300 Message-Id: <831qgkxlux.fsf@gnu.org> From: Eli Zaretskii To: Spencer Baugh In-Reply-To: (message from Spencer Baugh on Thu, 3 Aug 2023 07:54:22 -0400) Subject: Re: bug#62621: 29.0.60; uniquify can't make buffers unique based on things other than filename References: <87bkgfjugn.fsf@catern.com> <83edlb3t0t.fsf@gnu.org> <22ee6190-5946-9bde-b648-a55dd2188576@gutov.dev> <83mszt7a1a.fsf@gnu.org> <5c266c9b-a719-41d9-327e-6a2152adaffe@gutov.dev> <838rbc5c8v.fsf@gnu.org> <83v8eg3ue7.fsf@gnu.org> <83a5vpbaa6.fsf@gnu.org> <83cz0eog5a.fsf@gnu.org> <83v8dwy2qc.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-Debbugs-Envelope-To: 62621-done Cc: dmitry@gutov.dev, 62621-done@debbugs.gnu.org, sbaugh@catern.com X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Spencer Baugh > Date: Thu, 3 Aug 2023 07:54:22 -0400 > Cc: Dmitry Gutov , 62621@debbugs.gnu.org, > Spencer Baugh > > On reflection that specific test case is of dubious value, and since it's failing on Windows it means the > behavior isn't even consistent anyway. So just delete it. Done, and closing the bug. From unknown Sat Sep 20 01:11:45 2025 Received: (at fakecontrol) by fakecontrolmessage; To: internal_control@debbugs.gnu.org From: Debbugs Internal Request Subject: Internal Control Message-Id: bug archived. Date: Fri, 01 Sep 2023 11:24:05 +0000 User-Agent: Fakemail v42.6.9 # This is a fake control message. # # The action: # bug archived. thanks # This fakemail brought to you by your local debbugs # administrator