From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Drew Adams Newsgroups: gmane.emacs.bugs Subject: bug#52593: [External] : bug#52593: 28.0.90; (thing-at-point thing) has so much overhead since commit 7db376e560448e61485ba054def8c82b21f33d6a Date: Fri, 24 Dec 2021 22:43:00 +0000 Message-ID: References: <83zgoybbfr.fsf@gnu.org> <83ee689156.fsf@gnu.org> <87h7b0er9q.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="1731"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "52593@debbugs.gnu.org" <52593@debbugs.gnu.org> To: Lars Ingebrigtsen , Kang Niu Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Fri Dec 24 23:44:13 2021 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1n0tIK-0000GU-QH for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Dec 2021 23:44:12 +0100 Original-Received: from localhost ([::1]:40514 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1n0tII-0004q1-LD for geb-bug-gnu-emacs@m.gmane-mx.org; Fri, 24 Dec 2021 17:44:10 -0500 Original-Received: from eggs.gnu.org ([209.51.188.92]:42442) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1n0tIB-0004pt-2G for bug-gnu-emacs@gnu.org; Fri, 24 Dec 2021 17:44:03 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:54929) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1n0tIA-00065H-Mn for bug-gnu-emacs@gnu.org; Fri, 24 Dec 2021 17:44:02 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1n0tIA-00074i-HK for bug-gnu-emacs@gnu.org; Fri, 24 Dec 2021 17:44:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Drew Adams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 24 Dec 2021 22:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 52593 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch moreinfo Original-Received: via spool by 52593-submit@debbugs.gnu.org id=B52593.164038579127117 (code B ref 52593); Fri, 24 Dec 2021 22:44:02 +0000 Original-Received: (at 52593) by debbugs.gnu.org; 24 Dec 2021 22:43:11 +0000 Original-Received: from localhost ([127.0.0.1]:38242 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0tHK-00073J-TH for submit@debbugs.gnu.org; Fri, 24 Dec 2021 17:43:11 -0500 Original-Received: from mx0a-00069f02.pphosted.com ([205.220.165.32]:57512) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1n0tHF-000736-N3 for 52593@debbugs.gnu.org; Fri, 24 Dec 2021 17:43:09 -0500 Original-Received: from pps.filterd (m0246627.ppops.net [127.0.0.1]) by mx0b-00069f02.pphosted.com (8.16.1.2/8.16.1.2) with SMTP id 1BOExUwr003142; Fri, 24 Dec 2021 22:43:04 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-2021-07-09; bh=dkdmX2Tf46MPGWqUOnfPOrRmZoytMoH74ppy9LHkXKA=; b=XCfYZo2THCXWyKbv07HjqHTVFxPDiaT33GZb3Xek5TDc5Ze5oI5Yg9FfLWs4dvE0vq/X lF1Xgxw0XwGedEufBeJWLrEOGBpoMuepZ9akrxWEYYD0NP8jUPUqGCxNoct2x+vlMshN 8i1PVIMj2ZpwJMVg0nG/chYbyDJO1lnucjbiEJ9B8wqLn6uum95fYiSJqJ35RgITK6XQ fxOvUY8LdDUYUOzFMUh+MViSsBE/rYFtbU6E1ntMY6INt/kGOGI8kca3YReibyg1ZeaN FfeboVcqnOTWNPzLwD+jBFmI/WteW4MFhJsQBUzp0Q0pciyft5kLbnoopkPnfaat6Ogk 4A== Original-Received: from userp3030.oracle.com (userp3030.oracle.com [156.151.31.80]) by mx0b-00069f02.pphosted.com with ESMTP id 3d4f6w3vh0-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Dec 2021 22:43:04 +0000 Original-Received: from pps.filterd (userp3030.oracle.com [127.0.0.1]) by userp3030.oracle.com (8.16.1.2/8.16.1.2) with SMTP id 1BOMf9wm030930; Fri, 24 Dec 2021 22:43:03 GMT Original-Received: from nam10-mw2-obe.outbound.protection.outlook.com (mail-mw2nam10lp2103.outbound.protection.outlook.com [104.47.55.103]) by userp3030.oracle.com with ESMTP id 3d14s20m2g-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Fri, 24 Dec 2021 22:43:02 +0000 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=kxMpEZuuMKux4lLflxN2eguns7ATgFl+E3XdlBsdSp7RwE6vWKkwTPswZo8BEGwwmiwQ3GbIWLeQLxWFJCE+HLhUSeIIkUcSJ7buQf5PsKf0hRKjWdAtbA5GwiE0JeLLosUtcPVPy9qiegxNGTzjX8CCUseQ5NaW0zC4MXLQUmvcRwUwUvnK+BeUUypF7Og7DF0oQRbXtJxmMEclpVO0y0CQwJuf9k4u3VLVUXI74tflP3AfNbhhvMcbELuGHc8sDVCCMjewDLiVq8nepw2VdGOe2c8zVVmpQKgazdCy5JdwQ0xkiOylqOVX2iyWdYXMXpxA2BzRb+lXZjZUOKkLxg== 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=dkdmX2Tf46MPGWqUOnfPOrRmZoytMoH74ppy9LHkXKA=; b=ZgEzn5x2O92Kavq42pT1tMbHlik7lf+ughGOuTTnzro7Cn578SZ/1IXbZOZCFVA56sTejezu6wX491vTFQ1hQhSetJowSKrITrtnVFJgrKrkj4VilQ/D7qyF21GfM+66MH94OpRQnu+SpzQpW8GmV/Unuk8BARr5hW4n6Bro9mAyuM7A29Qb+AcVCvW+5UawstaT5vQaZw4MMSPdswAHiEi5G++sTWjId1y9uuQtVYh3WH1TReLTu4C2yn2CCSBBI8w924LVQGBdHdTKytHuNvi6oaPLd6InkXb1W6OYFy66WTbdOp78kVNrKKtZDZ5qFNEcuNHzd60Rju+u0FKt0g== 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=dkdmX2Tf46MPGWqUOnfPOrRmZoytMoH74ppy9LHkXKA=; b=0FtTh7A/5fBIRBr2do+Fzdy0uVyYNBR9i0kb8djohqbzs1KYNzpMtdIi9r/zf7BrMK1kZI9e8Rac3QZ3EdsV9mOdMkCuByG4d1XvxVcx+V2m7miKyGaNpK145sAkXGhBo/AGKvTThwdc1KXgeP76Nws0bKWpK+HU98q5LgNXyqg= Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com (2603:10b6:a03:37e::19) by BYAPR10MB2518.namprd10.prod.outlook.com (2603:10b6:a02:b8::33) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.4823.16; Fri, 24 Dec 2021 22:43:00 +0000 Original-Received: from SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3]) by SJ0PR10MB5488.namprd10.prod.outlook.com ([fe80::99a4:696f:5f30:36b3%8]) with mapi id 15.20.4823.021; Fri, 24 Dec 2021 22:43:00 +0000 Thread-Topic: [External] : bug#52593: 28.0.90; (thing-at-point thing) has so much overhead since commit 7db376e560448e61485ba054def8c82b21f33d6a Thread-Index: AQHX9zLekdYKoHs8Q0KkFf1Rss8PwaxCN16w In-Reply-To: <87h7b0er9q.fsf@gnus.org> Accept-Language: en-US Content-Language: en-US x-ms-publictraffictype: Email x-ms-office365-filtering-correlation-id: 6105f088-243e-4dc9-a63f-08d9c72ebd18 x-ms-traffictypediagnostic: BYAPR10MB2518:EE_ x-microsoft-antispam-prvs: x-ms-oob-tlc-oobclassifiers: OLM:10000; x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: qbBKF8GVNO2sTch1mB/DvHt+JMSy+wDzZ9jOUSTewe1VY4BQP7WeTyfLC9NxbFo2cLMMKSMO28HOFpgPvkHtkQTKEjjupZWhpdQX0SbL1YhM96XftNbnZLyO61w47gnysAfPJVYU4CgOfOo/gA9uMX2h1lTcefm7KKLaT0Lt0aJo2SnUrGW0WvqfTzRx8bj39tsb50h38EyVwVCN0iyNW3439RBhr5FVrcClJxd4PYMHuqD/xmwQpi3eRtazwifFtEF7O/5aNMrMZiJ/Zf1IpMlTJpAPCUhIRVRzpdmu7c/1LXwy0CMmwJYXmBOgarP73B0ecUp9VZ52F4/hxfwVd6/7ygmprF2bCbFxgZ+onlat0jYfCBkd5dCxaweIdgruOCLBRGSPk66TuW3UKFxRyc6k0j3yJ66Fr0uIRDLi22XSWdM4xBMuf3zaG915xxB6pjF2zBw3epyKKewUfzfQECtWL7VlIRNRQXI5m+qT4R5cGynrpIisPCbJzcxCAm+L6of08sz0y3TGlY4wtPgzNedXjxLaqVrDEaj0ECEJrCaG6Lzq/lL01Qa8mwxRM6lRoeDcEUZN8iXfCOIBCfXJhyo41BogEv0IQLbXmGJeee74sz7lkCsvEDCcREDGHlj8iP9vgW7SBPRCdLv3TMEvf+MzG0L8VsojFNVHjD6pyBDMizbFYyGv8TxQYH56ZpMGK4j+vdYefEU/fVSzXFqqaw== 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:(366004)(76116006)(8676002)(66556008)(52536014)(66476007)(64756008)(44832011)(38100700002)(66946007)(508600001)(66446008)(122000001)(71200400001)(8936002)(9686003)(186003)(7696005)(83380400001)(110136005)(26005)(2906002)(38070700005)(55016003)(33656002)(5660300002)(86362001)(6506007)(316002)(4326008); DIR:OUT; SFP:1101; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: hu61jJs92R77eGGSXy43RafeB3LaaNTZvyIBufpigzToeKeS1HJH9cuMDW+p/F/wLaJNKgRh6mY4HzTJgP8WQtW1w7G6LceFH1VAzjcLlM4m/T+AKOWW0XYFqiI5vTxfHOZRd11RmTPd02LHkC/NX7JqO9rjUxSnp4Bgvd1HuZLDSCUlJL4bnrfBN8cOCNA1+7pA6ykqJ91isI1q8vKV+eshFII2lXffGgCp4C+H2JOzsdBASPE7eZ915QcGMIhwZZ8JstQgxL0IBGJNpB94Nsg0XbfZuhcyx5UNhjQ5NKOlwtzO35xdlLRW6dgJmc3kRYMEwWxtmbBaXlzmqJHQXItunfKCckriRvzPQgpKDaXszgRb8yi2pF9o2+87IEu/n21iLI41b2D5Unfpg7PNGuJRKDMDjQ+izc3/meVXq71gkkPU3LeNh9tjDmU/odtZO/y4dqbYUkxS/9FSPIf6Oj1ISVLL096drWePQsLoLRVKjp8ctRUBbVUjcdS9X5j7pXOeGRAvmjJD1nyXNoaqPePuY6B/EnjK5/oiyU/QU1SMGrUjiRn/OfhcLUrA14/+iid20yy+Dr4XZ5gWk/xuc7fIDi0qt43p5HknyvucWP78r+qrGg+XSAz/1yb6o8IktEiOl3FJUox3Vg/Q1zgg2RWb3lw2T9At3Hk8lYhVgU/kCkWeM2Figbmkj52BeVu+uxMgPnT8EvzJBdwuItTB6AUa+ZqM0s0Ls/4sNp/of47HqV/BlyyZZEgL2O faar4S8etnvCNPQCprQSGHO7R+S5sXCZhz/l7JihqnJLtftokpjf4T++MKDSphfDZkbGobzFQFft1JRFtY7Y5KxSJvJjyXOLJ+ 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: 6105f088-243e-4dc9-a63f-08d9c72ebd18 X-MS-Exchange-CrossTenant-originalarrivaltime: 24 Dec 2021 22:43:00.4255 (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: zbfj2NbyqXYn8sgbF2cnHtazl2gPya9HZjWlFmZuPMHhoepZ+q1tvgJEUZgy5InYhGLsHNw671zg4Vk9agNHAw== X-MS-Exchange-Transport-CrossTenantHeadersStamped: BYAPR10MB2518 X-Proofpoint-Virus-Version: vendor=nai engine=6300 definitions=10208 signatures=668683 X-Proofpoint-Spam-Details: rule=notspam policy=default score=0 bulkscore=0 malwarescore=0 adultscore=0 phishscore=0 suspectscore=0 mlxscore=0 mlxlogscore=999 spamscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.12.0-2110150000 definitions=main-2112240115 X-Proofpoint-GUID: LsGQ4eytY9iYGB_xHMibUWFoEHV8RtCx X-Proofpoint-ORIG-GUID: LsGQ4eytY9iYGB_xHMibUWFoEHV8RtCx X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:223073 Archived-At: > > Maybe an optional arg for thing-at-point is necessary to respect fields= ? > > As I understand, it should be determined by the user of thing-at-point = to > > get what kind of thing at point. If the user knows or expects fields in > > the text, he passes the optional arg. If the user just wants the "norma= l" > > thing at the point whether there are fields or not, he calls it without > > the opt arg as the old way. That's right - or almost so. It's definitely right that thing-at-point functions should not, on their own and systematically, limit their check/search to a field that might be present. That would be awful. But I think it should not just be an argument to thing-at-point functions that controls/decides this. Users, not just Lisp code, should be able to control whether thing-at-point functions limit checking to a field at point (when a field is present). That means either a user option or a defvar that users and code can bind, to get the behavior they want. But this question of how/where to tell a thing-at-point function what to do about fields is a secondary question. ___ I disagree strongly with Lars that from now on all code that uses thing-at-point functions should have its behavior changed to always respect a field at point. That would not only break existing code; it would be inflexible for no reason. IIUC, this is essentially about wanting to add a NEW feature, which is that thing-at-point functions can BE ABLE to return a thing (of the given kind), while limiting the check/search to a field at point. There's nothing wrong with adding that possibility, as an optional feature. It would be terribly wrong to just impose such (backward incompatible) behavior going forward. Again: IIUC. > If a package uses fields to make the buffer more > understandable, then other packages like symbol-overlay > should use those fields automatically without having to > be altered. Other packages "should"? No. Other packages should perhaps _be able_ to. Let's not be draconian, please. Just because one package uses fields to "make the buffer more understandable", it does not follow that all (or even any) other packages want or need to take that particular understandability into account when checking for a particular kind of thing at point. That doesn't follow at all. You have no way of knowing what some arbitrary other package might want to do. Supposing that all packages must want to respect fields that are provided by some package (for all of their behavior no less!) is, well, misguided. > Ideally the way to make this work would be to change all the thingatp > functions to do their normal thing, but then see whether there's any > field separators in that area, and if so, recalculate the "thing". No, definitely not. Thing-at-point functions can be made _able_ to "recalculate the thing". They should not do so systematically or generally. > I think at this point, the way forward is to revert this change on > emacs-28 to fix the performance regression, and then open a new bug > report for this. So I'll do both now. The bug is not just a performance one (IIUC). The bug is in the misguided design that limitation to a field is what thing-at-point functions should always, or even generally or by default, do. Adding the ability to respect a field at point makes sense. The fact that a buffer has been given fields should not, by itself, control what thing-at-point functions do. It can reasonably _inform_ what they do.