From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Arthur Miller Newsgroups: gmane.emacs.devel Subject: Re: Info-mode patch Date: Tue, 04 Jul 2023 11:43:38 +0200 Message-ID: References: <86wmzpqva6.fsf@mail.linkov.net> <867cropyh3.fsf@mail.linkov.net> <86mt0kulli.fsf@mail.linkov.net> <86wmzmzs1s.fsf@mail.linkov.net> <86edluyxhl.fsf@mail.linkov.net> <86bkgxfm34.fsf@mail.linkov.net> <86zg4gddtf.fsf@mail.linkov.net> <86v8f2xkr4.fsf@mail.linkov.net> <86v8f04yws.fsf@mail.linkov.net> <86fs64maiv.fsf@mail.linkov.net> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13984"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jul 04 12:55:01 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 1qGdgR-0003S6-G4 for ged-emacs-devel@m.gmane-mx.org; Tue, 04 Jul 2023 12:55:00 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGdfm-0002eR-Nf; Tue, 04 Jul 2023 06:54:18 -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 1qGcZY-0005qh-MT for emacs-devel@gnu.org; Tue, 04 Jul 2023 05:43:48 -0400 Original-Received: from mail-he1eur04olkn2052.outbound.protection.outlook.com ([40.92.73.52] helo=EUR04-HE1-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 1qGcZT-0000tg-Lq for emacs-devel@gnu.org; Tue, 04 Jul 2023 05:43:48 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EIXWgK2gMJTztRr1IZWV2StDwtX3TFZyQ4xoz1g/NyjdHw6Q34+KoKsJvTokdR6oOi+ixvHYag+G/KPHuG4iSc+LkSTNAXrRDm3RRtFEzsjEMOoXkTo+9Dc9E9vU1WQPgju38iRNO3eMT7uv6mwjdPnzZfgu8QNZsmxtiw2u++qLGiKmJCp4Sp5bp5IRvlPWsBWMGlPXgk0Yt/tfgEkLUfvgdQMcxIcCGbeIA0xTYGYgCFHrMsR1HR6F/cmR4lAKg/uvougWV+LgxHam8JyKEgH3oYeg7CkZYfMVBFb8fEOYXwWXMO5b3zQm5yw467/ZcyvpFjVFCm4ny84Lh3BQ4Q== 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=2gCgytZaCpbk5mcRLiksJAP88Ztpxo5JSc4hKjH9gQ4=; b=D+NIz1dshbYlBdXgKowalTLTh4OTb1UDfbVp9ZKvQsIbgVIeCnH3XOWfvlFqWQd3Yjz+7YWHzdb/gqTTltEZ5H83HKJATfH9Sy+2D9bat6/3FLMD5l8cfN2rx7cHRPnlemSo/Bx9g0gb+hCYKjV8nD3/GPnLgHVtTxTvyrjsTD95XT0TTffLhnOMWpX97C2TGJYXkapynr7Tlx7tJZKpSSQz6UIGH5lfIwSRE6mb6K687itddUIxYfEmoxTNWrV4z5ZCbYXy4elc67ZyGFSQq6RI08jJIe+F6Ty++hAa0Ts2CxfiHV7A/W37komRN0X7ivOQwNSwHEa9PKSohwi8bg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=none; dmarc=none; dkim=none; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=live.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=2gCgytZaCpbk5mcRLiksJAP88Ztpxo5JSc4hKjH9gQ4=; b=uVx2Wy+v2empGH8JYMa+eVmkj25ptjsSfRVw7lCasxl9Ri3jAWzdALejtgU05rgz66QpRsLT8vhsk3Kpw/hhUoRvYva33L2LTEM/SQfFoJzNzvYhdU1jysFd0AcN2vB/MrtLu6fWxSz6VE9ByeCep+6m6WKWpzZTlzXxkoUZkGJ1ubfp9JTVfpDxPSikw8ovCQP9L/R3vsbCzZK7m8JUY37SnObIut8LjFdW/MepKQUonqP78oVgBJaO09TAJsY/q1dYqNV4cqdxGnh2Coezw/tVC0p+jTHQzNNZSdW05GsL5C29F7zfs1EvkpvKTLVrGHVsi+XFUoQo+qOkr9d21g== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by AM9PR09MB4612.eurprd09.prod.outlook.com (2603:10a6:20b:2da::11) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6544.24; Tue, 4 Jul 2023 09:43:41 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::4a5f:42f9:d78f:2021]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::4a5f:42f9:d78f:2021%4]) with mapi id 15.20.6544.024; Tue, 4 Jul 2023 09:43:41 +0000 In-Reply-To: <86fs64maiv.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 04 Jul 2023 09:54:48 +0300") X-TMN: [zju4w03ZWGvvRWLuDLyTyuzHV1T88/eb] X-ClientProxiedBy: BE0P281CA0032.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:14::19) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <82edlo9flh.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|AM9PR09MB4612:EE_ X-MS-Office365-Filtering-Correlation-Id: 746bcff2-1fcb-41a5-19eb-08db7c7325e8 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: QL+M3I5lKjcJsjIHJn0mm4HsfYFM7+DdCFcVowCi0AGcqD2Twx5ITJyeuso42Pb62xnmwD/G//4qv1iHU3hCGPYqApPDwwDSkg4xkpoBcVfWo53tITBry09aryMD4nm9jl75C1Akf4+VdUyreeJAO54HVlUX5o272KLVMhf1Ig0qvNUy3VEq/iqsMCTSoPfn8/CkBhMKHodLcMPBl6IaiN08dF0Y8Kkd426Za+9ZGw1U+p3MzirFO6lT941BZ9tvWe9wQCcuJ4yphLozNhpshgsiJL3zEuJcx3VlWMBAlp2jSgCzUIqJSIdGZr51yGQBV2wOFNL/8auGCZ+b6vlnl8odexAKjyCCri1Ec1xAghXylq5kB4yUKoRqqy1ZKA6LZDsT+FygCXjIQZMUGTeNO54wVfn8K34YGV9UbN5U+st7CuLzlUD5xlIY4RksOlIpgZBgOIeapvutvP5L9TfC+3KXuEolL9b964x6PMlUThEEj4gQctmDKQ00dL9l6U0l21qN6oEkdUjFq880a9lel2fu9KFicxdpBkUAR0FMxV984OH34VVM3PJ6SRYMs/QD X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?VJdhfmRhRX/7G2ldCXjafFRH7Apg0r9SAE9QR+ifntsWBq3OfYDNta6A8mNd?= =?us-ascii?Q?6C6IcLekiqdbsfXP38nlkGYlE+iS5r3W44G8QkLUWIQV+rKUNWg2xM18OCIg?= =?us-ascii?Q?MtCOWoapc4hmbpYIEZ+lxgZgHCj4VdqerfwwrBsf3x3EKF8KE3ULXSIHBzkq?= =?us-ascii?Q?nLubOwlGMqVhIb3HO4vNvakB+mtWHD5jxxID3YWMOuFwr2G7QkJMbwmtA95X?= =?us-ascii?Q?nP8vRaDgpHZ6qvEIPFCqs1rwWIHMbhVnodBE54JPg1JzFvJwcUBgY8PDuWbc?= =?us-ascii?Q?JpLaFuV6lImxbCk/xdROq9thr86p0NtHqSMxehHMLAQZEmLsncTtNbwXgduj?= =?us-ascii?Q?81uDhEQMav6ctSUqxHJ71K8lt0+BxbcNUiu/Uu8J1CGEKgw5xgMmzfkerjvH?= =?us-ascii?Q?+rhypvw15MRs+ptUwBWSaHIjjYwvo0xGsaGcb8Gmyw6fTnPMgfZw0ujJ0Qzq?= =?us-ascii?Q?sHDVfaxaYrZKv9A125WrtPPs40cZFRNkoTEcC8vejV4S7412LAFPDE4NUBJC?= =?us-ascii?Q?FAyM8oHxtk6UShdRpHrQ1DD1ohQcrIzpoegovFREMIueOllvrg1NQj4NA5xi?= =?us-ascii?Q?D8dK9DNWewwBqg0vCGwFEiKC3CmHOMaUAwfL8a1mXYJnaaGYL/SLihp8zKF2?= =?us-ascii?Q?JP X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 746bcff2-1fcb-41a5-19eb-08db7c7325e8 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jul 2023 09:43:41.0859 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 84df9e7f-e9f6-40af-b435-aaaaaaaaaaaa X-MS-Exchange-CrossTenant-RMS-PersistedConsumerOrg: 00000000-0000-0000-0000-000000000000 X-MS-Exchange-Transport-CrossTenantHeadersStamped: AM9PR09MB4612 Received-SPF: pass client-ip=40.92.73.52; envelope-from=arthur.miller@live.com; helo=EUR04-HE1-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, RCVD_IN_MSPIKE_H2=-0.001, 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-Mailman-Approved-At: Tue, 04 Jul 2023 06:54:16 -0400 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:307405 Archived-At: Juri Linkov writes: >>> But AFAIU, what you need is only to use with-current-buffer >>> wrapped around the interactive spec? There is no need >>> to select another window/frame while reading from the minibuffer? >> >> As said earlier, that highly depends on the work done in the interactive form; >> but for the majority of commands, and those in info.el specifically, it should >> be enough I believe. > > I agree, so commands that don't read the default value from the buffer > don't need even with-current-buffer. I believe that generally: * commands that do not prompt user in any way don't need to care at all (just switch to other window) * commands that prompt, but don't need data from the other window in any way, do not need to care either, don't need with-current-buffer either, but can't switch before they are done with prompting * commands that need to do something with data from the target buffer, need to use with-current-buffer and can't switch before they are done with prompting In those cases I believe you can generally just wrap interactive part in with-current-buffer and not worry about it; I wouldn't try to figure out which one needs to be wrapped, which one does not. I have used with-selected-window in all help-mode commands because they are in almost all cases simple, and it will work in all cases (they don't prompt user generally). But there can be other classes of commands, for example if command have to access some data in current buffer, but will act on some other buffer or window or commands that do not act on buffers but on windows, layout, etc, for example quit-window. Again, you have no guarantee what will happen with a command you haven't looked at since they can do anything. In most cases they will probably work by just wrapping them in with-current-buffer, but there is no guarantee. >> This works: >> >> (defun info-menu-wrapper () >> (interactive) >> (let ((window (info-window))) >> (with-current-buffer (window-buffer window) >> (let ((args (eval (cadr (interactive-form 'Info-menu))))) >> (with-selected-window window >> (apply #'Info-menu args)))))) >> >> I would still take it with a grain of salt that it will do in all cases, you >> should test each and every, but in majority cases it should work I think. > > If you prefer calling the original command from the body I am callling the function, not the command, on purpose. > then better to use 'call-interactively'. 'interactive-form' is > more suitable for being called from the interactive spec of the wrapper. Sounds like a complication to me, but I am not as advanced with elisp. Anyway according to the docs interactive-form returns what it says, the interactive form, which as I understand, can be evaled separately in another context to create the list of args one can just pass to the function and not risk extra prompts. I am sure it is possible to do it in more complicated ways then the above too. >>>> About wrapping; I agree that it is messy to go through each and every command as >>>> I did to modify them, so for old existing commands, it is definitely easier to >>>> do the wrapping, if possible. I just hope we get a better way for future command >>>> writing. >>> >>> I don't like creating wrapper commands too, but it seems there is no >>> better way, at least no one proposed anything better. >> >> You were against wrapping everything into with-selected-window, now you >> everything wrapped into another function :). > > I still think that adding new wrapper commands is less wrong than > wrapping existing commands into with-selected-window. Well, for the info.el and help-mode, I do prefer to use the work I have done. Were some bugs; I forgott the search, but I have fixed it and everything works fine so I don't need double keymap and wrappers. But I wouldn't do the same for all modes. >> The positive about wrappers is they will work with old commands, and if you turn >> that into a:core package in Elpa, then even users of older Emacsens can use >> it. So I am definitely not against wrappers per se; nor do I believe we should >> rewrite each and every user command. >> >> But for writing new commands, I do suggest to implement better macro; because >> all this can abstracted away, so we don't double all the commands in the future. > > I'm not sure if this should be a new coding convention for writing new commands > that should be mentioned in (info "(elisp) Programming Tips"). I think that should definitely be written about in the manual. I have used nothing but with-current-buffer, with-selected-frame and with-selected-window to achieve this. We could have had this all the time, if we just coded commands in a better way, and we wouldn't even needed "-other-window" wrappers. This can also be wrapped in a macro, say define-command, or defcmd, that does this automatically, so the future commands are callable from either buffer they act on or an other buffer. If there was an option to say to Emacs that prompts should always stay on the frame where a command loop is initiated, then the gymnastics with wrapping interactive-from into target buffer could be skipped, and new commands would only need to wrap their body into with-selected-window.