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: Last use of defadvice in Emacs Date: Fri, 08 Apr 2022 09:00:34 +0300 Message-ID: <83fsmoazct.fsf@gnu.org> References: <834k35ctd4.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="15028"; mail-complaints-to="usenet@ciao.gmane.io" Cc: bug-cc-mode@gnu.org, acm@muc.de, emacs-devel@gnu.org, raman@google.com To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Apr 08 08:06:19 2022 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 1nchlC-0003dt-54 for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 08:06:18 +0200 Original-Received: from localhost ([::1]:42568 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nchlA-0005Ph-QZ for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Apr 2022 02:06:16 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:58440) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nchfZ-0002MJ-U8 for emacs-devel@gnu.org; Fri, 08 Apr 2022 02:00:30 -0400 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]:59180) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nchfY-0001tm-Ti; Fri, 08 Apr 2022 02:00:28 -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=Bj0+DQiX/qbo76jFkXVJ0l/9C6NWB8ccY44NuStw0cQ=; b=D/V4oXA0IvO0KfLsx6lT WTi07Xw5rAeEUxWJnqtBx/CMAJrmLUH+0A89SfqVMXVgTfiZLPepl8cQWCiqcWnrHVpKEBvGNP1qY axQ9f5x12teBN2x9eomHc7uDSy+4X7YNwxd6cCzgrzTX/S8xzx7lKcNXHFxocWlzrq6FP0RCJsqny 6asErmTDzKWKB2FIApKdv/NBm4kxQ5c/loMBnnY8fmXD17OI4+9C77ZwcqKnand3SnNHWtEa5lmL9 LctpKUpsYmjNXGv0BeRvFN8wCvHNPiML/PZiYQX5iUG5fu2YIaDhkDAtRP4FDYWDAl+yHRIsSx74r 7lZ6CoFgyhrAcg==; Original-Received: from [87.69.77.57] (port=2828 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 1nchfV-0002Vk-Ty; Fri, 08 Apr 2022 02:00:28 -0400 In-Reply-To: (message from Stefan Monnier on Thu, 07 Apr 2022 17:59:41 -0400) 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" Xref: news.gmane.io gmane.emacs.devel:287919 Archived-At: > From: Stefan Monnier > Cc: raman@google.com, acm@muc.de, bug-cc-mode@gnu.org, emacs-devel@gnu.org > Date: Thu, 07 Apr 2022 17:59:41 -0400 > > > It would be nice if these issues (perhaps in less academic shape and > > in more practical terms) could be added to the ELisp manual, > > Not sure what "more practical terms" would look like. Something that makes it clear why using defadvice with lexical-binding will cause trouble: an explanation with one or two examples. > BTW, in https://emacs.stackexchange.com/questions/3079/#3102 > I mention a few other reasons, such as: > > • Design simplicity: defadvice has various notions that are > generally difficult to understand precisely and/or rarely used. > E.g. the difference between "enabling" and "activating" advices. > Or the meaning of "pre" and/or "compiled". There are also quirks in > the handling of `ad-do-it`, such as the fact that it looks like > a variable-reference rather than a call, or the fact that you need > to (setq ad-return-value ...) explicitly rather than simply > returning the value. > > • Defadvice suffers from various problems w.r.t macroexpansion and > compilation: the body of an advice is not exposed as "code" (which > the compiler and macroexpander see) but as "data" which is later on > combined to make up an expression. So macroexpansion happens late > (which can causes surprises if you use things like > `(eval-when-compile (require 'foo))`) and lexical-scoping is hard to > preserve correctly. > > E.g. regarding the first point, `ad-activate` or `ad-deactivate` are > arguably misdesigns since they have a global effect (they affect all > pieces of advice applied to a given function) and most uses of them are > latent bugs. This, too, is important to know, IMO. > This said, I don't know how important it is to document those > advantages Well, I obviously think it is, which is why I asked to do that, please. > To me the main benefit is that `advice-add` is simpler both in > implementation and in API (no need to learn about `add-(de)activate`, > `ad-(g|s)et-arg(s)`, `ad-do-it`, `ad-(en|dis)able-advice`, the > differences between "adding", "enabling", and "activating", the > occasional need to figure how and when to compile the code, ...). Perhaps, this should also be mentioned in the manual. Thanks.