From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= Newsgroups: gmane.emacs.devel Subject: Re: Do shorthands break basic tooling (tags, grep, etc)? (was Re: Shorthands have landed on master) Date: Fri, 08 Oct 2021 15:16:16 +0100 Message-ID: <87pmsf7gb3.fsf@gmail.com> References: <16338bdc2497fc51c6fb6d54ab370bfb@webmail.orcon.net.nz> <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> <871r534s2o.fsf@gmail.com> <87sfxgx09x.fsf@gmail.com> <83a6jkyrok.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="22694"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.60 (gnu/linux) Cc: psainty@orcon.net.nz, acm@muc.de, Eli Zaretskii , rms@gnu.org, emacs-devel@gnu.org To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 08 16:18:01 2021 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 1mYqhE-0005iP-Tl for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 16:18:00 +0200 Original-Received: from localhost ([::1]:43690 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYqhD-00006q-EJ for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 10:17:59 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:54688) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYqfb-0007Mr-MW for emacs-devel@gnu.org; Fri, 08 Oct 2021 10:16:19 -0400 Original-Received: from mail-wr1-x429.google.com ([2a00:1450:4864:20::429]:33699) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1mYqfZ-00010x-SD; Fri, 08 Oct 2021 10:16:19 -0400 Original-Received: by mail-wr1-x429.google.com with SMTP id m22so30443232wrb.0; Fri, 08 Oct 2021 07:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=kMU7Hm94mul1Dm/LgGNZRuxjOjEcyz5rls+UxfoQzs8=; b=oezidG2KCUBxhOBKD7bP1xx1ys7ek5JlOD8vSSXE0v6DME9jnsx1JKfzB08arMUJTy RuCrVA4lT354xDDaHMz5Gj8I3mtaiaeQuSCNorEKVo3LrLorX6UZmhoir3z4g8xnqYON Z9keR99dLOXGMjIexKUkxucLZ0tfQl6T1e1hm0zKWexgeJLGAbSdDbDUAWIr7dP1XY3X LrwaDeAI0YLbXwCJs7/6PwLZkklNqZKe41xI/G2GUwDzpaXBRx65/0x9crBCSgaXg8y6 jceU029pzN+RJqowb/GGB/ICHCnjCWMrnOGJgZVOVnWWmPYnT1FClDtzMF3XoOn+eEoN pk3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=kMU7Hm94mul1Dm/LgGNZRuxjOjEcyz5rls+UxfoQzs8=; b=xoH7OtPBYWbRGbatq4NJXns1OYjBP7IP1q5ATTADdm5i3laDCdMNIAKuYEzCHUwSPu KtPoR1dJnHOY+Ty9r9mE7w7rqiLGQHEr+6AFHmSnvaWMvIsHRynGgKH9CG7oKyVNhAN5 /3z3zCpuw7v1PU0sQxUv3sxgJ2HBxJ5OZp0Is8YK2A02QmK8clLRLDjaejM4RZMPEBEH REZTaosI9oK6wbI6fBRJx2KYcVRVxidrBf5WUas8oVV/b4q6ZPloSkIP9oaCMIG+P/1k ewaKD+MGEr/LiO09EZwa9PYObq3LNCabeO67jjTQXcdKa+KvcjBLaWBAcaML93lGVRL/ PkZw== X-Gm-Message-State: AOAM533PSrYiqGwT69/oY3TYMNgZ/4F4UucYK+zzGjcSDITUhvNVzu7G pDEyWIHpDqP4JkJ0govS7U5D3hVCvos= X-Google-Smtp-Source: ABdhPJxh4gilnb8/7M89MeRwpKVmhzT2+BvbvVvGacUNnWQJdwfLE370B+VuzWZtJAwhBo0iPV6qdA== X-Received: by 2002:a05:600c:354f:: with SMTP id i15mr3872208wmq.146.1633702574970; Fri, 08 Oct 2021 07:16:14 -0700 (PDT) Original-Received: from krug ([62.48.174.238]) by smtp.gmail.com with ESMTPSA id f18sm2612561wrg.3.2021.10.08.07.16.14 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 08 Oct 2021 07:16:14 -0700 (PDT) In-Reply-To: (Stefan Monnier's message of "Fri, 08 Oct 2021 08:58:55 -0400") Received-SPF: pass client-ip=2a00:1450:4864:20::429; envelope-from=joaotavora@gmail.com; helo=mail-wr1-x429.google.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, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 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:276561 Archived-At: Stefan Monnier writes: >>> An implementation of this idea is awaiting comments over at bug#50959. >> I think you should install that. > I'm not sure if he may be referring to another patch (I haven't checked > the whole thread), but the patch I saw in there implements it with an > ad-hoc `completion-style`. Yup, that is the one (it's the only patch there so far). > I consider this as an abuse of the notion of completion style (which > are supposed to be orthogonal to the actual completion data), so I'd > strongly recommend not to use this patch. What do you mean a style being orthogonal to the completion data? A substring style will complete "oo" to "foobar" because it knows that "oo" belongs in "foobar" according to the notion of substring, and likewise flex will complete "fb" to "foobar" because that belonging is also there, according to a certain "flex" notion. So the "shorthand" style makes "x-bar" complete to "string-library-foo" according to a certain notion of abbreviation based on "shorthands". How is this not "orthogonal to the data". > I could agree to the use of a new completion-style for it, but then the > code of the completion style should not be specific to > `read-symbol-shorthands`. Instead it should offer a generic feature > usable by other completion tables (and the part specific to > `read-symbol-shorthands` would be in the completion table of `C-x o` > rather than in the completion style code). In practice, does this change anything in terms of behavior? If not, then I suggest we push that patch and then augment it with this generalization, in case we do really come to the conclusion that this more generic scheme really is useful. Currently, the `C-x o` table (and other using help--symbol-completion-table) declares that it is of the 'symbol' category. Up to here I'd say you agree. Then, a shorthand-considering completion style is associated with the 'symbol' category. I think this is pretty clean. Obviously you disagree. So if your suggestion is to make a an "abbrev" completion style which consults the table for the specific source of abbreviations (which happens to be read-symbol-shorthands in the case of help--symbol-completion-table), than I have no strong points against, in principle. It's a question of adding something else to the metadata I think. But isn't this a bit of overengineering? And can't it be left for 'master', as it's kind of a new feature? Jo=C3=A3o