From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: hw Newsgroups: gmane.emacs.devel Subject: Re: Some developement questions Date: Fri, 07 Sep 2018 23:03:48 +0200 Organization: my virtual residence Message-ID: <871sa5nhor.fsf@toy.adminart.net> References: <8336v6cvem.fsf@gnu.org> <877ekigiiw.fsf@himinbjorg.adminart.net> <837ekhb2me.fsf@gnu.org> <87zhxcbmtr.fsf@himinbjorg.adminart.net> <83in409lub.fsf@gnu.org> <871sanb71j.fsf@himinbjorg.adminart.net> <83y3cu7t9j.fsf@gnu.org> <87lg8t2ki9.fsf@himinbjorg.adminart.net> <20180827015422.lcq44zvsjffeau4j@Ergus> <83a7p76f5e.fsf@gnu.org> <87lg8p9o6y.fsf@russet.org.uk> <83pnxx1foj.fsf@gnu.org> <87bm9d9zs9.fsf@russet.org.uk> <87efe75v02.fsf@toy.adminart.net> <87sh2lu471.fsf@toy.adminart.net> <282c6a86f8a2dabd7367c41d71cf31ab@webmail.orcon.net.nz> <87y3cdqwat.fsf@toy.adminart.net> <92e5aad5-47b9-f10f-6046-863dbfc1f0d1@orcon.net.nz> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain X-Trace: blaine.gmane.org 1536357322 9652 195.159.176.226 (7 Sep 2018 21:55:22 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Fri, 7 Sep 2018 21:55:22 +0000 (UTC) User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/26.1 (gnu/linux) Cc: eliz@gnu.org, phillip.lord@russet.org.uk, spacibba@aol.com, Richard Stallman , emacs-devel@gnu.org To: Phil Sainty Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Fri Sep 07 23:55:17 2018 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1fyOij-0002P3-4g for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2018 23:55:17 +0200 Original-Received: from localhost ([::1]:40442 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyOkp-00069l-KM for ged-emacs-devel@m.gmane.org; Fri, 07 Sep 2018 17:57:27 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:33087) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1fyOh5-0002uu-5e for emacs-devel@gnu.org; Fri, 07 Sep 2018 17:53:36 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1fyOh3-0000b9-TL for emacs-devel@gnu.org; Fri, 07 Sep 2018 17:53:35 -0400 Original-Received: from mo6-p00-ob.smtp.rzone.de ([2a01:238:20a:202:5300::7]:28419) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1fyOh1-0000P7-O5; Fri, 07 Sep 2018 17:53:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; t=1536357210; s=strato-dkim-0002; d=adminart.net; h=References:Message-ID:Date:In-Reply-To:Subject:Cc:To:From: X-RZG-CLASS-ID:X-RZG-AUTH:From:Subject:Sender; bh=zmr8RkFSOw8F80vErGRtSJtToI0HcG+/YdM5wswemJQ=; b=rPCOnQ8wHK1D649ltXJuuXmwLZEfoEPuEoMsTjAwUowsRG2i/tmYF58aJEcDdA/tdQ 0xq5g3jg/3lnPtg51JmY6CYGsQXPNVJlajHdLc+DlIyzAMSQPQAaWnIsg9ycVFeEv81Q F0aiTRbiNLfjxNG//5FpwD/tsps3n4W14zEbhb6qL7AAGx3T5mVfBT6wDqf7Z/sPIHOH /I9K/i06C0bQ/2GewXzb5RX+CG9zCKoncR8iRu7S88evGwwC8shLVw3L6zpPEpRRBw1z CDIMGPXD23/IIkq0/7NL4J5/LvChmqV2CeFTDrDJ/39Uv1ZaW0EGvzAk0YJPQWgmiiyV XbOw== X-RZG-AUTH: ":O2kGeEG7b/pS1FS4THaxjVF9w0vVgfQ9xGcjwO5WMRo5c+h5ceMqQWZ3yrBp+AVdIIwXjneEe9k=" X-RZG-CLASS-ID: mo00 Original-Received: from himinbjorg.adminart.net by smtp.strato.de (RZmta 44.0 DYNA|AUTH) with ESMTPSA id e03b99u87LrHD7w (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (curve secp521r1 with 521 ECDH bits, eq. 15360 bits RSA)) (Client did not present a certificate); Fri, 7 Sep 2018 23:53:17 +0200 (CEST) Original-Received: from toy.adminart.net ([192.168.3.55]) by himinbjorg.adminart.net with esmtp (Exim 4.90_1) (envelope-from ) id 1fyOgm-0001BI-Px; Fri, 07 Sep 2018 23:53:16 +0200 In-Reply-To: <92e5aad5-47b9-f10f-6046-863dbfc1f0d1@orcon.net.nz> (Phil Sainty's message of "Sat, 8 Sep 2018 03:34:37 +1200") X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 2a01:238:20a:202:5300::7 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.21 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.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.org gmane.emacs.devel:229458 Archived-At: Phil Sainty writes: > On 08/09/18 02:15, hw wrote: >> Phil Sainty writes: >>> Whatever you feel you're gaining from hiding the menus surely >>> can't be of greater benefit to you than all the knowledge and >>> functionality that you're missing as a consequence? >> >> Well, I'm not missing anything. What would I be searching for in >> the menues, and why would I bother to look? > > In the snippets I quoted before, as well as in other earlier emails, > you have explained how there are numerous Emacs features and modes > that you don't really know how to use because you don't know what the > key bindings are; That must have been a misunderstanding. Of course there are many features and key bindings I don't how to use or I don't know about at all. I will probably never know all there is to know. And that's fine because I do not need all the available features and key bindings. I only need to know those I use, and there is a difference between things I use frequently and things I rarely use. Info is one of the things I rarely use. The last time I used info was probably 4 or 5 years ago. I simply didn't need to use it in between because I was using Emacs just fine all the time. That is why I'm saying that it would be nice if the menu was automatically enabled with modes I rarely use and disabled with those I frequently use. It might have occured to me to look into the menu to find out how to go back if the menu had been enabled --- that the menu would have enabled itself automatically for the info buffer would have told me that I'll probably need it. Is that so difficult to understand? > and also that you have hidden the feature which would most trivially > let you find out what they did and how to use them. With the menus > visible I am *imagining* that it would occur to you to look at them > the next time you were wondering what sorts of commands a particular > mode provided, and that in the process you may even discover some > useful key bindings as well. I would try to ignore it if it was permanently enabled. It wastes screen space, it is inefficient and I rather learn the key bindings than having to use a menu. I wouldn't use it *because* it's permanently enabled and thus permanently annoys me. >> Do you have an example? > > Sure. You said just before: > >> Emacs can work with CVS systems like git. I haven't found yet out >> how to make use of this feature, yet I'm sure there are lots of key >> bindings that make editing source code much more efficient when you >> are using CVS systems. > > Sitting there waiting in the Tools -> Version Control menu we find > all of the following: I wouldn't enable the menu if I wanted to use this mode. I would read the documentation and learn how to use it. > [...] > > I have to admit that I'm genuinely perplexed. On the one hand you > profess to having some difficulty finding out how to do things -- or > even what things there might be available to do -- all of which sounds > to me a lot like "I'm missing things"; and on the other hand you say > "I'm not missing anything" and that you see no reasons to look in the > menus, despite those menus existing for the purposes of showing people > the things they can do, and making it easy to do them even when they > don't know the key bindings. I think that's probably because you misunderstood. When I was stuck in the info help, I wanted to read documentation about tramp, not about anything else. I followed a reference and didn't know how to get back, so I looked into the help. Then I just wanted to get out of the stupid help page because even that page didn't tell me how I could get back. Quitting the info buffer doesn't help for some reason because when you call info again, you get to the same place where you left --- that is a very annoying feature not only with info buffers. So finally I killed the buffer and started over. It didn't occur to me to turn on the menu. Why would it? It had nothing to do with I wanted. So guess what keys especially a new user might try to go back. Chances are pretty good he would try Alt-left rather than an ideosyncratic key only Emacs knows about. But that doesn't work, and the user remains stuck. The user quits the info buffer and calls info again to start over --- just to find out that he is still stuck at the same place. The new user may not be familiar with this weird behaviour and not know that he needs to kill the buffer. Seriously? Do you call that good design? Do you call that helpfull? I'm merely saying this is something to improve upon. You're pushing it back by saying I should have the menu enabled. The new user might still have it enabled, but he might also have found out that it can be disabled. He might have disabled it because he wants to learn the key bindings, and disabling the menu supports that because when something is harder to look up, there is more incentive to remember it. It might not occur to him to enable it when he's stuck in the help of info, or somewhere else, while trying to read documentation about something. That someone has trouble finding out something can happen to everyone. So why not make it easier for everyone? > If the menus are not one of the *best* answers to your issue, then > I've completely and utterly misunderstood. Apparently it happens to me all the time that people don't understand what I'm saying :/ I think I've found a better answer to the problem with the idea of the menues enabling and disabling themselves automatically. The answer to that was that I can have that by using mode hooks. That probably means it will never be considered to perhaps become a default behaviour. I think it would be an improvement, especially for new users who do not know about mode hooks. I don't know how to do it, either, but I'm sure I can find out when I want to.