From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.devel Subject: Re: Suggested experimental test Date: Wed, 24 Mar 2021 09:10:30 +0300 Message-ID: References: <831ba60af0cbfdd95686@heytings.org> <87mtuxj8ue.fsf@gnus.org> <9088e12cb3de3d30abf1@heytings.org> <8735wnjsum.fsf@gnus.org> <83sg4n9jei.fsf@gnu.org> <271290d7aac58f2f9e96@heytings.org> <83czvr9hvc.fsf@gnu.org> <271290d7aa69bbcaa204@heytings.org> <83lfae8fbg.fsf@gnu.org> <22aaf0fadd0894af49d9@heytings.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39207"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.6 (2021-03-06) Cc: Eli Zaretskii , larsi@gnus.org, emacs-devel@gnu.org To: Gregory Heytings Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Mar 24 07:16:13 2021 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 1lOwoP-000A4b-0y for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 07:16:13 +0100 Original-Received: from localhost ([::1]:56712 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lOwoO-0005gs-1B for ged-emacs-devel@m.gmane-mx.org; Wed, 24 Mar 2021 02:16:12 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:35424) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOwm8-0005DG-3w for emacs-devel@gnu.org; Wed, 24 Mar 2021 02:13:52 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:44471) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lOwm4-0000Pi-H9; Wed, 24 Mar 2021 02:13:51 -0400 Original-Received: from localhost ([::ffff:41.202.241.53]) (AUTH: PLAIN securesender, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 000000000001E082.00000000605AD898.000034AF; Tue, 23 Mar 2021 23:13:44 -0700 Mail-Followup-To: Gregory Heytings , Eli Zaretskii , larsi@gnus.org, emacs-devel@gnu.org Content-Disposition: inline In-Reply-To: <22aaf0fadd0894af49d9@heytings.org> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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" Xref: news.gmane.io gmane.emacs.devel:266922 Archived-At: * Gregory Heytings [2021-03-23 17:19]: > Just type emacs -Q, M-x list-packages RET, RET. The package you now see > ('ace-window') asks you to fiddle with your init file by adding a > 'global-set-key' to it. The second package in the list ('ack') does the > same. And so forth. That's not a problem for you and me, it is a problem > for newcomers, and these 'global-set-key's should be done automatically, > during the installation process. I really do not believe it is a problem for newcomers, but if you do, I would like to see how you get that data. Newcomers in almost any editor will be able to: - move cursors with arrows - insert chars with letters - delete chars with backspace or DEL - open and save files That is it. More than that newcomers do not need. Almost every editor will provide arrows as key bindings to move, saving and opening files. As soon as newcomer starts installing `ace-window' it is not "newcomer" any more. :-) > Do you know any other software that asks you to change a > configuration file manually to use an extension package? Actually it is not software that asks user, but README or source code. Software provides functions which user may use with M-x and for convenience such can be placed in the menu or on key bindings. We already discussed that software could ask user about the proposed key bindings and that it would be good so as it forwards artificial intelligence in Emacs which now excels itself only in the "Emacs Psychotherapist" part. Your point is valid and useful. When asking which other software asks you to change a configuration file manually, well, other software usually do not install functions that become convenient when placed on a key. So we do not speak just of extensions, we speak of how to make commands from extensions more convenient. They however work without key bindings. Key bindings is convenience for commands. Let us consider example of Gimp as other software, not being editor and having extensions. GIMP works with GTK, and GTK allows changing key bindings for every menu function on the fly. Isn't that handy? Again, to allow such change for any function on the fly, one has to configure it in: /home/data1/protected/.gtkrc-2.0.mine to be: gtk-can-change-accels = 1 Then user can go to favorite function such as "Blur" and press key on the menu item such as C-9 to assign Blur to C-9 on the fly. >From there on I see your proposal that users should be spared of customizing key bindings very positive for progress of Emacs. I do not know if Emacs GTK version allows GTK to change key bindings by pressing a key on the menu, but it should in my opinion, follow the example of GTK and GIMP above, and various other GTK based software, at least in GTK version of Emacs. Maybe it does, I have never tried. To improve Emacs in general, I would propose that: - Package authors should be nudged by instructions from the manual to make menu for the package by default, and that users can be asked upon installation if they wish to have menu turned on -- and how to turn it on later if they did not decide to turn it on. Menus could be sub-menu of new Extensions menu, as that way the menu line would not be full of various packages' menus. - Once user is in any menu, user could then press a key and assign key bindings. If user attempts to assign default key binding, Emacs would ask user twice about that decision. Otherwise any empty key bindings could be assigned to menu. - Package key binding assignment function. Instead or in addition to the menu system above that would allow simple customization by using mouse, Emacs could have a built in general function that summarizes all interactive commands from a package and asks user how to assign key bindings. This solves the problem on individual basis for each user separately, and does not ask package authors to do anything special. Package key binding assignment function ======================================= It would work as following: - when package P is loaded, Emacs would create automatically new interactive function named P-assign-keys - function `P-assign-keys' would encompass all interactive functions from package P - it would ask user: - For the function P-function-1 "This function erases screen as example" -- would you like to assign key bindings? When user attempts to assign default key bindings, user would be asked twice if sure. When user attempts to assign already assigned, but not default key binding, function would say it is already assigned and again ask user twice If key is not bound, it would just get assigned. - package authors could propose some default key bindings in a list that would be used by general key binding assignment function That way all keys can be assigned interactively with user having control how to do it. Package authors would not need to do anything special. If they do propose some key bindings, they could provide a list, and that list could be used by the general key bindings assignment function. When `P-assign-keys' is invoked, it would display some key bindings that package author recommended as default. Authors could also exclude some functions from `P-assign-keys' processing unless user press C-u to assign key bindings to all. That would eliminate users to make key bindings, but it would also not impose on users any new key bindings without users' control. Upon installation of a package, user could be asked if one wishes to assign key bindings immediately. > As the author of Magit wrote when he added the "C-x g" global binding: > > "Some [...] beginners will initially have a low threshold for things not > working out of the box and I don't want to (continue to) scare them off by > immediately forcing them to learn how to add key bindings and what that even > means. There's a lot of talk about making Emacs friendlier for beginners > and this is a small step in that direction." [1] > > [1] https://github.com/magit/magit/pull/4237#issuecomment-723495053 Sorry, the above paragraph is to me contradictory, as who uses Magit cannot be a beginner, and I telling people how to change key bindings results with programmers who contribute to Emacs or make their own packages. Let us not shoot in our own foot by sparing people to learn something new. Jean