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, 27 Jun 2023 09:54:27 +0200 Message-ID: References: <86fs6ertto.fsf@mail.linkov.net> <86wmzpqva6.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="35198"; 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 Jun 27 12:53:35 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 1qE6KD-0008xb-Lp for ged-emacs-devel@m.gmane-mx.org; Tue, 27 Jun 2023 12:53:34 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qE6JE-0001WQ-1x; Tue, 27 Jun 2023 06:52:33 -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 1qE3X3-0003yr-5Q for emacs-devel@gnu.org; Tue, 27 Jun 2023 03:54:37 -0400 Original-Received: from mail-vi1eur04olkn2049.outbound.protection.outlook.com ([40.92.75.49] helo=EUR04-VI1-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 1qE3X1-0007Wk-3N for emacs-devel@gnu.org; Tue, 27 Jun 2023 03:54:36 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=jPCOCLJ+YH28o7fDgiwBhyPBOfwMPidC5rItFfRlcc7P0mKfO3O0w9zd9BctjYGQ7o4TiOkPJVLw1h4oFZhHjDvfIBfEb52oSgICH6BYyBox0wX9BRh5b/vTVHizb/4XuG0HlazImgF077NLbslilAyZM3AVNtVfPkLYXF0T83Kuvdmm2ZrLkX4SMvFuIMOkj3F0o5q/J7qmwwy7Zrfp9BbSMYnS8+0naekw+B0NFGUZaVx+EfzsuTp7I2Ueu47USu+041cYcCNNt52m36C4XyslQuKNDwZuLn401YWNjcaeuICPr0m3Rh/HKPqFpqbNrlSr/PuYNADSnx/bl1+g5A== 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=59GM9TZ4KM6vLlRqO+hmCoIEAFOMSieK/Qggu5I2ryY=; b=H8uXlmhkjy86VJsFyLrgAvyox/RBJQx94jUJ1HS4zrAshT/HHTn/DL/bDus3XlHKTmki0GY3j6yTPTqHfTkpM0wpd3khIADVWnhtO3RSh7HJldJLNB6LvQoxbahpNzOr5FT+KLksD4/Qgs3aT7Bc4HPOhZttZ0VeVToe8UxU+dQo0oskCXX1hQOrJ2LjKQ6O8YLQSSRmq4lZlLZYlTWs/EA76wr9iUsu04WDENrSuPoqgxDMLA9Z45huT+kdJXcED+GIhuvUuUg+sVYme+JGCMXuvPqDdPlZBpVHQE2quDSdBIcnqIGyR7R/lIBHJQoX0/jV/hnUggMsH6pTA5PhNw== 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=59GM9TZ4KM6vLlRqO+hmCoIEAFOMSieK/Qggu5I2ryY=; b=cf6CGxcGwk9ntDysxM8nnwEmGDfB6sWroW5rEgFMN9pa/gIcsp3LvbNHJI6QScfNZWiDBdaVivYtRXN97Gdpm/Ui9paMpUSTkJyRoKh4oXPX1onaXRm4KewiCr1ZBzmtTB+OD81pA11bqS/XT5tcWp8c7gvN0nX4MrIkngLoUbJUD358fvevwahYSChaDZb7FHHkQThD+Qpx2i8yDWkNe1rCxyTC2kJHcFV+zmoO5wYLDBxiYEIaYW+Y/iPuJj/hJBEdnw27FDRfxO3ZtCng0ZqSxjRsdg2Sg+ZEtrPcmmJWMYv0KckJOOkGGcX3R0PU6YMi9QR4paotWIM9QILgCg== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by DB4PR09MB5896.eurprd09.prod.outlook.com (2603:10a6:10:387::5) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6521.26; Tue, 27 Jun 2023 07:54:30 +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.6521.026; Tue, 27 Jun 2023 07:54:30 +0000 In-Reply-To: <86wmzpqva6.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 27 Jun 2023 09:32:25 +0300") X-TMN: [G8nEoA6J9QoJi3f5WHZg/YMnRsgDPe4a] X-ClientProxiedBy: BE0P281CA0024.DEUP281.PROD.OUTLOOK.COM (2603:10a6:b10:14::11) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <82ilb92vd8.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|DB4PR09MB5896:EE_ X-MS-Office365-Filtering-Correlation-Id: 069d5d70-0ee6-4d76-c35c-08db76e3bc3e X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: wivr4UwBnzYoLE/l4+NWEHRxpwsvF1xuc/Iw/KKHt4JBX3y63kA1AvQ0rHFOBVQrn/L+10cGc/dSAe0rSB+KZzkppyuPou0hmExWaTUrGUYwyeS8l49rkLYADKJWJq3ja+5je5ZVk2vjOMFsQVe2cm/SMhMULRcpO4jMs2O6MchAnAudjg6R+F26cOFEoTSg7lawnxWdE+VLr/h0BIBXDGGAxcZLB5vAgDcOz1Rkeopefls6JYwVYCopfY8semjJucheL2dThTJY5I7x8NPxlGiw/XCwj7ZJpfpPGHpaZ+PaF5Wwg51sjHpyEXotZo7damX0l8oFaOwXAW9435nDEJIEK99LCK8uZXS59PsCTEpkCgG8uY2ucdrpw78ApiaVF4bOh4yz7WBvwfIdrko6q4lNqCnw0pn09nuT7IVE8EjuBbuIpOaiAD2m6R9zLOcBXy7GYnU7v4ZW2npofBDlBVqlgQz8tv8ioAXYHhTy+K++7oDq64JIPYnf6UscgU57W+utlnp00wq4QUAJ+k4rGhVEyB9lt5pGPEs7izztbfLEZk3gO2INVZOuZNa2sDjL X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?+J5SEHHj8Kmkm15uwYxGVXI6KD5vLp0M51UZwcVN3BMQFUgrBnPHiGSpYmPI?= =?us-ascii?Q?DKDApMtZXoQJDrSw4fGaaxDHTsoNNGq0oFlh/l11ZFUe5URKJn27rtIf5IPB?= =?us-ascii?Q?hks9ErArwCIpg1yL/qSbhJqHMxTJf6ZlSUFuq1NYiVj8/eA2Rpf3dcxLnhcd?= =?us-ascii?Q?RCiqWDe5W6V2yJmew7CkbY0h0U9UvpyYaL4kGdyd65J+xUGZk19NWts2GSPd?= =?us-ascii?Q?Syj03bUDfQD2vYydheajJKabzvRMm18IHK1HJJQ7Ooayv9lXabGsls4JxOt3?= =?us-ascii?Q?T/iUTFO5qVIv4x3m+s6ySCaeSbleyDvIOUFAXhOOaMXHFtC0qhLWiXF4vylb?= =?us-ascii?Q?HKxRuXEJSmAiE1ZHq9Bfx41nNUdYE4aCs9lTw6XBL5lqyTg5v4xDPYMlFXcK?= =?us-ascii?Q?0+r9QcBvcSbYO8QHxFAJf3XlWHFVrnMW+Uw3x8j0+vV/BsHosm2daqCfYVcy?= =?us-ascii?Q?1FoU1PGF9WphDf2dCyo4+V9hHFinoQaj4gxs84n0Qpa0nUJ17YLSw4r4MZm2?= =?us-ascii?Q?Ncx44XM2FSXfjfisa/Ot3GJovpsY14S/AMLkdr0PaD5TT5j9K8q23rG6ZQ3n?= =?us-ascii?Q?e0/ZrJX4n61IRw2eBANo6jqZEDcJsLXQdlX0VMPnwyml1V0t4A0egUzvxh9d?= =?us-ascii?Q?fQ X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 069d5d70-0ee6-4d76-c35c-08db76e3bc3e X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 27 Jun 2023 07:54:30.1214 (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: DB4PR09MB5896 Received-SPF: pass client-ip=40.92.75.49; envelope-from=arthur.miller@live.com; helo=EUR04-VI1-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, 27 Jun 2023 06:52:29 -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:307252 Archived-At: Juri Linkov writes: >> Also I didn't wanted to change API. Not that I believe that there are many 3rd >> party packages for Info and Help modes, and that people actually customize >> those, but anyway. Wrappers would be a new API, which all require at least some >> documentation etc. > > Actually adding new arguments to existing functions counts as changing API. Yes, but I have added just an optional argument at the end which shouldn't break anything, right? I ment to document 'window' in the function doc but I forgott, remembered after your mail last night :). > Whereas not changing existing functions means keeping the current API unchanged. > Since you need to bind commands to new keys anyway, there is no difference > whether you bind old commands or new other-window commands. I have introduced four new commands where I couldn't do otherwise. But I didn't want to duplicate all commands by wrapping. There is problem of documentation, people wondering why they are duplicate similar functions, more commands in Emacs, and in non-trivial examples it is not possible to just "wrap" stuff in with-selected-window anyway. I think doing it properly from the beginning and adapting stuff under the hood without changing the API or visible commands is a better alternative. >> Can you control on which frame the input goes when prompted by original >> function with a wrapper approach? I changed quite few prompts a wrapped stuff >> with both with-current-buffer, and with-selected-frame to achive that. I don't >> think I could do that if I wrapped stuff. But what do I know, perhaps there is >> some way? > > I see that you added with-selected-frame to Info-index. > But it seems this is not enough because with-selected-frame > still fails to switch focus to another frame. You need also > to use select-frame-set-input-focus. Where it fails? For me it prompts me on correct frame. I didn't want to switch focus on the info frame. I am aware of select-frame-set-input-focus, have used it in some test actually. The reasoning was like this: There are (possibly) two frames: "the user frame", one whith some other buffer and possibly on other frame than info, and "the info frame". We need to switch potential prompts that ask user for the input from info frame to the user frame, and execute the effects of the command on info buffer. We don't want to switch frames and user selected window, that is the point of the patch. If user wish to switch to info frame, they can do so already, as they would do pre-patch. At least that was my reasoning for the patch. > Since neither with-selected-window nor with-selected-frame > can switch focus, we could add a new macro like > > #+begin_src emacs-lisp > (defmacro with-selected-window-frame (window &rest body) > `(let ((frame (window-frame ,window))) > (unless (eq frame (selected-frame)) > (select-frame frame 'norecord) > (select-frame-set-input-focus frame 'norecord)) > (with-selected-window ,window > ,@body))) > #+end_src > > > Then everything works nicely with Have you tested *everything*? Interactively and from lisp? > #+begin_src emacs-lisp > (defun Info-index-other-window (topic) > (interactive (with-selected-window-frame (info-window) > (eval (cadr (interactive-form 'Info-index))))) > (with-selected-window-frame (info-window) > (Info-index topic))) > #+end_src That would be a different behaviour for *all commands* if you would to apply that macro to all commands consistently, but I don't think that is what you would want. In the end, I think you still have to go through each and every command and do something different on the basis if you want to switch window focus or not. Otherwise, if you gonna leave focus in info window, then just introduce a simple way to switch to info window, as I did with the "Info-jump" which I have removed in this patch. I think the reasons to jump over are less due to being able to create "connection" to an info window and use that as the default, without the need to prompt the user or type the numeric prefix. It also works with window created via "C-1/u m" which creates names based on chosen node for visit, for example *info-Elisp* instead of *info. Notice that select-frame-set-input-focus won't move the mouse cursor, which means that mouse will possible (not necessary) be left on the old frame. If a user has, like I did, enabled "focus follow cursor" than depending on the window manager user has, Emacs will be fighting for focus with the wm. Not all managers respect X11 hints and requests. Perhaps, you could save the frame that has the mouse cursor underneath and restore it afterwards too when needed, or warp mouse just somewhere into the info frame, and restore the position afterwards, but I wouldn't bother, that sounds like more troubles then worth.