From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Thu, 27 May 2021 16:15:08 +0300 Message-ID: References: <87zgwlb4xc.fsf@gmail.com> <617d06ca-27bf-2ae8-26eb-1042123499d3@daniel-mendler.de> <87pmxhb1rs.fsf@gmail.com> <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> <87y2c5nhsr.fsf@mail.linkov.net> <87h7irss50.fsf@mail.linkov.net> <43d1599e-2ba9-2efb-45c3-76c67d29a69d@daniel-mendler.de> <87tumrgqrb.fsf@gmail.com> <87tumq92pe.fsf@mail.linkov.net> <87lf82g10g.fsf@gmail.com> <87y2c24lww.fsf@mail.linkov.net> <871r9t2lsy.fsf@mail.linkov.net> <187a63cb-e4d2-1012-1b51-e393692de436@yandex.ru> <0452e0e9-0764-9a0e-93d7-5a7f53b8d797@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="32959"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: Daniel Mendler , "emacs-devel@gnu.org" , Stefan Monnier , Juri Linkov To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Thu May 27 15:35:59 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 1lmGB5-0008Mb-8X for ged-emacs-devel@m.gmane-mx.org; Thu, 27 May 2021 15:35:59 +0200 Original-Received: from localhost ([::1]:55466 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lmGB3-0005q5-Cg for ged-emacs-devel@m.gmane-mx.org; Thu, 27 May 2021 09:35:57 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42680) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lmFrT-0006LD-2J for emacs-devel@gnu.org; Thu, 27 May 2021 09:15:46 -0400 Original-Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:35361) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lmFrO-00007n-Ke for emacs-devel@gnu.org; Thu, 27 May 2021 09:15:40 -0400 Original-Received: by mail-wr1-x42f.google.com with SMTP id m18so4748304wrv.2 for ; Thu, 27 May 2021 06:15:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=+T1/b1nhT4bta2UEHiWLLLNa0zXm45MITkcDDAxQu3s=; b=CWRUlUQZ4NyA/UTJ1yfZxEjr/KofCyewNbdbrRjggE8zJHfO0eWbkBOr37tP1WzvcG xlXyqLbtY3zkuq06p9dQdFhumiAo9ZtrYcW/eqsHmpDukgysJ9s/1xSRrn0Sr/u2mloR ubmdYWHzHBxwFSLZL8frRybMyU2k5qdE3E7NlgPjJ13wRwy/N9RGr55Hyt39s5mTMgJm U2ZSAf/CF1G/PyeCbwLbEA8rPs0155NvjHiK/LtPvsopR9zcG1JmFA5N1zPsslhRm41Y yVT8S1PRUB2IaBxYsjs3+UBeXDxBxxtPLQRY+AXZXUgMu0if18SYv+AUqBpFZU8LqE+6 sW0g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=+T1/b1nhT4bta2UEHiWLLLNa0zXm45MITkcDDAxQu3s=; b=GVPy3wLKETgJS6vCkLXbffcIKbxIiezzsJUC8OY+1D5Ra8H7QQlHkP5/B0S0vepApC 38d6Zs50z0pVNgIl+tX7v5KfZDV+UqF0E3DEqC6AKG+a3AHCwrdGD7EW6R93Glzd/5Qo 5QVdrIc+KLW2jMYHUhn+lOFY56WOAUXpOrHohOhGkHNLk9e6RMQvOkRYW4K1xvGU7vQn IEmSq8PTROSPeloyOycZALJ5hT2OZLQeMLGdDp8m1jIuXCNyQZThQ4Drg7M3NMf/Omo1 KASRZi7MTbLn4XMOUrZ5n581XYn9h/RbVYiE95QsvffP2UBKdBs7bLI4dHHlGNyeV2dT r24g== X-Gm-Message-State: AOAM530frUCuaDii4Cm44YHMRFF2Xhsi4xWifpohBESbLM2+NLwEEbGH kL6i1Y+WYcrvDBueIbnz9cQz0DlwepQ= X-Google-Smtp-Source: ABdhPJwQ76Q7ApMX4pNnP3g34CRCyVQfha9ob4LpUWbVLli1xPiqKZqCeRHzNnDKLbbgDIFWhvay2A== X-Received: by 2002:adf:dc88:: with SMTP id r8mr3276884wrj.277.1622121337049; Thu, 27 May 2021 06:15:37 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l8sm3447022wry.55.2021.05.27.06.15.19 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 27 May 2021 06:15:20 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::42f; envelope-from=raaahh@gmail.com; helo=mail-wr1-x42f.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.25, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.25, NICE_REPLY_A=-0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:269943 Archived-At: On 27.05.2021 10:29, João Távora wrote: > On Thu, May 27, 2021 at 2:06 AM Dmitry Gutov wrote: > >>>> The downside should be obvious: you waste extra CPU and memory when you >>>> only need some of these values, and not all of them. >>> I don't see why, though. Isn't the `fields` arg supposed to solve just >>> that problem? Or am I missing something? >> OK, that was poor reading on my part (missed 'pcase'). >> Also, the above piece of code looks awfully similar to a Company backend >> or frontend definition, which you have disparaged on multiple occasions. > > [ Uncalled for, right? Let's keep cool with the animosity and > the vague accusations, stick to the topic. ] I don't exactly mean to initiate a shouting match here. Someone liking (or not) a particular API design can be pertinent, because people are going to have to use it, after all. > Here, I was referring specifically to your "obvious" objection, which > seemed nonsensical and ended up just being a reading mistake, that's > fine. Yup. > As to ways to improve on Juri's idea, I would maybe suggest a generic function > of string and a single field. Much like in `affixation-function`, > there's no need to ask > the backend the `mapcar`. To know what a backend implements would > mean asking that generic function for its methods. I don't think this can work without doing the long-discussed migration of the completion-table API (or c-a-p-f API) to generic functions. Upon which we'll lose the capability to mix-and-match using immediate values and refer to containing lexical scopes in implementations anyway (while gaining in comprehensibility, structure and better code navigation). Yet still, even when using generic functions, why would we create an additional dispatcher mechanism when cl-generic can already do that for us? To reduce the number of methods in the API description? > And if you want to "mix and match", a generic function with the backend > as its arg and a hierarchy of backends seems the most elegant choice. > So `:resolution-function` wouldn't be written like that at all, the > backend would > write methods for that `completion-resolution` gf. > But that's redesigning way too much and has numerous other implications > and experience tells me it's not going anywhere and we'd not solve > the annotation problem which is the topic here. Yes, it's orthogonal to the more pressing questions of how information returned by 'affixation', etc, should look.