From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Richard Stallman Newsgroups: gmane.emacs.devel Subject: Re: Finalizing 'inhibit-automatic-native-compilation' Date: Wed, 01 Feb 2023 00:04:34 -0500 Message-ID: References: <837cx8cey0.fsf@gnu.org> <83357vauh5.fsf@gnu.org> <837cx6a8me.fsf@gnu.org> <83357ua6ja.fsf@gnu.org> <83zga28ra8.fsf@gnu.org> <83r0vd97s0.fsf@gnu.org> <83lell73yv.fsf@gnu.org> <83k0145guk.fsf@gnu.org> Reply-To: rms@gnu.org Content-Type: text/plain; charset=Utf-8 Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="13119"; mail-complaints-to="usenet@ciao.gmane.io" Cc: eliz@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Feb 01 06:05:27 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 1pN5JH-0003Cz-Cw for ged-emacs-devel@m.gmane-mx.org; Wed, 01 Feb 2023 06:05:27 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1pN5IT-0003zq-AY; Wed, 01 Feb 2023 00:04:37 -0500 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 1pN5IR-0003zX-KQ for emacs-devel@gnu.org; Wed, 01 Feb 2023 00:04:35 -0500 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 1pN5IR-0001Np-CM; Wed, 01 Feb 2023 00:04:35 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=Date:References:Subject:In-Reply-To:To:From: mime-version; bh=f7dp3cxdZVqRAa2o8FgoIr9CBGCZ+ETruIDs8iUk8lo=; b=aopRAqIDWrz8 YO7oVl8f8YGcW27O4hOpCOORQZVIQXaX6hxbcOYtU8UkaJM3TY7m6Ma5HC3bkdBSA+IaSmP/A5qto 1+qiTp0PHc6UhWPByocJSflBkNOYqyhp7P2XUQWoobScgYb1mk0Za486E6TQ5aa7GO5r4wA56XWG9 aATNuUZSFIrk+OuyxtSDrjk/ZIhHjMtIxW5MxjzvXQuZnwXbjPm/ecImlJeFgc+hc5LPKJZDpPzaA PPvHgh0uow+x6T179GZvd1qvH+LgY/yjaw7ZW9eMHES3SKW/bI4M81yqfCJKRGW3CkEs/TbnqgpCk xskDXXvk0CkQG09sW0dDiA==; Original-Received: from rms by fencepost.gnu.org with local (Exim 4.90_1) (envelope-from ) id 1pN5IQ-0005hh-CN; Wed, 01 Feb 2023 00:04:34 -0500 In-Reply-To: (message from Stefan Monnier on Tue, 31 Jan 2023 09:26:23 -0500) 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:302846 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. ]]] > > Native compilation or no, I think that releasing a package A that puts > > advice on functions outside of A is asking to lose. > ?? > That's the whole point of advice. Not at all. The point of advice is for _users_ to alter functions in Emacs. But code in Emacs should never do that. If you want file A to modify the way file B operates, and these are both parts of Emacs, the proper way to do it is for B to define a hook variable, and document it. Then A can put something on that hook. The reason for this is to avoid confusion that hampers debugging. If B's behavior is altered through a hook, you will see in the code for B that it calls a hook at a certain place. That wil remind you to check the hook variable's value to see if that is affecting behavior. But if B's behavior has been altered through advice, nothing you see will remind you to check whether B is advised. The node Advising Named Functions in the Emacs Lisp Reference says: For these reasons, advice should be reserved for the cases where you cannot modify a function's behavior in any other way. If it is possible to do the same thing via a hook, that is preferable (@pxref{Hooks}). If you simply want to change what a particular key does, it may be better to write a new command, and remap the old command's key bindings to the new one (@pxref{Remapping Commands}). If you are writing code for release, for others to use, try to avoid including advice in it. If the function you want to advise has no hook to do the job, please talk with the Emacs developers about adding a suitable hook. Especially, Emacs's own source files should not put advice on functions in Emacs. (There are currently a few exceptions to this convention, but we aim to correct them.) It is generally cleaner to create a new hook in @code{foo}, and make @code{bar} use the hook, than to have @code{bar} put advice in @code{foo}. -- Dr Richard Stallman (https://stallman.org) Chief GNUisance of the GNU Project (https://gnu.org) Founder, Free Software Foundation (https://fsf.org) Internet Hall-of-Famer (https://internethalloffame.org)