From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.devel Subject: Re: Inferred function types in the *Help* buffer Date: Thu, 01 Jun 2023 14:35:42 +0300 Message-ID: <83ilc7ct4h.fsf@gnu.org> References: <83o7manh0e.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="24736"; mail-complaints-to="usenet@ciao.gmane.io" Cc: acorallo@gnu.org, akrl@sdf.org, emacs-devel@gnu.org To: Mattias =?utf-8?Q?Engdeg=C3=A5rd?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu Jun 01 13:35:37 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 1q4gaf-0006CX-34 for ged-emacs-devel@m.gmane-mx.org; Thu, 01 Jun 2023 13:35:37 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1q4ga9-0000bw-TE; Thu, 01 Jun 2023 07:35:06 -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 1q4ga3-0000S0-DV for emacs-devel@gnu.org; Thu, 01 Jun 2023 07:35:01 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4ga1-0004dP-Ko; Thu, 01 Jun 2023 07:34:58 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=MIME-version:References:Subject:In-Reply-To:To:From: Date; bh=LO2YMS4wu/DKk+zOIB8Ff6nJXYirQDNshOuVl3hWZwI=; b=ahGa/S7GjjtWvyITpH/B MzzGE9ioTKJV3ckWmgfWQgjPNbh8FJTPqEm81jGEBhikrEESs4b4bkAm8WkvJSn35TtI5N6alVeDS 0BmWbnoc/hYmDvHe58vYMMPkCwKG2KtHpYRIFRORWoSMdr/B00ZN+IuR/O66/GEpgEH1Br+tDCZmr IT85fd3bFZ214mAXO94/Fn9qnz1DuSHvA60RrqmA/Kdl1tKmJUJVlzxY5wa5qaEPW5fE7KybdqVCZ YcMwmsxbbSNy0RlumeuFBqb3dPG9QY6iLMxXbKHLBWOmBKlxKf3sP8kXPqAwQcklZgGDayE5l/bbc hNoICeRpFOq2jw==; Original-Received: from [87.69.77.57] (helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1q4ga0-00079y-TK; Thu, 01 Jun 2023 07:34:57 -0400 In-Reply-To: (message from Mattias =?utf-8?Q?Engdeg=C3=A5rd?= on Thu, 1 Jun 2023 13:28:43 +0200) 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:306503 Archived-At: > From: Mattias Engdegård > Date: Thu, 1 Jun 2023 13:28:43 +0200 > Cc: Andrea Corallo , > Eli Zaretskii , > emacs-devel > > 31 maj 2023 kl. 14.19 skrev Andrea Corallo : > > >> The main reason why I'd like to move them out is not to require the load > >> of comp.el for a simple C-h f. Secondary yeah I think that if it's in > >> use outside the compilation functionality should just not live there. > > > > Thinking about more I can't see why we should force people to load > > comp.el for a simple C-h f. If this data is consumed by both comp.el > > and help-fns.el it should stay in a commonly available place. > > Let's use a separate file for the data then, rather than subr-x.el. That also keeps down the size of subr-x.el which is used very widely in practice. If the information is moved into function declarations then that new file will just go away. I thought we all agreed to leave it in comp.el. Why not?