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: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Wed, 2 Jun 2021 01:02:02 +0100 Message-ID: References: <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> <22880197-6d05-c821-2c58-328ed3cfc02e@daniel-mendler.de> <87eedruui3.fsf@gmail.com> <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@daniel-mendler.de> <878s3zuq47.fsf@gmail.com> <09f2a253-84ba-5cfd-552e-0b89109864a5@daniel-mendler.de> <875yyxaoxp.fsf@gmail.com> <871r9laj6a.fsf@gmail.com> <1b73a130-204c-76fb-2b60-02b814aee0f0@daniel-mendler.de> <87r1hl8xom.fsf@gmail.com> <878s3t8tzw.fsf@gmail.com> <3c68bd00-70ca-fa18-f9b8-cd03029f9294@daniel-mendler.de> <8735u18lsd.fsf@gmail.com> <8e33bbfe-0015-b85c-b57c-ba448f2e6215@yandex.ru> <3d519805-f602-fa52-ec69-0506bb6cb568@yandex.ru> 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="7618"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Daniel Mendler , Juri Linkov , Stefan Monnier , "emacs-devel@gnu.org" To: Dmitry Gutov Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 02:02: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 1loELa-0001mb-Tu for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 02:02:59 +0200 Original-Received: from localhost ([::1]:47210 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loELa-0001JO-0Q for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 20:02:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34040) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loEKw-0000eP-Mi for emacs-devel@gnu.org; Tue, 01 Jun 2021 20:02:18 -0400 Original-Received: from mail-pj1-x1029.google.com ([2607:f8b0:4864:20::1029]:55201) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loEKu-00081Z-KD for emacs-devel@gnu.org; Tue, 01 Jun 2021 20:02:18 -0400 Original-Received: by mail-pj1-x1029.google.com with SMTP id g24so614265pji.4 for ; Tue, 01 Jun 2021 17:02:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=mime-version:references:in-reply-to:from:date:message-id:subject:to :cc:content-transfer-encoding; bh=bof1jQkxxLb5JmavQjsJhsUMHBYfGeGkMKEqBscCOb0=; b=hMpxDk3UKSmA5ROeCkiCpj9uZe4gofhK6qCaKm8xr7qkj8eM2LRFnG/ukzfwmsosiJ 101JF3M3LcQTF/dXdJBKI2/ahPz1r/bo+TO83gMCGhJZ8rhNBKMHc7kuuj5uod1pIAMI 1hoPchBUvoWzrk6wmhT/l5n2m7qUFsGSHCSu/cic+LHVbQDtaGWNNSm4KpHjM7mIqmxO dA5qhzI9a5iehwz/Cl0BkTIIyFQsw4x75vQQxrBIyY1JCWiX8dH5+689es8rgqrLVtb6 6DgXVRbB99OaCnTmDCi+bmdW/Jr0VRyyKIod2igGzaChluiJapcbFm+XtAWa/OXeWCaj GrHw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:mime-version:references:in-reply-to:from:date :message-id:subject:to:cc:content-transfer-encoding; bh=bof1jQkxxLb5JmavQjsJhsUMHBYfGeGkMKEqBscCOb0=; b=jl5YHJcPEOdc9sRGbVRz2byCei7E1PpV9vPAaFs+sgUYjowLIYCrtNyuEplTP98+QD jpTF0H0dY/3iZLPDJiev9ToXvkI49ex+xfWuTZW2lopcSwQr2/9Fu3gfTY+9Qrz4dLMt Msh+AJshv84ryes1Kct+nTVs1BpVxriw4C/xwr7+0aq2GmqsXHE2hmBx2mtiZZ+7Aokz 0OxgCpL4xH9qrAaL+2brYv4EGm/z5vNPTAh1p2EI0t+Asw6yF/6OTN9VW8Tw2Jb9JlV/ 9ex4VTf/sI9y+R+97mGWn2HgBewjZGWfB325FmLcg3FKs6fqWiFTT6S1Nzb+PncTNq83 fZLg== X-Gm-Message-State: AOAM5315788gEnnK1QmknUw74BAd3vV4bHdRLCRyI6cGILY4+Dqx1ch3 IydZobFahYbu/iSNpsEC2GDJAks/XslKfFYFw1o= X-Google-Smtp-Source: ABdhPJz3jgLAAuKkubAJQv69UzmuFkBQaHOpOsFHqy8fhHBVnxa8mJWszt6VymsR66ZIh0tdKj1VpO21eaOpoFfw6C8= X-Received: by 2002:a17:902:8b8a:b029:108:7849:dae0 with SMTP id ay10-20020a1709028b8ab02901087849dae0mr5291887plb.36.1622592135102; Tue, 01 Jun 2021 17:02:15 -0700 (PDT) In-Reply-To: <3d519805-f602-fa52-ec69-0506bb6cb568@yandex.ru> Received-SPF: pass client-ip=2607:f8b0:4864:20::1029; envelope-from=joaotavora@gmail.com; helo=mail-pj1-x1029.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:270262 Archived-At: On Wed, Jun 2, 2021 at 12:46 AM Dmitry Gutov wrote: > > Indeed. Indeed that does show that we simplify the code and can keep > > the current calling convention. But then why should we? Its akwardness > > becomes even clearer there: calling the same function twice in quick > > succession with different second arg for two different types of return = value. > > I think the awkwardness comes from the general organization of > minibuffer.el rather than from this particular addition. Yes, yes. Just that this particular addition pulls things in the wrong direction, in my opinion. Another pain point in minibuffer is the representation of candidates. Sometimes they are strings, sometimes they are lists of strings with prefixes and suffixes, lots of silly "if consp". Really should all be slot= s in a completion object. If that object is a string, text properties are a good choice (but we could even abstract the implementation away, though it could be slow). > >> Whether this results in better minibuffer.el code is debatable: your > >> diff has more additions than deletions, and one rather long line. > > > > Oh sure, that function is slightly more complicated, but if you look at > > > > completion--insert-strings > > completion--insert-horizontal > > completion--insert-vertical > > completion--insert-one-column > > display-completion-list > > minibuffer-completion-help > > > > You'll find they are all simplified. > > Yeah, OK, that's a recent change I haven't read yet. But couldn't any of > these functions fetch the current group-fun based on the minibuffer > contents and the current global values? Yes, but in that case, a dynamic variable is better than repeating that little md dance. > > Exactly, but my proposal doesn't prevent doing this near the > > print locus. > One might do the grouping and the printing at different stages (in > different functions). Yes. > It's a property (method) of a completion table, isn't it? We're talking about different things. The group function is a property of the completion table. Each invocation transforms a completion, meaning it produces a property of a completion. An that property could be stored in the completion, whatever the format. > The way I see it, we actually combine there two distinct actions > (grouping and transform), only in the interest of less typing or > whatever. But as the actions are distinct, it makes sense to be able to > ask for one or the other. They're related in the sense that one of them doesn't make sense without the other. So it's not only in the interest of typing, I'd say. --=20 Jo=C3=A3o T=C3=A1vora