From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Stefan Monnier 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 11:55:47 -0400 Message-ID: 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> <87pmsf7gb3.fsf@gmail.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="7014"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) Cc: Eli Zaretskii , psainty@orcon.net.nz, acm@muc.de, rms@gnu.org, emacs-devel@gnu.org To: =?windows-1252?B?Sm/jbyBU4XZvcmE=?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Fri Oct 08 17:57:24 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 1mYsFP-0001cl-Ml for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 17:57:23 +0200 Original-Received: from localhost ([::1]:60660 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mYsFO-000342-AB for ged-emacs-devel@m.gmane-mx.org; Fri, 08 Oct 2021 11:57:22 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:45574) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYsE5-0002BK-Hz for emacs-devel@gnu.org; Fri, 08 Oct 2021 11:56:01 -0400 Original-Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:56747) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mYsE1-0007lk-Ix; Fri, 08 Oct 2021 11:55:59 -0400 Original-Received: from pmg3.iro.umontreal.ca (localhost [127.0.0.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id B8D83440885; Fri, 8 Oct 2021 11:55:52 -0400 (EDT) Original-Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg3.iro.umontreal.ca (Proxmox) with ESMTP id F0A8E44084A; Fri, 8 Oct 2021 11:55:49 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1633708549; bh=FCr/59/3fhXjvQtZ2VxUsaPoRdo9Qa2RgoNLugkTOmU=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=fL2SF3ng1rsXeksZoKmvlD+Zj5ZBfBx+rh/0bN7paZ6iOqKuC6vB/jsjZ/Y4gKSL7 oqDM2Ain7eCcUfRtpA9mC4B0ZTvXWui06Xyvm8ZWGP3OfLO1CeFSAFAPcSdzQe2mkh pUbKH7eroXpCeMS+ZwnE5K4YpfPnd4+kLYcCYwwJzdQfwbL+6QR4DGiDTjtG+Mo2V5 l6p2hZRLeB8jQUcsP5sfBTVSHfVyrsAqRtoNT02ed0Ubgo5qKylvWed8RifPmZGTx2 PlsbjOpIN8uLzqG/PSD+cHx8JPJ8bwbA1EuwdyxprTLpw5UxDGwRsYCuczNVytUesP Bg2zchQLlIS8Q== Original-Received: from ceviche (modemcable063.211-21-96.mc.videotron.ca [96.21.211.63]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id C74421202DA; Fri, 8 Oct 2021 11:55:49 -0400 (EDT) In-Reply-To: <87pmsf7gb3.fsf@gmail.com> (=?windows-1252?Q?=22Jo=E3o_T=E1vo?= =?windows-1252?Q?ra=22's?= message of "Fri, 08 Oct 2021 15:16:16 +0100") Received-SPF: pass client-ip=132.204.25.50; envelope-from=monnier@iro.umontreal.ca; helo=mailscanner.iro.umontreal.ca X-Spam_score_int: -42 X-Spam_score: -4.3 X-Spam_bar: ---- X-Spam_report: (-4.3 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, RCVD_IN_DNSWL_MED=-2.3, 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:276566 Archived-At: >> 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? Completion styles are supposed to work meaningfully with "any" completion table. Some completion styles make more sense with some tables than others, admittely (and some like the `backend` completion style only do something useful with those completion tables setup to take advantage of it), but the completion styles should be agnostic to where the completion candidates come from (that's the job of completion tables), and so far that's been true of all completion styles. > 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. Right. And your completion style uses `read-symbol-shorthands` as a "style", but it makes no sense to apply `read-symbol-shorthands` to something else than symbol names, so it can only ever be used for the completion table which returns symbol names. > So the "shorthand" style makes "x-bar" complete to "string-library-foo" > according to a certain notion of abbreviation based on "shorthands". Yes, and I can accept this principle, but it should not be tied to a specific source of candidates (symbol names, in this case). > How is this not "orthogonal to the data". Does the above answer the question? >> 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? I don't think so. > 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. I find the current patch to be a hideous kludge completely subverting the design, so I'd rather you fix the code first. It doesn't have to be difficult. A bit like with the `backend` completion, you can just make the `shorthand` style call the completion-table to do the actual expansion, and thus move the part of the code specific to `read-symbol-shorthands` to where it belongs (the completion table). > 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), That's right. > than I have no strong points against, in principle. It's a question > of adding something else to the metadata I think. Indeed you can also put the info in the metadata for the `shorthand` style to use it (instead of calling the completion table with another argument). > But isn't this a bit of overengineering? No, it's just trying to keep the abstraction-breakage to a tolerable level. > And can't it be left for 'master', as it's kind of a new feature? I see no need to push any of this to `emacs-28`, so all my recommendations are for `master` here. On my end, I intend to implement what I consider is the "proper" behavior, presumably making it conditional on some user config since you seem to consider it strongly undesirable whereas I tend to consider it strongly "The Right Thing". Stefan