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: How to make Emacs popular again. Date: Sat, 26 Sep 2020 20:36:51 +0300 Message-ID: <20200926173651.GU1349@protected.rcdrun.com> References: <20200926163008.GS1349@protected.rcdrun.com> <83y2kwpjfo.fsf@gnu.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="7093"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/1.14.0 (2020-05-02) Cc: jamtlu@gmail.com, emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Sat Sep 26 20:47:47 2020 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 1kMFEZ-0001kp-3c for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Sep 2020 20:47:47 +0200 Original-Received: from localhost ([::1]:39148 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kMFEY-0004IV-1p for ged-emacs-devel@m.gmane-mx.org; Sat, 26 Sep 2020 14:47:46 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58032) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kME8D-0000U0-H9 for emacs-devel@gnu.org; Sat, 26 Sep 2020 13:37:10 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:48523) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kME89-00088r-GU for emacs-devel@gnu.org; Sat, 26 Sep 2020 13:37:09 -0400 Original-Received: from localhost ([::ffff:197.239.40.117]) (AUTH: PLAIN securesender, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 0000000000081F4E.000000005F6F7C39.0000750F; Sat, 26 Sep 2020 10:36:56 -0700 Content-Disposition: inline In-Reply-To: <83y2kwpjfo.fsf@gnu.org> Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@rcdrun.com; helo=stw1.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/09/26 12:02:28 X-ACL-Warn: Detected OS = Linux 2.2.x-3.x [generic] [fuzzy] 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-Mailman-Approved-At: Sat, 26 Sep 2020 14:46:29 -0400 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:256492 Archived-At: * Eli Zaretskii [2020-09-26 19:55]: > You cannot learn this stuff by walking around the UI and reading the > tooltips. It's unrealistic. Those tooltips assume some minimal > knowledge of the terminology and the UI elements, which are described > in the tutorial and in the first chapter of the manual. It is your opinion. I tried finding what should undecided-unix mean, and I cannot find, I just found that "unix" is alias for "undecided-unix". Does the tooltip assume that only experienced user, in this case, experienced developer is to know what it means?! You say that it is described in the tutorial and in the first chapter of the manual, and I gave you example with one term "undecided-unix" and it is not described or defined. It could be defined in the source code, but tooltip should not be written with such assumptions, tooltip should help the user understand what is it. In general tooltips are good. I just say there is space for improvement. > Making each term a hyperlink that leads to its description, then > each term in that description a hyperlink, and so on and so forth, > will in effect take the user down a huge rabbit hole. Is not that complex, maybe you should try wordnut package, I am using it all the time. I can find definition of the word "time" and I am facing new split buffer and if there is other word I do not understand, I can enter into its definition, and come back with "l" or quit, so it is very easy to provide a system of defining terms, they need not be underlined or highlighted as words. I think every term should be reachable from Emacs, as defining and helping users define and clear the meanings of words is what is making users understand the Emacs. > Users who need to actually do something useful with their time, not > just follow hyperlinks, will very quickly lose patience and stop > following. I just have a feeling you got that opinion too subjectively. In my opinion, every word should be reachable, so that user can understand everything, that was already principle of Emacs, that is why there is {C-h k} or other describe functions. It just needs better interactivity with users and improvements. > > - Making Emacs friendlier will be easier with a built-in dictionary > > that will describe any terminology in easy English > > We already have that: the Glossary section of the manual. But I don't > think taking the user there for each non-trivial word in our > documentation is a practical idea, or even a good one. If user cannot understand the word, then cannot understand the sentence, so how it can be good to bring users to misunderstandings? I don't get the logic. What is good is to bring users to understanding. > > - I press {C-h k} and then choose Tools -> Search Files (Grep)... > > > > Side comment: if it runs "grep" command, I don't know why it is > > capitalized, but alright. > > > > I wanted to find out about "Search Files..." so the menu option is > > pretty clear, it helps me search files, but then description about > > "Search files" does not even mention the word "search". > > Unsurprisingly, the doc string assumes the user already knows what > Grep is. So it doesn't say "search", because that's what Grep stands > for. >From the new user viewpoint I cannot possibly agree with that explanation. Descriptions of menus should be accessible and understandable for users especially from a new user viewpoint. > Doc strings are in generally terse; if you want more details, > including background etc, you need to read the description of the > commands in the user manual. There's a 95-line section there about > M-x grep and related commands. I am not speaking of myself Eli. I am speaking of new user viewpoint. Even "Search files..." is not well described. You cannot possibly design any interface for new user with experienced user viewpoint. The "Search files" with grep would actually mean to search the files containing certain term. But for new user, "Search files" would probably mean to find those files named "Alice-Homework.txt" or something like that. It is good for developers to think more from a new user viewpoint. Within Gnome, if you wish to find files, you open some find file dialogue and you type file names and if it is using grep or not, why it does matter? It does not matter for new user, as person wants to use "Search files". We speak here more of principles of design of the interface and descriptions. Practical implementations may come later. Jean