From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Daniel Mendler Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Tue, 1 Jun 2021 18:00:56 +0200 Message-ID: <3c68bd00-70ca-fa18-f9b8-cd03029f9294@daniel-mendler.de> References: <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> <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> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5539"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Juri Linkov , "emacs-devel@gnu.org" , monnier@iro.umontreal.ca, Dmitry Gutov To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jun 01 18:06:58 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 1lo6uv-00019k-Ve for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 18:06:57 +0200 Original-Received: from localhost ([::1]:45440 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lo6uu-0000k8-Jd for ged-emacs-devel@m.gmane-mx.org; Tue, 01 Jun 2021 12:06:56 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:59872) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo6pL-0003RL-Qk for emacs-devel@gnu.org; Tue, 01 Jun 2021 12:01:12 -0400 Original-Received: from server.qxqx.de ([2a01:4f8:121:346::180]:58783 helo=mail.qxqx.de) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lo6pC-0001EF-OK for emacs-devel@gnu.org; Tue, 01 Jun 2021 12:01:11 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Transfer-Encoding:Content-Type:In-Reply-To: MIME-Version:Date:Message-ID:From:References:Cc:To:Subject:Sender:Reply-To: Content-ID:Content-Description:Resent-Date:Resent-From:Resent-Sender: Resent-To:Resent-Cc:Resent-Message-ID:List-Id:List-Help:List-Unsubscribe: List-Subscribe:List-Post:List-Owner:List-Archive; bh=spDx97cecQ8WNB7GAVM3y08nalI/ycLlVL1q87ADNHs=; b=RysfWkzPZrAOr6FsdZJdqNZkX0 eMt7kwWaPKrxBEbHYmWtaJuAjnnYpBHfaKbYz0T0coAsd+vvFFrj3Q5V4ED+bO5oHThmVKj2DZ76C SLTTrLm6AG1n0nGEU6Y/qA/RjV46JOLZUrBjhCNi5QKweasHfvQnldy/4PEm+qDLTT5E=; In-Reply-To: <878s3t8tzw.fsf@gmail.com> Content-Language: en-US Received-SPF: pass client-ip=2a01:4f8:121:346::180; envelope-from=mail@daniel-mendler.de; helo=mail.qxqx.de X-Spam_score_int: -41 X-Spam_score: -4.2 X-Spam_bar: ---- X-Spam_report: (-4.2 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, RCVD_IN_DNSWL_MED=-2.3, SPF_HELO_PASS=-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:270214 Archived-At: On 6/1/21 5:49 PM, João Távora wrote: > But do you have any evidence to suggest that making a cons and > allocating a function is detrimental to this?? I just tried this small > patch to the function you suggested as a potential hog, since it > iterates all the completions. > > So basically the same. Cons and lambda's are cheap. The allocations itself are cheap but they put unnecessary pressure on the GC. The current version avoids this. This matters when scrolling through long candidate lists. >> The current implementation is simple enough and also avoids allocation >> of the cons pair and the allocation of the lambda as in your proposal. >> The efficiency is crucial here. > > I believe you, but I haven't seen any evidence (yet) to back up the > claim. But instead of me whistling premature optimization song, feel > free to point me to some numbers or something. The current version is proven in my packages and performs well. I don't see a point in replacing it to a more complicated and less efficient version. >> Furthermore I argue that the current implementation is simpler to >> understand for the completion table authors than your counter >> proposal, which introduces a deferred computation with the lambda. > > It's like the affixation-function thing, I don't think it makes sense > for client code to do these IFs, much as I dont' think it makes sense > for them to do MAPCARs. No it is not. It is more like the decoration function of which you are also in favor. The type is this: group-function : string -> bool -> string The bool corresponds to the fields to return in the decoration function. Either return the title or return the transformed candidate. > But to be clear, the main advantage here in my opinion is the cleanup in > minibuffer.el, which is somehwat messy in my opinion (not only from > group-fn's fault, of course). That's the wrong way to look at it. The main thing which should be optimized here is the performance and the ease of usage for the completion table authors. Furthermore I disagree with you that the minibuffer.el code is messy. The same applies to the Vertico code, where I implemented group function support. It is also reasonably clean. Please take a look at it. The suggestion of yours to mutate the candidates by putting a property instead of threading the group function through the call sites is much worse. >> There was a long discussion with Stefan, Dmitry, Juri and Eli where >> multiple different designs for the `group-function` have been considered >> and we settled on the current design. > > It could have been discussed with your favourite divinity, for all I > care. If I see something worthy of improvement for the next version, > I'm going to suggest it here. Especially in the case of a new feature > in master. "It's been discussed with so and so" is not a worthless > argument, but it's not very valuable either. Your version is not an improvement. Please read through the old discussion and consider my arguments. I also don't see a point in rediscussing this as long as you don't make a proposal which is a clear improvement. Daniel