From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Newsgroups: gmane.emacs.bugs Subject: bug#50959: 28.0.50; Shorthand symbols are unknown to Emacs Date: Sat, 2 Oct 2021 15:43:03 +0100 Message-ID: References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <831r59kyhf.fsf@gnu.org> <834ka4k15m.fsf@gnu.org> <83y27gijmz.fsf@gnu.org> <8335pmgnjy.fsf@gnu.org> <604da2cb10ac61f2b8b89a02c89056be@webmail.orcon.net.nz> <83a6jtff87.fsf@gnu.org> <5ac7a31cf2959c31c262a3377c736a5a@webmail.orcon.net.nz> <83ilygew7p.fsf@gnu.org> <83fstjdiwl.fsf@gnu.org> <837devdcz0.fsf@gnu.org> <93767e0236e7e85d27186293e38d3d25@webmail.orcon.net.nz> <8335pjd974.fsf@gnu.org> <87v92f3d15.fsf@gmail.com> <83y27bbs4d.fsf@gnu.org> <87mtnr3chk.fsf@gmail.com> <8735pj3amy.fsf@gmail.com> <83r1d3boeh.fsf@gnu.org> <83ilyfbj9h.fsf@gnu.org> Mime-Version: 1.0 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="32755"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Phil Sainty , 50959@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 02 16:44:09 2021 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 1mWgFF-0008EQ-BA for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Oct 2021 16:44:09 +0200 Original-Received: from localhost ([::1]:49798 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mWgFE-0007JV-DR for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 02 Oct 2021 10:44:08 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49266) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mWgF8-0007JN-HL for bug-gnu-emacs@gnu.org; Sat, 02 Oct 2021 10:44:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]:48643) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mWgF8-0004dP-A2 for bug-gnu-emacs@gnu.org; Sat, 02 Oct 2021 10:44:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1mWgF8-0004wz-7p for bug-gnu-emacs@gnu.org; Sat, 02 Oct 2021 10:44:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 02 Oct 2021 14:44:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 50959 X-GNU-PR-Package: emacs Original-Received: via spool by 50959-submit@debbugs.gnu.org id=B50959.163318580018962 (code B ref 50959); Sat, 02 Oct 2021 14:44:02 +0000 Original-Received: (at 50959) by debbugs.gnu.org; 2 Oct 2021 14:43:20 +0000 Original-Received: from localhost ([127.0.0.1]:60189 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWgES-0004vm-Cr for submit@debbugs.gnu.org; Sat, 02 Oct 2021 10:43:20 -0400 Original-Received: from mail-pj1-f47.google.com ([209.85.216.47]:38744) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mWgEQ-0004vX-Gh for 50959@debbugs.gnu.org; Sat, 02 Oct 2021 10:43:19 -0400 Original-Received: by mail-pj1-f47.google.com with SMTP id g13-20020a17090a3c8d00b00196286963b9so1257763pjc.3 for <50959@debbugs.gnu.org>; Sat, 02 Oct 2021 07:43:18 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=oh0EjatMDdUkBb2v0r3a7zYDbw64izDAhPBXYiJqE5Q=; b=Whn/LH8mNsJ2AQ/GQNNgWi7Li+8WCS/O2p5k8e0WKUWQzg7Dtk5cMBtid1tEHQ7rT1 JxtpwDzq2BdtPoR2j8bl/iZ/8OT49VKJ/FF6Cf0WYeYTgdI3l5+326K2lwco73p2YbCc OwBDPI+6Ront4ZCj0nvuZ39JpH7XdxWVLjlhKu3vGshZ4N+k0OFn2GkOUmx/cqrMSYb9 Vy0iWNGSi8En/HeVL84Gg7q5hbZ+jOgHjW06ORVFF5D3jpC2Xw99soPRKPQCNePfH9yV EdpMkxkB5ofUdV9/5y+MH8zB8XAV+0RvHNhqmd3u2YdVsEGpyB1Oda0LvVyJoUkYdZWu 1HNQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=oh0EjatMDdUkBb2v0r3a7zYDbw64izDAhPBXYiJqE5Q=; b=Ncp1Kj8Of5iJHMTvHb2C0vJ3GaOT/RiXbLEnywHl/jCorbQQXuDld9ZLEVfWrLv+1G 9w4UvWuqrQOSumibYHrZLEH65PumlmAfq+cRBJq3YXL49/MJJkPm+O0JUUgbR96NP2T/ oW104MSP1LcbHmfx0kirJc4VLqISmaCM6de1KBi09Yjw84VsW3kRqC8JZ/84ROaYc/+T KYJKKn0Kd4y6l2wiTJ4d8jqN0Jl+s3t633aTitJ7o3lLIBWyEMfOIsgvwKGoZ92bIXmZ vXtt4FJmQcGAWQ8jT0PzPHSo3kpGa2MSQDhta9T47UlnJhgv7EyoSPeP/q2NHvWWR9Y/ Bi7g== X-Gm-Message-State: AOAM533K3UNmgnfsCPG7ePx8WA79RUnONGYt6KNKfuN10npI9fAUdji9 ZnZsGsTkb1LsL6VA19L5XjpbJFctxdBPXH5e1Xs= X-Google-Smtp-Source: ABdhPJxGd0ou+rN9JRiGkyUNyPYryI5KqqM6CZ7UuWdKQmhlgfHh7fl5rPfFzIJIYwhVeWnIIc4/d3UWJWvOKbaFTyE= X-Received: by 2002:a17:902:bcc6:b0:138:d3ca:c356 with SMTP id o6-20020a170902bcc600b00138d3cac356mr14430372pls.6.1633185792476; Sat, 02 Oct 2021 07:43:12 -0700 (PDT) In-Reply-To: <83ilyfbj9h.fsf@gnu.org> 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:216160 Archived-At: On Sat, Oct 2, 2021 at 3:20 PM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Sat, 2 Oct 2021 15:02:41 +0100 > > Cc: Phil Sainty , 50959@debbugs.gnu.org > > > > > > 0. no integration > > > > > > > > 1. This is the current integration. I.e. when C-h o is pressed on = the > > > > symbol the global name is discovered and used as the default. T= his > > > > is how SLIME work with CL's namespacing system. SLIME is a very= well > > > > tested and widely appreciated Common Lisp IDE for Emcas. > > > > > > > > 2. The shorthands from the buffer where the minibuffer was entered = are > > > > _not_ in the completions list, but typing one of them interns th= e > > > > symbol with those shorthands present, so you get the desired res= ult. > > > > This would fix Phil's visually-copy-and-type scenario. > > > > > > > > 3. (Eli's suggestion): the completion list would be augmented with = the > > > > shorthands from the buffer where the minibuffer was entered from= . > > > > > > Are 2 and 3 significantly different (from the implementation POV)? > > > > I think so. > > > > I think 2 can be achieved by setting elisp-shorthands buffer-locally > > in the minibuffer and removing the "require-match" flag requirement to > > whatever completing-read call happens there. > > > > 3 is achieved by calculating the list of completions using > > 'elisp--completion-local-symbols` and then filtering it down as usual. > > "require-match" is kept untouched. > > You are saying that 3 is easier than 2? Then I think we should do 3, > as it's better from the user's POV, right? No, I don't know that for sure. And I don't think it's better from the user's POV. See my reply to Phil. It would mistakenly provide the idea that Shorthands are some alias to the symbol (in the sense of defvaralias). They are not. The user would then be quite surprised to find the list of completions chan= ge behind his back as he changes the place of origin of those C-h o calls. It could only make sense if these interactive prompts were clearly tied to the buffers they originated from. The current "Describe function" prompt should become "Describe function inside foobarbaz.el" . Even then, I think it is insufficient, and uncharted territory, whereas the current approach i= sn't (it's how SLIME/SLY work in a Lisp-based IDE with local namespacing) That _can_ be done, and I think all of Phil's list will eventually funnel down to a few existing function calls. But it nevertheless needs more profound wor= k and a careful understanding of the consequences. In summary, I think that with the exception of a shorthand-aware 'xref-backend-references', something that I am working on (between the drops of the torrential emails, some of them bordering on sheer harassment), this feature is currently consistent from a tools point of view. Again, Shorthands are buffer-local textual indirections to symbols. They are not the symbol. This will never change (not with Shorthands): so inclu= ding shorthands in a list of symbols is misguided. Displaying them in lists of fragments of text to be completed in the buffer is not. That is not to say I don't understand Phil's concerns: I do. I just don't understand the feeling of imminent catastrophe. As I wrote to Phil, I believe much of this anguish is improved if we font-l= ock shorthands specially. That doesn't seem hard at all. If I understand Phil= 's objections from day 1, he is talking about looking at something in an Elisp buffer and being uncertain about the nature of the thing that his eyes are focusing. But if he is _looking_ at it, then we can quench much of that doubt by changing the way it looks. If, on the other hand, he is operating on the thing with some other tool [*= ], not just his eyes, then I think the current tools are already doing the right thing. Jo=C3=A3o [*]: Yes, except when that tool is Grep or similar, but that's for all name= space systems ever invented, so if the concern is still Grep, please open another bug or (yet) another thread.