From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Ergus Newsgroups: gmane.emacs.devel Subject: Re: [External] : Re: Question about completion behavior Date: Mon, 14 Mar 2022 00:38:00 +0100 Message-ID: <20220313233800.44vfuwjje6wgsdm2@Ergus> References: <8735jqhxdr.fsf@yahoo.com> <20220310140331.xa53sex6wywkr56l@Ergus> <86ee39r69o.fsf@mail.linkov.net> <20220312001752.stzknhydiep6nsxn@Ergus> <8635jn81wt.fsf@mail.linkov.net> <20220313112108.j3lvtnvgybo7em65@Ergus> <86pmmpahdm.fsf@mail.linkov.net> <20220313211512.2kqyqcdpylxe2mgb@Ergus> Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii; format=flowed Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="26819"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , Po Lu , Eli Zaretskii , Stefan Monnier , "emacs-devel@gnu.org" To: Drew Adams Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Mon Mar 14 00:42:13 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 1nTXqn-0006qx-7W for ged-emacs-devel@m.gmane-mx.org; Mon, 14 Mar 2022 00:42:13 +0100 Original-Received: from localhost ([::1]:51636 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1nTXql-0005ME-CD for ged-emacs-devel@m.gmane-mx.org; Sun, 13 Mar 2022 19:42:11 -0400 Original-Received: from eggs.gnu.org ([209.51.188.92]:49330) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1nTXnX-0003Ug-Ff for emacs-devel@gnu.org; Sun, 13 Mar 2022 19:38:51 -0400 Original-Received: from sonic309-14.consmr.mail.bf2.yahoo.com ([74.6.129.124]:45245) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1nTXnU-0005K7-GC for emacs-devel@gnu.org; Sun, 13 Mar 2022 19:38:50 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=aol.com; s=a2048; t=1647214727; bh=U1o1bKpNJcl6mjc+bc/daCISNokoxnObzCDQM6HOC2Y=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From:Subject:Reply-To; b=G1JCgRqolIy4TS8Qu6KAfRTeqgRs0BBXDqn41b2rvvFacQC/nfI/8PONK9NRCQ/fCmD5iAbPv5nGOGZmFKbOOM6BrRT2FDfPtrFCfTBMLO/a95GOCXyLRu7J78Nhq6jUigPJME2ASj9MB3PXQGzmiisTzNEBcRNLCWqlD/IjfSNwIRSMB+RXOUcx1hkYGCNC/TKgOpVKTAuvMsr/jyvUA+BASnwPEU+JwfWEdOzT+JNTTvCgsuA6Pz896Yl0hs/py5hx8n3c2WZfqNuoWZ3j4Y1wou2acbv8Cc8Pp6JH2+LwO34oEvqIHH8Oekk36IElOWDGttOSFaXN5xoKwPbjQQ== X-SONIC-DKIM-SIGN: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yahoo.com; s=s2048; t=1647214727; bh=vIqSHEfGrxEVjEhGAe9PScTuTyFo4fCyRX68dZhtQjQ=; h=X-Sonic-MF:Date:From:To:Subject:From:Subject; b=HMmhtiP8igXg6jb78d6ViEoZ9pgsnPb5Hs0tiLuvi2Cj5qV9DJz3uxe+X9w9047g31om7lz28BwOxr9XB64xjD8o6UXsq3m6eIkZis7tCS2gg8GmBL4MIU7xKmM5AaFbtZmKVXvE6k9Xag0F4w0GTbL/PRWJy7bWaJxh+mfWlsqpdqTCxtzA0xKJ81f2krj6LWZ9ZeUIH8RcKhSeKpE3fDWobpq9GnfGyOuVfl0+HFIPufXhNYsk/rMQShZHFFcksdbZTtmt8SiLu4t9JiCbaE25gBSVdPMnTQOJVaUplLfqrvmSHVo0V+WAeJ8lOps2ReIZDM4DBRZLmEsYYX8Tuw== X-YMail-OSG: sTWervAVM1neODafrGPWaCHcBj2A6ZGnJietCbCXuIunjq4KPL0.ob3NAJaaqhe B1tLR3Fmo.gs6YdNRuF0aTv5sOxNma8vS0bqu4bUci.xDn3mtxYRwMcx.Y8qN1jHVDqTvrUm1JiQ vHGGzq7Z.lRPPoJGjUFow9wnuAYwwA5h7nHU6YYH3iu66WuVKZPAGJH50RaFCKac6J4SgU.Rzw8r QStm5_pV6Sjcp8wYVXUTvZfMoEyY_J.Lre.Z4v2ob9ya4XNIj7CfKJzCGRGk4oxVK7o3MuJEjFoP .cUlhPA9c7QTeAqptAF5KJhdYnUTv0whrJ0WsOokY4YESDWqRMUU4rfEp_pfOgXjxz10sldNZ6aa z1NNDpcLqf9qBwVPR1KcwDqgkm26AYvLd__Rko7qBNfONRW9O8mLDxvso5ydqjv60gew9rKpQlnw vkeSXNIpEK_PZ4hh2MROfJi0u5G05mhYM2aSOan.juSewN6alOtvNTrjqU36j7I0egAqZSL01JIS IAqjkqqUgWr7Y833NqXYMU4ENbdFOXK1CETVN0vOdAO_3Camxzgg5piuPme0ZGxwfUTQRE5EXhoD Olkpn5YxYAnuNObAVjaapLdORV1X9BrOtRRDq0zCtl3cDl.yzqDsVRCouksUx5NAYeKL.sTpLrEF 4EQSHk0JyBa5JFXtYpywtSuAHRLj9K88Z1EKD1mtg9GP2DDNQH6CIpyfoGySDpYPiuoXNDVGlL77 _5JovmVJCfI2AByaZVeti2Q7yCSB85x9Q.XVV8c3Xn_UcX3iKSp85O0ebuaQCmSgEB20KTOI8wbv _vMDN5KU8pZI2XjOn7DVHWCNpSUE8gDAaWc9_zFR2u X-Sonic-MF: Original-Received: from sonic.gate.mail.ne1.yahoo.com by sonic309.consmr.mail.bf2.yahoo.com with HTTP; Sun, 13 Mar 2022 23:38:47 +0000 Original-Received: by kubenode518.mail-prod1.omega.ir2.yahoo.com (VZM Hermes SMTP Server) with ESMTPA ID 3a10e71ccc66164ca9e1ae7fb5a9afc7; Sun, 13 Mar 2022 23:38:41 +0000 (UTC) Content-Disposition: inline In-Reply-To: X-Mailer: WebService/1.1.19878 mail.backend.jedi.jws.acl:role.jedi.acl.token.atz.jws.hermes.aol Received-SPF: pass client-ip=74.6.129.124; envelope-from=spacibba@aol.com; helo=sonic309-14.consmr.mail.bf2.yahoo.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001, T_SCC_BODY_TEXT_LINE=-0.01 autolearn=unavailable autolearn_force=no X-Spam_action: no action 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:287095 Archived-At: On Sun, Mar 13, 2022 at 11:14:56PM +0000, Drew Adams wrote: Hi Drew: Man, please relax... > >Doesn't sound like it - not regarding what I >asked about, at least. > >I have nothing against keeping *Completions* >showing and updating it as a user changes the >pattern to match (and either explicitly asks >for a rematch or has elected to get automatic >rematching). > >In fact, I invented such behavior for Emacs >(a couple decades ago). > >But why would we not _remove_ *Completions* >when there are no matches? > >We tell users in the echo area that there are >no matches. Why also show an empty buffer, >for nonexistent completions, with a redundant >message there saying there are none? > >(That's IBM's "This page intentionally left >blank." But at least there was a reason for >that notice.) > >Maybe "the new code is simpler". It sounds >like the new user experience is less simple >- and maybe a step backward. > >I understand your feature would be optional. >It sounds like it has room for improvement. > The user experience is exactly the same than before. Just that now there is an option to change, suppress or/and get a counter with the total number of completions where there was before just a bit superfluous hard-coded message: "Possible completions are:" That's it. Everything else is exactly the same. As usual, I am not doing rocket engineering here; I am just adding something simple and obvious that nobody wanted to give any attention before; in spite of many more experienced lispers like you could implement this in 30 minutes two decades ago ;p. >> > Why would we ever say "0 possible completions"? >> > >> > Why bother with "possible"? We never show >> > IMpossible completions, do we? >> > >> > When there are no matches we just tell users >> > there's no match. Always have. Simple. > >And your answer is? Because the original message was: "Possible completions are:" and it has been there since ever without hearing your complains about that the completions are not IMpossible. I don't care anything about one word at all and if the user doesn't like the word or you want to put there "Drews completions are:", at least now you have an option to customize it as you prefer... Best, Ergus