From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: JD Smith Newsgroups: gmane.emacs.bugs Subject: bug#55491: All completion fragments get added to obarray Date: Tue, 17 May 2022 18:50:41 -0400 Message-ID: References: <8AB5676F-ABCB-4849-AD65-B302AC5BDE6F@gmail.com> <87sfp7hpgg.fsf@gnus.org> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3696.80.82.1.1\)) Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="15073"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 55491@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Wed May 18 00:51:11 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 1nr623-0003jz-1X for geb-bug-gnu-emacs@m.gmane-mx.org; Wed, 18 May 2022 00:51:11 +0200 Original-Received: from localhost ([::1]:52802 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nr621-0002dD-LV for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 17 May 2022 18:51:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:50418) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nr61u-0002cv-51 for bug-gnu-emacs@gnu.org; Tue, 17 May 2022 18:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:36175) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nr61t-000385-Sd for bug-gnu-emacs@gnu.org; Tue, 17 May 2022 18:51:01 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1nr61t-0008GN-MB for bug-gnu-emacs@gnu.org; Tue, 17 May 2022 18:51:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: JD Smith Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 May 2022 22:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 55491 X-GNU-PR-Package: emacs Original-Received: via spool by 55491-submit@debbugs.gnu.org id=B55491.165282785331748 (code B ref 55491); Tue, 17 May 2022 22:51:01 +0000 Original-Received: (at 55491) by debbugs.gnu.org; 17 May 2022 22:50:53 +0000 Original-Received: from localhost ([127.0.0.1]:58305 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nr61k-0008G0-Ur for submit@debbugs.gnu.org; Tue, 17 May 2022 18:50:53 -0400 Original-Received: from mail-qv1-f50.google.com ([209.85.219.50]:44025) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1nr61i-0008Fn-I1 for 55491@debbugs.gnu.org; Tue, 17 May 2022 18:50:51 -0400 Original-Received: by mail-qv1-f50.google.com with SMTP id v5so267771qvs.10 for <55491@debbugs.gnu.org>; Tue, 17 May 2022 15:50:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bhrGiFBG4n26x5ImDPvv15AWFE2hpK5O70pWHGqHptI=; b=PtR7sklNdIDCMrQta894TEG19Cszmd+v8hBT17XkCIEXlgEILVFbpDSO4MJ39LRFDJ z4lc2lMllTprBrdXzFgPMMK0kQKCewm5lHtKgrPrgvzZ2W6+Qi9446JTDkAgutKHPsW9 Evu2YImm8vMcb/9+o2iqqRPAjQpLe8LGXJliUXok89VLrTMKjJNvAAsBVt3WN0r3Em+9 YIfaEQI7/sQEVC6lGXaBPmX2wG+0nnQjZW/BXuOndeQdIbUXv6XMPA9YrBFTuIzXCbHq jtLpaRHNWM0OUTgj/nsQs0sQKQmjCr67UPcC9r7RpdTFM3x7hYxxfJYNAXgyjdWFNnVQ b/Gg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:subject:from:in-reply-to:date:cc :content-transfer-encoding:message-id:references:to; bh=bhrGiFBG4n26x5ImDPvv15AWFE2hpK5O70pWHGqHptI=; b=VSFEpolJeLZLe2kJqKAf7bwV036NOapGlboJ+XD2ZMyWqL2Ch2ff0rHy4VD4McGuPV p0xhRcoddOPmudQ7hhXmrb0DKKMSNMqe/POizekuJniIODlMRtZka0BBPzJW2jT15qCu undttGebWMqfFrzjqxh3Kn1wRwuONM91zNowRIVZrRpEty33bIBGbhdTj54V+mWE8S9o jEA+ophsICRqwYxBMIF6URkaSbct19NOQKWBKrKaevRJWhukLA+adw89refnRDyjO2pT T0c/psgwEQ7HxmDICiEEIAnxQ6MgEO06emuvcTOWQ68saEwdtue2e6m487ur8o1j+lFs u+og== X-Gm-Message-State: AOAM533+AEjVIlhL8kwHENLyXgksomaR7Tl883qZS0WIcUQFroXm7HZl whvUBWahn2OK3ETfm2qfpaeA7Q1riPU= X-Google-Smtp-Source: ABdhPJx3n4pkEsP8WC/AJb7I5ggfSBfaEvv/zRsvjngbs7ecZUzav+ptbJRMDHHu51nVAo3ahPXrcA== X-Received: by 2002:a05:6214:21ef:b0:461:da67:89f9 with SMTP id p15-20020a05621421ef00b00461da6789f9mr6102505qvj.62.1652827844778; Tue, 17 May 2022 15:50:44 -0700 (PDT) Original-Received: from smtpclient.apple (cm-134-228-57-173.buckeyecom.net. [134.228.57.173]) by smtp.gmail.com with ESMTPSA id h25-20020ac87459000000b002f39b99f6c4sm119456qtr.94.2022.05.17.15.50.42 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Tue, 17 May 2022 15:50:43 -0700 (PDT) In-Reply-To: <87sfp7hpgg.fsf@gnus.org> X-Mailer: Apple Mail (2.3696.80.82.1.1) 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:232503 Archived-At: Thanks for your thoughts. The context is fairly specific =E2=80=94 = using cape-super-capf to compose two CAPF=E2=80=99s: = elisp-completion-at-point and cape-dabbrev. This results in incorrect = test-completion calls which interfere with candidate selection. With = your nudge, I discovered this is because cape is not handling the = elisp--shorthand-aware-* predicates returned by the elisp completion = system in all cases, so it can be fixed there.=20 I guess whether this constitutes a bug depends on whether anyone would = expect unbound completion fragments to pollute the obarray.=20 > On May 17, 2022, at 4:30 PM, Lars Ingebrigtsen wrote: >=20 > JD Smith writes: >=20 >> (intern-soft "ohno") -> nil >> (ohno -> No match >> (intern-soft "ohno") -> ohno :( >>=20 >> This has the result that, e.g.: >>=20 >> (test-completion "ohno" obarray nil) ; t! Sigh >>=20 >> will always return t during completion, for any completed fragment. >> For completion systems that complete against obarray >> (e.g. emacs-lisp), this is obviously undesirable. >=20 > Completion in emacs-lisp-mode doesn't take unbound variables into > account, I think? So putting stuff into the obarray shouldn't have = much > (if any) noticeable effect. >=20 > Where do you see anything undesirable as a result of this? >=20 > (This behaviour is still present in Emacs 29.) >=20 > --=20 > (domestic pets only, the antidote for overdose, milk.) > bloggy blog: http://lars.ingebrigtsen.no