From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Andrea Corallo Newsgroups: gmane.emacs.bugs Subject: bug#54437: 28.0.92; command-modes returns nil for native compiled functions Date: Mon, 21 Mar 2022 09:56:00 +0000 Message-ID: References: <87y218pr4x.fsf@dell.mail-host-address-is-not-set> <87fsngsfto.fsf@gnus.org> <87a6dosf58.fsf@gnus.org> <87y216owss.fsf@gnus.org> <83fsneezor.fsf@gnu.org> <874k3tq0lo.fsf@gnus.org> <87y214odof.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="9939"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: kahatlen@gmail.com, 54437@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Mon Mar 21 10:57:18 2022 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 1nWEmr-0002KP-IS for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Mar 2022 10:57:17 +0100 Original-Received: from localhost ([::1]:40408 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nWEmq-0004HP-BZ for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 21 Mar 2022 05:57:16 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:34226) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nWEmb-00044k-TA for bug-gnu-emacs@gnu.org; Mon, 21 Mar 2022 05:57:01 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:42041) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nWEmb-0000nS-Jy for bug-gnu-emacs@gnu.org; Mon, 21 Mar 2022 05:57:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nWEmb-0001Rj-J2 for bug-gnu-emacs@gnu.org; Mon, 21 Mar 2022 05:57:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Andrea Corallo Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 21 Mar 2022 09:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 54437 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: moreinfo Original-Received: via spool by 54437-submit@debbugs.gnu.org id=B54437.16478565685497 (code B ref 54437); Mon, 21 Mar 2022 09:57:01 +0000 Original-Received: (at 54437) by debbugs.gnu.org; 21 Mar 2022 09:56:08 +0000 Original-Received: from localhost ([127.0.0.1]:35938 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nWElj-0001Qb-Tm for submit@debbugs.gnu.org; Mon, 21 Mar 2022 05:56:08 -0400 Original-Received: from mx.sdf.org ([205.166.94.24]:56489) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nWEle-0001Q1-DV for 54437@debbugs.gnu.org; Mon, 21 Mar 2022 05:56:06 -0400 Original-Received: from ma.sdf.org (ma.sdf.org [205.166.94.33]) by mx.sdf.org (8.15.2/8.14.5) with ESMTPS id 22L9u0T9013126 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256 bits) verified NO); Mon, 21 Mar 2022 09:56:00 GMT In-Reply-To: <87y214odof.fsf@gnus.org> (Lars Ingebrigtsen's message of "Sun, 20 Mar 2022 16:18:24 +0100") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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:228655 Archived-At: Lars Ingebrigtsen writes: > Andrea Corallo writes: > >> Yes, we'd still need to store the information in each .eln and update >> the value of this new global hash table each time (probably in >> comp--register-subr). So some C should be modified anyway even if >> (maybe?) less, I doubt is doable in the realease branch at this point >> anyway. > > There's also the problem with stale entries -- if you're re-loading an > .eln with different functions with different command modes, you'd need > some way to nix out the old ones (for instance, if a command goes from > having modes to not). Or you'd have to register all the commands in the > hash table, which seems awkward. In comp--register-subr I'd add the entry into the hash table if the function being loaded is connected to some mode or I'd clean the entry in case the new function being defined has no mode but an entry is already present. But that said I agree with you that given the resulting patch would not be trivial and we have to touch some C anyway having two codes to solve the same issue doesn't sound like a good idea. > I think if we want this in Emacs 28, it's probably safer to just > cherry-pick the commit to master, as invasive as that is. On the other > hand, the command-modes stuff is new functionality in Emacs 28, so just > documenting that it doesn't work with native-comp (yet) would also be > fine, and then perhaps do an Emacs 28.2 later with the patch. Agree Thanks Andrea