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: Control help- and Info-mode buffers from other buffers Date: Wed, 31 May 2023 07:55:31 +0200 Message-ID: References: <87h6ruf09e.fsf@ledu-giraud.fr> <861qixbum2.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="21440"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: Manuel Giraud , emacs-devel@gnu.org To: Juri Linkov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed May 31 13:14:17 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 1q4JmS-0005LX-IQ for ged-emacs-devel@m.gmane-mx.org; Wed, 31 May 2023 13:14:17 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4JlR-0005dW-J9; Wed, 31 May 2023 07:13:13 -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 1q4Et1-0006q3-It for emacs-devel@gnu.org; Wed, 31 May 2023 02:00:46 -0400 Original-Received: from mail-ve1eur01olkn081f.outbound.protection.outlook.com ([2a01:111:f400:fe1f::81f] helo=EUR01-VE1-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 1q4Esy-0004UP-Oi for emacs-devel@gnu.org; Wed, 31 May 2023 02:00:42 -0400 ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=IbMCtsaTFD/tyMes9WY0eHS08oL5VDz1vbjsHXBnN4kTXO7NjpE7t1FS71eRtKZEQww0P/WWHP3Vl2ZOnkFoG8L9kM7tubQ5B5H6lQCah7eIEelo3bSBLFznC8n4tfx1J/a6GGapyXcd/55mSqmRtUT/D6DTDv7Lcs1jTEW+gntPwMHEbuGDBueEelyuUOG3pxCK+kRyZflCy1xCPdSrEbLiVto3ZWFZ5VOFq1fkKf6A40gAAXViStiXUYB5syLInJClpveZYXNZttbjrTzUOXywDpwqjqTh/vYzzlNXPltgZB031aO/Z8pSpm4MhcRhP4HX12o14GwzEWUIZDOoQg== 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=UWkK+j3oIVjwofjpHkRKW823KeAMuYP1eBSKN5taOpA=; b=oWLu+OAgQrJw9MPw8lOeFXmyXLYORuQiNYMkc5t8FIQPDQoSaureNRvuIS3trLwV1J6Q2CwJnnz4JKlPa/j1uJZaUFWK//M2IM1TyzMvqWyO1IsIR68MzhEdLtlq3fHCpha+zSxyMSK9Xj0GXzq7glgE3pCvUZ/z0gH1BF3UoisnpgR7EVr/4WQeal/BZX7RDU8AlPfmYFwGJW++EC06REhpcuF9SFt6hmGQt3/1MgDRs26c2xFjNeCpxi3F799sQKRjyrs5dhjY6dxr1rg2Wq97bXvxzSchFCjLUAH7GQZ270tC1guj2ZIYgaizka0WEnvEk+7LhN5s1vN0zGDkiw== 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=UWkK+j3oIVjwofjpHkRKW823KeAMuYP1eBSKN5taOpA=; b=SQ6Hu79f/g11sjwbAMeuc3uRr3Z61YYJVFs6EKLR9NBMzX5zOKiczSAMNBZFgMqQV+OZmDCpLrQRHZyypX73NgsgZ8+7DEC5jdj+yQXQnHnO9bb25TmOQQsGYav94/XFyQRZ10h7b4ynBBjFpf8ZzZd3YHQHAoeqggYgwxzk/OYVL+XzmjYkvuVdsQVZHvslWtvyQFAmr5fdR0GjHgRhgjx1dh/WrSCq1SEVTsT7tP74/TvnKX5lXa5avHWHOWGbtcI9Z+HUQ/n9OsJ0JDwDT2bJl0BXEjrACIzErn+pab0HFhJJRjKw+w3Y3yVRYpbI4XPPsln5+luXRV2t7fkVFA== Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) by DB8PR09MB4421.eurprd09.prod.outlook.com (2603:10a6:10:155::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6433.23; Wed, 31 May 2023 05:55:34 +0000 Original-Received: from AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::6983:1def:fb14:21bf]) by AM9PR09MB4977.eurprd09.prod.outlook.com ([fe80::6983:1def:fb14:21bf%6]) with mapi id 15.20.6455.020; Wed, 31 May 2023 05:55:34 +0000 In-Reply-To: <861qixbum2.fsf@mail.linkov.net> (Juri Linkov's message of "Tue, 30 May 2023 20:29:20 +0300") X-TMN: [7zsvHkaJTkqLv8JPFWSrTsKNRLDV29bqZiga+t2ixnM=] X-ClientProxiedBy: MM0P280CA0010.SWEP280.PROD.OUTLOOK.COM (2603:10a6:190:a::21) To AM9PR09MB4977.eurprd09.prod.outlook.com (2603:10a6:20b:304::20) X-Microsoft-Original-Message-ID: <87r0qx9h9o.fsf@live.com> X-MS-Exchange-MessageSentRepresentingType: 1 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: AM9PR09MB4977:EE_|DB8PR09MB4421:EE_ X-MS-Office365-Filtering-Correlation-Id: 00a2f869-92f2-41a2-26dd-08db619ba58e X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: DQn7G4QJcYP6eljouwnQvPWGifp3LQ1UD+dT8LOtWbCF/DnIqd3mbOlXtWFln74FtKZZy55ldxExpbZmNA8u6yvxd+fKDHoxsni3q58s7QJJ2fxpDZj0HZAebSQD5hCPStc++LPmot5y+AUNsuy8+Mc3aDzakaG9U11xSDg2DLhulzwc4gNIfqe0v4jByF+gvIodR0YeuliMnZRKkCol2pyvqU//oaXF5VfTcqDLmgND5lLt/aahoaoCGCgecbZH4JpzszYa+9qs992t8stbIA42eZG7QLT9izrODz47NRfCuaDW085zTbbdqbsgZrDf5tBUXqKVOGrTMb54LzrH6SFM5knyt+GYNcGYLIia/OAbMvHeC/omd8Cte6wXcub4zeYBQk3sTiDrOEp6lUuQjuovm4pGxpIIr9gU8pdNwCmeKG1QypKuiBop0Axo2sGC1DAOeN2FF8XLw1X/x5cnHWd664YpQYUB//t+gem5w2r80RMYMT+dvdIjn0IcKdozYxLgFyYpp90Ur2yLQUADPb9hQEQK0R+BrkgSPBw4GfDjWgYFz6eegGclVCimHbwR7J3Ne0vnTUv16gC/+BM44DLTelnw3C4gTB4XvdoBJW0= X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?us-ascii?Q?DzVVp2QDsQIFNTjGO/kxNLsvPESaa5Nkk+qfCA1aCKb2nA6Ul53oxprihI8g?= =?us-ascii?Q?N99CIPjlmUPMntiZ+HOpmGye43kKaMJb6dnmHhn2wppnoiybIF6hRCEDdgou?= =?us-ascii?Q?0dkkzILxcBiKF+Inzg6815fYh2bSEGptVYh14J+UKVW6MK3BZ5E3JAWm8ovb?= =?us-ascii?Q?za8PwxHEKzpkUoi1uVMw5haZawwu4ByvEKF3lTAkAb5Lk7pkzXPN4JYa0VWe?= =?us-ascii?Q?ieoeNwU6mE+s7st8t6Ye+ngW65+ExcrzZ9R52Cu5UKmQGlC+nbyU2fBrNl0I?= =?us-ascii?Q?17V+UYfsKNJyAdRCiMSIqAaOvhM3qbmJ2Q3pbWCqa5MWZX3h41v6bX78pjlQ?= =?us-ascii?Q?o2fzr07tSMI6S8NWQ3/PxV32kqfUYhjAnonTvdyUUzGbXOfgT7BXSDLLmBHS?= =?us-ascii?Q?AGoTC27/8I2XnWgxR+dXDoQK5dqi8R7DlqtxXtvEKfLOl0ZtncjrWv+Yw2kh?= =?us-ascii?Q?3oIjfrmG2sd4Mk0bURKkIfFCp67XWLFV/c16Vc/+VzDZDeDW202iKw2E0kd9?= =?us-ascii?Q?AxL53YlGGXjpGR6ool7cvJMqzmzB51ga2RGSir+vGPP/auMFt38zDA0qu1qA?= =?us-ascii?Q?8z2BybEYyNlIhzn17EUlwB8g1cFjzsCCFZItkyFFwJ4/6MiQYrXNc0/hLvxy?= =?us-ascii?Q?GC X-OriginatorOrg: sct-15-20-4755-11-msonline-outlook-64da6.templateTenant X-MS-Exchange-CrossTenant-Network-Message-Id: 00a2f869-92f2-41a2-26dd-08db619ba58e X-MS-Exchange-CrossTenant-AuthSource: AM9PR09MB4977.eurprd09.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 31 May 2023 05:55:34.8584 (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: DB8PR09MB4421 Received-SPF: pass client-ip=2a01:111:f400:fe1f::81f; envelope-from=arthur.miller@live.com; helo=EUR01-VE1-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, 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: Wed, 31 May 2023 07:13:11 -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:306437 Archived-At: Juri Linkov writes: >> I have actually tried to find some general way to do this >> programmatically with any buffer, but thus far, I don't see any >> general way that is both efficient and 100% failsafe. > > Please share your experience what have you tried Hi Juri; I have tried several quite different things, so that would be quite a long mail :-). In that particular place, I am actually referring to something different then what you think of, I believe. As I wrote to Manuel, I was basically doing programmatic what I have done manually with the patch. Problem with the programmatic way was too much processing, and some functions didn't work. The former could be perhaps helped by using a macro to do it at compile time, and the latter is perhaps lack of lisp-fu on my side. I don't know, but the idea was to advise the already prefixed commands in a mode-map, and to generate new commands for those that are not prefixed. The advice switches to the buffer, executes the original commands, and switches back. Something like this (just the advising and generation part): #+begin_src emacs-lisp (defun remote--make-advice-body (buffer-name) "Create lambda function for buffer with name BUFFER-NAME." #'(lambda (fn &rest args) (let ((previous (selected-window)) (buffer (get-buffer buffer-name)) (window (get-buffer-window buffer-name))) (unwind-protect (when (get-buffer buffer) (unless (window-live-p window) (display-buffer buffer)) (select-window window) (apply #'call-interactively fn args)) (select-window previous))))) (defun remote--make-advice-function (buffer-name) "Create advice function for buffer with name BUFFER-NAME." (let ((advice-name (intern (format "help-remote--%s-advice-fn" buffer-name)))) (unless (fboundp advice-name) (defalias advice-name (remote--make-advice-body buffer-name))) advice-name)) (defun remote--advise (fn buffer-name advised) "Advice function FN to run in buffer with name BUFFER-NAME." (let ((advice (remote--make-advice-function buffer-name))) (add-to-list advised (cons fn advice)) (advice-add fn :around advice))) (defun remote--gen-cons (binding prefix buffer-name advised) "Ensure BINDING in buffer named BUFFER-NAME uses symbol prefixed with PREFIX." (let ((name (symbol-name (cdr binding))) (symb (cdr binding))) (unless (string-match-p prefix name) (setq symb (intern (concat prefix name))) (defalias symb (symbol-function (cdr binding)))) (remote--advise symb buffer-name advised) (cons (car binding) symb))) #+end_src However I was not able to trick Emacs to trust me its executing in the "correct" environment. Also, there was too much processing in info mode. Some methods worked well; for example everything in help-mode, but some functions that asks for user input in info-mode, for example info-menu, didn't work at all. > since it would be nice to have a general function > that will delegate key presses to any window, I think it is similar, but still a different problem then remotely executing commands available in other buffer. To start with there is a nice trick via pre/post command hooks, someone posted to me on Reddit: https://www.reddit.com/r/emacs/comments/x0r0pe/share_your_otherwindow_commands/ It works quite well in some cases, but not in all. For example it does not work with Info-menu when invoked from other buffer either. > not just the hard-coded *Help* and *Info*. I understand your sentiment, and I agree that it might be useful to have a way to delegate input to other window, but I also think we would still like to wrap such generic command into some hard-coded cases to save typing. For example in case of generic command and multiple windows, you will have to ask user which window to execute in. In order to save that prompting and additional typing on user part, it is handy to hard code such generic function to certain cases like help and info here. To shorten, I haven't found a good way to delegate input to other windows and I am not sure if it will even work as a general idea at all. Perhaps for some cases, it would work, but not for all. I am inclined to believe that this is the wrong side to attack the problem. Perhaps it is better to write commands that are aware that they could be executed from other buffers than the one they act on? In that case command could prompt the user for a window or buffer to act on and auto switch to that window and back. Since the command usually knows which mode it belongs, it could even filter out windows/buffer that does not have that mode activated, or some other feature it requires. It would be relatively simple to implement with prefix-argument? But perhaps I am wrong too. Perhaps you have something different? :)