From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: "Eric S. Raymond" Newsgroups: gmane.emacs.devel Subject: Shrinking the C core Date: Wed, 9 Aug 2023 05:46:55 -0400 (EDT) Message-ID: <20230809094655.793FC18A4654@snark.thyrsus.com> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="39439"; mail-complaints-to="usenet@ciao.gmane.io" To: emacs-devel@gnu.org Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Aug 09 11:48:11 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 1qTfnW-000A5Z-FK for ged-emacs-devel@m.gmane-mx.org; Wed, 09 Aug 2023 11:48:10 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qTfmP-0006pC-G6; Wed, 09 Aug 2023 05:47:01 -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 1qTfmN-0006ov-Ix for emacs-devel@gnu.org; Wed, 09 Aug 2023 05:46:59 -0400 Original-Received: from thyrsus.com ([71.162.243.5] helo=snark.thyrsus.com) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1qTfmL-0007Pt-Op for emacs-devel@gnu.org; Wed, 09 Aug 2023 05:46:59 -0400 Original-Received: by snark.thyrsus.com (Postfix, from userid 1000) id 793FC18A4654; Wed, 9 Aug 2023 05:46:55 -0400 (EDT) Received-SPF: pass client-ip=71.162.243.5; envelope-from=esr@thyrsus.com; helo=snark.thyrsus.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.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:308462 Archived-At: Recently I have been refamiliarizing myself with the Emacs C core. Some days ago, as a test that I understand the C core API and the current build recipe, I made and pushed a small commit that moved the policy code in delete-file out to Lisp, basing it on a smaller and simpler new entry point named delete-file-internal (this is parallel to the way delete-directory is already partitioned). I've since been poking around the C core code and am now wondering why there is so much C-core code that seems like it could be pushed out to Lisp. For example, in src/fileio.c: DEFUN ("unhandled-file-name-directory", Funhandled_file_name_directory, Sunhandled_file_name_directory, 1, 1, 0, doc: /* Return a directly usable directory name somehow associated with FILENAME. A `directly usable' directory name is one that may be used without the intervention of any file name handler. If FILENAME is a directly usable file itself, return \(file-name-as-directory FILENAME). If FILENAME refers to a file which is not accessible from a local process, then this should return nil. The `call-process' and `start-process' functions use this function to get a current directory to run processes in. */) (Lisp_Object filename) { Lisp_Object handler; /* If the file name has special constructs in it, call the corresponding file name handler. */ handler = Ffind_file_name_handler (filename, Qunhandled_file_name_directory); if (!NILP (handler)) { Lisp_Object handled_name = call2 (handler, Qunhandled_file_name_directory, filename); return STRINGP (handled_name) ? handled_name : Qnil; } return Ffile_name_as_directory (filename); } Why is this in C? Is there any reason not to push it out to Lisp and reduce the core complexity? More generally, if I do this kind of refactor, will I be stepping on anyone's toes? -- >>esr>>