From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Imports / inclusion of s.el into Emacs Date: Mon, 04 May 2020 22:50:43 -0400 Message-ID: References: <831ro2tqqx.fsf@gnu.org> <4a1fd3f4-df92-c756-9874-4d07b54148ac@yandex.ru> <3bd09dca-dcdc-7569-e5fb-f6b53397af9d@yandex.ru> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="710"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, dgutov@yandex.ru, joaotavora@gmail.com, monnier@iro.umontreal.ca, emacs-devel@gnu.org To: chad Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue May 05 04:51:20 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 1jVnfz-000Y4E-SM for ged-emacs-devel@m.gmane-mx.org; Tue, 05 May 2020 04:51:19 +0200 Original-Received: from localhost ([::1]:41626 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVnfy-0007TR-Ub for ged-emacs-devel@m.gmane-mx.org; Mon, 04 May 2020 22:51:18 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:55408) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jVnfR-0006s3-Mj for emacs-devel@gnu.org; Mon, 04 May 2020 22:50:45 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:45344) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jVnfR-0008Je-6x; Mon, 04 May 2020 22:50:45 -0400 Original-Received: from rms by fencepost.gnu.org with local (Exim 4.82) (envelope-from ) id 1jVnfP-0005nP-8T; Mon, 04 May 2020 22:50:43 -0400 In-Reply-To: (message from chad on Sun, 3 May 2020 17:12:00 -0700) 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:248928 Archived-At: [[[ To any NSA and FBI agents reading my email: please consider ]]] [[[ whether defending the US Constitution against all enemies, ]]] [[[ foreign or domestic, requires you to follow Snowden's example. ]]] > Cruically, I > would go further and say that Emacs will be poorer over-all if it insists > on supporting only one part of this spectrum. I think that it's fair to > say that it currently leans away from the method that a large number of new > coders are demonstrating that they prefer. If that refers implicitly to API-based help screens, I don't think anyone is against better support for those. There is no need to argue for the general idea of better API-based help screens. The question is if and how far > emacs is willing to change to adapt. No, that is NOT the question. People have not asked for "better API-based help screens". What they have asked for is specific ways of implementing such API-based help screens. Ways that, for the most part, would have other painful consequences. People are arguing that we should suffer those painful consequences. However, discussion has revealed that one of the things some of those people really want is better API-based help screens. We can implement that without any downside. I've presented a few ways. There are surely others. Some of these API-based help screens would require attaching data to some function names -- for instance, to say that 'concat' is a function for operating on strings. But that is not hard. When we see what data is useful, we can install it. So don't worry about installing it -- figure out what data is useful for this. Fitting these better API-based help screens into the contexts where they would be most useful would require changes in various places, including apropos.c. But those changes are not hard. When code for those screens is implemented and ready to install, we will put in the changes to invoke the code from the best places. Would people like to write code to display these help screens as they would like them to appear, based on the data that is available or that we could add? -- Dr Richard Stallman Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)