From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Newsgroups: gmane.emacs.bugs Subject: bug#5293: 23.1; unload-feature on buffer-local hooks Date: Mon, 06 Apr 2020 23:27:55 +0200 Message-ID: <87o8s4jodg.fsf@gmail.com> References: <87hbr4p67t.fsf@blah.blah> <871uxsl778.fsf@blah.blah> <87aabnnxna.fsf@blah.blah> <87zhbojzmv.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="49748"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Notmuch/0.29.3 (https://notmuchmail.org) Emacs/28.0.50 (x86_64-pc-linux-gnu) Cc: Kevin Ryde , Stefan Monnier , 5293@debbugs.gnu.org To: Juanma Barranquero Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Apr 06 23:28:16 2020 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1jLZI0-000CrK-PJ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Apr 2020 23:28:16 +0200 Original-Received: from localhost ([::1]:38244 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLZHz-0000EG-Lk for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 06 Apr 2020 17:28:15 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37710) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jLZHn-0000E6-IQ for bug-gnu-emacs@gnu.org; Mon, 06 Apr 2020 17:28:04 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jLZHm-0007PX-FB for bug-gnu-emacs@gnu.org; Mon, 06 Apr 2020 17:28:03 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:37767) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jLZHm-0007PL-Bs for bug-gnu-emacs@gnu.org; Mon, 06 Apr 2020 17:28:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1jLZHm-0006Uh-8x for bug-gnu-emacs@gnu.org; Mon, 06 Apr 2020 17:28:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?=C5=A0t=C4=9Bp=C3=A1n_?= =?UTF-8?Q?N=C4=9Bmec?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 06 Apr 2020 21:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 5293 X-GNU-PR-Package: emacs Original-Received: via spool by 5293-submit@debbugs.gnu.org id=B5293.158620845324870 (code B ref 5293); Mon, 06 Apr 2020 21:28:02 +0000 Original-Received: (at 5293) by debbugs.gnu.org; 6 Apr 2020 21:27:33 +0000 Original-Received: from localhost ([127.0.0.1]:49313 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jLZHJ-0006T1-Fg for submit@debbugs.gnu.org; Mon, 06 Apr 2020 17:27:33 -0400 Original-Received: from mail-lf1-f50.google.com ([209.85.167.50]:44404) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1jLZHG-0006SW-Pr for 5293@debbugs.gnu.org; Mon, 06 Apr 2020 17:27:31 -0400 Original-Received: by mail-lf1-f50.google.com with SMTP id 131so650931lfh.11 for <5293@debbugs.gnu.org>; Mon, 06 Apr 2020 14:27:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:user-agent:date :message-id:mime-version:content-transfer-encoding; bh=I9r3Xq7b7RnzSsJrgiJa8v/kEyYbQuk3pFdF4ckALo8=; b=O9/n01n/+25XFTOL9hKzaBjAVB0Rxk4FJKt/WqLJ7HOGNV21KmmWYbbzZlYOyF+vaq o7qHyV+fiW5BSvDkFbikNAb1k0j7L1PvEFMAwf2JdxZfBCyeFbcufcRU7EqOaCJEPIq6 Vn9l6wrYsExjXQKJCljxng1BOzue4fGEQ/SlhD2S6QT/CC+J68efggmb7blwlwYYf4VH AAMRj3Riy4BdeLZ9NtSvKvtb3PSHIkMh34O3OU1GeIvs8tDcxLkOiD/JlUTzrbxb872y +sgSEUFZcqMvae318apECj3pSsFwXJfZNJCu/IXpKnWImJaVmEoLaQt3vFSUBXnJ2pcF PyYw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references :user-agent:date:message-id:mime-version:content-transfer-encoding; bh=I9r3Xq7b7RnzSsJrgiJa8v/kEyYbQuk3pFdF4ckALo8=; b=AN/X3lI2tcNA0hJpUtDHgpc33WfhOYdRhLn+CWJeLMDFOCFP+V1IS0gCYcWJU9/QPS yeYNpuPJNZVOCJwUr0yFR8WUm5lbhEVHtjajMM11Y64Dz9mkaSBZ29s6Oq0OnsIM3nLz DGmMH+Yk4Xozx8sL5pboIzH0zvcQxOLnyPKiUwt6r3aleOV1ZeyVX69mZQe+nDCmO1zV I7/5Pj20zc6ML1OdACmCWqfPx+KIZhiGV1FLSsBr3Yuc0g9LrIfLmqbfRdF1QZGrEQ00 u17i+m7Sb9cylRUfX2HthWp1a5dfGQ5id0xorusLmXa2redFijVyXcLKg2qoqnRDYAvP u2bg== X-Gm-Message-State: AGi0PubO9YXUrSSEaNBUTwcwu8x3cPn6WqUnleuwj0km2pVWGBWvt4IH 9L7xaiCReCmG5gVlpiWsfTw= X-Google-Smtp-Source: APiQypKdMw7JLzVUF2j92aSiQpsJPAeUbuRVw5qufLoakQpT5AO9mmP2OkN9WhFNRagx66uHFWG8fw== X-Received: by 2002:a19:e345:: with SMTP id c5mr14154480lfk.188.1586208444674; Mon, 06 Apr 2020 14:27:24 -0700 (PDT) Original-Received: from localhost ([185.112.167.47]) by smtp.gmail.com with ESMTPSA id 133sm10652216ljj.91.2020.04.06.14.27.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 06 Apr 2020 14:27:24 -0700 (PDT) In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 209.51.188.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.io gmane.emacs.bugs:178104 Archived-At: On Mon, 06 Apr 2020 22:39:50 +0200 Juanma Barranquero wrote: > On Mon, Apr 6, 2020 at 7:24 PM =C5=A0t=C4=9Bp=C3=A1n N=C4=9Bmec wrote: > >> Actually, I wonder if ignoring even the global hooks (as opined by >> Juanma) and enforcing more widespread usage of FEATURE-unload-function >> wouldn't be better; > > Anything automatically done in the unload-hook is just an ad hoc fix > for things the module author knows how to do better than us. One common scenario where this doesn't quite hold IIUC is minor modes which users are supposed to put on various hooks themselves: the library author has no way of dealing with that, short of doing something like `unload-feature' does, although checking for just a few known symbols from an unload function instead of the brute-force approach of the latter would arguably be more effective. > FEATURE-unload-function has already been there for a few years. I > don't remember right now whether we suggest in the mode-creation > documentation to use it, We do (lispref/tips.texi). Unfortunately, most elisp libraries in the wild seem to be written by people who either haven't read it, or have remained resistent to most of its edificatory influence. > but certainly that's something module authors should do, and the > automatic unloading is just a last-resort feature for those old > modules that don't. Actually, IME the older, the better behaved. I can't remember last time I saw a newish package with an unload function (while I do remember those without one which left my Emacs broken when I tried unloading them). > There's no point IMHO to make the hands off approach work better. I don't know what you mean by "hands off" here, but in any case, while I used to argue for handling as much as possible in `unload-feature', these days I don't feel strongly about it. So even though this particular issue (local hooks) does seem solvable (thanks again to Stefan!) without making anything much worse or uglier than it already is, I remain of two minds on whether it is the best thing to do or not. --=20 =C5=A0t=C4=9Bp=C3=A1n