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 23:40:46 +0200 Message-ID: References: <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> <86sfa3bpvf.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="7632"; 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 Wed Jul 05 04:21:56 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 1qGs9S-0001hh-48 for ged-emacs-devel@m.gmane-mx.org; Wed, 05 Jul 2023 04:21:55 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qGs8Y-0006y0-NC; Tue, 04 Jul 2023 22:20:58 -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 1qGnlV-0001og-LY for emacs-devel@gnu.org; Tue, 04 Jul 2023 17:40:53 -0400 Original-Received: from mail-am7eur03olkn2089.outbound.protection.outlook.com ([40.92.59.89] helo=EUR03-AM7-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 1qGnlT-0001vI-CQ for emacs-devel@gnu.org; Tue, 04 Jul 2023 17:40:53 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=cY/zq/t4LbR8suxTh0SRolBDXq62ClCOSoTvc1hrh3fsq46PlSOoALTGa06mvy3gByKmjk7rrFTfhyjHKnqqG2HwtoinMMOp+xEPhDYBAwdSOVHiVrhD/WWu6P961J2mHeinq/G76jJWHMlgT025GKLVCAnsRgctrSAL5Kp8K80ld1B2YFcRycascwVR4epwsUbyrhFxM3BuB1CYdq2nuN/CEw/WnDs5F3BwAa8SXYGuA0x8X18tKnoQso3zv68GAH9NQEyIFqRaXFs0Dl2VmosSF2HgyqwnxoF5k99jpkZen8LGY8pX7csZ/lHeVkxgOFe+itxyDTIl9V5XU/4+ng== 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=ONUwuPLhpD83vosC/avYZFniH8/9fsgcmqsx5OGwuMM=; b=aOaBr9D3dzbHNS76KcqgfJIVPD1X+0hksrXwBv8gK3P6CgS2zJe2HFzrDn9QRoE7YN7+L/GhomGiUh2yCU59jabCdmidlGDB9vVgxBtCQ4+F5u+do+n51ynXVVPJT1cKUvg/QFLAqLXGMwe1zTL1X27EaoGAYc7rBxEkL5/ltBHERR+UiNAmYiZ+3PQYg+BNBN3Pa4guDhu4zuN+ad7XL9fj82ns+OKSvwEeOfIPirSM0Eq4bJj4XXmkp+X4JoZFromTocxzOY7ho/tXa+h+6FndG1bT1e1NeTOM6aYcOa04rkrRBiaz44Rg8uaPngW6zZ00HXXAW9NlS3f0Me9Tbg== 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=ONUwuPLhpD83vosC/avYZFniH8/9fsgcmqsx5OGwuMM=; b=PprCu1iv1wc0QKcUU3T540kxGUggST1P7W3csrmlgUKgpTXKMibkrs3IdOPd8ktBZfFOhV8Dqqak7oQpTD5LNG9V+5r4BaOAnx7fUOW9xiY4gMeX/FbwPtN7jhJEa7jGAZZK65AHuvEO/apbnj4IriMIwcrkzMR/1ptQpJdeGjANUxZC2nScWEJN2nQFIiFaz5oHI+md1ubVGRUga/PHYGNq6zDbkY1p17l6doWHOba+uY86AFtRxCl2Nhdenp5kSdvep5X+LOsDybvUazUtdssO7hI9bww11LmYRLJzVQ1zrY1QCP6jnNrEdsb6XbY+HsdhJkHZUYLuRTvzk+PW6Q== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by DB8PR09MB4233.eurprd09.prod.outlook.com (2603:10a6:10:12d::23) 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 21:40:48 +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.6565.016; Tue, 4 Jul 2023 21:40:48 +0000 In-Reply-To: <86sfa3bpvf.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 04 Jul 2023 20:51:00 +0300") X-TMN: [xRB4IsaiZcdBqhxNOFxDTLotViJOly7f] X-ClientProxiedBy: BE1P281CA0086.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:78::10) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <82ilaz4aox.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|DB8PR09MB4233:EE_ X-MS-Office365-Filtering-Correlation-Id: dc4fdd43-9dd5-46e9-cb8b-08db7cd75488 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: iJ4ne1f1W/fGSNo+36uqcEZTy+w5Qe4XX1sS591Pvql+48qPGF7AvbH5scmUyOWw58OmoYYoasvJGguvVmspx6bRBqCHJ8ltx7S7zGUZ+4mMImAhQWkPdDqTz0ne/m3odmfeb6TRI8ihocTupQWi4C7ET9zW/eLZ/3PiWerqHcSrAw1yvXTdU95+obapkrNuCUreNhl9vMrhJU5G16Tn7aD3snMEMdVkoNEl6b2VNV5DNvfVRCVBQXmRoDdw+nj5pk8QF0BU8ayhQjtekLclUJ6sx6V0WnRCRAJrB5OpW5rh41n8sxGZGohtXSHZSbTcIF7dgNwPkCLMUwHAxYOEjEcLiTIlaVK9VYQTaIwMztuuEQPhUpqPvdctKLYidIgJ6JNugULtwhd4UYVUCsVyOF+q4EBFZXAQna7lZog0zpQtUPw3YSlGauxacqg5RgY8xKtA7lPpHm5409bbntLocjSkEkBEyUGlUnU6Iq/7w2E1HoqNR9Elt8NPZEyZxz73OsgC1ZyarHGCaBiitqvHnybL6+RNvGh1PlfdBzHnAAAfg4cAf3ZgMHmrlBG+oYQj X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?SoV6bdPvJdwBWM7wnCjSGuY/Zg30AorjVfvW5z6MaxNfcEXFwWEILUM4pEbQ?= =?us-ascii?Q?EkeKhtnAljaHyeaFTkhGTY2uJP0R0pNhXd+alFUjzJP6clxNK/6AbKM6PSam?= =?us-ascii?Q?YBEuOjk0oXgjVjA/A+9BEEOFwn6XYDhU4yjhB/o+ssKmw/oqY0dEk0ZMQdhU?= =?us-ascii?Q?+NzELDPbfp5XfxFkCFWvW11kT05aSRcB3h18+rqT1nLRMBCoWbca6P8SZoi6?= =?us-ascii?Q?Weml6Mraecmt51qThGDadSn5EpWCragLtNjHGt4+6ERZHxYO0qtjIOgxyc8O?= =?us-ascii?Q?dRys2VFuMwpVPjkxiglVVruIxPkkEdAB9w3S0pFHu49UTDznKOg82Juo9Ob7?= =?us-ascii?Q?k4EBhWs0IVj5pecLlCmstKHtVO2ETeFsOdJnb4VFbpo2Rb38h6nLIvXbGOk4?= =?us-ascii?Q?U3APwpLWIcMcxV0r9l/NlduXz1IJAg4zEqxtRGVBe4W7JRhXi3RKJh1tK3EL?= =?us-ascii?Q?d4yhPbti9+FWZwvMkNwBLVcmSDDnt+XwFV1tM5nA4RV6UkmXH0mzgS7cBu8x?= =?us-ascii?Q?B4kG/XjXinQSjvtCa14eu0aaMHh0rBzDIDRvPrtmTeeCA1cHa6OcA9LGJY57?= =?us-ascii?Q?rtcnJH7RlaDV6yeIXh+hOCzNPvXCYRk6vGt1MGDGAmKmgqDDt8L/BfWKEYpw?= =?us-ascii?Q?aT X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: dc4fdd43-9dd5-46e9-cb8b-08db7cd75488 X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 04 Jul 2023 21:40:48.8279 (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: DB8PR09MB4233 Received-SPF: pass client-ip=40.92.59.89; envelope-from=arthur.miller@live.com; helo=EUR03-AM7-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 22:20:57 -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:307448 Archived-At: Juri Linkov writes: >>>> (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. > > It would be inconsistent to call interactive-form in the body. Incosistent with what? > Better to do this in the interactive spec: > > (defun info-menu-wrapper (window &rest args) > (interactive > (let ((window (info-window))) > (with-current-buffer (window-buffer window) > (cons window (eval (cadr (interactive-form 'Info-menu))))))) > (with-selected-window window > (apply #'Info-menu args))) As said; there are always more complicated ways :). To start with, observe that I was not discussing how you should implement your patch. You wanted to confirm if it is enough to just wrap in with-current-buffer, so I prototyped a few lines just for the illustration of the idea. If you are going to send aguments to your wrapper, sure, I can understand you would want to do it in the interactive form, but for your example, I am not sure why are you sending the twindow and args in. I guess you are making some sore of a framework, but if you are keeping *some* sort of automated guessing framework, such as info-window than I see no point of sending in that window argument. Now, I don't know what you do, and how your framework looks like, but I would either keep exactly the same arguments as in the wrapped function, or take the opportunity and get rid of all arguments in the wrapper. I don't think you need them. That would make possible code generator easier to implement, and it would be easier to potential users write their own lambdas and so on. >> 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. > > Such option could be added to the third argument of the interactive spec. *Iff* such hypothetical variable existed, then it certainly should be the users choice to decide where prompts are shown, not the 3rd party code. I think the variable you pointed me too that didn't do "what I expected", could be used, perhaps with some new symbol as the value, or perhaps the nil value just does not work as advertised? Anyway, it should ceartainly be left to the user to customize where prompts are shown. Mode/library/command writers should neither have to bother with that decision or be allowed to decide for the user where prompts should display. > There is a new feature added in Emacs 28 where the second argument defines > to which mode the command is applicable, for example, Info-mode: I know. Two days ago I ported my patched info.el to separate package and to older versions. Porting it back all the way to 25 was relatively painless and trivial, minus reworked interactive spec which causes older version to omit a sea of warnings about maligned interactive spec. Seems like the the warning is not defined as a symbol, I just see byte-compile-warn-x emit it as a string, I don't see it defined as a symbol so I am not sure how to turn it off without further hacking. > (interactive "P" Info-mode) > > The third argument could define which window the command should select. > For example: > > (interactive "P" Info-mode (info-window)) I personally wouldn't do that. You only need this for commands that are already written, not for new commands. For those that already are in existence, I think you can simplify with a simple wrapper that does not take arguments as I did in the protytope and as discussed above. At least I think so; pehaps I am missing some case? There is no reason to complicate meaning of interactive spec and to hardcode what things mean in this regard, at least not just yet. Once you hardcode that meaning we will have to live with that for the rest of Emacs history, but perhaps it is not needed at all? I understand your enthusiasm, but let us live with this for a version or two until we get better understanding how this works in practice and what we need. I sincerely think you should port few relatively complex commands as I did in info.el to get understanding for this, if you didn't already. For new code, I am quite sure we can have a nice macro that takes care of the details so we don't need to generate wrappers for any new command that is yet to be written. I would also wait to introduce those wrappers into Emacs. Perhaps, there are other solutions too. Perhaps a compiler/gengerato could be written to translate old commands to more flexible implementation that can work when called from other windows too, since it is a mechanical process. Info.el and help-mode.el, as reworked manually, don't require "-other-window" wrappers; they are fully compatible with repeat mode as expected and are completely backward compatible with existing lisp code and user experience. It might be a long shot, but perhaps it is possible to write a generator that rewrites commands automatically, or better to say, I know it is possible, perhaps not in 100% cases, but for the majority of cases. The technical issue is just how to decide which commands need to be so flexible and which don't. But the real question is if it would be acceptible.