From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Shynur Xie Newsgroups: gmane.emacs.devel Subject: Re: Bug? Date: Fri, 5 May 2023 16:18:54 +0000 Message-ID: References: <875y9aciir.fsf.ref@yahoo.com> <875y9aciir.fsf@yahoo.com> <9DC42D1F-2061-48ED-932B-9704538356C8@acm.org> <380B9B5B-9FB9-4A99-830B-117A33519D3A@acm.org> <838re5mzcu.fsf@gnu.org> <83v8h7jsph.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="12739"; mail-complaints-to="usenet@ciao.gmane.io" Cc: "mattiase@acm.org" , "emacs-devel@gnu.org" To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri May 05 18:19:54 2023 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1puy9w-0003BT-US for ged-emacs-devel@m.gmane-mx.org; Fri, 05 May 2023 18:19:53 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1puy97-0003kY-3E; Fri, 05 May 2023 12:19:01 -0400 Original-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 1puy95-0003jD-E1 for emacs-devel@gnu.org; Fri, 05 May 2023 12:18:59 -0400 Original-Received: from mail-sn1nam02olkn2057.outbound.protection.outlook.com ([40.92.44.57] helo=NAM02-SN1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1puy93-0000Ft-DX; Fri, 05 May 2023 12:18:59 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=LJG9T5oWDI4TOo0WG7cI7HDjIQgNwlIWZMW6Mbggy8rKZZaX/SsI0wrZCas4JwhZTNysilXJCRZBVh2gZowymhYf7q+X1uEnWXCgG3bzPoa0Q53WfVxVbJmCcQPtf0sqNGmrSe/8r+E3hoBK+XbxzDewxtl6qwkks82DKNnIaeb/DQc3ygNsPCBZGk4MNA9DxJAUuThlaf1mrobVhUO6Oac1/G/T5u7oNQIICx58wwxGql97ZqF3uCbRVEU+ayC2W9gDEaE8fh5nssZOLW7WTFpXAz6US4JunJDb4iv4jnJ2ntO9IbVPVKyBANvgInAUdPnimSTadQkh5llbyw848w== 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=srgZc9xv90NxRYlAe9Y6WIWlqMdJG5oPabIz/x8/nSo=; b=TeZ+vYc48YaxBGPHTo0MQGb3r54VoHqjwBhx8xesxwtGIqNS7qB/ahu45lN57X6wfPsO655cWS3/CgqJM4JwGIj2MprLR2zTstF27PO271s1v8eOJJrBWgysNKPH7AYHpPb8bpoY/ZsFQZVPephWWjOIQlGiaVOChcRlmN31yxnEj+5lPqNkQuxjfo9JmOpI0v2n9Bl2k/TwuBPQijhz9ACyWsJQwRfnk17oDPh5kxq3z7Q7g2wjjk91yYOHKKxBOuw29rKUsZxB+IT3OSYfzmpj9p/8OFnI+LqvwbFWKlzgxP7WCJeLzlO0qvZvz8vtvv00pcsZZTvX4mFWOAEqKA== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=outlook.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=srgZc9xv90NxRYlAe9Y6WIWlqMdJG5oPabIz/x8/nSo=; b=I+5qWrmx7kEgdYvF5bNhYOFnvkuUVpHqC+nlqoTN7tfcxn4qMzXfod1BbFA2gLRMwdT6NIafPoaic3XMVyIa3v3RbZRtm9kre6gQJXfYclujEKRXjVbylhl4L94XHH8DS3tsa2q0XUB95KaVM61a/oBIz+7HEGKn9472Xim9tOHi5Bxyo6MTx9GJZfwBHgsY5Avqqn8o+ubK+hF59NCgwmMFWXIzlEqr/eG3M4gIQLzcQdnyDwIfagczfwdsw6JJmnRaQ881C9dM+IFGHiuW4fVq3GeAFT8rn341CFCYp5H/W+d6pIAJVLgfzU+1IfAmqKHfgON6YkRRlY/t0003Ww== Original-Received: from SA0PR04MB7433.namprd04.prod.outlook.com (2603:10b6:806:e2::8) by DM6PR04MB6560.namprd04.prod.outlook.com (2603:10b6:5:1b7::10) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.27; Fri, 5 May 2023 16:18:54 +0000 Original-Received: from SA0PR04MB7433.namprd04.prod.outlook.com ([fe80::9fe0:ce70:5b47:8989]) by SA0PR04MB7433.namprd04.prod.outlook.com ([fe80::9fe0:ce70:5b47:8989%7]) with mapi id 15.20.6363.027; Fri, 5 May 2023 16:18:54 +0000 Thread-Topic: Bug? Thread-Index: AQHZfaNGszu99UqFS0ucz7esmA6Jfq9IVCqAgAAUGTSAAjJWGIAAgYzwgADC9i8= In-Reply-To: <83v8h7jsph.fsf@gnu.org> Accept-Language: en-US, zh-CN Content-Language: en-US x-ms-exchange-messagesentrepresentingtype: 1 x-tmn: [pY2kq5jYYpM+4Ft9rq4Pnz+Rx5pbvkNG] x-ms-publictraffictype: Email x-ms-traffictypediagnostic: SA0PR04MB7433:EE_|DM6PR04MB6560:EE_ x-ms-office365-filtering-correlation-id: 9fcdb169-12c3-4c54-f25d-08db4d846c05 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: S4WMMRPMJjncsjTKUaTChuVglyO+8UjBf5OK/qZQcSzIzPS+6l8FKrdJBH3zRyA4nc1wS5RcL1f7y1qpoIPdlWo/AMNW59jHdvZM0WnR480ZeUEv6VEwdl+lNQGRh+EOib5Ix9nwbIsJSviBUiGAOy7YjZIMcd5yntpZfSwmvAWJlHiShb/Ilkdkh0Gz8XnWgKDCK6HYxvwjQTw+1DUNOIaZxQ+tF9FgB/QkxEk6n7HvVq2ILlXj+M6vrCSrh+XdMn6pBWS0gsgJp1s7AQIxkt+CnIRkp/xH0ScVNeDBac5UrA6/R3EnWOzUNXseReD6y/qm7sr7Y23F4rVd5bNzOg7fK/blKkg+MINFpagP4ytu02AGGFFqirjSpXa1aQkGMkOo9bnGn0oxPmtb6K92Tc54y1sbS49Ogpyofdv8p7JPyGNbAS10RJiw/DZ/Tt4+E06j+knUYR+6HCC6yo1T0EH9cbcbrOEZgOD6gwbDdzH4qGNC3l3B2eXeUq6ttGWXe2kUM/loN9KeFSoB9A7WwyWTPomQLKQInsR4Jdiay/GGwJcqpQ4d5xs1s3fKA+EZzQfud3mJ4LXPXsSUl9uLmEbYPbctFHhjvrkjhQVpai+DTtqre0uYl/Y5LVZTUfl2 x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-1?Q?WJ/Q1qcGCbnvw6/9Kf2+h8j/4i5HOLAhxXqH/G4Q3vCa6APRCfqsyP5CtK?= =?iso-8859-1?Q?v9Zk01b8J+sdWwWqgQwx6fLeHdrlGO39zLQ9F/+FZuJBX5/7JFTyZ5t2hy?= =?iso-8859-1?Q?2AmUBmWFxAugGZ5nbIvh1yRdZ+z7+CQ3GKIEGk/pEAWqUhjYb3fTJrt0dF?= =?iso-8859-1?Q?5ldZ+VRA+/xWuFxzOb2Lyrx2yOJGuncENh97wRTpuC4BzltqzfYd0/bF2u?= =?iso-8859-1?Q?OFeNwruhGywJphnXaVXfUTTJjff7tDtAVOKyZ+r7v+n9PuKQ+aNFEiVC1N?= =?iso-8859-1?Q?2c8ZqTT5Xk8jiXZ3KLyHetNGyayqXQEgnKVDv1MrcHIc7pG9wEnupypgj9?= =?iso-8859-1?Q?Rl/p0N9fRGgmtXyvUpKmk9eKqtsSWVvNTBO8Ctf/E2S34dWks9aQqdntWM?= =?iso-8859-1?Q?eYumn9FvvoNut5x3GKEsmnCuhF8Om2wN44kZjty4XW1L0Jeh/H8l4d7l8a?= =?iso-8859-1?Q?sT1FwCvut7bnnnHtrb+z5z/l3y8/Tctp6Us/fHmVBihbP8/TLoKW2cIWgs?= =?iso-8859-1?Q?Lw18TMEn5nICT27uLgz4W2mX+3p0oP8FgnD0ZUdSWR/HvXEtyeUJHU4sWf?= =?iso-8859-1?Q?8TMX85KM491I6jv7qUgBchR3Tcrn6QXZPZ7Sx4S3tUuHv8W/KSvzYiUnqi?= =?iso-8859-1?Q? X-OriginatorOrg: outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: SA0PR04MB7433.namprd04.prod.outlook.com X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-Network-Message-Id: 9fcdb169-12c3-4c54-f25d-08db4d846c05 X-MS-Exchange-CrossTenant-rms-persistedconsumerorg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-CrossTenant-originalarrivaltime: 05 May 2023 16:18:54.6303 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-Transport-CrossTenantHeadersStamped: DM6PR04MB6560 Received-SPF: pass client-ip=40.92.44.57; envelope-from=one.last.kiss@outlook.com; helo=NAM02-SN1-obe.outbound.protection.outlook.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.devel:305883 Archived-At: > From: Eli Zaretskii=0A= > Subject: Re: Bug?=0A= > Date: Fri, 05 May 2023 07:41:14 +0300=0A= > To: Shynur Xie=0A= >=0A= > didn't you tell that the problem reported above is not a bug, but=0A= > the expected and long-time behavior of blink-matching-paren?=0A= =0A= Yes, it is not a bug to the original author of this function. But now=0A= `show-paren-mode' also uses this function, which leads to a bug, or at=0A= least a counterintuitive behavior:=0A= > From: Mattias Engdeg=E5rd=0A= > For example, in shell-script-mode, when `esac` matches `case`, only=0A= > the `c` in `case` is high-lit.=0A= =0A= _____________________________=0A= =0A= Let me explain it in details.=0A= =0A= At first (when emacs-version is 28.2), there was only the function=0A= `blink-matching-open'. Later, someone refactored this function, by=0A= separating out a part of it, thus there is a function named=0A= `blink-paren-open-paren-line-string' now.=0A= =0A= Both of the above 2 functions are defined in to=0A= implement the basic parenthesis matching feature (let's call it=0A= `blink-matching` for now) mentioned in:=0A= > (emacs)26.4.3=0A= > Emacs _briefly_indicates_ the location of the matching opening=0A= > delimiter, ... If it is not on the screen, Emacs displays some of=0A= > the text near it in the echo area."=0A= =0A= The goal of `blink-matching` is just to _briefly_indicate_ the=0A= location of delimiter (such as '(' in Lisp and 'case' in Bash), so it=0A= is reasonable to _treat_only_the_1st_character_of_a_delimiter_=0A= specially -- `blink-matching` highlights only the 1st character (to=0A= observe this, you need to disable `show-paren-mode' first) when the=0A= matched delimiter is on-screen; when it's off-screen, only the 1st=0A= character is made sure to be contained in the message that is shown in=0A= the echo area. For example, in `shell-script-mode', when off-screen:=0A= case case <- off-screen=0A= ^=0A= ... <- many empty lines=0A= esac* <- cursor here=0A= only "case c" is shown in the echo area. Thus my first patch can only=0A= highlights "c" because "ase" is not contained at all. So=0A= > From: Mattias Engdeg=E5rd=0A= > I also noticed that when the closing bracket is comprised of=0A= > multiple characters, only the first character is high-lit using that=0A= > face.=0A= =0A= _____________________=0A= =0A= > From: Eli Zaretskii=0A= > Shynur, could you please fix this deficiency?=0A= =0A= Deficiency, yes, it is, and belongs to `show-paren-mode'.=0A= =0A= Let's take a look at what `show-paren-mode' provides first:=0A= > (emacs)26.4.3=0A= > Show Paren mode is a minor mode that provides a _more_powerful_ kind=0A= > of automatic matching.=0A= So this mode treats the entire matched delimiter specially, instead of=0A= only the 1st character. For example, in `shell-script-mode', when=0A= on-screen:=0A= case <- on-screen=0A= ^^^^=0A= esac* <- cursor here=0A= the entire "case" is highlit.=0A= =0A= But when off-screen, if `show-paren-context-when-offscreen' (an option=0A= of `show-paren-mode') is t, the job of showing the matched off-screen=0A= delimiter in the echo area is taken by `show-paren-mode' instead of=0A= `blink-matching`.=0A= =0A= I notice that `show-paren-mode` does this job=0A= _simply_by_invoking_`blink-paren-open-paren-line-string'_, which=0A= assumes that only the 1st character of the matched delimiter needs to=0A= be treated specially -- same example as the first one I mentioned:=0A= case case <- off-screen=0A= ^=0A= ... <- many empty lines=0A= esac* <- cursor here=0A= "case c" is shown in the area.=0A= =0A= > From: Eli Zaretskii=0A= > This seems to be about show-paren-mode, not about=0A= > blink-matching-paren.=0A= =0A= About both, IMO. They both use `blink-paren-open-paren-line-string'=0A= but this function only guarantees the returned string containes the=0A= 1st character of a delimiter, which is suitable for `blink-matching`=0A= but not for `show-paren-mode'.=0A= =0A= _____________________=0A= =0A= > From: Eli Zaretskii=0A= > what exactly does this patch fix?=0A= =0A= It fixes cases such as "case c". Thus, if=0A= `show-paren-context-when-offscreen' is t, "case case", which contains=0A= the entire matched delimiter -- "case", will be shown in the echo=0A= area. And if `blink-matching-paren-highlight-offscreen' is also t,=0A= "Matches case case"=0A= ^^^^=0A= the entire delimiter, instead of only its 1st character, will be=0A= highlit.=0A= =0A= --=0A= shynur=