From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Jun 2021 01:40:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: report 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 48841@debbugs.gnu.org X-Debbugs-Original-To: bug-gnu-emacs@gnu.org Received: via spool by submit@debbugs.gnu.org id=B.162285719829274 (code B ref -1); Sat, 05 Jun 2021 01:40:01 +0000 Received: (at submit) by debbugs.gnu.org; 5 Jun 2021 01:39:58 +0000 Received: from localhost ([127.0.0.1]:48094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpLI6-0007c6-7W for submit@debbugs.gnu.org; Fri, 04 Jun 2021 21:39:58 -0400 Received: from lists.gnu.org ([209.51.188.17]:47576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpLI3-0007bx-K8 for submit@debbugs.gnu.org; Fri, 04 Jun 2021 21:39:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpLI3-0002Ak-Cb for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 21:39:55 -0400 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:41812) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lpLI1-0000Ay-Gw for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 21:39:55 -0400 Received: by mail-wr1-x435.google.com with SMTP id h8so10956018wrz.8 for ; Fri, 04 Jun 2021 18:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=w+Vi8Fpo1tJdAAFVOptzaAe9XHfZKDU/nqNQTPxTR6M=; b=i1crFa30B8GbHmqBOb8TCrma99l4X3pCSu8mm2DpDqZAmATZPVnIoWKcKkXWxui3uP Y9yUsQGvIBtbWEKAzO2+ymC9lh3ix/x88kvjzWOZ87ffOUggEnV3Ue2w/2XvQt1M7C96 JAiJcr2ottLrpRq0TngXylxhpVWJowpc1yjP5s8E+XavGA3ypZL+YOtl7p4IuW5yGYxy LzFjwx6R0q5Kfhjem5Whvx6GkcFvx+lgL6p7z8i9tagXcGSyEFu4ixCxZVmko1RDsOZX /BZDE+7btFdKwh2xMr7UG8+TyoZc0FVEPX7TJ/+VJyyJw7lPUF7TVeY3EnPNvUhheBP0 j/Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=w+Vi8Fpo1tJdAAFVOptzaAe9XHfZKDU/nqNQTPxTR6M=; b=bJzkqYalNQ5ijdZqUKaUglFwLMaZUy8yBaWmKAMVLU/e04eTy2qcz6hoT/ChfOvait revbsKaIcnv4OEFmkGhjypCKNmSkvFhOxq3rwOWpbKpYQgvN/gnIP5D5fH0YyB+sx0HK TKKWcZF1K6oP50xLxMGb+VuujI7q5AGcUkLlXQ8zh+Ld+7pYQxAOg6XpRUsCxO3O2KqV 4kjlyG/pRmxuTTK+xQBz5VnQQivSghoZKOkJRwbm8bFKqftxQ3nTzCUmx2WJcEJdkjTe 2SUjdLuX6IUTyAIqtBdqTZyRbMn0XV7Z1Ek+JpEbIHIMvSrfUtY9ijBQXUQk3GpLs7q0 ZqpQ== X-Gm-Message-State: AOAM533itREXD0GDI8RhX1y9EN9bKsDDcPJ18hm6c84FoZ/1EVDJj8FE 1QVCjkzUZdmsHJafyed4uSAf8LSCPrw= X-Google-Smtp-Source: ABdhPJxbX4wtdl7i73Z5mS/SwhBb5vA7FPw2IDcoYR5voDsdcL+48ylHkJhr83sLsLyrfYPaFNm+9Q== X-Received: by 2002:adf:fa0f:: with SMTP id m15mr6275716wrr.379.1622857191261; Fri, 04 Jun 2021 18:39:51 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u7sm2846858wrt.18.2021.06.04.18.39.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Jun 2021 18:39:50 -0700 (PDT) From: Dmitry Gutov Message-ID: Date: Sat, 5 Jun 2021 04:39:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=raaahh@gmail.com; helo=mail-wr1-x435.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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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-Spam-Score: -0.8 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) I'm comparing ido-mode with ido-ubiquitous-mode (for support for arbitrary completion tables), available at https://github.com/DarwinAwardWinner/ido-completing-read-plus with (setq ido-enable-flex-matching t), of course versus fido-mode with (setq icomplete-compute-delay 0) (setq icomplete-show-matches-on-no-input t) (setq icomplete-max-delay-chars 0) The values chosen for behavior maximally close to ido. Try something like: - Start a session with personal config and a number of loaded packages (so that there are a lot of functions defined in obarray) - Type 'C-h f' - Type 'a', then type 'b'. - Delete 'b', type it again, see how quickly you can make the completions update. With ido, the updates seem instant (probably due to some magic in ido-completing-read-plus); with fido, there is some lag. Not huge, but easy enough to notice. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Jun 2021 09:36:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16228857588420 (code B ref 48841); Sat, 05 Jun 2021 09:36:02 +0000 Received: (at 48841) by debbugs.gnu.org; 5 Jun 2021 09:35:58 +0000 Received: from localhost ([127.0.0.1]:48309 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpSig-0002Bh-WE for submit@debbugs.gnu.org; Sat, 05 Jun 2021 05:35:58 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:34682) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpSic-0002BR-OR for 48841@debbugs.gnu.org; Sat, 05 Jun 2021 05:35:54 -0400 Received: by mail-wr1-f45.google.com with SMTP id q5so11686848wrm.1 for <48841@debbugs.gnu.org>; Sat, 05 Jun 2021 02:35:50 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=TnMwxKzpBBNmQzIjgnZWGBDk8pMUauUg4V4iVjHucTQ=; b=rt5uQu2f8wb4I2PgkhctHhJKouAr6ul+71f7lvs/MpAvf4dvhmwS1ESTXPIHaXqoRk 3Os+Aentp8NddVZjklZQsG/AcP49LVxVyd00DuLOHrCEehxAoth+psm3yw4UPnpqzGwe AA5J36FkZiqk7xgnr3Rx1vzSkLEDICunz7nFifwC5QNHocRQumkf9sW54iF3439Lm1eb 8JsWyebnCBJSZwMNDnM7te+KbfUufPLXyc8QHZCJxj9LQdqhBrJY3IYNZ3Mx4+d94Wkg 2VEcPKtmfxEflw4c5ohFi/sVZh2QqZ1wsRNhlLQhkcZ8YkiFsd6Zu482G8bQIJydcPYR UybA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=TnMwxKzpBBNmQzIjgnZWGBDk8pMUauUg4V4iVjHucTQ=; b=Uif/sDXHBHWzXbnH9bjPuMYRQma3GEPa0lraBZ/7IqHCvbAOm1IAaW6Wf7khIY+Kso kY6l+/DNbzVr0VTNwwmvyxXHNTnvMsbNd0jwRUmkbwW3vNwBYc+rfPQdEUWIWuv0F8X3 Yd/wChbm71Ke8S9We2guJ3Qe22b2km4IyT/kdkj5CGtr8IkmAaoM8r9TGwrL+7X6fMpY jl/e2Jzyos2fQuKdrc9pyDmCB0jOrqtBlNIoxyp6tEVHeE8yndKpdtjVP5/Gyv4TyE79 Iwf1RWcGcpxwGrcupoQ6w73OJgkJfioz6G6Ij+mN8wEn+QmMCWC8eiEW4nPCyeUzO4Pe 1uSw== X-Gm-Message-State: AOAM530T/+lmI8lfAhUVuveaD9m1p7jUS0gBEHD9xNQy2yMMjT5VB3Y0 9XscxHAuRZAqZRN+NJGE6a90cgMb5iw= X-Google-Smtp-Source: ABdhPJyFzoljKpdA/XFiBVZK8by2Af1wORL5Gm35fx9JCj/VzcV4CICBDkQOvMLuAV02Y7bXQljWgQ== X-Received: by 2002:a5d:5182:: with SMTP id k2mr7835541wrv.381.1622885744273; Sat, 05 Jun 2021 02:35:44 -0700 (PDT) Received: from krug ([89.180.146.244]) by smtp.gmail.com with ESMTPSA id v8sm10034203wrc.29.2021.06.05.02.35.43 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Jun 2021 02:35:43 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: Date: Sat, 05 Jun 2021 10:35:42 +0100 In-Reply-To: (Dmitry Gutov's message of "Sat, 5 Jun 2021 04:39:49 +0300") Message-ID: <87eedgy7pt.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > I'm comparing > > ido-mode > with ido-ubiquitous-mode (for support for arbitrary completion > tables), available at > https://github.com/DarwinAwardWinner/ido-completing-read-plus > with (setq ido-enable-flex-matching t), of course > > versus > > fido-mode > with > (setq icomplete-compute-delay 0) > (setq icomplete-show-matches-on-no-input t) > (setq icomplete-max-delay-chars 0) > > The values chosen for behavior maximally close to ido. > > Try something like: > > - Start a session with personal config and a number of loaded > packages (so that there are a lot of functions defined in obarray) > - Type 'C-h f' > - Type 'a', then type 'b'. > - Delete 'b', type it again, see how quickly you can make the > completions update. > > With ido, the updates seem instant (probably due to some magic in > ido-completing-read-plus); with fido, there is some lag. Not huge, but > easy enough to notice. Thanks for the report. Before I try reproducing, can you try with fido-vertical-mode and tell us it if that changes anything? I think I remember that skipping some suffix-calculation logic saved on a few traversals of the big list of symbol completions. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Jun 2021 23:03:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162293415612703 (code B ref 48841); Sat, 05 Jun 2021 23:03:01 +0000 Received: (at 48841) by debbugs.gnu.org; 5 Jun 2021 23:02:36 +0000 Received: from localhost ([127.0.0.1]:50267 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpfJL-0003Io-VK for submit@debbugs.gnu.org; Sat, 05 Jun 2021 19:02:36 -0400 Received: from mail-wr1-f44.google.com ([209.85.221.44]:37504) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpfJI-0003IZ-1w for 48841@debbugs.gnu.org; Sat, 05 Jun 2021 19:02:35 -0400 Received: by mail-wr1-f44.google.com with SMTP id i94so8002319wri.4 for <48841@debbugs.gnu.org>; Sat, 05 Jun 2021 16:02:31 -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=JU2U9i9tR5/J5jRlQzNoMiQZL0ctlSMRNqfK0DBoyTk=; b=Mnz9r1+3fj7JvwTr0gxCBBNgt0kmu8SycH4hQ9Th8NTkXcPVn5vCXhfhKPPZ8MVfSy 2UWpVizneoDJT8POBQG9lo02PZyJhsHNUkdKJSp40vmIGO4C6Ms9OR1ukKxeXhsrhfY+ czLNOVn6llHZMfxrAcnriSXVIwr5o77bqCLUa8S9pbuVTsFZInsImVxR6T8B024mk47X 9sHj6MwZZKHSbwnM+f0JGzowzupYKQQIcBIdUhhGXWv/xBXzOWDtL7ENzmR9uLcAgLQx sCHdJMBJ37/SHXKucnEEF87t9x69NW1WY3KQ76i5jV3A+ph5kUFF3ApGpfK71KQJTMHH DRkA== 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=JU2U9i9tR5/J5jRlQzNoMiQZL0ctlSMRNqfK0DBoyTk=; b=nawbUF1bUvhGI33/Kr6cpKU+PnahiQj+z+mX42gUZl9V//4bpDiBWKmqlEPSFVDuPh jNmpsPTIjvG2pvoG297kiXrWkfxmuEd1bBdB7qEin4qIFDDJ8iLnBjX8vA/LOTXhB0UW ww3Km8kkEVKHNEfWwlzQChmlnLqnv51ZmiunIUuKb1lNx2IwBX2bHQtgsAvMEfeYPOTQ wX0D+xlRQ7Nv64/zM7qd2lYU9twVn/mt0iG+II/DFUqe1ISUKk56cnkYWHdJgAsW6Yxt D/qjB+DmFIZeKXgT6l160EVl+bMJn/3VAYxX6Ql6NmAjK/jraB/qxioWkE2jpWqfPKnP l13A== X-Gm-Message-State: AOAM533Brvm3/ZZBVWddepY7E99pB2jHlm+JoIeFMebR61hF3tWAfp3F xtp4/i9qhc3eVOgRhVKS36DGSreEEC4= X-Google-Smtp-Source: ABdhPJwLIFzu20krXXcJTTg9RC5wxKK4rzYvjA7ItWpK7bhXDUrGwblEYI6sUUZgYELSimoJ220nQA== X-Received: by 2002:a05:6000:1089:: with SMTP id y9mr10122564wrw.412.1622934146156; Sat, 05 Jun 2021 16:02:26 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l22sm12147641wmq.28.2021.06.05.16.02.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Jun 2021 16:02:25 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> From: Dmitry Gutov Message-ID: <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> Date: Sun, 6 Jun 2021 02:02:24 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87eedgy7pt.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) On 05.06.2021 12:35, João Távora wrote: > Thanks for the report. Before I try reproducing, can you try with > fido-vertical-mode and tell us it if that changes anything? I think I > remember that skipping some suffix-calculation logic saved on a few > traversals of the big list of symbol completions. Why, yes it is. fido-vertical-mode is definitely snappier with such settings. Maybe still not on the level of ido-mode, but at least halfway there, compared to the "horizontal" version. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Jun 2021 23:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov , monnier@iro.umontreal.ca Cc: 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162293524014224 (code B ref 48841); Sat, 05 Jun 2021 23:21:01 +0000 Received: (at 48841) by debbugs.gnu.org; 5 Jun 2021 23:20:40 +0000 Received: from localhost ([127.0.0.1]:50278 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpfap-0003hM-QK for submit@debbugs.gnu.org; Sat, 05 Jun 2021 19:20:40 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:53015) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpfan-0003h8-Hf for 48841@debbugs.gnu.org; Sat, 05 Jun 2021 19:20:38 -0400 Received: by mail-wm1-f52.google.com with SMTP id f17so7550014wmf.2 for <48841@debbugs.gnu.org>; Sat, 05 Jun 2021 16:20:37 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=0SsC1OOXrvTZ7RCsaUmvBieks2UWV7DPo25x5rKzOcE=; b=DFLixvh5f+fcfVieEtE8GF+YVfVQKFRptRpTcONCU+uLyfr4wFvv1a61eNlFi4SW+6 5YPRvs61hyvjdmEV8fg+6zfErHO3B6+RKyfYkl/YU6orCWb3GXrlxpmOM+Z97p0JpZA+ js99W55jQaUrrU2wU5ACa9pgvTYCstVrnJcxg1FEUd83grFGQcLIujgnZEXT09gV5Ycr mX9Og//Oi5/HAT6EWWP1efDXykLTdz0BYU1UMqMcfZTAkLMCJvOuCkuDe81ccIJMLvvi 8zuhodxXb3OzQ/0dngm/7UkS+vOwb7i5zKyU6XJKccqXy/DMEm8eKtngIVAnu05EvgMx IqVw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=0SsC1OOXrvTZ7RCsaUmvBieks2UWV7DPo25x5rKzOcE=; b=VUeG4UXqZIE8dxOMr9xET7quA1IqOX2CHwjV9H6f8F7Q4pcc4JxqtaoXXqbnoFL/Ax HeGE+sTulS3rhv6yDfmWfqfj6UneDhhAMoBh5S2gEHk+cPY3PBI0YeCSiX8PkZuMaXIu jh3DxoqOxQc3ekL7G34F25tXaHXJeNaL2mt92hk/JwNU34KoW9kZabUdnOwNtJEFuyMd W9NiTNgqRYSHUhoSDCOHcCPNLbMFOjZpKP8E314Vkpw78WdsW0walZl3umyKEd0p52ov WRhA6JwB4DBBmXxeR4VlaGiUO/VMN/x8XGUSkGkZ3MK2zlQ9agLSFttjktcjVMnpPU/6 lm8w== X-Gm-Message-State: AOAM530qJWgKezzWFYiu6Qx6GY8kkPp0laGaWyzLj8ZjmIKPtclgfiu6 hUJc6snBmpqH8xc8NH9gnhebMBKFnT8= X-Google-Smtp-Source: ABdhPJw55fhtCielN9mVkgNpmg950Hy3yE07XM/cG3Y0weNe3lBCikLBzApWvv2t51NMoaJjJlHSow== X-Received: by 2002:a7b:c935:: with SMTP id h21mr9886969wml.183.1622935231304; Sat, 05 Jun 2021 16:20:31 -0700 (PDT) Received: from krug ([89.180.147.196]) by smtp.gmail.com with ESMTPSA id m65sm9698039wmm.19.2021.06.05.16.20.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Jun 2021 16:20:30 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> Date: Sun, 06 Jun 2021 00:20:28 +0100 In-Reply-To: <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> (Dmitry Gutov's message of "Sun, 6 Jun 2021 02:02:24 +0300") Message-ID: <87a6o3x5j7.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 05.06.2021 12:35, Jo=C3=A3o T=C3=A1vora wrote: >> Thanks for the report. Before I try reproducing, can you try with >> fido-vertical-mode and tell us it if that changes anything? I think I >> remember that skipping some suffix-calculation logic saved on a few >> traversals of the big list of symbol completions. > > Why, yes it is. fido-vertical-mode is definitely snappier with such > settings. > > Maybe still not on the level of ido-mode, but at least halfway there, > compared to the "horizontal" version. Yes, that is also my assessment after trying your recipe. fido-mode + fido-vertical-mode is not quite as snappy as ido-ubiquitous-mode, but decently close. My bet is that the remaining lag is due to sorting. In a dumb but illustrative example, when given the pattern 'fmcro' flex-enabled ido-mode pops 'flymake--backend-state-p--cmacro' to the top, while fido mode selects the much more reasonable 'defmacro'. Now, what I called here the "suffix-calculation logic" is what I also called the "[mplete] dance" back in the emacs-devel thread. Truth is, it's always annoyed me in icomplete partially because I don't understand what it does exactly and how it is supposed to help me. I suppose Stefan knows best here. Regardless of its use, it seems to require another try-completion call in all the filtered candidates (which might be very big) so that's probably where the extra lag comes from. So, in summary, to speed this up for whomever is _not_ using fido-vertical-mode, either we manage to speed up that part of icomplete.el, or we get rid of it completely (at least for fido-mode). For reference, it lives in an "else" branch of one of the "if"s in icomplete-completions. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 05 Jun 2021 23:43:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , monnier@iro.umontreal.ca Cc: 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162293656916218 (code B ref 48841); Sat, 05 Jun 2021 23:43:01 +0000 Received: (at 48841) by debbugs.gnu.org; 5 Jun 2021 23:42:49 +0000 Received: from localhost ([127.0.0.1]:50290 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpfwG-0004DW-WE for submit@debbugs.gnu.org; Sat, 05 Jun 2021 19:42:49 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:51945) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpfwD-0004DH-KL for 48841@debbugs.gnu.org; Sat, 05 Jun 2021 19:42:47 -0400 Received: by mail-wm1-f41.google.com with SMTP id r13so7571945wmq.1 for <48841@debbugs.gnu.org>; Sat, 05 Jun 2021 16:42:45 -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=8Kmm/Fi9lwNonVukfgTpH5+OH6gFamvQ2hASIsfyGvg=; b=MaUDTnbX3uHZN8pF72nDshfjh7vpHGzGN7szT/7nGZgr6lHaFcceiEr3TcqTDApnSt EKbwGHjmqNnfiQwMb8z2jproLl9XQhxfhoNSMAechTsyeI4ER/b9a2idvt0FCMMs+1Ap 08iHGlBfebQiXelG3JhfMRWGWYKvOXQwNLHNoiBPZiSzF4MzPB+XRr7C6suh3nJo3Vsh hsnvB34igg3K6Bg/Jg7LR5B+B6SLsFr3cSwu4XXOMwTkBKjnwi/nlfkzg7MqebgKhyT2 GagS0kY8+LCZebKvDM6Jj+zcRIFm3fgUz52RRQ0tk+LVZYToLROWceSmuh7wJtlaPbjx apGg== 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=8Kmm/Fi9lwNonVukfgTpH5+OH6gFamvQ2hASIsfyGvg=; b=UZVwJnt4HT/CWkllxQqJAyQKbUEUkTUGdzj4V2kRC6wbDfQYaF9XyAQU7E47RRjnVg u/4oFlAYK2F9hUIA2Jgn4u/DeyN1dg1Y7bQrrrkxPg5/ivc5K/PSdRcX2UcvxWyXD8ub sU1Daa+GYCk9mMFG6bjVV5AFPPX+pylruHe6vW8X7geY97dzaMfe6x7ZnMlUsVZhFI2Y xl/Gq9+w2mOKWa88zH/CrowcGuPuBSu6nwQXi1Kvr+MEDv73Uy5UrljIiSe+nnB+AYKA GAH2v2x4X27yFTxmYffFxwhrGfj/mgyjTB+uFPc2e+AGXBkOU0c3eQONWbCipjmmgr0y YGow== X-Gm-Message-State: AOAM530udsgGCmL1L/CMLNCs/Og8qIVdngJHbWZes/NqlzTVnK1fbvdR kMFgCtE6t0Bg3jzWcTzmTj2V+l1w5BM= X-Google-Smtp-Source: ABdhPJxaG910IBcNYCXj4vn+umJ6mzFV+ziyapiARXTU3ST0S2hQIrqFpJtrttF9x4aojZ1fyCNYbg== X-Received: by 2002:a1c:bd41:: with SMTP id n62mr9712529wmf.83.1622936559604; Sat, 05 Jun 2021 16:42:39 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i9sm4563019wrn.54.2021.06.05.16.42.38 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Jun 2021 16:42:39 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> From: Dmitry Gutov Message-ID: Date: Sun, 6 Jun 2021 02:42:37 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87a6o3x5j7.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) On 06.06.2021 02:20, João Távora wrote: > Now, what I called here the "suffix-calculation logic" is what I also > called the "[mplete] dance" back in the emacs-devel thread. Truth is, > it's always annoyed me in icomplete partially because I don't understand > what it does exactly and how it is supposed to help me. I suppose > Stefan knows best here. Regardless of its use, it seems to require > another try-completion call in all the filtered candidates (which might > be very big) so that's probably where the extra lag comes from. Shouldn't this logic (whether it's used) be governed by the variable icomplete-hide-common-prefix? Which icomplete--fido-mode-setup sets to nil (appropriately, given than ido-mode does not have this behavior). And looking at its behavior, it only does the "[mplete] dance" when there is only one match remaining. Whether to make icomplete-hide-common-prefix affect even the "only one match" case is a matter of taste: I could personally find an argument for either choice. But we're seeing performance degradation when there are many matches, not one. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 00:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , monnier@iro.umontreal.ca Cc: 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162293913020053 (code B ref 48841); Sun, 06 Jun 2021 00:26:02 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 00:25:30 +0000 Received: from localhost ([127.0.0.1]:50329 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpgba-0005DM-6W for submit@debbugs.gnu.org; Sat, 05 Jun 2021 20:25:30 -0400 Received: from mail-wr1-f42.google.com ([209.85.221.42]:37491) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpgbY-0005D9-Aj for 48841@debbugs.gnu.org; Sat, 05 Jun 2021 20:25:28 -0400 Received: by mail-wr1-f42.google.com with SMTP id i94so8116871wri.4 for <48841@debbugs.gnu.org>; Sat, 05 Jun 2021 17:25:28 -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=OyKbGUaxzqqRRPXsYlvJT6X6qR6hOW9FB+ICq8Ii0O8=; b=ff6QakltRu3AYmhF1ybpdK+y+zNjgeOHowD1GM0XLCm8rr1veFjoB6ZEYdyp9fCam2 RIM8PJDl9q5wyv9bUx7mZa1GLHEmDL9jxZ8M7hVV/e7z3YEW7jAFKyHz95ThP+maitjZ pLapwhMJpGRQ38ed1zmUtWrCw0x/OIh52HypucTtExkk5SpRMPJRlPXP+AHxqOtlq52k ZosMxR6wzPXxa+bHlMLYhydLXhtd/5T5XerInG051qLqZaaah6UHPbK0t31mWj2AdrQQ vmIhLpxSJGTnK/eM5Ww1Agrj4sEsNZGd53/ZCQsNrp6qfTRwCu8wuPQBiDBBzg2IjaLz hvoQ== 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=OyKbGUaxzqqRRPXsYlvJT6X6qR6hOW9FB+ICq8Ii0O8=; b=XAGfctCMCjxU3gD8vLemh+X1dOPCybSPURQslrat8oeZEyTtIfXYs1ZxG+FcVcWNPP Cx4j3pIZmPiQHAmuqJ/qsCxN12BGg2WWwZCd4vR4LB/1vdpJR0rzJk8aWL/8JyMb60TH GoZJ7AcAi2J08MKVsJR4ci1V9Qi4RzAgFwEL0cPcbnRwKCTjMsr8bZE71eXnQZParZfN aOQc6cUCkqT+PmnC0KsMxCMQ8WjHYOO0gxAXnpetqCk1FZYwupaxt3ep3wqMj5g8oE6V fLyxM4uuJd4Sr2NZNPP99KWRfCgrAV8Fy8X1DN74bwSDfqOucvYkifWHKNnL3s62YWSA MRXg== X-Gm-Message-State: AOAM531s8dw8y/cD9HJJ3OmN+yF8gGdkUs7j+o0pjCq9Nthas50QLusr 4c2bNSgh+Qn93uRV93j+JnH34+SMfcw= X-Google-Smtp-Source: ABdhPJxNFF2hHjfvaM1v8FfUn8Ke73bJfLruMsSFmbZifkJEb0Pd9X0Zx/8U31UrqtUxWw7L3moWPQ== X-Received: by 2002:adf:ba07:: with SMTP id o7mr7103304wrg.160.1622939122593; Sat, 05 Jun 2021 17:25:22 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q1sm12723877wmq.48.2021.06.05.17.25.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 05 Jun 2021 17:25:22 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> From: Dmitry Gutov Message-ID: Date: Sun, 6 Jun 2021 03:25:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87a6o3x5j7.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -0.1 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.1 (-) On 06.06.2021 02:20, João Távora wrote: > My bet is that the remaining lag is due to sorting. In a dumb but > illustrative example, when given the pattern 'fmcro' flex-enabled > ido-mode pops 'flymake--backend-state-p--cmacro' to the top, while fido > mode selects the much more reasonable 'defmacro'. Perhaps not sorting exactly, but the scoring part? Lowering the implementation into C might help, we discussed something like that in the past. And/or pick a different algorithm. E.g. Jaro-Winkler, which apparently is used in a lot of "fuzzy matching" implementations out there, it's pretty fast. I took an example like (setq s (all-completions "" obarray)) (setq ss (cl-delete-if-not (lambda (s) (string-match-p "a" s)) s)) then (benchmark 1 '(completion-all-completions "a" ss nil 1)) prints 0.180s here, whereas a "pure Ruby" implementation of Jaro-Winkler takes about 0.060s on the exact same set of strings. But perhaps Ruby is just faster than Elisp, I don't have a good comparison. (The only J-W implementation in Elisp I have found yet -- https://github.com/rdiankov/emacs-config/blob/master/.emacs-lisp/auto-complete-1.3.1/fuzzy.el#L70 -- is slower than the current scoring algo). From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 02:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 48841@debbugs.gnu.org, Dmitry Gutov Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16229469037549 (code B ref 48841); Sun, 06 Jun 2021 02:36:01 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 02:35:03 +0000 Received: from localhost ([127.0.0.1]:50401 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpicx-0001xh-F6 for submit@debbugs.gnu.org; Sat, 05 Jun 2021 22:35:03 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:5962) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpicu-0001x9-QF for 48841@debbugs.gnu.org; Sat, 05 Jun 2021 22:35:02 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 455348091E; Sat, 5 Jun 2021 22:34:55 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id F00C780182; Sat, 5 Jun 2021 22:34:53 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1622946893; bh=Pvtkr4jVWGi0EB0iHeipOtRHGH9utosN0azLOyY+OXg=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=I7Vq37i5x9WzLX0kMMrSWj0Q47LWavzTOVLkTfUd+aRZU9yR6v6AyvE5kstZivljA qhQgiG/XjjYxZCnIiu7PDKwfgANZTjfVIA7Czn32kGGSpqqNi9eVAW3TYMIKr72LAd SplW1ezMwOAbxg7CRRbbsB+y9rZ1wda6wEdVz65beOpEf/1kHW0FebaWyDwyL+A0S9 IdewvPBukJXQIwBozZAsQMSPfDglbKeKbaiZMJEWWGqVmRHStdSZpGG4+y2HDqgMGK ME1JQXwbdqHjc/SNkxI0iHJNQe0B3SG6RLzyxOcrMcxZTM2eblzB0JqQ7w7N0inP6Z Js9UQEGwneFqg== Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id A38951202C2; Sat, 5 Jun 2021 22:34:53 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> Date: Sat, 05 Jun 2021 22:34:53 -0400 In-Reply-To: <87a6o3x5j7.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sun, 06 Jun 2021 00:20:28 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.024 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Stefan knows best here. Regardless of its use, it seems to require > another try-completion call in all the filtered candidates (which might > be very big) so that's probably where the extra lag comes from. IIRC the `try-completion` call is performed on the list of possible completions rather than on the original completion table, so it should be quite fast. I'd be surprised if it is a significant portion of the overall time. Stefan From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 06:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: monnier@iro.umontreal.ca, 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162296250732058 (code B ref 48841); Sun, 06 Jun 2021 06:56:01 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 06:55:07 +0000 Received: from localhost ([127.0.0.1]:50510 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpmgc-0008Kx-C9 for submit@debbugs.gnu.org; Sun, 06 Jun 2021 02:55:06 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:46707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpmga-0008KN-Be for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 02:55:05 -0400 Received: by mail-wr1-f41.google.com with SMTP id a11so11828657wrt.13 for <48841@debbugs.gnu.org>; Sat, 05 Jun 2021 23:55:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=8svOU4tjQPHm28oClawcBoM27TLRHh2uRNoVyznm7BM=; b=jAqd/iW4RyUjcPqSpVpQN85IrGfJY7Lu7U5vKJcZZ1whLXULjMzcMYN8Q6v0yeuCsP BCUWMOjQJ5S0M9tId1YozZPda5ndFn8FNB4cbWnugGGNRx1EP77UBySt4bPFHcKDFF6n YQUm70dglbsozMX+Hbo29Ug4zVDddz020MZ0uuG9D3al//sWRywKjiL3ddc581HkrQJ+ Pr7d5kbN0+tLM6K064tRjKU+AWUCh7K1DAvKbLRrondIxWGwWV5u9uLjKz4j4scdnnJI wn260Hlkh1chT2uKXm93CtPs4rQSX22Mc6Jcv9NxL54AB4bOXHdyVhmWvg12Q7Q5ky4e ESHQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=8svOU4tjQPHm28oClawcBoM27TLRHh2uRNoVyznm7BM=; b=HZqimXrTRoap/mDPvMLXzMYMaPU4kbOSwfLM1MdcxoVwi9QnZbW6h2LEqvXXyrchJL 6lajOY9H4nhfGz6imfSY31Yh7SCXMfB/41hxO3QGsEqIxKoFlq2HMxAFyQd0gEnAssp4 ULF1X9m3xxzP/FbaED/RwqEhkWcPXHaJPAg0bnyftkhXxX5DFf+dCI6cCS9BS7b8ysJH RhyzZDFiA8KmRmP/2gpvv62A62RU8qRcznXs9zyQyDXdNfq7gKNF09ZFw5dqs5rQ/NfB tbMFqligf26L9C5fm7m764XmGw/v53m/p7xmfVv/has7JjElmX9ydYBB2myo7KnN3ZMj uMEA== X-Gm-Message-State: AOAM531BruKQJxvwpEOriaM0XDYns3clb165nnd3AAlwNimI5oSSej78 wF4L+N6fmQXVhFSOn22h1kcgkkGbj4c= X-Google-Smtp-Source: ABdhPJwlhxtEVcX5o9kk3H1nfUsvWJ5NtOUPqmG52LE39+JX2rvi6LAvfXm2VIV6gucCDFBhMmq09Q== X-Received: by 2002:a5d:64c9:: with SMTP id f9mr9467877wri.121.1622962497990; Sat, 05 Jun 2021 23:54:57 -0700 (PDT) Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id 125sm14121802wmb.34.2021.06.05.23.54.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Jun 2021 23:54:57 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> Date: Sun, 06 Jun 2021 07:54:55 +0100 In-Reply-To: (Dmitry Gutov's message of "Sun, 6 Jun 2021 03:25:20 +0300") Message-ID: <87y2bnv5xc.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 06.06.2021 02:20, Jo=C3=A3o T=C3=A1vora wrote: >> My bet is that the remaining lag is due to sorting. In a dumb but >> illustrative example, when given the pattern 'fmcro' flex-enabled >> ido-mode pops 'flymake--backend-state-p--cmacro' to the top, while fido >> mode selects the much more reasonable 'defmacro'. > > Perhaps not sorting exactly, but the scoring part? Lowering the > implementation into C might help, we discussed something like that in > the past. Perhaps, all could be measured. But I also remember explaining that scoring is basically free. The flex algorithm search algorithm is greedy already, it doesn't backtrack. Given a pattern 'foo' against 'fabrobazo', it takes 9 steps to see that it matches. I can't see any other way to improve that, short of a something like a tottaly different string implementation. The scoring's numeric calculations at each step are trivial. One way to verify this is to do the scoring, but simply disregard it for sorting purposes. > And/or pick a different algorithm. E.g. Jaro-Winkler, which apparently > is used in a lot of "fuzzy matching" implementations out there, it's > pretty fast. That may be useful, but for other purposes. If I understand correctly, Jaro-Winkler is for finding the distante between two arbitrary strings, where the first in not a subsequence of the second. I bet google uses stuff like that when you accitendally transpose characters. Flex just gives up. Those other others algos still catch the match (and Google than probably NL-scours your most intimate fears and checks with your local dictator before showing you typing suggestions) > I took an example like > > (setq s (all-completions "" obarray)) > (setq ss (cl-delete-if-not (lambda (s) (string-match-p "a" s)) s)) > > then > > (benchmark 1 '(completion-all-completions "a" ss nil 1)) > > prints 0.180s here, whereas a "pure Ruby" implementation of > Jaro-Winkler takes about 0.060s on the exact same set of strings. But > perhaps Ruby is just faster than Elisp, I don't have a good > comparison. Go ahead and kill the scoring calculationg altogether in completion-pcm--hilit-commonality. I bet it won't make a difference. If fact, for that experiment, try a simple substring search. I bet you're just seeing an inferior GC at work, or a string implementation that's made optimized for other stuff that Ruby's can't, like propertization. Try making Ruby strings that mimic Elips if you've time to spare... > (The only J-W implementation in Elisp I have found yet -- > https://github.com/rdiankov/emacs-config/blob/master/.emacs-lisp/auto-com= plete-1.3.1/fuzzy.el#L70 > -- is slower than the current scoring algo). There you have it. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 07:00:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 48841@debbugs.gnu.org, Dmitry Gutov Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162296275632410 (code B ref 48841); Sun, 06 Jun 2021 07:00:01 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 06:59:16 +0000 Received: from localhost ([127.0.0.1]:50514 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpmke-0008Qg-7p for submit@debbugs.gnu.org; Sun, 06 Jun 2021 02:59:16 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:39606) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpmkY-0008QP-AZ for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 02:59:14 -0400 Received: by mail-wr1-f45.google.com with SMTP id l2so13742469wrw.6 for <48841@debbugs.gnu.org>; Sat, 05 Jun 2021 23:59:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=D/FgjubYlVB3UyvzhPfsFoMObSPBOZ08gD/3yeZ7BFM=; b=Xw7J9yr1M92Nbrxld8c7B4bYSmX80wsCYyl76BN8M7IjZEUCeWMAEBxsuy+gC9kaut T6q8H+2W/fF2CEX03FUJKZup4b1BoIfknr8gBaQVzCxXItu9Xg1PfeNXsVKYu5BxTp5+ 8apllLapg/hYw0j6UupIg4EcLnf7XLnmLQKpa3yItmgDOGj3mW1dZOPnycFxevEkTXqF X802MM3hET0TNWmQf7neQ0yriTBoMAsaKQiREZ3P8N3d4ZP7ZZTrnfY4Fm+V16cJT/dg qCH5C9+kaVdBfWUIVb9tcV+85FUe5siCp3x7or3cglHr/sBx5MWKyfzWWWpWHK38WWbO bjJg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=D/FgjubYlVB3UyvzhPfsFoMObSPBOZ08gD/3yeZ7BFM=; b=dKFo8ON5vUTR/xbgk9pGtpFA39xfqZOzdZAZu4ta8K7j7L+AJEJpAEn4QvVS/bJa6I rXZeOSoERcPqKL+hTDdNbkqjHA3RSgychSYJWL1aXZ1Mn3AmK+DUc3ZaSQsblEpDRnl/ RjOXb892SRATFi5wb97nOU+z4W0XKLchzqi+QBfug76uiikSzM+ONrMDhPQ2tgjNbPvK +48qT1vqAz/fSjTg6hMMt8n4c2C8M64yaJqCtzErShCyySMggxvFyWtawXeSeIa1DwAt obexV2a+2wAhoWUYTzEvGRRbyhtu2CSPnMe8zHWJD2U0WHGiMefK79xv8rMbStiBK6sO 9Mmg== X-Gm-Message-State: AOAM531nsFc3hytUZH3njd3LrU11zbOAhs6Asa/cQ3fpERz1kmsHIlWo haOnWgOQj0ZGrwO4Ia0NQ2MJwlFTG4o= X-Google-Smtp-Source: ABdhPJwkbaJ4FZOZqJ+mTC3XpgnSFtWq0YdTjbGczFrpscWhGCWmHFzGbmTTUV5KZrckevDpQRUE3Q== X-Received: by 2002:a5d:6b52:: with SMTP id x18mr11222618wrw.11.1622962744217; Sat, 05 Jun 2021 23:59:04 -0700 (PDT) Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id l10sm11678141wrm.2.2021.06.05.23.59.03 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 05 Jun 2021 23:59:03 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> Date: Sun, 06 Jun 2021 07:59:02 +0100 In-Reply-To: (Stefan Monnier's message of "Sat, 05 Jun 2021 22:34:53 -0400") Message-ID: <87tumbv5qh.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Stefan Monnier writes: >> Stefan knows best here. Regardless of its use, it seems to require >> another try-completion call in all the filtered candidates (which might >> be very big) so that's probably where the extra lag comes from. > > IIRC the `try-completion` call is performed on the list of possible > completions rather than on the original completion table, so it should > be quite fast. I'd be surprised if it is a significant portion of the > overall time. Very true, but here's the suprise: In the flex style, there are a _lot_ of "possible completions" for the null or very short patterns. So those calculations -- which were more than certainly thought up for prefix-ish styles -- are quite slow (and also quite useless for flex). At least that's my theory. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 16:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Stefan Monnier Cc: 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162299851031697 (code B ref 48841); Sun, 06 Jun 2021 16:56:02 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 16:55:10 +0000 Received: from localhost ([127.0.0.1]:53790 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpw3J-0008FB-Qm for submit@debbugs.gnu.org; Sun, 06 Jun 2021 12:55:10 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:38640) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpw3G-0008EX-7H for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 12:55:08 -0400 Received: by mail-wm1-f48.google.com with SMTP id t4-20020a1c77040000b029019d22d84ebdso11002627wmi.3 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 09:55:06 -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=gH+LCQWfnd/B/jYANhu5DTPhrcbesR6icVxjK/vwRMA=; b=tolzYKuQtSdziE8dNpf5mYKoBN76RRGOVXKQ1VThY58Ttytn/RwH9jXt1j+dfo5fSP eKX36KGPgGWw+LoddrRzH1w0XLLhQ4bknzh99aTJuJD6QOaUEffdcmbYBLRAR6v7iIgx fvZt3foRg9O0lwjbTdBilSTPKiO8RsB3J/nfPDr07k+U26nU4StRKf0aupYdNm8HLWiq Y2ZKi1hRjotijSwbZckxRwKXQmNUpfNKZHXUA/8QCXh+9GPfVfBQIoeZsvn2I8y/TbNB 2w0QuP7L11THADkJXeVO6kCL8PAdT3LaDvaTow7EZLkUqW654iQXMTE+09YM2ygvYulO HNKQ== 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=gH+LCQWfnd/B/jYANhu5DTPhrcbesR6icVxjK/vwRMA=; b=ElLdIEMEs2Yyiy2OnsKy7X1PkIKJF8DwS7yeXPa7bZe5upCky1vXY2OYqxBbAiY7EN ZHq02/kF2qYTMoz9JvV5MVhWjGCqDBs6eJNR5PaqGaWCHI8sEYyRu7wUifVk6eTQAyFJ Ufm2EUMgdf1BSU6u4ldNHMiKgSz0cDIS2DMtJUwb043HOEzys5Ywg9QxYro3IFQKv32Q F3cnqnnHlgmnzcyD7hFwr88LJ5qel+RuKg29X9C6RVy+44xK+1oAk5EVysCQFObbv9An 31cF91LJT4sZIG2KF/HQxHggRLPwF2zbap9/BEnv5A1sf4sw/6gPYYCa1145WbgAMte+ CaSg== X-Gm-Message-State: AOAM533wEDNc/2pMEpjpb9ak9sc7gWWS3UhrRRYzNtfNmkV2o9Wmg6NR x4k51fB82NxvvdM3sBl0MXeZdAzqiGM= X-Google-Smtp-Source: ABdhPJyHsUXpJZQFt6v3Wb7zeycigzPlgH5ity4AwUhH4R+gvg5WZLJuLlWKvZGP78dsCaP8n2T05Q== X-Received: by 2002:a1c:8049:: with SMTP id b70mr980029wmd.92.1622998500237; Sun, 06 Jun 2021 09:55:00 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k82sm15044478wmf.11.2021.06.06.09.54.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 09:54:59 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87tumbv5qh.fsf@gmail.com> From: Dmitry Gutov Message-ID: <5efda5a3-f7ed-ca90-9e70-b35eb1c24750@yandex.ru> Date: Sun, 6 Jun 2021 19:54:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87tumbv5qh.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 06.06.2021 09:59, João Távora wrote: > Very true, but here's the suprise: In the flex style, there are a_lot_ > of "possible completions" for the null or very short patterns. So those > calculations -- which were more than certainly thought up for prefix-ish > styles -- are quite slow (and also quite useless for flex). At least > that's my theory. try-completion doesn't trigger any completion style machinery; only completion-try-completion does. And are we talking about the 'try-completion' call which is guarded with (when icomplete-hide-common-prefix ...)? icomplete--fido-mode-setup sets that variable to nil. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Stefan Monnier Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 17:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: 48841@debbugs.gnu.org, Dmitry Gutov Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16230021165346 (code B ref 48841); Sun, 06 Jun 2021 17:56:01 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 17:55:16 +0000 Received: from localhost ([127.0.0.1]:53837 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpwzU-0001O9-Dx for submit@debbugs.gnu.org; Sun, 06 Jun 2021 13:55:16 -0400 Received: from mailscanner.iro.umontreal.ca ([132.204.25.50]:40707) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpwzR-0001Nq-IM for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 13:55:15 -0400 Received: from pmg2.iro.umontreal.ca (localhost.localdomain [127.0.0.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 0D81680497; Sun, 6 Jun 2021 13:55:07 -0400 (EDT) Received: from mail01.iro.umontreal.ca (unknown [172.31.2.1]) by pmg2.iro.umontreal.ca (Proxmox) with ESMTP id 9441680240; Sun, 6 Jun 2021 13:55:05 -0400 (EDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=iro.umontreal.ca; s=mail; t=1623002105; bh=Y2Yf7mmGeRVtwYUTw1aQq8xVaU3V4dqOpwvkUmh2/PE=; h=From:To:Cc:Subject:References:Date:In-Reply-To:From; b=MnePlB5GfoC1B9ACLNXNJ4jc9A6Tiv8jMEenZmcPuEsSYU1C07bsB7bHXglDfDKEk 9dJx5wCkBBHeletib7ZIBFd18QPbXOdkj3UYlFjrRJwpEN0CTCrawmCFr++lgmGyB0 qr0ygtyYveeQjfxQhNp0hnLX1EcOEwHMZWIVIcPkxTBNRhaofVUwcnmCs0wso/ABio 7OVI8OXOe1im4KOKZL+yntsLdD3s/k0rvTsp99opE6/P6LbYRxzQzQoaCfz3R/Xh2T 8iy30Zk0yMfZ92DG3stnjxIjbaaeDSWmTYhF2pOrPp/qaKVJT0tWz5KdxBBKUF+eFv nhwuhXAOC4QVw== Received: from alfajor (69-196-163-239.dsl.teksavvy.com [69.196.163.239]) by mail01.iro.umontreal.ca (Postfix) with ESMTPSA id 623201200E2; Sun, 6 Jun 2021 13:55:05 -0400 (EDT) From: Stefan Monnier Message-ID: References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87tumbv5qh.fsf@gmail.com> Date: Sun, 06 Jun 2021 13:55:04 -0400 In-Reply-To: <87tumbv5qh.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sun, 06 Jun 2021 07:59:02 +0100") User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-SPAM-INFO: Spam detection results: 0 ALL_TRUSTED -1 Passed through trusted hosts only via SMTP AWL -0.020 Adjusted score from AWL reputation of From: address BAYES_00 -1.9 Bayes spam probability is 0 to 1% DKIM_SIGNED 0.1 Message has a DKIM or DK signature, not necessarily valid DKIM_VALID -0.1 Message has at least one valid DKIM or DK signature DKIM_VALID_AU -0.1 Message has a valid DKIM or DK signature from author's domain X-SPAM-LEVEL: X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Very true, but here's the suprise: In the flex style, there are a _lot_ > of "possible completions" for the null or very short patterns. So those > calculations -- which were more than certainly thought up for prefix-ish > styles -- are quite slow (and also quite useless for flex). At least > that's my theory. In the very worst possible case, `try-completion` will be just as slow as the original computation of the set of possible completions. So at most it will double the total time (and this assumes we do basically nothing else than a single call to `all-completions` to get the set of candidates and then display them). In practice I'd be surprised if it ever reaches the 20% mark of the time spent. Stefan From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 18:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16230046499857 (code B ref 48841); Sun, 06 Jun 2021 18:38:02 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 18:37:29 +0000 Received: from localhost ([127.0.0.1]:53881 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpxeL-0002Yv-23 for submit@debbugs.gnu.org; Sun, 06 Jun 2021 14:37:29 -0400 Received: from mail-pg1-f170.google.com ([209.85.215.170]:43905) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpxeH-0002Yg-BD for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 14:37:27 -0400 Received: by mail-pg1-f170.google.com with SMTP id e22so12096118pgv.10 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 11:37:25 -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; bh=UayIdd/Hmwygy0E2HCpjkNrLxmEM9NXMmDfmmL2aajU=; b=BMNjqeEQZdYXqcjbcm8Zod9A7qO4zTps07KMJhftuQn+JKG0yFwmz2QXkTBG0OnRUY /vGK9SxawMe6VSywEUy2sueO9c1LQvI9VLVHw70ItskrwVHWHChN3442P/kyPYTfVaYm pfFCq+UJEpelkj+muVBGEN6xt9c0kxJddaVHCDGF+lFhzo0D4p1UMMSD0hQ5J0QQkS3o mbLz4S2x4+vE3iaw5L67BIoohc/uzge3otwBuxeMY9mkXkzBoyPSWJPfcIpqXYSe+4sL HF2KLaTVxXiqPLKbznCPGLjGMoD7rXKB1kyusn41ULVLBKS6PSJA7XBg7ZoqRBs65ReV KEzA== 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; bh=UayIdd/Hmwygy0E2HCpjkNrLxmEM9NXMmDfmmL2aajU=; b=Lz8H80plUwjHK7LfECuCJ6ptHy7uJe8gmp0VY2J7Q3JZqlQRjGesUOIz5dt38Ezza8 4JVvCnU9aaBpa1ffOphyI6T22qU94DQm4R9lENAj7EkcgHurB6JhC8q/pASYkzfwKkx4 lLg9xFl34lKnylR8z01+LjokGr8LCYOTXYj2f8lvdqqmmQPbzcrW3H8IptpDwp4Jvcis QJ/h+wEr7Y3K7LTEiY79tBmFwdc8Nrb7AQC+N7lEdaBVn7wt7tkfjReTRZD8v9e2ST6n G1Gk/ipTa2JhV91qIOGlhJluNgtBExj2LVqV8leoH8Q2IXXwvSvEBbD9wHgpZIgPzOuU 3cQg== X-Gm-Message-State: AOAM532MDgShfDkz5N8mWKmAzDMcLZN/wA0VE0k0dSzo31uMwF2jthVv ++9C/4NK/dxDzZqltXzgyjI9ypg4BZtamDI2Z+8= X-Google-Smtp-Source: ABdhPJz41XdKUlX0GgmTlPGJ83qQkJUwTPsfFZNzXPI6tygAlsXvU79h1t9+vCXmvB7Ba0Rt1p5ZRgrRDV18EfJW5yg= X-Received: by 2002:a62:5547:0:b029:2ec:8f20:4e2 with SMTP id j68-20020a6255470000b02902ec8f2004e2mr12011622pfb.71.1623004639234; Sun, 06 Jun 2021 11:37:19 -0700 (PDT) MIME-Version: 1.0 References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87tumbv5qh.fsf@gmail.com> <5efda5a3-f7ed-ca90-9e70-b35eb1c24750@yandex.ru> In-Reply-To: <5efda5a3-f7ed-ca90-9e70-b35eb1c24750@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Sun, 6 Jun 2021 19:37:05 +0100 Message-ID: Content-Type: multipart/alternative; boundary="000000000000fd8ce305c41d365f" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000fd8ce305c41d365f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 6, 2021, 17:55 Dmitry Gutov wrote: > On 06.06.2021 09:59, Jo=C3=A3o T=C3=A1vora wrote: > > Very true, but here's the suprise: In the flex style, there are a_lot_ > > of "possible completions" for the null or very short patterns. So thos= e > > calculations -- which were more than certainly thought up for prefix-is= h > > styles -- are quite slow (and also quite useless for flex). At least > > that's my theory. > > try-completion doesn't trigger any completion style machinery; only > completion-try-completion does. > I have no idea if completion style stuff b is related. Just that else branch is there to calculate some 'determ' thing and a cursory look revealed try-completion calls being passed 'comps', or 'completions'. Presumably lots of data given short flex style patterns. No idea what it accomplishes, as I said. Bottom line is that something (TM) happened to speed up the whole thing when I skipped over that whole part. I had vertical mode basically visually equivalent to vertical, but quite slower. After skipping that part they became practically equivalent. And you yourself witnessed this when switching yo vertical mode, which is when the skip is made. I'll check later in the week, away from my computer now. And are we talking about the 'try-completion' call which is guarded with > (when icomplete-hide-common-prefix ...)? > No idea > > icomplete--fido-mode-setup sets that variable to nil. > May be. Jo=C3=A3o > --000000000000fd8ce305c41d365f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 6, 2021, 17:55 Dmitry Gutov <dgutov@yandex.ru> wrote:
On 06.06.2021 09:59, Jo=C3=A3o T=C3=A1vora wrote:
> Very true, but here's the suprise: In the flex style, there are a_= lot_
> of "possible completions" for the null or very short pattern= s.=C2=A0 So those
> calculations -- which were more than certainly thought up for prefix-i= sh
> styles -- are quite slow (and also quite useless for flex).=C2=A0 At l= east
> that's my theory.

try-completion doesn't trigger any completion style machinery; only completion-try-completion does.

I have no idea if completion style stuff b i= s related. Just that else branch is there to calculate some 'determ'= ; thing and a cursory look revealed try-completion calls being passed '= comps', or 'completions'. Presumably lots of data given short f= lex style patterns. No idea what it accomplishes, as I said.

Bottom line is that something (TM) ha= ppened to speed up the whole thing when I skipped over that whole part. I h= ad vertical mode basically visually equivalent to vertical, but quite slowe= r.=C2=A0 After skipping that part they became practically equivalent. And y= ou yourself witnessed this when switching yo vertical mode, which is when t= he skip is made.

=C2=A0I= 'll check later in the week, away from my computer now.

And are we talking about the 'try-completion' = call which is guarded with
(when icomplete-hide-common-prefix ...)?

No idea

icomplete--fido-mode-setup sets that variable to nil.

May be.

Jo=C3=A3o
--000000000000fd8ce305c41d365f-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 21:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Stefan Monnier Cc: 48841@debbugs.gnu.org, Dmitry Gutov Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162301522510583 (code B ref 48841); Sun, 06 Jun 2021 21:34:02 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 21:33:45 +0000 Received: from localhost ([127.0.0.1]:54063 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq0Ov-0002kd-JW for submit@debbugs.gnu.org; Sun, 06 Jun 2021 17:33:45 -0400 Received: from mail-pj1-f51.google.com ([209.85.216.51]:39516) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq0Os-0002kO-0d for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 17:33:44 -0400 Received: by mail-pj1-f51.google.com with SMTP id o17-20020a17090a9f91b029015cef5b3c50so10654716pjp.4 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 14:33:41 -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; bh=NPhMA2y8vLE5TrIVwEoGXz/FQcVSRu75PvU4MAYmN4g=; b=G7YFfDUkQGrl0AxEvvweDoFEcjJZQwlsZvYWUpRWUZkcYH4JzOSqepC5uYX5hgL/2k JXC0gxPVJkvkmlbFv3sO8DS1K8+coYz1o3wgv+dQzkZXtieVlWk5+7FzVMs2kcpBH5Al 9ozhhyF1FzWnCG9DDx7LKtC5Bp9p2GG7wjoO9mspU/zeivanp6Z9BOKvnPysQGTHEQIW 7begGfCT9Hbuphr5PUqvPGx/XqpbsdHeT3pZ/YDvlXE0c79CtuE5hyc7VIZKgW89fxJV l2RAaN7RJRZtOHN5QIY2eaavh3uxPB6kMPj/AtjEU6riq9ASqEAXc9X7ezQAOFbWjM2t pt4w== 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; bh=NPhMA2y8vLE5TrIVwEoGXz/FQcVSRu75PvU4MAYmN4g=; b=BW/hG0xdGNH+cgbGpmCkwblGmFJreMj75kV3+2FT3pivIf5H4iYCIXZJhN5kevkYgZ o/0xbGFhlYVAH/fCMSC3gyPwRcoaYyveBnS5xHkjtvbckjsxEh/ovRKhBE5GLHj7J5Tk n+i5LntyBPVEYhIvaJuVntD/+q5r4V0+iF+sKeH8XnrLJTS3gjZKEvEH7kouRfCs7qEY X8mU/DNKnBaszF5xjY2kYzIFRn351aE0dTVkjkBkgtcr1DUbr6ryOOPH8EWW3Afdoeu4 3Vl23xKE1F5uyjQVBQl3X5XAl+T0lpNRqG5583MEt03tX0rG9yMZeqrWT9I5cGNont1V HGng== X-Gm-Message-State: AOAM530igLrpFaGOvbyQl3pYtPmbKAfml3QuuHUb0kpZeHsTUed2ZboB 4GZ+XH14VMowJe3CC/YiVInAu2AY0GqIQzxVeFU= X-Google-Smtp-Source: ABdhPJyE1wolXalDUCeqQI75AGiw09gZA3Ob+V6CNtpPBvUIXt2K7Ljb3akVClHxD4MJBWDc0WvgFGuMROvM3b6hLtA= X-Received: by 2002:a17:902:8b8a:b029:108:7849:dae0 with SMTP id ay10-20020a1709028b8ab02901087849dae0mr14807401plb.36.1623015216200; Sun, 06 Jun 2021 14:33:36 -0700 (PDT) MIME-Version: 1.0 References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87tumbv5qh.fsf@gmail.com> In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Sun, 6 Jun 2021 22:33:22 +0100 Message-ID: Content-Type: multipart/alternative; boundary="0000000000006d3d5a05c41fad40" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000006d3d5a05c41fad40 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 6, 2021, 18:55 Stefan Monnier wrote: > In practice I'd be surprised if it ever reaches the 20% mark of the time > spent. Personally, I'm usually suprised if less than 80% of my estimates aren't totally off. :) Anyway, if not try-completion like I theorized, it should be reasonably easy to pinpoint: something non-fido-essential in that else branch is causing a real slowdown. Jo=C3=A3o > > --0000000000006d3d5a05c41fad40 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 6, 2021, 18:55 Stefan Monnier <monnier@iro.umontreal.ca> wrote:
In practice I'd be surprised if it ever reaches the 20% mark of the tim= e spent.

Personally, I'm usually suprised if less than 80% of my estimates a= ren't totally off. :) Anyway, if not try-completion like I theorized, i= t should be reasonably easy to pinpoint: something non-fido-essential in th= at else branch is causing a real slowdown.

Jo=C3=A3o
=C2=A0
--0000000000006d3d5a05c41fad40-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 22:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: monnier@iro.umontreal.ca, 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162301802214915 (code B ref 48841); Sun, 06 Jun 2021 22:21:01 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 22:20:22 +0000 Received: from localhost ([127.0.0.1]:54113 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq182-0003sV-Dd for submit@debbugs.gnu.org; Sun, 06 Jun 2021 18:20:22 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:55914) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq181-0003sJ-1z for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 18:20:21 -0400 Received: by mail-wm1-f41.google.com with SMTP id g204so8758346wmf.5 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 15:20:21 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:from:subject:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=6xB7X+SdGtL2L6oP8WIEDQz7toaKPv+5Hm37Y2uyvgw=; b=a1KoxI9rJJqtL0BWSqrySt04YDTiiG9HggNeEDy9PJTU0sgcSMc4qM69t3n2Ld2nct +wC7pG1iaN+K1lfPXmQYZo//s/gyw4Fsm78NI1Vw0j7YP8Ju4UK/tHDyl2SGZg66V3a0 1Hnki1o+vLQ2Bl9BptYN1jhwBUf2OA1DxIiFrZQfRRqjzZZyKgwxSUQPEOk6T8APVe8a 7d0ME775pyw5+q1DHsIvqV4rBhzWTuaNecyOxsut/Xc1lOgUmRqAZSINDNYoGptOXd19 DBKQqliXFdQ60CkL+FXg3kr5hcZ+BTcuQfQUwFxabnicdod2+XmqwULhTfB+Pitl18fC sUxg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:from:subject:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=6xB7X+SdGtL2L6oP8WIEDQz7toaKPv+5Hm37Y2uyvgw=; b=LI+qC3/uCpCQTzOFHHPsINAQXgfYFxUvaEmfvhxVkmMtYhqV1EYPCk431Mj//AzLgM ufyVbBelDusZykgF4QDvA7AGgyeJ+sH1deX5rcW6v5KKA6J4fzjTFWDfm3CDdNy71/CF jnK0xOHYqW7SLMIWMgi/vf/QLEdD7LTRydWlaUt7jkhmS84dYoYY2HWWODLtpPKy3dN7 FDuluOBPWiuCThCFgmbHepW4t/VqQtxGNAZp6N2+RUn1iBHCObKHuZ/PsttwvCKRBLTK EbgBCq9qMWmaRbyyTa2ptKxyV+LCfQnKDWzNF9dWsj7O6Gn+UFUkiD/KMZyv+wRx/8js w0Og== X-Gm-Message-State: AOAM531v+/vT0EjkmMsGo1RLBsmJo7xmQTII+sfnn+xlDGAQEF/52ps3 dAfYBvcNr5QE8n47eyghw0kXIH+Qbzc= X-Google-Smtp-Source: ABdhPJxUNQiB4hfz0s0XMgQt0Ms9H8tU0km54ChLGjaVQn1cLavSa0X8onAIfrts/mYK5RIQEQFDtQ== X-Received: by 2002:a7b:cbc4:: with SMTP id n4mr14439600wmi.153.1623018015138; Sun, 06 Jun 2021 15:20:15 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id w13sm14973997wrc.31.2021.06.06.15.20.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 15:20:14 -0700 (PDT) From: Dmitry Gutov References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> Message-ID: <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> Date: Mon, 7 Jun 2021 01:20:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87y2bnv5xc.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 06.06.2021 09:54, João Távora wrote: >> Perhaps not sorting exactly, but the scoring part? Lowering the >> implementation into C might help, we discussed something like that in >> the past. > > Perhaps, all could be measured. But I also remember explaining that > scoring is basically free. The flex algorithm search algorithm is > greedy already, it doesn't backtrack. Given a pattern 'foo' against > 'fabrobazo', it takes 9 steps to see that it matches. I can't see any > other way to improve that, short of a something like a tottaly different > string implementation. The scoring's numeric calculations at each step > are trivial. Thanks, if it's indeed that fast, I might have a use for it as well, in a different context. ;-) >> And/or pick a different algorithm. E.g. Jaro-Winkler, which apparently >> is used in a lot of "fuzzy matching" implementations out there, it's >> pretty fast. > > That may be useful, but for other purposes. If I understand correctly, > Jaro-Winkler is for finding the distante between two arbitrary strings, > where the first in not a subsequence of the second. I bet google uses > stuff like that when you accitendally transpose characters. Flex just > gives up. Those other others algos still catch the match (and Google > than probably NL-scours your most intimate fears and checks with your > local dictator before showing you typing suggestions) I'm not crazy about shuffling completion, but some people did indeed ask for it. The filtering step has to be more complex, though (you can't just construct a straightforward regexp to filter with). >> I took an example like >> >> (setq s (all-completions "" obarray)) >> (setq ss (cl-delete-if-not (lambda (s) (string-match-p "a" s)) s)) >> >> then >> >> (benchmark 1 '(completion-all-completions "a" ss nil 1)) >> >> prints 0.180s here, whereas a "pure Ruby" implementation of >> Jaro-Winkler takes about 0.060s on the exact same set of strings. But >> perhaps Ruby is just faster than Elisp, I don't have a good >> comparison. > > Go ahead and kill the scoring calculationg altogether in > completion-pcm--hilit-commonality. I bet it won't make a difference. > If fact, for that experiment, try a simple substring search. Same result, indeed. We should note, though, that completion-pcm--hilit-commonality has some steps that were added together with the 'flex' style, for it to work. > I bet > you're just seeing an inferior GC at work, or a string implementation > that's made optimized for other stuff that Ruby's can't, like > propertization. Try making Ruby strings that mimic Elips if you've time > to spare... I did some instrumenting, replacing (completion-pcm--hilit-commonality pattern all) inside completion-flex-all-completions with (benchmark-progn (completion-pcm--hilit-commonality pattern all)). Recompiled between each change (interpreted mode gives very different numbers). Unmodified, the call takes ~85ms: Elapsed time: 0.085520s (0.068406s in 4 GCs) If I comment everything inside its first lambda except the returned value (making the function the same as #'identity), the time goes down to <1ms. Uncomment the 'copy-sequence' and 'string-match' calls (which one might suspect of garbage generation): Elapsed time: 0.006380s Tried binding gc-cons-threshold to a high value, and even galling garbage-collect-maybe (or not): that speeds it up, but adds some unpredictable GC pauses later (though it would be nice to be able to consolidate the pauses into one collection pass). Long story short, the patch I just installed, to reuse the match data, brings the runtime down to Elapsed time: 0.066388s (0.050087s in 3 GCs) Tried other things like moving the update-score-and-face lambda out of the mapcar loop - that didn't move a needle. Someone more familiar with the code might get further. But perhaps it's just the cost of executing this logic in Lisp 12000 times, and doing some of that in C would be the next step. And a weird part: replacing all repeated (length str) calls with a reference to an existing local binding makes it *slower* (back to the original performance). Check this out: diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index d5a0118b7c..d7102245a2 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3544,7 +3544,7 @@ completion-pcm--hilit-commonality score-numerator (+ score-numerator (- b a))) (unless (or (= a last-b) (zerop last-b) - (= a (length str))) + (= a end)) (setq score-denominator (+ score-denominator 1 @@ -3562,12 +3562,12 @@ completion-pcm--hilit-commonality ;; for that extra bit of match (bug#42149). (unless (= from match-end) (funcall update-score-and-face from match-end)) - (if (> (length str) pos) + (if (> end pos) (add-face-text-property pos (1+ pos) 'completions-first-difference nil str)) - (unless (zerop (length str)) + (unless (zerop end) (put-text-property 0 1 'completion-score (/ score-numerator (* end (1+ score-denominator)) 1.0) str))) @@ -3980,7 +3980,7 @@ completion-flex-all-completions string table pred point #'completion-flex--make-flex-pattern))) (when all - (nconc (completion-pcm--hilit-commonality pattern all) + (nconc (benchmark-progn (completion-pcm--hilit-commonality pattern all)) (length prefix)))))) ;; Initials completion From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 06 Jun 2021 22:22:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162301809215045 (code B ref 48841); Sun, 06 Jun 2021 22:22:01 +0000 Received: (at 48841) by debbugs.gnu.org; 6 Jun 2021 22:21:32 +0000 Received: from localhost ([127.0.0.1]:54117 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq199-0003ua-TY for submit@debbugs.gnu.org; Sun, 06 Jun 2021 18:21:32 -0400 Received: from mail-wr1-f53.google.com ([209.85.221.53]:45832) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq197-0003uK-Fw for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 18:21:29 -0400 Received: by mail-wr1-f53.google.com with SMTP id z8so15262169wrp.12 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 15:21:29 -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=Xp5xZYra07gEC132g1qMNKIzGmLHyyiiu5CFwHRfxm8=; b=t38u11Hv8b+ojoflHwFP5QZdlxbJExQkwWPWnVyVjtcZ8kGuy0x5FJvix40959hzEX nxjNm7+nRhvPKzAo7ZFzJSLz8rNzoFkqIewcswvjiBUeQ9I5XjE7xyvOPY3/1JvcxKg6 pE3JlSZziim+GBPg1Fop5FC0flyUWpkWy2spGxnITIZ2vdulj6vh0Yi+V698OOzL17bd B4EDvqhIxR8pBvgM8HfJ23wplJsJ5mFTfI+3lmXoLUTQSNczhM9cskTLNhKD0dCJyLvk J7AlsxqEGh4IYQB9tIDKJRmy+xyYpyBUykdKiBO898u3V6JEOk0b/O5r8VA2GqWKVoJy pPug== 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=Xp5xZYra07gEC132g1qMNKIzGmLHyyiiu5CFwHRfxm8=; b=p/kqaec4NhxBqcQ/f9lR3lSxZotnMtAR1iOH5K9JRxNHHVlnkYYnHpYFYphhDZTrDd LvSA9uhOlonxu7CjQEVxKoZOxMcZd2qZLd3gF/Iv5woz0PmfeXJpp1FISYNfRMORG63g e18kYDUK7w7XAugHBXK4lloTt1AHeeXibOdQpv/WsjDfnYaDay3fH9DtACu6yMvjS0ea BJbF5WBwocFW+jx7hVpdgXgImHxxhU8zB13HiBAgWIXejl2iohwh2HARQceLwoppCkUE BEXHzGW+5ysBf+Ci6/k0Wl+DzWaxiTbE0LnpkcYecschFKIs/AthomB4lOy+nrckkGVA K3bA== X-Gm-Message-State: AOAM5331SI9/Mt+NHhdTqNOQ0DZHTYWew8L4Cr/OYjnQQVX/OT4vk+kJ F/PnU7C8Ci7T8xKS9EqDWqC7BN1wJWE= X-Google-Smtp-Source: ABdhPJxZ6NKOCOpIBdXcgWLFXo33ewkV6emnz1vozxUsf3Xu3q/EnCF7x1X9vvBvwm2cIAK5kLkjSA== X-Received: by 2002:a5d:6e92:: with SMTP id k18mr14359689wrz.94.1623018083828; Sun, 06 Jun 2021 15:21:23 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b10sm16538208wrr.27.2021.06.06.15.21.22 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 15:21:23 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87tumbv5qh.fsf@gmail.com> <5efda5a3-f7ed-ca90-9e70-b35eb1c24750@yandex.ru> From: Dmitry Gutov Message-ID: <31baa0d5-02e0-368d-7946-7a3b98a8a5ca@yandex.ru> Date: Mon, 7 Jun 2021 01:21:22 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 06.06.2021 21:37, João Távora wrote: > Bottom line is that something (TM) happened to speed up the whole thing > when I skipped over that whole part. I had vertical mode basically > visually equivalent to vertical, but quite slower.  After skipping that > part they became practically equivalent. And you yourself witnessed this > when switching yo vertical mode, which is when the skip is made. Yep. >  I'll check later in the week, away from my computer now. Looking forward to it. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Jun 2021 01:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162302981431774 (code B ref 48841); Mon, 07 Jun 2021 01:37:02 +0000 Received: (at 48841) by debbugs.gnu.org; 7 Jun 2021 01:36:54 +0000 Received: from localhost ([127.0.0.1]:54179 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq4CD-0008GP-RT for submit@debbugs.gnu.org; Sun, 06 Jun 2021 21:36:54 -0400 Received: from mail-pg1-f174.google.com ([209.85.215.174]:42786) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq4CB-0008GA-Rj for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 21:36:53 -0400 Received: by mail-pg1-f174.google.com with SMTP id i34so6187912pgl.9 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 18:36:51 -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; bh=MSh0ek3MqGWUtKtgZXaXrsqHaTuof9mIPeyiqOMQaDM=; b=H2RI+FkBP5d2J6WaIFfcrdqVdz9GuBOcvI0mIrpSEN4jXhavZvHfQAwsAcxXK/8sZI Dd1Co1qf6WDSQ6hlaeHWinW/+757acMPP716K3PWHYTFI6KmGgtlsb3OLRyzFLhoVO51 o0GPZgWgheF9gS74AGVqjCVCUR8Q7IRGR+ulCiwDmJs9UBp6LDpco71zUSWgduj1Gfz2 h04L5N/ZOZFmIIqpzRhqiv0gUcXV5ybMgSdaeX2Fa/B64pvHBL/aV/TvmAo6VVNY6ZAd JJM+cJjJGDvaDBp+MMeS3EakeC1QekUdb8npVHfy+uHgW/T3cEjX+jJca6cUNRg4lJtR iC4g== 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; bh=MSh0ek3MqGWUtKtgZXaXrsqHaTuof9mIPeyiqOMQaDM=; b=U9u89oO8uHIScnEeEeTy/0rs6OQ0AkcK6vJMJnqga25WQ9WHaG3pzHll5EbkdmYA30 0BPlPX8xySsdr1TRKeWrvnjn8lnwv3llaK/bDLLHUSY0rVpDo5t7aN3SXiANwyrT8WY7 z7HVizOGsgmYGCDcyq+SZAKGc1jRqjwf8Bw084le7VmZ2/7D/yzBlqebWu1qOI2ya+Ie a8YjesDrQ4BKPrhHEV4aaUX+QfhY5PzK3AgMeX+qD0kFyfO0T41vxDFjmdshT182hNtf VQpHIUS2roBARXphCY7dejja18ZeiskKbttR2S6G1tJWixT5XWckj/BJzmz0z9di45yy relQ== X-Gm-Message-State: AOAM532vWCgZewEC08cvOauKONM+B+gKS1oCuon0jMHbEjKgDGSi0p7o 4at6Ev/V90fe+DiGmU746vkxFEq2jT/ahyt66nWeNUuq X-Google-Smtp-Source: ABdhPJx+lBqSlHKaTg5m+Qel20kVW8wHY9Sb+rMeDFS9DhRHWsr9OssDBkZpnw13O64aLxprDtqHudYlCdingqlVW9g= X-Received: by 2002:a17:902:ed8f:b029:110:a434:4d76 with SMTP id e15-20020a170902ed8fb0290110a4344d76mr9009369plj.52.1623023404154; Sun, 06 Jun 2021 16:50:04 -0700 (PDT) MIME-Version: 1.0 References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> In-Reply-To: <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 7 Jun 2021 00:49:51 +0100 Message-ID: Content-Type: multipart/alternative; boundary="0000000000007782bf05c421955f" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000007782bf05c421955f Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 6, 2021, 23:20 Dmitry Gutov wrote: > > >> And/or pick a different algorithm. E.g. Jaro-Winkler, which apparently > >> is used in a lot of "fuzzy matching" implementations out there, it's > >> pretty fast. > > > > That may be useful, but for other purposes. If I understand correctly, > > Jaro-Winkler is for finding the distante between two arbitrary strings, > > where the first in not a subsequence of the second. I bet google uses > > stuff like that when you accitendally transpose characters. Flex just > > gives up. Those other others algos still catch the match (and Google > > than probably NL-scours your most intimate fears and checks with your > local dictator before showing you typing suggestions) > Meant to write ML as in machine learning, not NL. I'm not crazy about shuffling completion, but some people did indeed ask > for it. The filtering step has to be more complex, though (you can't > just construct a straightforward regexp to filter with). > I think you calculate the distance using one of these fancy multi-surname algorithms , then do cutoff somewhere. Same result, indeed. We should note, though, that > completion-pcm--hilit-commonality has some steps that were added > together with the 'flex' style, for it to work. > But nothing algorithmically aberrant, I think. I did some instrumenting, replacing (completion-pcm--hilit-commonality > pattern all) inside completion-flex-all-completions with > (benchmark-progn (completion-pcm--hilit-commonality pattern all)). > Recompiled between each change (interpreted mode gives very different > numbers). > > Unmodified, the call takes ~85ms: > > Elapsed time: 0.085520s (0.068406s in 4 GCs) > By the way, I think you should be running benchmarks multiple times to get times in the seconds range, and reduce noise. Multiple levels of CPU cache and other factors like temp thottling may skew results when running just one time. If I comment everything inside its first lambda except the returned > value (making the function the same as #'identity), the time goes down > to <1ms. > > Uncomment the 'copy-sequence' and 'string-match' calls (which one might > suspect of garbage generation): > > Elapsed time: 0.006380s > > Tried binding gc-cons-threshold to a high value, and even galling > garbage-collect-maybe (or not): that speeds it up, but adds some > unpredictable GC pauses later (though it would be nice to be able to > consolidate the pauses into one collection pass). > Maybe in Elisp that's a good idea, in other lisps and other languages, second-guessing the GC is a bad idea. I hear ours is so basic that indeed it might be reasonable. Long story short, the patch I just installed, to reuse the match data, > brings the runtime down to > > Elapsed time: 0.066388s (0.050087s in 3 GCs) > That's nice! but are you sure you're not seeing noise, too? Tried other things like moving the update-score-and-face lambda out of > the mapcar loop - that didn't move a needle. If a lambda is non capturing of stuff inside the loop, only one copy of it is ever made, I think. So it doesn't suprise me. And a weird part: replacing all repeated (length str) calls with a > reference to an existing local binding makes it *slower* (back to the > original performance). Might be noise, or you might be thrashing of CPU caches, who knows? If the string length is on the same cache line as the contents of the string you're reading, then evicting that to go read the value of a boxed integer somewhere radically different is slow. Just speculation of course. Might just be noise or something else entirely. Jo=C3=A3o --0000000000007782bf05c421955f Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 6, 2021, 23:20 Dmitry Gutov <dgutov@yandex.ru> wrote:

>> And/or pick a different algorithm. E.g. Jaro-Winkler, which appare= ntly
>> is used in a lot of "fuzzy matching" implementations out= there, it's
>> pretty fast.
>
> That may be useful, but for other purposes.=C2=A0 If I understand corr= ectly,
> Jaro-Winkler is for finding the distante between two arbitrary strings= ,
> where the first in not a subsequence of the second.=C2=A0 I bet google= uses
> stuff like that when you accitendally transpose characters.=C2=A0 Flex= just
> gives up.=C2=A0 Those other others algos still catch the match (and Go= ogle
> than probably NL-scours your most intimate fears and checks with your<= /blockquote>
> local dictator before showing you typing suggestions)
=

Meant to write ML= as in machine learning, not NL.

I'm not crazy about shuffling completion, but some people did indeed as= k
for it. The filtering step has to be more complex, though (you can't just construct a straightforward regexp to filter with).

I think you calcula= te the distance using one of these fancy multi-surname algorithms , then do= cutoff somewhere.

Same result, indeed. We should note, though, that
completion-pcm--hilit-commonality has some steps that were added
together with the 'flex' style, for it to work.

But nothing algorith= mically aberrant, I think.

I did some instrumenting, replacing (completion-pcm--hilit-commonality
pattern all) inside completion-flex-all-completions with
(benchmark-progn (completion-pcm--hilit-commonality pattern all)).
Recompiled between each change (interpreted mode gives very different
numbers).

Unmodified, the call takes ~85ms:

=C2=A0 =C2=A0Elapsed time: 0.085520s (0.068406s in 4 GCs)
<= /div>


By the way, I think you should be running benchmarks multiple tim= es to get times in the seconds range, and reduce noise. Multiple levels of = CPU cache and other factors like temp thottling may skew results when runni= ng just one time.

If I comment everything inside its first lambda except the returned
value (making the function the same as #'identity), the time goes down =
to <1ms.

Uncomment the 'copy-sequence' and 'string-match' calls (whi= ch one might
suspect of garbage generation):

=C2=A0 =C2=A0Elapsed time: 0.006380s

Tried binding gc-cons-threshold to a high value, and even galling
garbage-collect-maybe (or not): that speeds it up, but adds some
unpredictable GC pauses later (though it would be nice to be able to
consolidate the pauses into one collection pass).

Maybe in Elisp that's = a good idea, in other lisps and other languages, second-guessing the GC is = a bad idea. I hear ours is so basic that indeed it might be reasonable.

=
Long story short, the patch I just installed, to reuse the match data,
brings the runtime down to

=C2=A0 =C2=A0Elapsed time: 0.066388s (0.050087s in 3 GCs)
<= /div>

That's nice! b= ut are you sure you're not seeing noise, too?
Tried other things like moving the update-score-and-face lambda out of
the mapcar loop - that didn't move a needle.

If a lambda is non capturing of= stuff inside the loop, only one copy of it is ever made, I think. So it do= esn't suprise me.

And a weird part: replacing all repeated (length str) calls with a
reference to an existing local binding makes it *slower* (back to the
original performance).

=
Might be noise, or you might be thrashing of CPU caches, = who knows? If the string length is on the same cache line as the contents o= f the string you're reading, then evicting that to go read the value of= a boxed integer somewhere radically different is slow. Just speculation of= course. Might just be noise or something else entirely.

Jo=C3=A3o
--0000000000007782bf05c421955f-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Jun 2021 01:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16230309501025 (code B ref 48841); Mon, 07 Jun 2021 01:56:02 +0000 Received: (at 48841) by debbugs.gnu.org; 7 Jun 2021 01:55:50 +0000 Received: from localhost ([127.0.0.1]:54199 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq4UX-0000GS-SN for submit@debbugs.gnu.org; Sun, 06 Jun 2021 21:55:50 -0400 Received: from mail-oi1-f181.google.com ([209.85.167.181]:45746) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq4UV-0000GE-9O for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 21:55:48 -0400 Received: by mail-oi1-f181.google.com with SMTP id w127so16495497oig.12 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 18:55:46 -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; bh=1kM4TfMW4FOkcIwsTRHxD+Y3eNN6nT8MdBgp0go9NPA=; b=Z0pc1SoTDq7sWRL0MiK4IcahyAlcqiVTUWvjz383QquSySxOFPH7CydCKj8i9OkIkU DNF/GhqwToqYXXweH/kUhBnMreukAu3WpuXI906wO/R6BtrQhajOZ4xNcHqOg9IHDco/ xOD4hVlEhgewzjVUJmWbqHjjOFfCDmOyD+InHVT4czpt0NWKVL28f3+sDt9Va5x1Pwl6 LELJn3z8RuariKXrBANkfZOpyRUlGpDG+i4h9GcZ3XaVv2M0RklnCEW/rP/dpkASt7wR Dlovp5Xj+BTCr1VA8UL99YY1ArkBlpuXw+XipgDd3tng00eTQYGz8k0FWudr2588W4co 6xOw== 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; bh=1kM4TfMW4FOkcIwsTRHxD+Y3eNN6nT8MdBgp0go9NPA=; b=Vik08H6HKxS0yTAwRJPktZVyoKqRe6M6znDj43V/56zo2geqkwBdcX4GWYzwanxPn4 RUled0WPE+So8fvcaO/c6/7JxqAFy4SL9xQM7mujLUhQ2LMtc9DImr7ZX9lqS6iVFXM0 qqi86TyD7jkLQLtvy4xT9k9PlP0J01RuzY1EBPKJ+xJ/ceH/MzTLc3E9klMEtFjtcX6u 1PT4OFHPPrFcaUYD3vgdQljBunoGB9LT8sdNBhFa6EAzCKSUxFo/QeX/KVLLKllqH42U +AWQH/6Csnz+RUgohO/3ecUlUgPe1fdgUzHOJysODWXNwDN/66eapYXXRTuOu6bwGAZx srkQ== X-Gm-Message-State: AOAM530s+6l4G1Yfy+pBwslhUGc0F6koLfl2Kj7dUhP19BPB2mvYLCr5 TfMneGUdGUKBN+XAOmjkDDaTyv1c9fdhCOC4K9VC+jX4 X-Google-Smtp-Source: ABdhPJyEYZlAGVCgEG6or1UxuvWk7c0MVYlCMBSqDQo9I4/f9i3iGRAnws90BI+zz+P6sKJOIrIsZKgHvTxOOCU9eZE= X-Received: by 2002:a17:90a:1141:: with SMTP id d1mr17522806pje.56.1623022088420; Sun, 06 Jun 2021 16:28:08 -0700 (PDT) MIME-Version: 1.0 References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87tumbv5qh.fsf@gmail.com> <5efda5a3-f7ed-ca90-9e70-b35eb1c24750@yandex.ru> <31baa0d5-02e0-368d-7946-7a3b98a8a5ca@yandex.ru> In-Reply-To: <31baa0d5-02e0-368d-7946-7a3b98a8a5ca@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 7 Jun 2021 00:27:55 +0100 Message-ID: Content-Type: multipart/alternative; boundary="0000000000000afeb505c4214748" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --0000000000000afeb505c4214748 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Sun, Jun 6, 2021, 23:21 Dmitry Gutov wrote: > On 06.06.2021 21:37, Jo=C3=A3o T=C3=A1vora wrote: > > Bottom line is that something (TM) happened to speed up the whole thing > > when I skipped over that whole part. I had vertical mode basically > > visually equivalent to vertical, but quite slower. After skipping that > > part they became practically equivalent. And you yourself witnessed thi= s > > when switching yo vertical mode, which is when the skip is made. > > Yep. > By the way, earlier I meant to write: "I had vertical mode basically visually equivalent to vertico.el, but quite slower. After skipping that part they became practically equivalent. " autocorrect on my phone had other ideas... Jo=C3=A3o --0000000000000afeb505c4214748 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Sun, Jun 6, 2021, 23:21 Dmitry Gutov <dgutov@yandex.ru> wrote:
On 06.06.2021 21:37, Jo=C3=A3o T=C3=A1vora wrote:
> Bottom line is that something (TM) happened to speed up the whole thin= g
> when I skipped over that whole part. I had vertical mode basically > visually equivalent to vertical, but quite slower.=C2=A0 After skippin= g that
> part they became practically equivalent. And you yourself witnessed th= is
> when switching yo vertical mode, which is when the skip is made.

Yep.

By the way, earlier I meant to write:

=
"I had vertic= al mode basically=C2=A0visually=C2=A0equivalent to vertico.el,=C2=A0but quite slower.=C2=A0 After skipping that=C2=A0part=C2=A0they became practically equivalent.= =C2=A0"

=C2=A0autocorrect on my= phone had other ideas...

Jo=C3=A3o
--0000000000000afeb505c4214748-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Jun 2021 02:06:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16230315512079 (code B ref 48841); Mon, 07 Jun 2021 02:06:02 +0000 Received: (at 48841) by debbugs.gnu.org; 7 Jun 2021 02:05:51 +0000 Received: from localhost ([127.0.0.1]:54223 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq4eF-0000XT-8L for submit@debbugs.gnu.org; Sun, 06 Jun 2021 22:05:51 -0400 Received: from mail-wm1-f54.google.com ([209.85.128.54]:53944) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lq4eA-0000XD-RK for 48841@debbugs.gnu.org; Sun, 06 Jun 2021 22:05:49 -0400 Received: by mail-wm1-f54.google.com with SMTP id h3so8977789wmq.3 for <48841@debbugs.gnu.org>; Sun, 06 Jun 2021 19:05:46 -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=Qh3fWlA8R0G+DuOtNzp724Hh4UwP1QBX9ubO7NjSys0=; b=GYKFAoMh0ZvWXWzJI0ATJBJXAUEl/9OqRMasjnjOYHn/AqbPVxMLvDFP/qnqLaOrSg V8NqRM07LJvI7+TXXEAZjyInWDZCF+7wh25q27F8z6C8FRqAV/SJaNnprxiR9CPSHQve eq2o7QZHoz27wX+Nv9RvH+kH0HnBvSbbWB+5ASA3FISYXYGGXUUy+2TRnSLYhdA3kFNC xCzkhTQf6rQYnkunZzM7Mse5y6bB6ebV0rkVDblUpaOgfwo2UovHGMKazqsaRjyUeyHu sFTx8uKCrkECjL86l4mM/55wYAsUcn+PpVdFPLkRwQMkfalGoCnQsPaTtW3ssfvDXhCb I0xw== 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=Qh3fWlA8R0G+DuOtNzp724Hh4UwP1QBX9ubO7NjSys0=; b=RYEWqH7Y3jFfP0M2mElva+HsrjWsaGFUJKUV1g/vC0h5GxHAZcHIxMuEj7UsTiiM8u m3j0j4zV5XqUQgWkSjzOcHsgusziGuBHgOZsJbxOiG02ukX90sEMWcj/ni+061VaaKyg MwZikZvCc3hCx0F+MdszKGen5NStSMvKiVhnI9U6nU9vMwC5xmSeh9azm+2iDmdkrJJx vpRSwjZtbx8A/KnLM2MER0hd+L14xl+6/QSz18rDolO6BqPqFIz1TkTu38mG5llxLTWC qRDd8JONCcM47w+yq3uFIbeDV81oGVK01TaKbiHfOEaU164qhur9WdxgSS3FkB+/9K4O tvZg== X-Gm-Message-State: AOAM53342/Igw7mzStdvW2dDEFZ2/TKKgKeBC+l98PWrqhe/+DoAT9Jn kYJk+yuvoVSyhcbSZM07SO+hEAPl71E= X-Google-Smtp-Source: ABdhPJxUM1oSG+JRblYXYWljouB1tbxWOZH7vDC4T/DMOyTY/hzgXS1Wm10EKmS/kOpfMDx6jEP84g== X-Received: by 2002:a1c:740b:: with SMTP id p11mr13978927wmc.94.1623024703737; Sun, 06 Jun 2021 17:11:43 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id 89sm14715741wri.94.2021.06.06.17.11.42 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 06 Jun 2021 17:11:43 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> From: Dmitry Gutov Message-ID: Date: Mon, 7 Jun 2021 03:11:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 07.06.2021 02:49, João Távora wrote: > Same result, indeed. We should note, though, that > completion-pcm--hilit-commonality has some steps that were added > together with the 'flex' style, for it to work. > > > But nothing algorithmically aberrant, I think. Just some stuff adding work to GC, I think. > By the way, I think you should be running benchmarks multiple times to > get times in the seconds range, and reduce noise. Multiple levels of CPU > cache and other factors like temp thottling may skew results when > running just one time. Yeah, I repeat the action with each version for like a few dozen times, until I see the numbers stabilize, or just take the average. > Tried binding gc-cons-threshold to a high value, and even galling > garbage-collect-maybe (or not): that speeds it up, but adds some > unpredictable GC pauses later (though it would be nice to be able to > consolidate the pauses into one collection pass). > > > Maybe in Elisp that's a good idea, in other lisps and other languages, > second-guessing the GC is a bad idea. I hear ours is so basic that > indeed it might be reasonable. I never get good results with that. > Long story short, the patch I just installed, to reuse the match data, > brings the runtime down to > >    Elapsed time: 0.066388s (0.050087s in 3 GCs) > > > That's nice! but are you sure you're not seeing noise, too? Pretty sure. > Tried other things like moving the update-score-and-face lambda out of > the mapcar loop - that didn't move a needle. > > > If a lambda is non capturing of stuff inside the loop, only one copy of > it is ever made, I think. So it doesn't suprise me. update-score-and-face references both variables in its closest binding form (score-numerator, score-denominator) and the parameter of its containing lambda (str). Maybe moving all of them to parameters and return values (making it a static function and having the caller manage state) would help, I haven't tried that exactly. > And a weird part: replacing all repeated (length str) calls with a > reference to an existing local binding makes it *slower* (back to the > original performance). > > > Might be noise, or you might be thrashing of CPU caches, who knows? If > the string length is on the same cache line as the contents of the > string you're reading, then evicting that to go read the value of a > boxed integer somewhere radically different is slow. But the string value is boxed as well, right? So the code needs to follow one indirection either way. Perhaps there's also overhead in looking up the lexical scope. I also tried using the new-and-shiny length> and length=. This simply made no measurable difference. > Just speculation of > course. Might just be noise or something else entirely. This is highly reproducible. On my machine, at least. Given how weird it is, I wouldn't just write about it without recompiling, restarting Emacs and measuring the scenario several times, with different versions of code. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 07 Jun 2021 08:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162305600410255 (code B ref 48841); Mon, 07 Jun 2021 08:54:02 +0000 Received: (at 48841) by debbugs.gnu.org; 7 Jun 2021 08:53:24 +0000 Received: from localhost ([127.0.0.1]:54427 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lqB0d-0002fK-Lp for submit@debbugs.gnu.org; Mon, 07 Jun 2021 04:53:23 -0400 Received: from mail-pf1-f177.google.com ([209.85.210.177]:41769) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lqB0b-0002f3-0i for 48841@debbugs.gnu.org; Mon, 07 Jun 2021 04:53:22 -0400 Received: by mail-pf1-f177.google.com with SMTP id x73so12576976pfc.8 for <48841@debbugs.gnu.org>; Mon, 07 Jun 2021 01:53:20 -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; bh=aM3peZxgz3qG7mfQMQnJl8cjmMJ9dxCDWM2MeMZFHAg=; b=j7Ur1G2B/HTudQdYEvzgBqDlqiUy/xTZDBsuNbNzgLTALKQlYA8TgdALNC2D+CV2u2 sBp6CPARKJLoomQMaXC3io9MJ2tjZx4l7jWb2NuREw5PNeFF4pSDMi5mBMQmjija4y4D QuH5pTtkUafPpbFU7fR1yJXiKG62p/FtPPM61arr5OOms+0ptd7cbeh1IBTD+jCHywx+ RXCTkUOqRgQg6M1lDvFlKvZ960jIr4se3V6N+RfQj8VBPa3u2pytrrJlSLY6AUILelFx vEA5bU2lMhLg2Flb+9FzciermEpvClpCpAKHjrmsVI96r+/oCx4LWMRrr1ystk/cVLhA 4jnw== 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; bh=aM3peZxgz3qG7mfQMQnJl8cjmMJ9dxCDWM2MeMZFHAg=; b=jRsXrBRBhZkCRP/LbdnXNRxsFKB3xtuPZHlviS7cHbEllbE6Q7cO131PblHeFHLmu2 h0TO1TuaDXho1eNs0buXNlOLcC4VKnmdZaKnx2RcE/bPOrI5DwoPIjhkasr5ZfO0hp6s /fA9grfgKd3xTu52bhM6K7vSjo/YCbMzZQ8TfQ+4BBmj/F6kcma8OgjX08J0/xv/d798 3OC7H13DtxFXnQj0qN1odtcKH5Y3kowM2WH6R2bL5rumjc9IQWb41zAmYyGspmdCaTli HqkpN/6K9MHQCwqWYvu4IJsiwA28/x9i8qV55Ah4GweOMnHVQrHFlElGBR9tGDWUSSFT MZZQ== X-Gm-Message-State: AOAM531mCrZNm4yiZ7k/ej2RCJZoEbNqD7iqWlVy9XfDqiV7n+lo9AnA 0AKsa2dsovEr0xmVFJTD7/Pdbi9ev/tNEzV9IAc= X-Google-Smtp-Source: ABdhPJyGCFz5qsXjNnFAQnQoiim6k0rqfmqFIHlCbAQHUuYycHJXBYw7J23G9RD4wtEwUNQ07u2Qv3sqeJLrnzqV6Zk= X-Received: by 2002:a65:63d2:: with SMTP id n18mr16905363pgv.447.1623055995062; Mon, 07 Jun 2021 01:53:15 -0700 (PDT) MIME-Version: 1.0 References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 7 Jun 2021 09:52:59 +0100 Message-ID: Content-Type: multipart/alternative; boundary="000000000000094bd205c4292c46" X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --000000000000094bd205c4292c46 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Jun 7, 2021, 01:11 Dmitry Gutov wrote: > On 07.06.2021 02:49, Jo=C3=A3o T=C3=A1vora wrote: > > > Same result, indeed. We should note, though, that > > completion-pcm--hilit-commonality has some steps that were added > > together with the 'flex' style, for it to work. > > > > > > But nothing algorithmically aberrant, I think. > > Just some stuff adding work to GC, I think. > O(n) stuff being a property and a number on each string, small in comparison to the string. Maybe moving all of them to parameters and return values (making it a > static function and having the caller manage state) would help, I > haven't tried that exactly. > Normally, in those adventures you end up with the same allocations somewhere else, and uglier code. But you can try. > Might be noise, or you might be thrashing of CPU caches, who knows? If > > the string length is on the same cache line as the contents of the > > string you're reading, then evicting that to go read the value of a > > boxed integer somewhere radically different is slow. > > But the string value is boxed as well, right? The key is locality. If the string length and data happen to live nearby in memory (in the same box, so to speak), there's a decent chance that reading one brings the other into the cache, and you get a nice hit depending on your subsequent operation. Here I'm just speculating, as I said. In managed languages such as Lisps, it's somewhat unpredictable. It's also always hardware dependent. Though given C/C++, a known processor and the right application, this will make a world of a difference, and will yield truly "weird" results (which arent weird at all after you understand the logic). Like, for example a vector being much better at sorted insertion than a linked list. (!) Look it up. Bjarne Stroustrup has one of those talks. Jo=C3=A3o --000000000000094bd205c4292c46 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Mon, Jun 7, 2021, 01:11 Dmitry Gutov <dgutov@yandex.ru> wrote:
On 07.06.2021 02:49, Jo=C3=A3o T=C3=A1vora wrote:

>=C2=A0 =C2=A0 =C2=A0Same result, indeed. We should note, though, that >=C2=A0 =C2=A0 =C2=A0completion-pcm--hilit-commonality has some steps th= at were added
>=C2=A0 =C2=A0 =C2=A0together with the 'flex' style, for it to w= ork.
>
>
> But nothing algorithmically aberrant, I think.

Just some stuff adding work to GC, I think.

O(n) stuff being a property and = a number on each string, small in comparison to the string.

Maybe moving all of them to parameters and return values (making it a
static function and having the caller manage state) would help, I
haven't tried that exactly.

Normally, in those adventures you end up wit= h the same allocations somewhere else, and uglier code. But you can try.

> Might be noise, or you might be thrashing of CPU caches, who knows? If=
> the string length is on the same cache line as the contents of the > string you're reading, then evicting that to go read the value of = a
> boxed integer somewhere radically different is slow.

But the string value is boxed as well, right?=C2=A0

The key is locality. If the = string length and data happen to live nearby in memory (in the same box, so= to speak), there's a decent chance that reading one brings the other i= nto the cache, and you get a nice hit depending on your subsequent operatio= n.=C2=A0

Here I'm ju= st speculating, as I said. In managed languages such as Lisps, it's som= ewhat unpredictable. It's also always hardware dependent. Though given = C/C++, a known processor and the right application, this will make a world = of a difference, and will yield truly "weird" results (which aren= t weird at all after you understand the logic). Like, for example a vector = being much better at sorted insertion than a linked list. (!) Look it up. B= jarne Stroustrup has one of those talks.

<= div dir=3D"auto">Jo=C3=A3o

--000000000000094bd205c4292c46-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jun 2021 02:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16233779558520 (code B ref 48841); Fri, 11 Jun 2021 02:20:02 +0000 Received: (at 48841) by debbugs.gnu.org; 11 Jun 2021 02:19:15 +0000 Received: from localhost ([127.0.0.1]:37923 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrWlP-0002DL-Bj for submit@debbugs.gnu.org; Thu, 10 Jun 2021 22:19:15 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:41546) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrWlM-0002D8-0X for 48841@debbugs.gnu.org; Thu, 10 Jun 2021 22:19:14 -0400 Received: by mail-wr1-f46.google.com with SMTP id o3so4294788wri.8 for <48841@debbugs.gnu.org>; Thu, 10 Jun 2021 19:19:11 -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; bh=wj5EuA8ANQmlPd2nPzxl3lhKoHqXxF0/XggB9vFIOoY=; b=Ga6QZ3Yyi3s7iQojdKhvk9qo57ReFABYTy7xG1nxrhI2MXtHPnIcnyJJyQ1sC6IF52 AvyWa7bjGi3xhqmNcXZrmJTjuv7MwG+sc7UU0ScpUHpmSbqJJB52aO45FzNS0n8OGEUQ hKRUTLi28pcTwKyzMYwjYzIX1vY4LIfPp8Nt1gnT9GfR1ykVxxvOXkhkAj5Jl09vrsQy y8zTFWiaurC2IM7RxtTOgaBS4d0N+gDfW6kH6BngGpRNI0qXzKsDXkLEIHl8SvQSx+b/ uS37aY/WkYB44qWmAta4aEHPVBdNUF21OhLsEhldWagsSWk2fyjhDXSWiG2tQ2k74WyB cZ+g== 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; bh=wj5EuA8ANQmlPd2nPzxl3lhKoHqXxF0/XggB9vFIOoY=; b=nHgPIjozb0UwMc30gMbhMt/FCWE54yfVnMo/nDwubadmtVGSevgimqZxmMkuWEtPVS o3Rdz7+5X0yBfxmQyABKlnbZFzWMVLhzoACqGeEKiX+GDFDRW16UvsB57JgkYJqTKghr V6H9Sgo0abeNZyuzYi+2DMM9CBUMsda3z+O/U9h5VKgBxgNbgcT5y4QpJ9aJjQ8wpL/J bPfsKHzqsIlvCkFU/dsPETHJsEUgPDUqChAgUBcJSBZ0jH88eOysnYctcSBWBxKsjpW9 XoRpr3C3OyH/TQ2SHNyXmGZ1m5alY10TKLnrvJRwrsUbc+L0wHqRK9m7kax/q9qqSvsY dJKA== X-Gm-Message-State: AOAM530VF5BzJwL9sCGF0W6Tk5rsC4WuVo3hQFCBHTQ047fcM/6KPYDX MW1R9ByP3trK2UeZxcHSFxxd4Qrn6k4= X-Google-Smtp-Source: ABdhPJyAKBusvaaIqK80+XSE7+FozrzXuD4eABDRQj7bsk8td6+cmaILw8Cdxl/Gx8vDQNfu3j7YvA== X-Received: by 2002:adf:d1c9:: with SMTP id b9mr1242584wrd.101.1623377945937; Thu, 10 Jun 2021 19:19:05 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id k8sm5327836wrp.3.2021.06.10.19.19.04 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Thu, 10 Jun 2021 19:19:04 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> From: Dmitry Gutov Message-ID: <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> Date: Fri, 11 Jun 2021 05:19:03 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------F6E563123C8DCDF34497F7F5" Content-Language: en-US X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) This is a multi-part message in MIME format. --------------F6E563123C8DCDF34497F7F5 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit On 07.06.2021 11:52, João Távora wrote: > Maybe moving all of them to parameters and return values (making it a > static function and having the caller manage state) would help, I > haven't tried that exactly. > > > Normally, in those adventures you end up with the same allocations > somewhere else, and uglier code. But you can try. I have it a try, with little success (patch attached, for posterity). Since there's no multiple value returns in Lisp, I had to define a container for the three values. The performance is basically the same, which seems to indicate that either Elisp has to allocate very little for a compiled lambda code, or it's optimized out (which would also make sense: the only thing necessary for it is a new container for the current scope). > > Might be noise, or you might be thrashing of CPU caches, who > knows? If > > the string length is on the same cache line as the contents of the > > string you're reading, then evicting that to go read the value of a > > boxed integer somewhere radically different is slow. > > But the string value is boxed as well, right? > > > The key is locality. If the string length and data happen to live nearby > in memory (in the same box, so to speak), there's a decent chance that > reading one brings the other into the cache, and you get a nice hit > depending on your subsequent operation. > > Here I'm just speculating, as I said. In managed languages such as > Lisps, it's somewhat unpredictable. It's also always hardware dependent. > Though given C/C++, a known processor and the right application, this > will make a world of a difference, and will yield truly "weird" results > (which arent weird at all after you understand the logic). Like, for > example a vector being much better at sorted insertion than a linked > list. (!) Look it up. Bjarne Stroustrup has one of those talks. When you have to do some work, better memory locality can indeed change a lot. But in this case we have an already computed value vs. something the code still needs to compute, however fast that is. Accessing function arguments must be currently much faster than looking up the current scope defined with 'let'. Anyway, looking at what else could be removed, now that the extra allocation in 'match-data' is gone, what really speeds it up 2x-11x (depending on whether GC kicks in, but it more often doesn't), is commenting out the line: (setq str (copy-sequence str)) So if it were possible to rearrange completion-pcm--hilit-commonality not to have to modify the strings (probably removing the function altogether?), that would improve the potential performance of c-a-p-f quite a bit, for fido-mode and other frontends (depending on how much overhead the other layers add). Ultimately, the scoring information doesn't have to live in the text properties. For sorting, the frontend could allocate a hash table, then ask the [backends? styles?] for completion scores on each item and sort based on that. Since faces are needed only for the completions that are currently displayed, even having to repeat the regexp matching stuff for each of them later would be no big deal performance-wise, compared to the current approach. Anyway, these are musing for the much-discussed future iteration of the API. With the current version, and tied by backward compatibility, it might be possible to wring 10ms of improvement by consolidating text property changes somehow, but likely no more than that. Looking forward for your analysis of fido-vertical-mode's performance improvement over the "normal" one. --------------F6E563123C8DCDF34497F7F5 Content-Type: text/x-patch; charset=UTF-8; name="completion-pcm-score-struct.diff" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename="completion-pcm-score-struct.diff" diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index d5a0118b7c..0cb247fc19 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3485,6 +3485,7 @@ completion-pcm--hilit-commonality (let* ((re (completion-pcm--pattern->regex pattern 'group)) (point-idx (completion-pcm--pattern-point-idx pattern)) (case-fold-search completion-ignore-case) + (score (make-vector 3 0)) last-md) (mapcar (lambda (str) @@ -3531,37 +3532,17 @@ completion-pcm--hilit-commonality ;; (SUM_across_i(hole_i_contrib) + 1) * len ;; ;; , where "len" is the string's length. - (score-numerator 0) - (score-denominator 0) - (last-b 0) - (update-score-and-face - (lambda (a b) - "Update score and face given match range (A B)." - (add-face-text-property a b - 'completions-common-part - nil str) - (setq - score-numerator (+ score-numerator (- b a))) - (unless (or (= a last-b) - (zerop last-b) - (= a (length str))) - (setq - score-denominator (+ score-denominator - 1 - (expt (- a last-b 1) - (/ 1.0 - flex-score-match-tightness))))) - (setq - last-b b)))) + ) + (fillarray score 0) (while md - (funcall update-score-and-face from (pop md)) + (completion-pcm--update-score-and-face str from (pop md) score) (setq from (pop md))) ;; If `pattern' doesn't have an explicit trailing any, the ;; regex `re' won't produce match data representing the ;; region after the match. We need to account to account ;; for that extra bit of match (bug#42149). (unless (= from match-end) - (funcall update-score-and-face from match-end)) + (completion-pcm--update-score-and-face str from match-end score)) (if (> (length str) pos) (add-face-text-property pos (1+ pos) @@ -3570,10 +3551,35 @@ completion-pcm--hilit-commonality (unless (zerop (length str)) (put-text-property 0 1 'completion-score - (/ score-numerator (* end (1+ score-denominator)) 1.0) str))) + (/ (completion-pcm--score-numerator score) + (* end (1+ (completion-pcm--score-denominator score))) + 1.0) + str))) str) completions)))) +(cl-defstruct (completion-pcm--score (:type vector)) + (numerator 0) (denominator 0) (last-b 0)) + +(defun completion-pcm--update-score-and-face (str a b score) + "Update score and face in STR given match range (A B)." + (add-face-text-property a b + 'completions-common-part + nil str) + (let ((last-b (completion-pcm--score-last-b score))) + (setf (completion-pcm--score-numerator score) + (+ (completion-pcm--score-numerator score) (- b a))) + (unless (or (= a last-b) + (zerop last-b) + (= a (length str))) + (setf (completion-pcm--score-denominator score) + (+ (completion-pcm--score-denominator score) + 1 + (expt (- a last-b 1) + (/ 1.0 + flex-score-match-tightness))))) + (setf (completion-pcm--score-last-b score) b))) + (defun completion-pcm--find-all-completions (string table pred point &optional filter) "Find all completions for STRING at POINT in TABLE, satisfying PRED. @@ -3980,7 +3986,7 @@ completion-flex-all-completions string table pred point #'completion-flex--make-flex-pattern))) (when all - (nconc (completion-pcm--hilit-commonality pattern all) + (nconc (benchmark-progn (completion-pcm--hilit-commonality pattern all)) (length prefix)))))) ;; Initials completion --------------F6E563123C8DCDF34497F7F5-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jun 2021 17:10:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162343135830827 (code B ref 48841); Fri, 11 Jun 2021 17:10:02 +0000 Received: (at 48841) by debbugs.gnu.org; 11 Jun 2021 17:09:18 +0000 Received: from localhost ([127.0.0.1]:39863 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrkej-000819-Kb for submit@debbugs.gnu.org; Fri, 11 Jun 2021 13:09:18 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:35525) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrkeg-00080t-K4 for 48841@debbugs.gnu.org; Fri, 11 Jun 2021 13:09:16 -0400 Received: by mail-wr1-f45.google.com with SMTP id m18so6831653wrv.2 for <48841@debbugs.gnu.org>; Fri, 11 Jun 2021 10:09:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=KP0ZmxByNAbqDds4hVyYLDCrRC7HWkwWxEbZN4U21dE=; b=IxwOq0MqgHBxQIa9Nbvzevl15fMIkC0wd10uHBh9iYhdH1smNwOWi5pTDhSMDY9aEf Um6y3tBm5skqCpw9m3LDV2XyrrlSUfS13WM953qIVOlYvkM9C+wvaIbe37EQC2IbXHCJ 4doUdckmyOaCBFRYp6J1k5xL4yVSgMsEgeuYQFBOC4dXs2QwmI77y389W3EMG5xntKdf fgGUBaFrTxzcHiZp9uSmYg5IGwxaj49xeAJX1EyhPTa5d6hhdcYwMaI6hjxwfWCmJR09 z0dDUlml7nzYU5gIwNrMSyOlSItgarQF268IgjkKZ/SsEMG3ZGiKuhz0dVPgq4oK9O1u pelg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=KP0ZmxByNAbqDds4hVyYLDCrRC7HWkwWxEbZN4U21dE=; b=I0ARhDf0rhUUOrdlm0O/rGoNuVotVi4V7+D6nmbio2/xSeYPvDC+yMcoo+RRoiRxnC zZ9bnW3KluM00zkd4YWlxmkIuX61dAI54aNDkIWjPoB6olVFhcyMd3/43d2aYd8uN8RO /88l50R/R2QvAdirLyr7UKBsDqARR5up+LqQoTEz9rsC68HvrWl+DudDZECKYfU6Z9IZ RX44LGsYmu/Hggm2Ci8FXp8SBjPxy/QtyrSyY7ZsrGi7pppmQcCKdvKcESyC43nLmiaz Xygmtnq9FnM0q9W75FMYnw3tocWzSLFwgd28w6OnSKcgfw9UHEz0bS/vgdWbTdjnYJoT 5Vhw== X-Gm-Message-State: AOAM532KVo12RPGxbNKI0ASnQEiZaBPpivBU5rziLXvi7DZU0jWEfoC4 L/5SU+VMQOIDlYTXWV24n2mYyr7jpsg= X-Google-Smtp-Source: ABdhPJzjhQ/Wu+gV0Z6S0LXtfeORPQmffKHmFomPAF7eIOtItueJJDnNxVjJxIA1xgKK4DUD9hUuLg== X-Received: by 2002:a5d:4089:: with SMTP id o9mr5202889wrp.195.1623431348187; Fri, 11 Jun 2021 10:09:08 -0700 (PDT) Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id c7sm7775820wrs.23.2021.06.11.10.09.06 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Jun 2021 10:09:07 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> Date: Fri, 11 Jun 2021 18:09:04 +0100 In-Reply-To: <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> (Dmitry Gutov's message of "Fri, 11 Jun 2021 05:19:03 +0300") Message-ID: <87mtrwuy4v.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 07.06.2021 11:52, Jo=C3=A3o T=C3=A1vora wrote: > >> Maybe moving all of them to parameters and return values (making it a >> static function and having the caller manage state) would help, I >> haven't tried that exactly. >> Normally, in those adventures you end up with the same allocations >> somewhere else, and uglier code. But you can try. > > I have it a try, with little success (patch attached, for > posterity). Since there's no multiple value returns in Lisp, I had to > define a container for the three values. And if there were multiple value, you can bet the container for them wouldn't be free ;-) > The performance is basically the same, which seems to indicate that > either Elisp has to allocate very little for a compiled lambda code, > or it's optimized out (which would also make sense: the only thing > necessary for it is a new container for the current scope). Which lambda are we talking about? Is it ` update-score-and-face`? If so, I would guess that the capture of `score-denominator` is what takes space, and that space is no bigger than another variable in that let scope. >> Though given C/C++, a known processor and the right application, >> this will make a world of a difference, and will yield truly "weird" >> results (which arent weird at all after you understand the >> logic). Like, for example a vector being much better at sorted >> insertion than a linked list. (!) Look it up. Bjarne Stroustrup has >> one of those talks. > When you have to do some work, better memory locality can indeed > change a lot. But in this case we have an already computed value > vs. something the code still needs to compute, however fast that is. But `length` of a string, in any sane string implementation, _is_ accessing "an already computed value". Which likely lives just besides the data. In Emacs, it seems to be two pointers (8 bytes) apart from the data. In a system with 64bytes of L1/2/3 cache it still theoretically makes up to 52 bytes come in "for free" after you read the length. But to be honest I tried a bit and haven't come up with benchmarks to help confirm -- or help dispel -- this theory. Maybe you can distill your "weird" experiment down to a code snippet? > Accessing function arguments must be currently much faster than > looking up the current scope defined with 'let'. In a compiled CL system, I would expect the former to use the stack, and the to use the heap, but it wouldn't make any difference in reading the variable's value, I think. But Elisp is byte-compiled, not natively compiled (except for that thing now, haven't tried it), and i don't understand how the byte-compiler chooses byte-codes so all bets are off. > Anyway, looking at what else could be removed, now that the extra > allocation in 'match-data' is gone, what really speeds it up 2x-11x > (depending on whether GC kicks in, but it more often doesn't), is > commenting out the line: > > (setq str (copy-sequence str)) > > So if it were possible to rearrange completion-pcm--hilit-commonality > not to have to modify the strings (probably removing the function > altogether?), that would improve the potential performance of c-a-p-f > quite a bit, for fido-mode and other frontends (depending on how much > overhead the other layers add). Very interesting. I don't know what the matter is with modifying the string itself. Is it because we want to protect its 'face' property? Maybe, but what's the harm in chaning it? Maybe Stefan knows. Stefan, are you reading this far? If we do want to protect the shared 'face' property -- and only 'face' -- then we could very add some other property about face that the frontend could read "just in time" before it itself makes a copy of the string to display to the user.=20=20 This technique appears to be slightly simpler than using the hash-table indirection you propose (we would need something like that if, for some reason, we absolutely could not touch the string's property list.) > Anyway, these are musing for the much-discussed future iteration of > the API. With the current version, and tied by backward compatibility, Maybe I'm missing something, but I don't see why my above idea requires changing _that_ much of the API (a bit would change yes). It's a matter of letting frontends opt-out of the current readily-available face-propertized completions and opt-into a display-time facility that does this propertization.=20 But if the speedup is big, I'd revisit the rationale for requiring those copies to be performed in the first place. In my (very brief) testing it doesn't hurt a bit to remove it. > Looking forward for your analysis of fido-vertical-mode's performance > improvement over the "normal" one. Will take a look now. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jun 2021 22:36:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162345091213172 (code B ref 48841); Fri, 11 Jun 2021 22:36:01 +0000 Received: (at 48841) by debbugs.gnu.org; 11 Jun 2021 22:35:12 +0000 Received: from localhost ([127.0.0.1]:40050 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrpk7-0003QO-Op for submit@debbugs.gnu.org; Fri, 11 Jun 2021 18:35:12 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:34523) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrpk2-0003Pu-SZ for 48841@debbugs.gnu.org; Fri, 11 Jun 2021 18:35:10 -0400 Received: by mail-wr1-f49.google.com with SMTP id q5so7537744wrm.1 for <48841@debbugs.gnu.org>; Fri, 11 Jun 2021 15:35:06 -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=kspJlPrvXJdmD+apw3Q6OZ2yPlWxQjMirT12OsZA0hg=; b=OQGl49CdAH6Go60KdmG6PnK27eIDYFNiR5EBaZTltwl/udUo3kgG3y5DrmOvmXWTge 9cQtzvfdTNC9pCagEqhXFcnTDUyEA1ViEH7DWzWLwT0fcLpeJRIJlwSbFpSzK80jq0xP 21hvlFkbJi/FjWORY4VRRlhGg9F0atUccoD5ghP9BGninwuPDDUdBS3nu+/H++sJtV42 aaqjTus+CuBgVXhx3ZvYCUs+2m/BKz4DPMQpMv2oNSe5whkYeXmCWL9ISihmMlpKYcmf Pmjx6K+Y6uANtbWYXSKvqutkAYR0VtniiQ+yVo6nuRYKiQx8vW37PurymUZ+V2OLqs+X GmUw== 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=kspJlPrvXJdmD+apw3Q6OZ2yPlWxQjMirT12OsZA0hg=; b=bnJK1rJqRKcIXs1SqTSGEt2MHggY5YCmvP8vg1XEIBlr3yxJBsc12+M5GARI8gDfWN 5KLJmCiAxHesesj9tcEroGOj+HfLHbyMTDfRBVLVAkUEUlz8U07k0gHxAmvs8yi8iEUu U+TciY355IzMprIrT+lOkxV8nj8ZSRv6yYwoMXFSn6p6sPEAuhSq0/t5yu4R4lPLJRB2 9D19WvUmy9asg+1IDNbnprannSN3WqHIzvUpVstBfyzslEWwAPRttaiLfoeI6g5PHmIO wcVuTI+uVGFLxwx2Ucm7Ohuet7Eu0gjq0efjOmz9VHgDHWA/exVszTgrNSUj7JtglSaw TAQA== X-Gm-Message-State: AOAM533oFDg0yGBdEUyjl8pJJe2df+nyB/1OmU+x0oGUWAOptMEPkxJS YloXY/Fgx9K/Wri40mzZb56UKCzIVMw= X-Google-Smtp-Source: ABdhPJyTIHSjLiq2jPnVEdwKGvMLvCT0Yf/NlWk8zeOuCWYAgzufkmGYgsLgKEmzFHNyK5H3/DPPag== X-Received: by 2002:adf:fc90:: with SMTP id g16mr6234159wrr.183.1623450900970; Fri, 11 Jun 2021 15:35:00 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b188sm17934050wmh.18.2021.06.11.15.34.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Jun 2021 15:35:00 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <87mtrwuy4v.fsf@gmail.com> From: Dmitry Gutov Message-ID: <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> Date: Sat, 12 Jun 2021 01:34:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87mtrwuy4v.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 11.06.2021 20:09, João Távora wrote: >> The performance is basically the same, which seems to indicate that >> either Elisp has to allocate very little for a compiled lambda code, >> or it's optimized out (which would also make sense: the only thing >> necessary for it is a new container for the current scope). > > Which lambda are we talking about? Is it ` update-score-and-face`? If > so, I would guess that the capture of `score-denominator` is what takes > space, and that space is no bigger than another variable in that let > scope. Yes, that one. > But `length` of a string, in any sane string implementation, _is_ > accessing "an already computed value". Which likely lives just besides > the data. In Emacs, it seems to be two pointers (8 bytes) apart from > the data. In a system with 64bytes of L1/2/3 cache it still > theoretically makes up to 52 bytes come in "for free" after you read the > length. But to be honest I tried a bit and haven't come up with > benchmarks to help confirm -- or help dispel -- this theory. Maybe you > can distill your "weird" experiment down to a code snippet? I've tried reproducing the effect with a small snippet, and failed. :-( >> Anyway, looking at what else could be removed, now that the extra >> allocation in 'match-data' is gone, what really speeds it up 2x-11x >> (depending on whether GC kicks in, but it more often doesn't), is >> commenting out the line: >> >> (setq str (copy-sequence str)) >> >> So if it were possible to rearrange completion-pcm--hilit-commonality >> not to have to modify the strings (probably removing the function >> altogether?), that would improve the potential performance of c-a-p-f >> quite a bit, for fido-mode and other frontends (depending on how much >> overhead the other layers add). > > Very interesting. I don't know what the matter is with modifying the > string itself. Is it because we want to protect its 'face' property? > Maybe, but what's the harm in chaning it? I imagine it's just a "correctness" thing. Text properties are part of the string's identity. We add text properties, so we make a copy because we don't own the original list (it might be saved to some constant and also used for, I don't know, IMenu items?) > If we do want to protect the shared 'face' property -- and only 'face' > -- then we could very add some other property about face that the > frontend could read "just in time" before it itself makes a copy of the > string to display to the user. Yes, it's an option (though a less elegant one): apply some namespaced text properties with the necessary data. And then we'd also be able to fontify "just in time". Do we have any "frozen strings" in Emacs, which absolutely could not be modified? Do we plan to? > This technique appears to be slightly simpler than using the hash-table > indirection you propose (we would need something like that if, for some > reason, we absolutely could not touch the string's property list.) I disagree it's a simpler technique, but it would indeed be a simpler change, based on the current implementation. >> Anyway, these are musing for the much-discussed future iteration of >> the API. With the current version, and tied by backward compatibility, > > Maybe I'm missing something, but I don't see why my above idea requires > changing _that_ much of the API (a bit would change yes). It's a matter > of letting frontends opt-out of the current readily-available > face-propertized completions and opt-into a display-time facility that > does this propertization. Even your version is a breaking enough change to be a pain, but possibly not beneficial enough to bother all consumers with, until we also add some more awaited features, I guess. But I don't mind it myself, and happy to update Company. Either way it's a step forward. > But if the speedup is big, I'd revisit the rationale for requiring those > copies to be performed in the first place. With fido-vertical-mode, and with that particular input, it's Elapsed time: 0.130773s (0.031547s in 1 GCs) without copy-sequence, and Elapsed time: 0.169842s (0.069740s in 4 GCs) with it. Not game changing, but definitely measurable. > In my (very brief) testing > it doesn't hurt a bit to remove it. Same. But it likely depends on where the strings came from. In the most usual case, of course, they are created at runtime. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jun 2021 22:42:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162345128513804 (code B ref 48841); Fri, 11 Jun 2021 22:42:01 +0000 Received: (at 48841) by debbugs.gnu.org; 11 Jun 2021 22:41:25 +0000 Received: from localhost ([127.0.0.1]:40061 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrpq8-0003aa-Q0 for submit@debbugs.gnu.org; Fri, 11 Jun 2021 18:41:24 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:53242) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrpq6-0003aL-IV for 48841@debbugs.gnu.org; Fri, 11 Jun 2021 18:41:23 -0400 Received: by mail-wm1-f46.google.com with SMTP id f17so8834773wmf.2 for <48841@debbugs.gnu.org>; Fri, 11 Jun 2021 15:41:22 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:from:to:cc:references:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=jfhXKxQOai75JSAaNGZfViGvrT0Dku9BLtNhYohe66M=; b=H72uMg1MzK7S5/IHWFNtm5macohAiJ/T64pUuaAUcmAWaV0KaJUo2vgyCybVTGGPcg iYl3eclkDVmgNRT0dZuubZBood+XXSazhhvY1RNBAjF9p5MIn8VUBqjy6wN9bTIr/Cos HTVBEQETkSjDBNQJ2u/5lMHfdUXWBUcXhZ44FxGzO8s0yUc1YLmLgEWk6BThO3hnF6Uy dP5wSFzP8O1u7v04LwKNvUjSnf5JheWQY3AP0AxEK9SMfmrvENURgjTBNTCt5H1TEOZ9 h0ylp/QQvYCAhchPKBlQ9sV8csSdAfXOOdNw7lmZKYf2cIIqkZRAoC6GTNTezHvtHsGN rwGw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:from:to:cc:references:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=jfhXKxQOai75JSAaNGZfViGvrT0Dku9BLtNhYohe66M=; b=JiYqWbIaQDbVVkLr0es1TCHWeFhfIk1T3bflnFcFvGptPjARhZj1oJaE1nhGEdSpzt YcEUNbdK616Tq/o5etfF/l23i+ChyxFHCIjWHTtckBF6mPrZq8gFPPYFjcmI8zGA2m4V obs7BtoLDcDlgxw6KJWi2uVDzV8mw+zZm7nKG3c8i6DZYvUm0y4zT9/lVmPh1LdI8KsA 7CzqF2ZI+VSk/flfhl+nsi3lsLlVSOaDe76w5ZJorFYdU/nZW4vRsvRGGLZXsF8g8ABG 2UuVaJVYvSfQnxGB4104DsCeRhBRqhMYbZ2Q0t2kFNhIIMyu+1fA0N8GTC/U7ajvF8yc IgXg== X-Gm-Message-State: AOAM5310V5V0qHi3vtOVwBumIKpm47GBE7DjBsu5a7z/6BV/l0NJQgVY 0QNiCOmwT2P/Sf/ljR8IGytDBE/QNBs= X-Google-Smtp-Source: ABdhPJwm/dk5wm3sXswV8Bv2kl0G2R+RYEwulNIaA2qG6e+pXLCl39IC1V02Zo4JHkeJUGIhgj6bnA== X-Received: by 2002:a05:600c:350a:: with SMTP id h10mr5973464wmq.164.1623451276629; Fri, 11 Jun 2021 15:41:16 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id z10sm7639811wmb.26.2021.06.11.15.41.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Jun 2021 15:41:16 -0700 (PDT) From: Dmitry Gutov References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <87mtrwuy4v.fsf@gmail.com> <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> Message-ID: Date: Sat, 12 Jun 2021 01:41:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 12.06.2021 01:34, Dmitry Gutov wrote: > With fido-vertical-mode, and with that particular input, it's > >   Elapsed time: 0.130773s (0.031547s in 1 GCs) > > without copy-sequence, and > >   Elapsed time: 0.169842s (0.069740s in 4 GCs) > > with it. Not game changing, but definitely measurable. it = icomplete-completions' runtime From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 11 Jun 2021 23:26:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162345390517711 (code B ref 48841); Fri, 11 Jun 2021 23:26:01 +0000 Received: (at 48841) by debbugs.gnu.org; 11 Jun 2021 23:25:05 +0000 Received: from localhost ([127.0.0.1]:40093 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrqWP-0004bb-Et for submit@debbugs.gnu.org; Fri, 11 Jun 2021 19:25:05 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:45643) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrqWL-0004b3-9r for 48841@debbugs.gnu.org; Fri, 11 Jun 2021 19:25:04 -0400 Received: by mail-wr1-f46.google.com with SMTP id z8so7608090wrp.12 for <48841@debbugs.gnu.org>; Fri, 11 Jun 2021 16:25:01 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=5N8MJefkkErbcKL3yt1Q9vafvlkOrDRcc5cHNlYH3oY=; b=jeyOO9w1HnpyeEhKZyftSZine1TmaS4L9p66qbGLXRFkLcwQwSAgAbGJGkzh1flYXQ MLDOV4H4p5CdyardbSHAzFJJHNRZ8N7EdBykA5urMsG+1xQzqEVpaIVvPfRZII1YljdT WMxcjz4r3QlehQQFNUo2ydulnWjjnu/M92lN6FJWz4Qc4wm1Mbuk1oGDZUi1HBbrR6fq j716JyUB9tT/pUBqEc3d79cZG0OTUV13VXcQbxRPNJui+rlDXxDAUOIjiCM3UcKKbTxi sIxXy3ZRkaG9FvFvOLtMwNw/08j3WVSM2HlVgYRxtJAoezbML984HSHIQkdYSey/35Pp lUgA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=5N8MJefkkErbcKL3yt1Q9vafvlkOrDRcc5cHNlYH3oY=; b=JD32P5REqmK63ApRmFwl9rIq0NWGMm/S29P+VQ9+eCds9nRHdt6j30eSns6V4ti+Tg jCky4PmyJAN7F9zxvCZo+vI92buQwOppRkg6iFo6YsfIdWP+XZSNRNHGawb2EUfWQSO3 mK2S7jLvH5xYdNkkKO6MnQBgrlr2Cy3g4Uww+O49psJMTbiNHTT0DasOJ0bxLZ+qXyOa CahAfpwhaJfY4fR4Jt6LjWvk+gmX1LJs/7Di0YVS+03BmcpE3c2OeyMeZpkBYbjHJfE1 VD2SEn49wDPfXqlXt4lANgA9gowmz9JlxS46D6qK9p3YPYPG2oak7GzfH+JmtffbpKvZ 9lQw== X-Gm-Message-State: AOAM5312Mn/jJjaw+uN4zlMQyK/kNFQjiotvYGrV7Yn47nEQ1wcrv3EB E68j80oPBflCVFoO7YM9FKpxUW4byao= X-Google-Smtp-Source: ABdhPJxcLF9/4xNfprXm4s7vfV6ECLMSUL/8ckGimzRmb0spQkzfecuh7yWXfVptjshBsnMuxm/05g== X-Received: by 2002:a5d:4d4d:: with SMTP id a13mr6516012wru.33.1623453895006; Fri, 11 Jun 2021 16:24:55 -0700 (PDT) Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id p15sm2767773wmq.43.2021.06.11.16.24.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Fri, 11 Jun 2021 16:24:54 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> Date: Sat, 12 Jun 2021 00:24:52 +0100 In-Reply-To: <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> (Dmitry Gutov's message of "Fri, 11 Jun 2021 05:19:03 +0300") Message-ID: <878s3gugqj.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > Looking forward for your analysis of fido-vertical-mode's performance > improvement over the "normal" one. So, I benchmarked before and after this patch to icomplete.el: diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 08b4ef2030..3561ebfa04 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -858,16 +858,8 @@ icomplete-completions ;; removing making `comps' a proper list. (base-size (prog1 (cdr last) (if last (setcdr last nil)))) - (most-try - (if (and base-size (> base-size 0)) - (completion-try-completion - name candidates predicate (length name) md) - ;; If the `comps' are 0-based, the result should be - ;; the same with `comps'. - (completion-try-completion - name comps nil (length name) md))) - (most (if (consp most-try) (car most-try) - (if most-try (car comps) ""))) + (most-try nil) + (most "") ;; Compare name and most, so we can determine if name is ;; a prefix of most, or something else. (compare (compare-strings name nil nil The patch itself nullifies the calculation of the 'determ' thing that I and presumably some other users don't value that much. It doesn't affect fido-mode's basic funcionality. How did I benchmark? Well, to measure the delay the user experiences until all completions are presented I had to take out the `while-no-input` in icomplete-exhibit so that this test would work: ;; After the form, type C-u C-x C-e C-m in quick succession (benchmark-run (completing-read "bla" obarray)) If I don't remove this `while-no-input`, icomplete will not lose time showing all the completions and will instead select just the first one. That's a very nice feature for actual use, but for this benchmark that is not what I want: I want to measure the time to show all the completions. Then, the times presented by benchmark-run are the same that the user sees if he waits to see the completions. Now the values: Before my patch: (1.802209488 5 1.3678843490000077) (1.609066281 4 1.1170432569999775) (1.878972079 5 1.3725165670000479) (1.901952581 5 1.3979494059999524) (1.820800064 5 1.3283940110000003) After the patch: (0.552051921 1 0.3079724459999511) (0.58396499 1 0.3038616050000087) (0.861106587 2 0.6046198220000178) (0.611551175 1 0.30275532399997473) (0.62500199 1 0.3160454470000218) Without the patch but with icomplete-vertical-mode: (0.645366711 1 0.3412892389999911) (0.6256968110000001 1 0.3234302760000105) (0.9716317630000001 2 0.6676939319999633) (0.6414442749999999 1 0.3325084230000357) (0.627684562 1 0.32241421699995954) Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 12 Jun 2021 00:44:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162345863424715 (code B ref 48841); Sat, 12 Jun 2021 00:44:01 +0000 Received: (at 48841) by debbugs.gnu.org; 12 Jun 2021 00:43:54 +0000 Received: from localhost ([127.0.0.1]:40122 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrrkf-0006QZ-TT for submit@debbugs.gnu.org; Fri, 11 Jun 2021 20:43:54 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:34393) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lrrkd-0006QK-7E for 48841@debbugs.gnu.org; Fri, 11 Jun 2021 20:43:52 -0400 Received: by mail-wr1-f51.google.com with SMTP id q5so7729166wrm.1 for <48841@debbugs.gnu.org>; Fri, 11 Jun 2021 17:43:51 -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=pmAjKVCdbcmleM697UMZh8BoBJqY0GBHaUmnU8e9u5c=; b=e/ByEfoP5a72FCwYwwqyrzLboifymVYLa5iQJj4RO8GJQ5qL5C4VDJnljoB5FVTfOT zLrdWQBkaQYQmw5RAdKKnbL0ffcHtjfb9FAbqxSecIk02/DWvD2o6cgERxhbSy9mjz9z 9E2uFJAaVAddE6Wi/XkXX2yjUBoBCNVxfNDiNQXocKCzvAQRI6feeZhhBrrPcgdaZBT5 1cWVM404cj7gkJHC+PFNIsJb91unM8hMXLHj+u+GZw7tApx4u37ZvFRij+jTBNkomJM9 HVDCxGUEWheF5KCvRu16+zzSVhcEVaz/pqP0EVGiE/pz/5TJ5EdABj1KV7+pOk3HyKFk fSEQ== 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=pmAjKVCdbcmleM697UMZh8BoBJqY0GBHaUmnU8e9u5c=; b=Vn+HxpAFdN5wWvXawGV8fk79afAJbQ/ukaj+6b/zz3UmJhRhpgtQB51lQLvXVQqS5u CnZSXFEl+k5KY1Cw5wz3XGXUOZGNv6J8SwXGBbWSRV0/TRPb7LBd3axV+R9dX5taL+3f vdAzdYlPbtPsRyCXAno9SAv8NtpO5xpVo4nz60i59Uqv2oeSCLWj1FkDXlaCjYFmpY95 2R1yKAmQZIidOXwkWsRr5XDOw5MsZqPyAYhiASORgpx2i1ut+34akJs+ep/Os0+Tek9Y aHWcs1LvWyQGRM5RzzVAxT62zLuM0gMhqLUg2wD/TnRC7ej8XsV/vfO+MMv81EwwCSLZ BxuA== X-Gm-Message-State: AOAM530QtHVhBxe/L26oOT/VQX6BeqkiUBALyZi5yd2cFpkMCRnX0IaT ma1yw7+5efmizrVGHDhlBE+aexjrQ0c= X-Google-Smtp-Source: ABdhPJw1RrHBjEXdE+Fo1GHbEVdlMze+chzZC1h3bt+C4w15ub7zHnsUrUC3hL41s2rO+VQnkGqTXg== X-Received: by 2002:a5d:48ce:: with SMTP id p14mr6725793wrs.170.1623458625046; Fri, 11 Jun 2021 17:43:45 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l9sm7411716wme.21.2021.06.11.17.43.43 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 11 Jun 2021 17:43:44 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <878s3gugqj.fsf@gmail.com> From: Dmitry Gutov Message-ID: Date: Sat, 12 Jun 2021 03:43:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <878s3gugqj.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 12.06.2021 02:24, João Távora wrote: > Dmitry Gutov writes: > >> Looking forward for your analysis of fido-vertical-mode's performance >> improvement over the "normal" one. > > So, I benchmarked before and after this patch to icomplete.el: > > diff --git a/lisp/icomplete.el b/lisp/icomplete.el > index 08b4ef2030..3561ebfa04 100644 > --- a/lisp/icomplete.el > +++ b/lisp/icomplete.el > @@ -858,16 +858,8 @@ icomplete-completions > ;; removing making `comps' a proper list. > (base-size (prog1 (cdr last) > (if last (setcdr last nil)))) > - (most-try > - (if (and base-size (> base-size 0)) > - (completion-try-completion > - name candidates predicate (length name) md) > - ;; If the `comps' are 0-based, the result should be > - ;; the same with `comps'. > - (completion-try-completion > - name comps nil (length name) md))) > - (most (if (consp most-try) (car most-try) > - (if most-try (car comps) ""))) > + (most-try nil) > + (most "") > ;; Compare name and most, so we can determine if name is > ;; a prefix of most, or something else. > (compare (compare-strings name nil nil All right, so this is not about try-completion, it's about completion-try-completion. That makes sense. > The patch itself nullifies the calculation of the 'determ' thing that I > and presumably some other users don't value that much. It doesn't > affect fido-mode's basic funcionality. > > How did I benchmark? Well, to measure the delay the user experiences > until all completions are presented I had to take out the > `while-no-input` in icomplete-exhibit so that this test would work: > > ;; After the form, type C-u C-x C-e C-m in quick succession > (benchmark-run (completing-read "bla" obarray)) > > If I don't remove this `while-no-input`, icomplete will not lose time > showing all the completions and will instead select just the first one. > That's a very nice feature for actual use, but for this benchmark that > is not what I want: I want to measure the time to show all the > completions. Did the same, can repro. > Then, the times presented by benchmark-run are the same that the user > sees if he waits to see the completions. Now the values: > > Before my patch: > > (1.802209488 5 1.3678843490000077) > (1.609066281 4 1.1170432569999775) > (1.878972079 5 1.3725165670000479) > (1.901952581 5 1.3979494059999524) > (1.820800064 5 1.3283940110000003) > > After the patch: > > (0.552051921 1 0.3079724459999511) > (0.58396499 1 0.3038616050000087) > (0.861106587 2 0.6046198220000178) > (0.611551175 1 0.30275532399997473) > (0.62500199 1 0.3160454470000218) I get (0.377195885 10 0.24448539800000013) before and (0.245218061 6 0.1390041310000001) after. A solid improvement. BTW, if I just stick benchmark-progn around icomplete-completions like diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 08b4ef2030..b9fe3e1836 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -678,12 +678,13 @@ icomplete-exhibit ;; seems to trigger it fairly often! (while-no-input-ignore-events '(selection-request)) (text (while-no-input - (icomplete-completions - field-string - (icomplete--completion-table) - (icomplete--completion-predicate) - (if (window-minibuffer-p) - (eq minibuffer--require-match t))))) + (benchmark-progn + (icomplete-completions + field-string + (icomplete--completion-table) + (icomplete--completion-predicate) + (if (window-minibuffer-p) + (eq minibuffer--require-match t)))))) (buffer-undo-list t) deactivate-mark) ;; Do nothing if while-no-input was aborted. ...it reports Elapsed time: 0.329006s (0.246073s in 10 GCs) vs Elapsed time: 0.169200s (0.113762s in 5 GCs) I suppose the 40-70ms difference is due to delay in typing. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jun 2021 14:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162359458620166 (code B ref 48841); Sun, 13 Jun 2021 14:30:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Jun 2021 14:29:46 +0000 Received: from localhost ([127.0.0.1]:44176 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsR7R-0005FB-UZ for submit@debbugs.gnu.org; Sun, 13 Jun 2021 10:29:46 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:38711) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsR7P-0005Ex-E1 for 48841@debbugs.gnu.org; Sun, 13 Jun 2021 10:29:44 -0400 Received: by mail-wm1-f51.google.com with SMTP id t4-20020a1c77040000b029019d22d84ebdso11305501wmi.3 for <48841@debbugs.gnu.org>; Sun, 13 Jun 2021 07:29:43 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=/R8iY8ERrZ3TRuY7uXH+hyClzItdnd/yDz57yx2q/8g=; b=A82QEDikrlKbVAF+TvxrkOfzgp6lK+S5ZI42UCCZtoTnQcYMkgwpKCqOoPV3VCqmGQ 3fSnSDwvt0t9jOGsO1iOC4ROpFbU0cPfops5Eub0c++A75VFRpOplCw+1axJN7whEo80 +i+Bt6dYl/iIWm8Y7mmpvfnNqoqK4CPVlcSN6SJ2rilGoWM7rzJiPxQmQwPJgyYxetWq sc3u/v5RzZCQfutoenwGJBx6rb3WyPTiuP0cP1uUnV7yELnlGvBKPnEtqtiiuioZDxzd xhBkDMHGy8XptD5oIDZTJSZABprsglL58maAdr3MEwCNHHnbBY3RkJxScwrjjZ8ml3Ds 3W3Q== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=/R8iY8ERrZ3TRuY7uXH+hyClzItdnd/yDz57yx2q/8g=; b=KbsQP8rC3E8oH+mIFBdFAIqKtVSrtHcbGX92klUsqZG1JtN3FxOkQJ4RUo8Zc655YB N884SZdALl9sMKMsqYeyGtUDlWlY7gN9VOo/6ZDB54+zAotu37O8JNpCU7Gh1374Abez F2Gmn5v4+WQ90Qv+r3kRzjRCi//Dmb3TPbMWeOsYADNAZ0SPQKdgUBEe239vVNPMBUpt kTwWqZy6a6YGGjeDE7HGgk6aSS2l0ShcvQvnySl1AUoLyte2RHB6B/ChzEQgNbpK4VKh S8xyHxleKGSs7qusBY0+qhaQ3WJ7zJjxV2WYRDMfpr9XheUkBfVbkHykwTb0RYpXKA8x QSEg== X-Gm-Message-State: AOAM532TkXDiJaoxRnTb7alDw4vZGgEJtxfJ8Km7y4u5EzF3C/Z4xl3y GiGgnI4GzLJ9tYgPFqZwM6xQvO4+fmg= X-Google-Smtp-Source: ABdhPJzBqzlRg3ZavlOoWI1jLe6YxFHExs+27Z4Pz1+HGeUv7SwGCIurWUecS732LgQxCyQtaTSRyA== X-Received: by 2002:a7b:c4d2:: with SMTP id g18mr11946303wmk.25.1623594577064; Sun, 13 Jun 2021 07:29:37 -0700 (PDT) Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id l9sm11008989wme.21.2021.06.13.07.29.35 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Jun 2021 07:29:36 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <878s3gugqj.fsf@gmail.com> Date: Sun, 13 Jun 2021 15:29:33 +0100 In-Reply-To: (Dmitry Gutov's message of "Sat, 12 Jun 2021 03:43:43 +0300") Message-ID: <87zgvtu9bm.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 12.06.2021 02:24, Jo=C3=A3o T=C3=A1vora wrote: >> Dmitry Gutov writes: >>=20 >>> Looking forward for your analysis of fido-vertical-mode's performance >>> improvement over the "normal" one. >> So, I benchmarked before and after this patch to icomplete.el: >> diff --git a/lisp/icomplete.el b/lisp/icomplete.el >> index 08b4ef2030..3561ebfa04 100644 >> --- a/lisp/icomplete.el >> +++ b/lisp/icomplete.el >> @@ -858,16 +858,8 @@ icomplete-completions >> ;; removing making `comps' a proper list. >> (base-size (prog1 (cdr last) >> (if last (setcdr last nil)))) >> - (most-try >> - (if (and base-size (> base-size 0)) >> - (completion-try-completion >> - name candidates predicate (length name) md) >> - ;; If the `comps' are 0-based, the result should= be >> - ;; the same with `comps'. >> - (completion-try-completion >> - name comps nil (length name) md))) >> - (most (if (consp most-try) (car most-try) >> - (if most-try (car comps) ""))) >> + (most-try nil) >> + (most "") >> ;; Compare name and most, so we can determine if na= me is >> ;; a prefix of most, or something else. >> (compare (compare-strings name nil nil > > All right, so this is not about try-completion, it's about > completion-try-completion. That makes sense. Yeah, to be honest, once I'm done actually using these functions I immediately evict the differences between try-completion, completion-try-completion, try-try-completion-completion, or any of these yoda-speak variations from my mental cache.=20=20 Here I meant is that there was something apparently useless and slow (to fido-mode at least) going on in that else branch. > Elapsed time: 0.329006s (0.246073s in 10 GCs) > > vs > > Elapsed time: 0.169200s (0.113762s in 5 GCs) > > I suppose the 40-70ms difference is due to delay in typing. No idea. In my (slower?) system, I typed C-u C-x C-e C-m pretty fast. Presumably the C-m goes in before pp-eval-last-sexp has a chance to read more input so I wouldn't think it's a delay in typing. I could investigate, but since your measurements confirm the same tendency anyway, I think this simple patch is what's needed to close this issue. diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 08b4ef2030..5d37f47e7d 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -859,13 +859,14 @@ icomplete-completions (base-size (prog1 (cdr last) (if last (setcdr last nil)))) (most-try - (if (and base-size (> base-size 0)) - (completion-try-completion - name candidates predicate (length name) md) - ;; If the `comps' are 0-based, the result should be - ;; the same with `comps'. - (completion-try-completion - name comps nil (length name) md))) + (and (not fido-mode) ; Fido avoids these expensive calcula= tions. + (if (and base-size (> base-size 0)) + (completion-try-completion + name candidates predicate (length name) md) + ;; If the `comps' are 0-based, the result should be + ;; the same with `comps'. + (completion-try-completion + name comps nil (length name) md)))) (most (if (consp most-try) (car most-try) (if most-try (car comps) ""))) ;; Compare name and most, so we can determine if name is Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 13 Jun 2021 14:56:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162359614822834 (code B ref 48841); Sun, 13 Jun 2021 14:56:01 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Jun 2021 14:55:48 +0000 Received: from localhost ([127.0.0.1]:44203 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsRWe-0005wE-Bq for submit@debbugs.gnu.org; Sun, 13 Jun 2021 10:55:48 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:38592) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsRWc-0005w1-BN for 48841@debbugs.gnu.org; Sun, 13 Jun 2021 10:55:47 -0400 Received: by mail-wm1-f50.google.com with SMTP id t4-20020a1c77040000b029019d22d84ebdso11327636wmi.3 for <48841@debbugs.gnu.org>; Sun, 13 Jun 2021 07:55:46 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=MOKm0vFEiIKTy8tfYfBBuh3DzPkLjD/0sBF+RuwSlGQ=; b=XbQbwz9ZVWYNSf35VBpNKFggP9GmcZCUTzqX3FXnoubXnzc4bya5w92Px0GGHycnIu OjbtKi7ZcgFShehVN7DmlbYg6qKPIhkFFbOWuYvMEA1Uqw3EWYkbPQ18k327cOOxx0By pfO8UXRpbxA9lk3TVvR/bWSSdvAy0Te4/TYOETu4KvCMjDdRoHg+lgJjgdH0k/6TamSW cmQTF4IJFS9UbMXtoSrOFiCuc8SVMasyHW2Rs7BAsr86Y5pGurPPjuhMaFZcpNlW683L kRO0BybvgX3Rwa429I9FqA1+FzNFh9ml4cmHfXEhATB/f1EhMn7b2e7vMgaVfwGLaCC5 1XQQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=MOKm0vFEiIKTy8tfYfBBuh3DzPkLjD/0sBF+RuwSlGQ=; b=duEP5aILDEpcq4N8uJ/+fkv1eU09qmmR7tAWAZ14bVriOxFx2klrLhYHr4N65WeR6A 4GYkjb3Rrl5ykplWnY6op561psoEIorprlWuJpVdpDOMs3i2cHMj9wcEgSH129QFdsaj DYHYgiv19S+7Hc2OKHRFkz/hs3KgjGMGmypz/Xk+uapVVPhmqULsCXjPQj3UTxyHPE5K 1E5Lc9qFZeFpjHrWL+8ierfgsJOOz0/OC0ZTwrE4v3H5h9fUk6c7TmNZb+3hmKLZbXlM EUvoHtjg+Q6wGR1xk9yN7swvs51tAdU2uHfDS9vQqWzstK8XVg2vIJoxO09pk4aRV96N isBA== X-Gm-Message-State: AOAM531MQqDP5cGpQDoa27ArqAJJP5NTnbnaddHa2opJS0xGDuaSVL9C tRlnnNDSZDS9zLaScOLnFwk2sAHenEg= X-Google-Smtp-Source: ABdhPJzKOLtzHnREKmS+Ci0XpPwJhYMs++RDyTi9nnlEYxUKJLufD+HFAhhCOdeQtxwHfjZw4swBxw== X-Received: by 2002:a7b:c2f0:: with SMTP id e16mr12056591wmk.136.1623596140035; Sun, 13 Jun 2021 07:55:40 -0700 (PDT) Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id q19sm9239717wmf.22.2021.06.13.07.55.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 13 Jun 2021 07:55:39 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <87mtrwuy4v.fsf@gmail.com> <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> Date: Sun, 13 Jun 2021 15:55:38 +0100 In-Reply-To: <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> (Dmitry Gutov's message of "Sat, 12 Jun 2021 01:34:58 +0300") Message-ID: <87v96hu845.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: >> Very interesting. I don't know what the matter is with modifying >> the >> string itself. Is it because we want to protect its 'face' property? >> Maybe, but what's the harm in chaning it? > > I imagine it's just a "correctness" thing. Text properties are part of > the string's identity. We add text properties, so we make a copy > because we don't own the original list (it might be saved to some > constant and also used for, I don't know, IMenu items?) I just confirmed it's not for correctness. If one foregoes the copy, in fido-mode a C-h f followed by some input followed by C-g and an M-x and no input (empty pattern) will show interesting results, i.e. a list of propertized strings when nothing should be propertized. But maybe that's a question of removing the propertization when the pattern is empty? I'll try later. >> If we do want to protect the shared 'face' property -- and only 'face' >> -- then we could very add some other property about face that the >> frontend could read "just in time" before it itself makes a copy of the >> string to display to the user. > > Yes, it's an option (though a less elegant one): apply some namespaced > text properties with the necessary data. And then we'd also be able to > fontify "just in time". > > Do we have any "frozen strings" in Emacs, which absolutely could not > be modified? Do we plan to? Immutable strings? And error when one tries to? Or just ignore the modification? And how would that help here? > I disagree it's a simpler technique, but it would indeed be a simpler > change, based on the current implementation. simpler means simpler in my book :-) > But I don't mind it myself, and happy to update Company. Either way > it's a step forward. If Company and fido-mode and a couple more outside the core/Elpa are all that's needed, it's probably warranted. But there are so many frontends right now, I don't know... We'd need some "opt into the optimization", I think." >> But if the speedup is big, I'd revisit the rationale for requiring those >> copies to be performed in the first place. > > With fido-vertical-mode, and with that particular input, it's > > Elapsed time: 0.130773s (0.031547s in 1 GCs) > > without copy-sequence, and > > Elapsed time: 0.169842s (0.069740s in 4 GCs) > > with it. Not game changing, but definitely measurable. I don't have these results. I tried the previous experiment: ;; C-u C-x C-e C-m in quick succession (benchmark-run (completing-read "bla" obarray)) And turned icomplete.el's while-no-input into a progn. In an Emacs -Q where (length (all-completions "" obarray)) is about 20000. ;; with copy (0.39647753 6 0.22811240199999983) (0.431950471 7 0.263988651) (0.451116177 6 0.2249686070000001) =20=20=20=20 ;; without copy, small but measurable speedup (0.29890632 2 0.08419541699999966) (0.293501099 2 0.08622194699999985) (0.306566633 3 0.0853211100000002) In a loaded Emacs where (length (all-completions "" obarray)) is 64554 ;; with copy (2.869362171 6 2.3882547280000495) (2.909661303 6 2.4209153659999743) (2.845522439 6 2.3638140250000106) =20=20=20=20 ;; without copy. Huge speedup. (0.79817337 1 0.4526993239999797) (0.8231736510000001 1 0.4752496449999626) (0.719004478 1 0.4016016420000028) Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Jun 2021 00:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162362930328003 (code B ref 48841); Mon, 14 Jun 2021 00:09:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Jun 2021 00:08:23 +0000 Received: from localhost ([127.0.0.1]:44560 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsa9O-0007Hb-Mv for submit@debbugs.gnu.org; Sun, 13 Jun 2021 20:08:22 -0400 Received: from mail-wm1-f46.google.com ([209.85.128.46]:36647) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsa9N-0007HO-Ad for 48841@debbugs.gnu.org; Sun, 13 Jun 2021 20:08:21 -0400 Received: by mail-wm1-f46.google.com with SMTP id h11-20020a05600c350bb02901b59c28e8b4so11319933wmq.1 for <48841@debbugs.gnu.org>; Sun, 13 Jun 2021 17:08:21 -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=i9VUk7Qg3o9sOcj66Z8h+fz53TKbup8aW0SSsBcvg7I=; b=OPYkHaQbEq4JQJc8zrxHjhq2GD3ggHeuanlV/DzjTqSFUXipATMb9f+tkuhJRoUun2 13/dbz33XA0xm6lI/TU5Wr8UhLkTVlw47sN4zpcMNsd1EQmynN4gLN57e5J3ImHSGnwO wFSNcsMk1H7pQI87+YsXm/mYrPosIYVW+uiH2fIbgkPEDi1h9/A4OMi63L2fRXfkE/aQ f92ysdqJrqe2KZ/OwKG731PslklorGQ4cXA2/vgQk3PXPt6nVe6eqnQrU/w4EezZ39yh yQ6ei+gycfQKOiw5ptGex3KYC42sp7Vrk33DPEluGts4hin92OhLwKt0OG4UyDUPPbpP Kv8w== 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=i9VUk7Qg3o9sOcj66Z8h+fz53TKbup8aW0SSsBcvg7I=; b=D/3q0s7Gz48kSl6bvpQI8VYpYq+CLcXx24RrUzgEgaCh+kkMCAj8aK067oO6EK+We+ OwtMHcQeEajvnzKWDlNgs0ZC0IEN8LyrXyHbTRnS/BpF2++r7+57vua/BOOa8pmOro1h 0U2gjyQH8dDNmyIyR68l6rE25W4g01KCibr4dUoysz3icLIHO/Pj73p5ikxKd2yum37W 1ovgdY6FtvSX/idOt8JY6dHgUpwFx60WZp1McbmMAdQNJE/uH91/f7FRHeRQucEWk8QY KM9eLD5rkMWrmjMotp8fVgCYFOovN8sTAnahFC/QQhmd5ULcSSpybQIr6LOUWMXcmrHM vsEQ== X-Gm-Message-State: AOAM532MOPDbhW1YWnoBPFd8WOiX+jKcNpZRzLLEZcwR2bj71qssu8Gm LLg5VmbuSvSu1IlV5fwiIEhSXeHj0CM= X-Google-Smtp-Source: ABdhPJw9oWkie5K5umnB+eV9Qcc7JL56nZwJV0Akwv27crz/JvVpA1vEIDihzkd+grLKbP5qpv99jw== X-Received: by 2002:a05:600c:a45:: with SMTP id c5mr12709081wmq.153.1623629295376; Sun, 13 Jun 2021 17:08:15 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id g23sm17016678wmk.3.2021.06.13.17.08.14 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 13 Jun 2021 17:08:14 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <878s3gugqj.fsf@gmail.com> <87zgvtu9bm.fsf@gmail.com> From: Dmitry Gutov Message-ID: <033e12e5-86e2-cb0c-ac8b-6753b96fa4b2@yandex.ru> Date: Mon, 14 Jun 2021 03:08:13 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87zgvtu9bm.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 13.06.2021 17:29, João Távora wrote: > Yeah, to be honest, once I'm done actually using these functions I > immediately evict the differences between try-completion, > completion-try-completion, try-try-completion-completion, or any of > these yoda-speak variations from my mental cache. > > Here I meant is that there was something apparently useless and slow (to > fido-mode at least) going on in that else branch. And there it was! >> Elapsed time: 0.329006s (0.246073s in 10 GCs) >> >> vs >> >> Elapsed time: 0.169200s (0.113762s in 5 GCs) >> >> I suppose the 40-70ms difference is due to delay in typing. > > No idea. In my (slower?) system, I typed C-u C-x C-e C-m pretty fast. > Presumably the C-m goes in before pp-eval-last-sexp has a chance to read > more input so I wouldn't think it's a delay in typing. Some input latency must be there, of course it depends on how fast Emacs is handling the previous events, how fast the machine is, etc. Anyway, I was just describing an easier way to benchmark the same effect (without having to hit the key sequence very quickly). Hope you or someone else find it useful. > I could > investigate, but since your measurements confirm the same tendency > anyway, I think this simple patch is what's needed to close this issue. Haven't tested it myself, but it looks like it will almost certainly work. > diff --git a/lisp/icomplete.el b/lisp/icomplete.el > index 08b4ef2030..5d37f47e7d 100644 > --- a/lisp/icomplete.el > +++ b/lisp/icomplete.el > @@ -859,13 +859,14 @@ icomplete-completions > (base-size (prog1 (cdr last) > (if last (setcdr last nil)))) > (most-try > - (if (and base-size (> base-size 0)) > - (completion-try-completion > - name candidates predicate (length name) md) > - ;; If the `comps' are 0-based, the result should be > - ;; the same with `comps'. > - (completion-try-completion > - name comps nil (length name) md))) > + (and (not fido-mode) ; Fido avoids these expensive calculations. Perhaps predicate it on the value of icomplete-hide-common-prefix instead? fido-mode sets it to nil, and this way we retain a better level of abstraction, and better backward compatibility for vanilla icomplete-mode users. Next step might be switching this var's default value to nil. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 14 Jun 2021 00:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162362980228731 (code B ref 48841); Mon, 14 Jun 2021 00:17:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Jun 2021 00:16:42 +0000 Received: from localhost ([127.0.0.1]:44564 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsaHS-0007TL-K1 for submit@debbugs.gnu.org; Sun, 13 Jun 2021 20:16:42 -0400 Received: from mail-pj1-f41.google.com ([209.85.216.41]:55044) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lsaHQ-0007T7-A9 for 48841@debbugs.gnu.org; Sun, 13 Jun 2021 20:16:41 -0400 Received: by mail-pj1-f41.google.com with SMTP id g24so8728081pji.4 for <48841@debbugs.gnu.org>; Sun, 13 Jun 2021 17:16:40 -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=e/yaLscUPfQmX08lEvydOCLfeRZsw4reqb/MeMB4q6s=; b=RHqcz8udoh0W+oNmrAOJGERMvqkw+R1ChGWcdUqsnUTejsABF+Uik0ZHBHe82PFGIL V0rtHNDxdovqOmJ2F6xdtf352tgC/ifCwKLqOWF/+ACnEpJHSdwIik7GggWFUIs7kosG jNWs6ehmi6xvPYkMZcxRZJgBj8yd83mkGiZ84uC5DkHP6wp9usFLpSuCzV6Tn/ZGlShU e2COqZs3cr8U3KTxLXXhNeeAzVjBIwSOR43U/sp2Wxe8lPHIB3WgpYRfLb5UhHypvlY6 KRHnXJ3EisMqGj052Fcrg3VB9ziCIcOu63pb+wYCXwXVemiyn/ZwFypMl+T6PHjFpThM vbcQ== 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=e/yaLscUPfQmX08lEvydOCLfeRZsw4reqb/MeMB4q6s=; b=Kz80yu4gTn+8osf1XloQ8lUqnCGctuRs7gsyykhe5qFNCNBPTTiav3ZnkWlQNlZ136 2FUw/AcRruCDLCMNMmoNjCwJ0gLbMdCafUsvNJtWzzURrFaq+AhiuZ10hwjRUdS6pkqH goB2Fdd+8TRPn0ByELudzZk30csPXOcH/wzG1ofjBPyN00SO9tBuNV1ZcQCudKNm/gQI CRfQxrNbI7PxB6fQsoPcGzm4J0J/Ds512WCleSuIL5D3NvmE64Z0mXzfBmfSaVyz6yXT 4f1NVKpv43kurzzxhMeHYcKl1RwAG9NYcAhNLX9YMEJjjQYikues+VqrhBXlfVHxyQiS /QiA== X-Gm-Message-State: AOAM5301eDouVCOLEiQpxww7mSdm8YHzFVR0f1JBJZzkrxFqPpOsnzUQ uFS/rZHr8CLKrJUzuiV2wuefhUiAYtoEcU4XJo0= X-Google-Smtp-Source: ABdhPJwdKOnxDBd2frT5pjOIxbeYw9W/CRpz6VCo6XT5s7N6An6+1wXT124UtDq2OnQmCU3nW+uMh02laPTvLJD28VQ= X-Received: by 2002:a17:90a:6e07:: with SMTP id b7mr20302192pjk.7.1623629794574; Sun, 13 Jun 2021 17:16:34 -0700 (PDT) MIME-Version: 1.0 References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <878s3gugqj.fsf@gmail.com> <87zgvtu9bm.fsf@gmail.com> <033e12e5-86e2-cb0c-ac8b-6753b96fa4b2@yandex.ru> In-Reply-To: <033e12e5-86e2-cb0c-ac8b-6753b96fa4b2@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 14 Jun 2021 01:16:23 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Jun 14, 2021 at 1:08 AM Dmitry Gutov wrote: > Anyway, I was just describing an easier way to benchmark the same effect > (without having to hit the key sequence very quickly). Hope you or > someone else find it useful. Yes. It is useful. I didn't know about benchmark-progn. > > I could > > investigate, but since your measurements confirm the same tendency > > anyway, I think this simple patch is what's needed to close this issue. > > Haven't tested it myself, but it looks like it will almost certainly work= . > > > diff --git a/lisp/icomplete.el b/lisp/icomplete.el > > index 08b4ef2030..5d37f47e7d 100644 > > --- a/lisp/icomplete.el > > +++ b/lisp/icomplete.el > > @@ -859,13 +859,14 @@ icomplete-completions > > (base-size (prog1 (cdr last) > > (if last (setcdr last nil)))) > > (most-try > > - (if (and base-size (> base-size 0)) > > - (completion-try-completion > > - name candidates predicate (length name) md) > > - ;; If the `comps' are 0-based, the result should be > > - ;; the same with `comps'. > > - (completion-try-completion > > - name comps nil (length name) md))) > > + (and (not fido-mode) ; Fido avoids these expensive cal= culations. > > Perhaps predicate it on the value of icomplete-hide-common-prefix instead= ? > > fido-mode sets it to nil, and this way we retain a better level of > abstraction, and better backward compatibility for vanilla > icomplete-mode users. This is a good idea, the level of abstraction. But what is this "common prefix" anyway? Is it the the same as the "determ" thing, or the "[mplete...] dance" as I called it earlier. Shouldn't fido-mode then _hide_ it? I'm confused, but if you're not, go ahead and make that more abstract change instead of relying on fido-mode. > Next step might be switching this var's default value to nil. Also confused, but no objections. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jun 2021 02:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162389664316224 (code B ref 48841); Thu, 17 Jun 2021 02:25:02 +0000 Received: (at 48841) by debbugs.gnu.org; 17 Jun 2021 02:24:03 +0000 Received: from localhost ([127.0.0.1]:53569 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lthhL-0004Db-5c for submit@debbugs.gnu.org; Wed, 16 Jun 2021 22:24:03 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:35661) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lthhK-0004D5-1i for 48841@debbugs.gnu.org; Wed, 16 Jun 2021 22:24:02 -0400 Received: by mail-wm1-f45.google.com with SMTP id o39-20020a05600c5127b02901d23584fd9bso2474103wms.0 for <48841@debbugs.gnu.org>; Wed, 16 Jun 2021 19:24:02 -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=5Wk59ATAthGiUvW1ihcv+1BOgjM0MwXfUCBJokeYIBY=; b=Fe/265fWNdnCDbP71tXObxdb5THku2P3Dfli0p3vqI85bXklL81o+j4HsCL54Va73H FbSExDP9KQ4ZksVfOrAcE3y4nOPlsmAKyANZuomyBBOLb9kAIfbtfR7hLhcafinjBKa6 8E2yrGDNHfBHW9/hQ1mxKCUiz95MTy6vQEkQPhBg2wS7i7NNLnwE3M1gJlH3P24sMmEd K493AsKBxbMtunIBSML88PHXZNPf6EWoupfnCMD4bovOABOBq3oE058zV5V1b3o7Zx/+ nfyXH4Vh8UDguP3MhHjR4w7TXUH1i+tGy09bmy4/BSFfEexe/+UM3Djh57lznc0Bm39N J1SQ== 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=5Wk59ATAthGiUvW1ihcv+1BOgjM0MwXfUCBJokeYIBY=; b=hcCaNdrbXg7ZftMjunFah6u1vn4X6PAiZwQ8VYadwBnfzPgWLWyC0LysKQThlPAPzE iZXW7Gt49LWlS+pcs//jVgwhelpzZcsF/b42M/9rbLhYT9aUZqk8oYhTdj0diIjA7zLV OGw08ZuewNi1HFOIfNg0+i1w3GESG3dOMqlC4lNMPWtBHenKc+mx70zdQb1/2ypYv7S1 bGH9jrpcvTHGn+L73QpG1OCAFmr19h2LdYQl4DuSqzcXPtyi1sSpZBlJHZ9tYBixSGO9 KV4xBfe+3SDspuqFUYroue6o7sxIoAHHLicXhPKDK/dDCuxXoUfDPAg0kyPWxo/ieWxz BCqg== X-Gm-Message-State: AOAM530nwo/qMSdO+xw0AofjpwsrRJ4Q0XxdJi2/rILwfzgYZtGxaiVs tDo5p7X0OQ7FLuqJkRvimr00XtsoJAs= X-Google-Smtp-Source: ABdhPJzttqT822jGQbY8HET5xQTq78tFechMoeXLpEAKj+TiLagJyq8cfS4hE7kz/Qk3lQPDGmyCrw== X-Received: by 2002:a05:600c:358b:: with SMTP id p11mr2154206wmq.112.1623896636085; Wed, 16 Jun 2021 19:23:56 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id w23sm6917457wmi.0.2021.06.16.19.23.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 19:23:55 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <878s3gugqj.fsf@gmail.com> <87zgvtu9bm.fsf@gmail.com> <033e12e5-86e2-cb0c-ac8b-6753b96fa4b2@yandex.ru> From: Dmitry Gutov Message-ID: <33224e9c-2185-29c0-5aa9-f798b2f3ccaf@yandex.ru> Date: Thu, 17 Jun 2021 05:23:53 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 14.06.2021 03:16, João Távora wrote: >> Perhaps predicate it on the value of icomplete-hide-common-prefix instead? >> >> fido-mode sets it to nil, and this way we retain a better level of >> abstraction, and better backward compatibility for vanilla >> icomplete-mode users. > This is a good idea, the level of abstraction. But what is this > "common prefix" anyway? Is it the the same as the "determ" > thing, or the "[mplete...] dance" as I called it earlier. Shouldn't > fido-mode then_hide_ it? > > I'm confused, but if you're not, go ahead and make that more > abstract change instead of relying on fido-mode. So... it's a bit more complex than that. The 'most' value computes the biggest "fuzzy" match (taking into account completion styles) and bases the resulting display of the "single match" on that. Before your patch the output could look like: starfshe|(...t-file-process-shell-command) [Matched] with the patch it's much less informative: starfshe| [Matched] ...so it has value, whether the variable I mentioned above is t or nil. It seems there are two ways to proceed from here: - Just alter the printing logic in the "single match" case to print the match text in full is it's not equal to the input string. I haven't puzzled out the logic doing that yet. - Try to keep the current behavior while avoiding the duplicate work. About the latter option: the result of that most-try stuff is only useful when there is only one match, right? But that work is performed unconditionally. Unless I'm missing something and the value does see some use in the multiple-matches situations, the patch below both keeps the current behavior and gives the same performance improvement: diff --git a/lisp/icomplete.el b/lisp/icomplete.el index 08b4ef2030..fc88e2a3e0 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -859,13 +859,14 @@ icomplete-completions (base-size (prog1 (cdr last) (if last (setcdr last nil)))) (most-try - (if (and base-size (> base-size 0)) + (unless (cdr comps) + (if (and base-size (> base-size 0)) + (completion-try-completion + name candidates predicate (length name) md) + ;; If the `comps' are 0-based, the result should be + ;; the same with `comps'. (completion-try-completion - name candidates predicate (length name) md) - ;; If the `comps' are 0-based, the result should be - ;; the same with `comps'. - (completion-try-completion - name comps nil (length name) md))) + name comps nil (length name) md)))) (most (if (consp most-try) (car most-try) (if most-try (car comps) ""))) ;; Compare name and most, so we can determine if name is From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jun 2021 02:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162389741117450 (code B ref 48841); Thu, 17 Jun 2021 02:37:02 +0000 Received: (at 48841) by debbugs.gnu.org; 17 Jun 2021 02:36:51 +0000 Received: from localhost ([127.0.0.1]:53574 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lthti-0004XN-F7 for submit@debbugs.gnu.org; Wed, 16 Jun 2021 22:36:50 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:43829) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lthtg-0004X9-SD for 48841@debbugs.gnu.org; Wed, 16 Jun 2021 22:36:49 -0400 Received: by mail-wr1-f46.google.com with SMTP id r9so4817595wrz.10 for <48841@debbugs.gnu.org>; Wed, 16 Jun 2021 19:36:48 -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=5/nwz58rPyP5tD1djpKtzlcG+IBLdenjg0bZJ54OcBI=; b=TdtYRU78cdhYKejiqjW2w0qlVG7Wuj2JuXxQ8eNIvHMqTvkFwHL0rzdb4TVcLcIZ8U ka11ghSUO0KIEi0o1lGpRBN45r9blFn/h7M5yWROLqa2i38W4elECGF59ebWqpw+iXEX 38Ef4HHh/RsHM8SZNHpOH/3lfrBbsfK28fmQRNy9S7Jx/GTj8WnG6zLwQx87Q6UjLR6n kh6hV4QQLOfUotdlwZpH5zbF3yHfpE0ijj29HQsxgsLrZZhlWnYM+AydZfISRYHK1DTi BsZKLBWHCBYqHjS5RdjCHTAQfCmh0+62s2AvtWRZdMBlUfbvKju2r6j/9NWRezTHB05J aUqg== 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=5/nwz58rPyP5tD1djpKtzlcG+IBLdenjg0bZJ54OcBI=; b=FC4SKm88M6ingqrY5L56b2Ya/I8TEqpIgnfrnnM9thOImNqXvma1NYpPMDVKzmMrlR Wa7Lf7ifq4Gmmr9nCOAl33vgejronsCUWsWl9Ms5nT+ZNN2EvomSHW1/KloEyXNBLaaA X5VLOlp9MaQWFv1fmNmKltf2zSHRlfkI+t0Cjckc+YvurqCtDgQ6JV1X2gYIL7aCB4P2 Z8PtqhRPiD/kMcEagl9By9cHM0JiNdfExVyPJ8rrBgRZvcTIzuSgyyTmPDLLhK4jlP/+ PVvPqTNNICXUeCUNvcnz/CR26jZ+pxEZH5hBE5kGqHTiako6C9bwVB7YrqvlI1e5oSu1 6AZg== X-Gm-Message-State: AOAM5313eIU2QHvGvdGFinvJGczNbDo0kvHcotwgcr4+nFDmsE+q3smT hYR88FeuYgnakL7x1by+swrxwzpUcNk= X-Google-Smtp-Source: ABdhPJxX52+9RMaEqKt+s7OWx7hN+0gBRhVSFmqOvsOmEJ+O4L2v96WZk0WqSfNKWIAi5aXcgpjQWg== X-Received: by 2002:adf:e485:: with SMTP id i5mr2645196wrm.214.1623897402824; Wed, 16 Jun 2021 19:36:42 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id j5sm3721775wro.73.2021.06.16.19.36.41 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 16 Jun 2021 19:36:42 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <87mtrwuy4v.fsf@gmail.com> <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> <87v96hu845.fsf@gmail.com> From: Dmitry Gutov Message-ID: <310ab8d8-2bba-33bb-1aa4-1dc88dcb57d8@yandex.ru> Date: Thu, 17 Jun 2021 05:36:41 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 In-Reply-To: <87v96hu845.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.3 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.7 (/) On 13.06.2021 17:55, João Távora wrote: > I just confirmed it's not for correctness. If one foregoes the copy, in > fido-mode a C-h f followed by some input followed by C-g and an M-x and > no input (empty pattern) will show interesting results, i.e. a list of > propertized strings when nothing should be propertized. That's also an example of correctness problem, just the more obvious kind. It probably happens in a number of situations, e.g. all (?) uses of completion-table-with-cache. > But maybe that's a question of removing the propertization when the > pattern is empty? I'll try later. That must add some performance penalty as well, for extra mutation. And wouldn't cover some potential other uses of the same set of strings. In IMenu, maybe? The latter is hypothetical, of course. >> Do we have any "frozen strings" in Emacs, which absolutely could not >> be modified? Do we plan to? > > Immutable strings? And error when one tries to? Or just ignore the > modification? And how would that help here? It wouldn't help. It would do the opposite: basically forbid the approach you suggest, mutation without copying. >> I disagree it's a simpler technique, but it would indeed be a simpler >> change, based on the current implementation. > > simpler means simpler in my book :-) One is simpler diff, another is simpler resulting code. Both have their upsides. >> But I don't mind it myself, and happy to update Company. Either way >> it's a step forward. > > If Company and fido-mode and a couple more outside the core/Elpa are all > that's needed, it's probably warranted. But there are so many frontends > right now, I don't know... We'd need some "opt into the optimization", > I think." Since all other users are third-party (and thus have short release cycles), it shouldn't be too much of a problem. Some highlighting code would start to fail, but probably without disastrous results. And then people will issue updates to look for some new property when the old expected ones are all missing. >>> But if the speedup is big, I'd revisit the rationale for requiring those >>> copies to be performed in the first place. >> >> With fido-vertical-mode, and with that particular input, it's >> >> Elapsed time: 0.130773s (0.031547s in 1 GCs) >> >> without copy-sequence, and >> >> Elapsed time: 0.169842s (0.069740s in 4 GCs) >> >> with it. Not game changing, but definitely measurable. > > I don't have these results. I tried the previous experiment: > > ;; C-u C-x C-e C-m in quick succession > (benchmark-run (completing-read "bla" obarray)) > > And turned icomplete.el's while-no-input into a progn. > > In an Emacs -Q where (length (all-completions "" obarray)) is about > 20000. > > ;; with copy > (0.39647753 6 0.22811240199999983) > (0.431950471 7 0.263988651) > (0.451116177 6 0.2249686070000001) > > ;; without copy, small but measurable speedup > (0.29890632 2 0.08419541699999966) > (0.293501099 2 0.08622194699999985) > (0.306566633 3 0.0853211100000002) > > In a loaded Emacs where (length (all-completions "" obarray)) is 64554 > > ;; with copy > (2.869362171 6 2.3882547280000495) > (2.909661303 6 2.4209153659999743) > (2.845522439 6 2.3638140250000106) > > ;; without copy. Huge speedup. > (0.79817337 1 0.4526993239999797) > (0.8231736510000001 1 0.4752496449999626) > (0.719004478 1 0.4016016420000028) Even better. My current session has 37559 symbols, so it's somewhere in the middle. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jun 2021 21:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16239649302095 (code B ref 48841); Thu, 17 Jun 2021 21:23:02 +0000 Received: (at 48841) by debbugs.gnu.org; 17 Jun 2021 21:22:10 +0000 Received: from localhost ([127.0.0.1]:55281 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltzSk-0000Xi-3v for submit@debbugs.gnu.org; Thu, 17 Jun 2021 17:22:10 -0400 Received: from mail-wm1-f47.google.com ([209.85.128.47]:35362) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltzSe-0000XB-Ny for 48841@debbugs.gnu.org; Thu, 17 Jun 2021 17:22:08 -0400 Received: by mail-wm1-f47.google.com with SMTP id o39-20020a05600c5127b02901d23584fd9bso4483617wms.0 for <48841@debbugs.gnu.org>; Thu, 17 Jun 2021 14:22:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=n5NeRDCaWL65pCf8vgM0h1oDBPo6zIcpN06MN2kBl5w=; b=uDjUCL2r5khLYgoP4pPw2umPrEX4TiYzfiHC6h9d3S2+hD9PQMPKIiDEICTe4AuEfg lxNdBBO8SqOUJUTF8+gHWkzTFfQseW4x5uTnHZIwPaCeX+2WRS001LnzFRBtwbT17hGF 5yuuTN+pu6bWmHNRekUGwFTQbD3bPhDHovvCt1D2dzEpOVyOohvLgmk02YikVPMt7gqx yzG26zvJmo7/3zSQiO0qDsZo4p1IZzZ2hCvRftt+7n1UWlt3UeZO2dtGbD8byHIU/Jv2 H2td9wCAihFbfW3TPZhMFa/WU2J0XUMbfXwthuFA3FbbzGk8WTyNqVjUZQhmsNntdIq7 H+ww== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=n5NeRDCaWL65pCf8vgM0h1oDBPo6zIcpN06MN2kBl5w=; b=kzfhRqoubQ2W88sBOM/aw2f3WkBhH1zjl9Sk1CJ/jxTYlJYmliBOL7/GkuIOP/y68c jz+qfQUxRHQ/KMHDsdUMe/dfb6ut6d0b1nf8vXiUo0/cXCNqnNAwY75AHFS4uqV03BVx MJTgVpY23IfetwJ1Sgoug9Uh+Kp+AmA3I/As9HFVPow23tpJOvZy3jmcXzdSaIXkUNZ+ 0+yPME1g4E7VgwbKp7SNRHq7t89pDcaGc9J5B1bve6UpHFGS1XbHW+rDS1MaZXUqO5qe jEPrDkeZd32z4LrAS3/c9o/lVizqHziANFizlJ7zyalGLlSQNY5N06VzHEb5OFBQJejf 4JpQ== X-Gm-Message-State: AOAM530v+ewqMjstRCkSTi0mbf2SXk9NN+0WuXPXg8C9TwR/iSkVB84B bdAxWfFgJnxPXxmtBkXkrJ7rhsvnPog= X-Google-Smtp-Source: ABdhPJyBIRHg6PA5aepzkVnf1rAizozp9FvREO3TY9FwuEu8jBqtjF8RFMu0B1ytlPCkNHbrB9odmg== X-Received: by 2002:a05:600c:190c:: with SMTP id j12mr7642921wmq.42.1623964918572; Thu, 17 Jun 2021 14:21:58 -0700 (PDT) Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id y16sm3058875wrp.51.2021.06.17.14.21.57 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Jun 2021 14:21:57 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <87mtrwuy4v.fsf@gmail.com> <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> <87v96hu845.fsf@gmail.com> <310ab8d8-2bba-33bb-1aa4-1dc88dcb57d8@yandex.ru> Date: Thu, 17 Jun 2021 22:21:55 +0100 In-Reply-To: <310ab8d8-2bba-33bb-1aa4-1dc88dcb57d8@yandex.ru> (Dmitry Gutov's message of "Thu, 17 Jun 2021 05:36:41 +0300") Message-ID: <877disb30s.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: >>> I disagree it's a simpler technique, but it would indeed be a simpler >>> change, based on the current implementation. >> simpler means simpler in my book :-) > > One is simpler diff, another is simpler resulting code. Both have > their upsides. Oh, you meant the The Big Redesign? I'm a fan of that too, not only here but constantly, everywhere... That indeed means simpler resulting code in abstract. Problem is that also means different resulting code to different people. But is definitely doable. >>> But I don't mind it myself, and happy to update Company. Either way >>> it's a step forward. >> If Company and fido-mode and a couple more outside the core/Elpa are >> all >> that's needed, it's probably warranted. But there are so many frontends >> right now, I don't know... We'd need some "opt into the optimization", >> I think." > > Since all other users are third-party (and thus have short release > cycles), it shouldn't be too much of a problem. Some highlighting code > would start to fail, but probably without disastrous results. And then > people will issue updates to look for some new property when the old > expected ones are all missing. OK. I can live with that rationale. So what are the places to touch that "we" control? - icomplete.el? for fido-mode & friends - minibuffer.el, for the *Completions* buffer - company.el - Any notable others? >> ;; with copy >> (2.869362171 6 2.3882547280000495) >> (2.909661303 6 2.4209153659999743) >> (2.845522439 6 2.3638140250000106) >> ;; without copy. Huge speedup. >> (0.79817337 1 0.4526993239999797) >> (0.8231736510000001 1 0.4752496449999626) >> (0.719004478 1 0.4016016420000028) > > Even better. > > My current session has 37559 symbols, so it's somewhere in the middle. Yes, this is a big performance bottleneck. But i wonder if tweaking GC parameter would help here. I know nothing of Emacs GC parameters. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 17 Jun 2021 21:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16239653752715 (code B ref 48841); Thu, 17 Jun 2021 21:30:02 +0000 Received: (at 48841) by debbugs.gnu.org; 17 Jun 2021 21:29:35 +0000 Received: from localhost ([127.0.0.1]:55285 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltzZv-0000hj-0i for submit@debbugs.gnu.org; Thu, 17 Jun 2021 17:29:35 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:42975) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1ltzZq-0000hT-Bq for 48841@debbugs.gnu.org; Thu, 17 Jun 2021 17:29:33 -0400 Received: by mail-wr1-f49.google.com with SMTP id c5so8300377wrq.9 for <48841@debbugs.gnu.org>; Thu, 17 Jun 2021 14:29:30 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=kZyrr5n5gjeW2bqoqY3eiyN26tcb8zyAgKhDvy/MxNc=; b=U/XRyZk3udRfBYyT2Qkf4qOaHRmXQOdoWpEU6fBbgoU04AQ/J1mBuGAO1mDunO0+b4 dRTSr5inuJOu1m0R+eZbb+89vDSgEOHfOsWInl+7uxjXdl/PPgJLKGdnm7p/CZxZoTWV +4Jf23UTEXqYBh3U5s+z0Egste0AmUMwF4UNOPiMfRFmP+92GXPvFM4NzPpLJTywFwZv F2g8pSYpvImWyAjFsScNVQ+H7Un8u6aefBgcMDCg34BHEtIyDQAAk0RbUNS4DT4Dx0lZ 0BiQD+/K9uIaJPX75TDwPcaLxWPJvtXTuOxv4QUqrIlpdBw9kT62Til3bmzrj8oRRBAf 7vEw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=kZyrr5n5gjeW2bqoqY3eiyN26tcb8zyAgKhDvy/MxNc=; b=hHuKzdS3PH7EyvtaQq0dyD6eqoNJSIWnhtD2CVS/VozaJUpK1YG2n9EA+i3e1Ts1ss LkuLdfktQcogl36sD/wC9i4v1cFnhgcMRLg+EAiD4n0fwkrhdE4bUZelNRqO0gbvs3wG 4Lax2TIyGYDfqdpsmJAyj3ifqLzSD6maS5C0B6sOQHoHXDR3rgxgKtBYi7cjzmYSrAz2 apznS/P0NHEJGPoNJ0mxn9bEVvIZ19fc/+H/949YOTrEEvNb/5LZl0Sgmvwo8hk7vp69 yuWGA0TRgpCkz3tZK9UwK5Uvg834EIcBbgD839QMxHc+i0CtAKGvSA+bjTAgRiWw8Nkj PIVQ== X-Gm-Message-State: AOAM530Phf23VTAgKaPxuu+Y7oiSJapdlks9XpxhUEYti+BQrOZbjXAe gP+5luLYJtZ5KGXkzjh6hZT7nxztvWo= X-Google-Smtp-Source: ABdhPJxooZnAEWUus8H9eH+4cFQcLUgrAnJS6/H8MA8XVbmxLTyMc8+iONjLpZvg99kT9V/Tyu/MDg== X-Received: by 2002:adf:e54f:: with SMTP id z15mr8343351wrm.141.1623965364149; Thu, 17 Jun 2021 14:29:24 -0700 (PDT) Received: from krug (a94-133-55-152.cpe.netcabo.pt. [94.133.55.152]) by smtp.gmail.com with ESMTPSA id k16sm5730052wmr.42.2021.06.17.14.29.23 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 17 Jun 2021 14:29:23 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <878s3gugqj.fsf@gmail.com> <87zgvtu9bm.fsf@gmail.com> <033e12e5-86e2-cb0c-ac8b-6753b96fa4b2@yandex.ru> <33224e9c-2185-29c0-5aa9-f798b2f3ccaf@yandex.ru> Date: Thu, 17 Jun 2021 22:29:22 +0100 In-Reply-To: <33224e9c-2185-29c0-5aa9-f798b2f3ccaf@yandex.ru> (Dmitry Gutov's message of "Thu, 17 Jun 2021 05:23:53 +0300") Message-ID: <871r90b2od.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 14.06.2021 03:16, Jo=C3=A3o T=C3=A1vora wrote: >>> Perhaps predicate it on the value of icomplete-hide-common-prefix inste= ad? >>> >>> fido-mode sets it to nil, and this way we retain a better level of >>> abstraction, and better backward compatibility for vanilla >>> icomplete-mode users. >> This is a good idea, the level of abstraction. But what is this >> "common prefix" anyway? Is it the the same as the "determ" >> thing, or the "[mplete...] dance" as I called it earlier. Shouldn't >> fido-mode then_hide_ it? >> I'm confused, but if you're not, go ahead and make that more >> abstract change instead of relying on fido-mode. > > So... it's a bit more complex than that. Yes, my batch broke the things you mentioned. > It seems there are two ways to proceed from here: > > - Just alter the printing logic in the "single match" case to print > the match text in full is it's not equal to the input string. I > haven't puzzled out the logic doing that yet. >=20=20=20 > - Try to keep the current behavior while avoiding the duplicate work. Both sound absolutely fine to me. > About the latter option: the result of that most-try stuff is only > useful when there is only one match, right? No idea, but may be. > Unless I'm missing something and the value does see some use in the > multiple-matches situations, the patch below both keeps the current > behavior and gives the same performance improvement: That'd be fantastic, but I doubt you'd be keeping the exact same behaviour. I never understood it -- that's the thing here -- but I think that completion-try-completion is doing more stuff when multiple candidates matched by a pattern happen to share the same prefix or suffix or something like that. I might be completely wrong, tho. But really if you make this patch conditional to fido-mode or that other var that you think is more abstract, I think it's fine and it's a very clear win. I really doubt that the tiny number of fido-mode users care about that behaviour anyway, but I'm sure they'll appreciate the considerable speedup. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Jul 2021 01:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162536296027687 (code B ref 48841); Sun, 04 Jul 2021 01:43:02 +0000 Received: (at 48841) by debbugs.gnu.org; 4 Jul 2021 01:42:40 +0000 Received: from localhost ([127.0.0.1]:40210 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzr9b-0007CV-Mb for submit@debbugs.gnu.org; Sat, 03 Jul 2021 21:42:39 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:38643) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzr9Z-0007CI-6G for 48841@debbugs.gnu.org; Sat, 03 Jul 2021 21:42:38 -0400 Received: by mail-wm1-f52.google.com with SMTP id b14-20020a1c1b0e0000b02901fc3a62af78so5030209wmb.3 for <48841@debbugs.gnu.org>; Sat, 03 Jul 2021 18:42:37 -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=mf/RM6T+aNhp2Wm89BbNUXm8BpQLgsQV0+hTdalnHYM=; b=DgmhVwJoZ8uuf1Yi1bwteyIRzMXF20qa+vVmIkOc3eYjzjhobFu8EBRsFgTGRHHYyC jaxhGtzlVjfhFrZfxdphJFxfpl0mAwOZmOz3ZwjgQ6rhxH2sbzFuGGu1yZMsUqbNQP4A uewgfvpX/PoAfS3Bw682gBvB+b8TRSDuYLF3JGYxv11p+zgnQ+kts1nj3g3RSxhPL7/p XiaMXTip7QvjpPrMUjgEOSknu5OnNdQ+gckxNdm43+ffw7RptSHxb/iVG1M03/vJv+WY Ify11LG5apwdJ0ON/aMOcf2rtvveZmisiVkuL1JSTU+H78ahlbCdhuwMHHQOaybw8ZGf k3wg== 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=mf/RM6T+aNhp2Wm89BbNUXm8BpQLgsQV0+hTdalnHYM=; b=NrpSEcK2dJ7slqW5N3n6XwGPms+t/LxN7r4Z+ZxrW2a/AoEQz7F4rJdruUPJTBjVqc /PuFBc5uL7djvgKQQazUlwV81pPluyKlW2dddlY2CNzFrWYImZlu6SuOTaRlptebsHKB KSDVsgKZ9rZWihFQeeGF1wIwSd5rgX6f9AjCyFP0RMqvT5ZxtiV6yB8HtEqHzZrYvtAH j5qfE5+W44A6sEaIhFxD6Cth9VrZpC9PKIx+WCAAaef9h8f90cwC+8SoHrpvxLp1YWo/ 93Hmb9LrSc1QG4z/c2slv7LhiON6QrFkeMdCBIyIKFG/PP2PorupR+V7fwVpUW+kx6/c HWEA== X-Gm-Message-State: AOAM530t0FgwBym3DXfmeZ86J2EXN+2KQMEnBLccDjTpmsU5DDdiyCe5 lGVUI1rc451EmlpsqfI1PLeEdXzmrz8= X-Google-Smtp-Source: ABdhPJxHHnD3VSoAyFzL8yIxoeoJoIk7+WNbWbuEqupUoA9soR8fWCA7DXvh6HTVzQ7d8GLYiI6l/Q== X-Received: by 2002:a7b:ce82:: with SMTP id q2mr7290748wmj.60.1625362951277; Sat, 03 Jul 2021 18:42:31 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n7sm16327195wmq.37.2021.07.03.18.42.29 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Jul 2021 18:42:30 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <878s3gugqj.fsf@gmail.com> <87zgvtu9bm.fsf@gmail.com> <033e12e5-86e2-cb0c-ac8b-6753b96fa4b2@yandex.ru> <33224e9c-2185-29c0-5aa9-f798b2f3ccaf@yandex.ru> <871r90b2od.fsf@gmail.com> From: Dmitry Gutov Message-ID: <21357b0f-0c95-c520-15c6-7bd326681e69@yandex.ru> Date: Sun, 4 Jul 2021 04:42:28 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <871r90b2od.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 18.06.2021 00:29, João Távora wrote: >> Unless I'm missing something and the value does see some use in the >> multiple-matches situations, the patch below both keeps the current >> behavior and gives the same performance improvement: > > That'd be fantastic, but I doubt you'd be keeping the exact same > behaviour. I never understood it -- that's the thing here -- but I > think that completion-try-completion is doing more stuff when multiple > candidates matched by a pattern happen to share the same prefix or > suffix or something like that. I might be completely wrong, tho. Turns out that indeed the logic is used in the "multiple matches" case: when icomplete-hide-common-prefix is non-nil. Meaning, with icomplete-mode but not with fido-mode. > But really if you make this patch conditional to fido-mode or that other > var that you think is more abstract, I think it's fine and it's a very > clear win. I really doubt that the tiny number of fido-mode users care > about that behaviour anyway, but I'm sure they'll appreciate the > considerable speedup. So I have done the above. There is no change in observable behavior either (AFAICS), so it's win-win. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 04 Jul 2021 01:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162536360128634 (code B ref 48841); Sun, 04 Jul 2021 01:54:02 +0000 Received: (at 48841) by debbugs.gnu.org; 4 Jul 2021 01:53:21 +0000 Received: from localhost ([127.0.0.1]:40216 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzrJw-0007Rl-PK for submit@debbugs.gnu.org; Sat, 03 Jul 2021 21:53:21 -0400 Received: from mail-wm1-f51.google.com ([209.85.128.51]:54834) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lzrJr-0007RV-LL for 48841@debbugs.gnu.org; Sat, 03 Jul 2021 21:53:19 -0400 Received: by mail-wm1-f51.google.com with SMTP id l1so8989544wme.4 for <48841@debbugs.gnu.org>; Sat, 03 Jul 2021 18:53:15 -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=ak10DCJqFvpOETh+D4yKpdoeXKfQSRrOzfXtuKu3Ck0=; b=QncbwTJiW+G4C64k0QDa1kNZRL3jPiYmgjOGmJN2Z6dGOy1TktT3Tpz2dfwoxgfz2L Z8HKlvY0V6zufuACkP90eT0/gcbbcJIPjOP0Mqvl/8pqHJXU7mY2zvla57ZeRTLLz2Rt hjqAjfP9mUeL9jPyLHf1DBhxnLN+Jw8iQgOiFaZTttbwFohKmsKDHbJ6o4aAsKAb9/nP gDHwlhPGdCswIvBeZ5UrL04866fXjGZ9AyhUsI+sWLKmyVSfbE781ygF/fXUk863zqnN lIdhnoyWO00bG4KEw5+TcMORvlS4g6GTuQXZiuADL6QY7MLWOQaajHZv9IFHlV6Yvg/Q jEew== 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=ak10DCJqFvpOETh+D4yKpdoeXKfQSRrOzfXtuKu3Ck0=; b=MXgLDNTJzCffcKrM42MMoA49JvgcngWLy0EFS34/09yZfBEQGbbKNwnLCulRPwgC/K h77fP0w5fpNHddH1XWb2JkyzjcVUswK3/CAp5KWmX+t1uUrqsxlWFzDWtSFa9RSS2eZ7 LQF7NeBzE78YOe6HAeea+ICHcuxho4pwXyGMKNr1btvp4abiMzuI5INbYVXkg+qZBEtR wSrgKE53GaG2O6J2iga1YZYyihZxxnECQtIOoUNda/6li4LA4j+PFZlR1++9IIV61DEd Sn4833Detl7q98eBD0YQc/Zj+rLo3AAhon1R2+/CHw7CtsEOtz67ftTeWrw/9+/glTFO Ys4A== X-Gm-Message-State: AOAM530/CpUDoOJ7KQq1Cr88aiRFNacV2ClezdRGjM2BJU32jD4FjBks 95J23Np6HjctRyDdtbRS/4E= X-Google-Smtp-Source: ABdhPJz0+RmXAo8OH5V/i/r6qb5ycSIDuzCnjtSuqaGQUdqbwYsMMz6laWVPYjC9a3fYkt+/M2f4Mw== X-Received: by 2002:a05:600c:3589:: with SMTP id p9mr7611322wmq.182.1625363589800; Sat, 03 Jul 2021 18:53:09 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id c9sm8119719wro.5.2021.07.03.18.53.08 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 03 Jul 2021 18:53:09 -0700 (PDT) References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <87mtrwuy4v.fsf@gmail.com> <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> <87v96hu845.fsf@gmail.com> <310ab8d8-2bba-33bb-1aa4-1dc88dcb57d8@yandex.ru> <877disb30s.fsf@gmail.com> From: Dmitry Gutov Message-ID: <526eeb14-31c2-f414-ec44-192180d59164@yandex.ru> Date: Sun, 4 Jul 2021 04:53:07 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <877disb30s.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.5 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.5 (/) On 18.06.2021 00:21, João Távora wrote: > Dmitry Gutov writes: > >>>> I disagree it's a simpler technique, but it would indeed be a simpler >>>> change, based on the current implementation. >>> simpler means simpler in my book :-) >> >> One is simpler diff, another is simpler resulting code. Both have >> their upsides. > > Oh, you meant the The Big Redesign? I'm a fan of that too, not only > here but constantly, everywhere... That indeed means simpler resulting > code in abstract. Problem is that also means different resulting code > to different people. But is definitely doable. I meant a particular change (not modifying the strings at all in advance) which would be bigger and indeed might better fit The Big Redesign. >>>> But I don't mind it myself, and happy to update Company. Either way >>>> it's a step forward. >>> If Company and fido-mode and a couple more outside the core/Elpa are >>> all >>> that's needed, it's probably warranted. But there are so many frontends >>> right now, I don't know... We'd need some "opt into the optimization", >>> I think." >> >> Since all other users are third-party (and thus have short release >> cycles), it shouldn't be too much of a problem. Some highlighting code >> would start to fail, but probably without disastrous results. And then >> people will issue updates to look for some new property when the old >> expected ones are all missing. > > OK. I can live with that rationale. So what are the places to touch > that "we" control? > > - icomplete.el? for fido-mode & friends > - minibuffer.el, for the *Completions* buffer > - company.el > - Any notable others? corfu, consult, etc? Probably Ivy too. All of these are in GNU ELPA. BTW, I think Daniel had some ideas about applying the face property lazily as well. I can't find the particular discussion now, but perhaps he can add to this discussion as well. >>> ;; with copy >>> (2.869362171 6 2.3882547280000495) >>> (2.909661303 6 2.4209153659999743) >>> (2.845522439 6 2.3638140250000106) >>> ;; without copy. Huge speedup. >>> (0.79817337 1 0.4526993239999797) >>> (0.8231736510000001 1 0.4752496449999626) >>> (0.719004478 1 0.4016016420000028) >> >> Even better. >> >> My current session has 37559 symbols, so it's somewhere in the middle. > > Yes, this is a big performance bottleneck. But i wonder if tweaking GC > parameter would help here. I know nothing of Emacs GC parameters. I think the current understanding that by raising gc-cons-threshold we exchange the number of GC pauses for larger latencies. I suppose one could tune that value to a particular workload such that the 4 GCs in a row that I had will turn into just one (and thus save on re-scanning the heap 3 times), but data sets change. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: fido-mode is slower than ido-mode with similar settings Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 07 Jul 2021 08:57:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162564817714037 (code B ref 48841); Wed, 07 Jul 2021 08:57:02 +0000 Received: (at 48841) by debbugs.gnu.org; 7 Jul 2021 08:56:17 +0000 Received: from localhost ([127.0.0.1]:50830 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m13Lt-0003eG-0J for submit@debbugs.gnu.org; Wed, 07 Jul 2021 04:56:17 -0400 Received: from server.qxqx.de ([178.63.65.180]:47469 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1m13Lq-0003dw-Aq; Wed, 07 Jul 2021 04:56:15 -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=o3u4a1/ZU7W8pFLoHziFDm4XIG8WTn7yTgWzxLbAWns=; b=gK3nxdsmphgKTeETBcWmUA4Qo4 RXioGPDTTt2+6BBibZiNXl6TkIjZzWODFkUe4nCHqnjBNe/RTTOf4gv21nCSPj+CVPUOx3IDvkJd/ MRQUXLGIzxJLD9wS5GLJQI1sU87P9dSvztcdan9oTMWD+M8HvgMeDm+MEwY3McP+gD5s=; References: <87eedgy7pt.fsf@gmail.com> <1f659c88-4d9d-8fc9-733a-5e6068f9ed4a@yandex.ru> <87a6o3x5j7.fsf@gmail.com> <87y2bnv5xc.fsf@gmail.com> <35be6652-9c8d-ee21-e9eb-9598ad6777eb@yandex.ru> <858682b2-b8fd-898b-bef3-97dbe5e4debc@yandex.ru> <87mtrwuy4v.fsf@gmail.com> <2234991b-c2e0-81e3-c1ef-b1d94d35a728@yandex.ru> <87v96hu845.fsf@gmail.com> <310ab8d8-2bba-33bb-1aa4-1dc88dcb57d8@yandex.ru> <877disb30s.fsf@gmail.com> <526eeb14-31c2-f414-ec44-192180d59164@yandex.ru> From: Daniel Mendler Message-ID: <7fc8ce6d-20ba-79ed-56d8-f10be72cddc8@daniel-mendler.de> Date: Wed, 7 Jul 2021 10:56:05 +0200 MIME-Version: 1.0 In-Reply-To: <526eeb14-31c2-f414-ec44-192180d59164@yandex.ru> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 7/4/21 3:53 AM, Dmitry Gutov wrote: >> - icomplete.el? for fido-mode & friends >> - minibuffer.el, for the *Completions* buffer >> - company.el >> - Any notable others? > > corfu, consult, etc? Probably Ivy too. All of these are in GNU ELPA. > > BTW, I think Daniel had some ideas about applying the face property > lazily as well. I can't find the particular discussion now, but perhaps > he can add to this discussion as well. Yes, Vertico and Corfu apply highlighting lazily. This leads to significant performance wins. See `vertico--all-completions` in https://github.com/minad/vertico/blob/main/vertico.el#L243-L279 and bug#47711. The technique I am using in Vertico and Corfu retains backward compatibility, such that the strings are returned unmodified by the completion style. Highlighting is applied lazily by copying the candidate strings and mutating the copies. For now I am relying on advices. One could add an optional argument (or dynamically bound variable) to completion styles which tell the completion style to opt out of copying the candidates and the highlighting. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting References: In-Reply-To: Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Aug 2021 14:18:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "emacs-devel@gnu.org" Cc: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 47711@debbugs.gnu.org, Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162869143125218 (code B ref 48841); Wed, 11 Aug 2021 14:18:01 +0000 Received: (at 48841) by debbugs.gnu.org; 11 Aug 2021 14:17:11 +0000 Received: from localhost ([127.0.0.1]:36220 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDp2b-0006Yd-7i for submit@debbugs.gnu.org; Wed, 11 Aug 2021 10:17:11 -0400 Received: from server.qxqx.de ([178.63.65.180]:59847 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDp2X-0006Xz-HJ; Wed, 11 Aug 2021 10:17:08 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Type:MIME-Version:Date:Message-ID:Subject:From:Cc :To:Sender:Reply-To:Content-Transfer-Encoding:Content-ID:Content-Description: Resent-Date:Resent-From:Resent-Sender:Resent-To:Resent-Cc:Resent-Message-ID: In-Reply-To:References:List-Id:List-Help:List-Unsubscribe:List-Subscribe: List-Post:List-Owner:List-Archive; bh=jI1hVGefRnIqqV63epya37LbCwXprNTn1ArIfYVUC30=; b=yxBwqrKs8WqUGCKrekohWXbjMR m08SIThso/uGJtkcBilQwb/05lPWJ9HN8PxrQOP6eiiT7fsug3Re7hkbNRdqo6Unt9xIxRfl70zp3 NsowJoPS7ZMi4mClGdJmTb33/gve/EMaHQ/WkjdJpco+1za1E/Y8Z0vV91g0rWb0eXh8=; From: Daniel Mendler Message-ID: Date: Wed, 11 Aug 2021 16:16:57 +0200 MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="------------3147CDE26CD3C1A11006A179" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------3147CDE26CD3C1A11006A179 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I prepared a patch which provides the API `completion-filter-completions`. This function supports deferred highlighting and returns additional data with the list of matching completion candidates. The API supersedes the existing function `completion-all-completions`. The main goal of the new API is to avoid expensive string allocations and highlighting during completion. This is particularly relevant for continuously updating completion UIs like Icomplete or Vertico. Furthermore the end position of the completion boundaries is returned with the completion results. This information is not provided by the existing `completion-all-completions` API. See also the relevant bugs bug#47711 and bug#48841. I am looking forward to your feedback. Thank you! Daniel Mendler --------------3147CDE26CD3C1A11006A179 Content-Type: text/x-diff; charset=UTF-8; name="0001-Add-new-completion-filter-completions-API-and-deferr.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Add-new-completion-filter-completions-API-and-deferr.pa"; filename*1="tch" >From e7f26abc520ac36cc154a92bfb4744837d9f7e5e Mon Sep 17 00:00:00 2001 From: Daniel Mendler Date: Mon, 12 Jul 2021 21:40:32 +0200 Subject: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Fix bug#47711. Add a new `completion-filter-completions` API, which supersedes `completion-all-completions`. The new API returns the matching completion candidates and additional data. The return value is an alist, with the keys `completions`, `base`, `end` and `highlight`. The API can be extended in a backward compatible way later on thanks to the use of an alist as return value. The `completions` value is the list of completion strings *without* applied highlighting. The completion strings are returned unmodified, which avoids allocations and results in performance gains for continuously updating completion UIs, like Icomplete or Vertico (GNU ELPA). The value `base` is the base position of the completion. Correspondingly the value `end` specifies the end position of the completion counted from the beginning of the input strng. In comparison, the old function `completion-all-completions` only returned the base position in the last cdr of the returned completions list, which complicated usage. The `end` position was not provided by `completion-all-completions`. Given the new API the `completion-base-position` can be set accurately. Finally the `highlight` value is a function taking a list of completion strings and returns a new list of new strings with highlighting applied. A continously updating UI can use the highlighting function to apply highlighting only to the visible completions. * lisp/minibuffer.el: (completion-pcm--hilit-commonality): Remove scoring computation. (completion--adjust-metadata): Rename to `completion--style-metadata` due to change of calling convention. (completion--nth-completion): Call renamed metadata adjustment function. Ignore the old property `completion--adjust-metadata`. (completion--flex-adjust-metadata): Rename function. (completion--twq-all): Attach `completion--unquoted` text property to quoted completion strings. (completion--flex-score): New optimized scoring function. Use `completion--unquoted` text property. (completion--flex-style-metadata): Use it. (completion--pattern-compiler): New function. (completion-substring--all-completions, completion--flex-score): Use it. (completion--hilit-commonality): New function. (completion-hilit-commonality): Use it. (completion--deferred-hilit): New function. (completion-basic-all-completions, completion-emacs21-all-completions, completion-emacs22-all-completions): Use it. (completion--pcm-deferred-hilit): New function. (completion-pcm-all-completions, completion-flex-all-completions, completion-initials-all-completions, completion-substring-all-completions): Use it. (completion--filter-completions): New variable to conditionally enable the new alist completions result format. This variable is for internal use to preserve the existing calling convention of the completion style `all` functions. (completion-filter-completions): New API which returns the completion strings and additional data as an an alist. Transparently convert old-fashioned completion style results to the new format. (completion-all-completions): Transparently downgrade the new-fashioned completion style result to the old list format. (minibuffer-completion-help): Use the new API, set `completion-base-position` correctly. (completion-try-completion, completion-all-completions): Update doc string. (completion--replace): Remove unnecessary property removal. * test/lisp/minibuffer-tests.el: (completion--pcm-score): Remove obsolete function. (completion-*-test-*): Remove obsolete functions, rename. (completion-flex-score-test-*): Add new scoring test functions. (completion--test-style): New test helper function. (completion-*-style-test): Add new API tests for each built-in completion style. (completion--test-boundaries): New test helper function. (completion-*-boundaries-test): New boundary tests for each built-in completion style. (completion-filter-completions-highlight-test): New API test. (completion-emacs22orig-all-completions): New function. (completion-upgrade-return-type-test): New test of transparent completion style return value upgrade. --- lisp/minibuffer.el | 453 +++++++++++++++++++++++----------- test/lisp/minibuffer-tests.el | 257 +++++++++++++++---- 2 files changed, 516 insertions(+), 194 deletions(-) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 9f327df28f..ba8855c4ea 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -692,6 +692,10 @@ completion--twq-all 'completions-common-part) qprefix)))) (qcompletion (concat qprefix qnew))) + ;; Attach unquoted completion string, which is needed + ;; to score the completion in `completion--flex-score'. + (put-text-property 0 1 'completion--unquoted + completion qcompletion) ;; FIXME: Similarly here, Cygwin's mapping trips this ;; assertion. ;;(cl-assert @@ -1035,6 +1039,17 @@ completion--styles (delete-dups (append (cdr over) (copy-sequence completion-styles))) completion-styles))) +(defvar completion--filter-completions nil + "Enable the new completions return value format. +If this variable is non-nil the `all-completions' function of a +completion style should return the results in the new alist format of +`completion-filter-completions'. This variable is purely needed to +for backward compatibility of the existing builtin completion style +functions. New completion style functions may always return their +results in the new alist format, since `completion-all-completions' +transparently converts back to the old improper list of completions +with base size in the last cdr.") + (defun completion--nth-completion (n string table pred point metadata) "Call the Nth method of completion styles." ;; We provide special support for quoting/unquoting here because it cannot @@ -1061,6 +1076,15 @@ completion--nth-completion ;; the original table, in that case! (functionp table)) (let ((new (funcall table string point 'completion--unquote))) + ;; FIXME For now do not attempt deferred highlighting if + ;; quoting is used. Not doing deferred highlighting is + ;; not too severe in this case, since + ;; `completion--twq-all' is already an expensive + ;; function, which allocates all completion strings. In + ;; contrast to plain completion tables, the savings of + ;; deferred highlighting would be minimal in the case of + ;; quoted completion tables. + (setq completion--filter-completions nil) (setq string (pop new)) (setq table (pop new)) (setq point (pop new)) @@ -1074,9 +1098,10 @@ completion--nth-completion string table pred point))) (and probe (cons probe style)))) (completion--styles md))) - (adjust-fn (get (cdr result-and-style) 'completion--adjust-metadata))) - (when (and adjust-fn metadata) - (setcdr metadata (cdr (funcall adjust-fn metadata)))) + (style-md (get (cdr result-and-style) 'completion--style-metadata))) + (when (and style-md metadata) + (setcdr metadata (cdr (funcall style-md + string table pred point metadata)))) (if requote (funcall requote (car result-and-style) n) (car result-and-style)))) @@ -1084,22 +1109,64 @@ completion--nth-completion (defun completion-try-completion (string table pred point &optional metadata) "Try to complete STRING using completion table TABLE. Only the elements of table that satisfy predicate PRED are considered. -POINT is the position of point within STRING. -The return value can be either nil to indicate that there is no completion, -t to indicate that STRING is the only possible completion, -or a pair (NEWSTRING . NEWPOINT) of the completed result string together with -a new position for point." +POINT is the position of point within STRING. The return value can be +either nil to indicate that there is no completion, t to indicate that +STRING is the only possible completion, or a pair (NEWSTRING . NEWPOINT) +of the completed result string together with a new position for point. +The METADATA may be modified by the completion style." (completion--nth-completion 1 string table pred point metadata)) (defun completion-all-completions (string table pred point &optional metadata) "List the possible completions of STRING in completion table TABLE. Only the elements of table that satisfy predicate PRED are considered. -POINT is the position of point within STRING. -The return value is a list of completions and may contain the base-size -in the last `cdr'." - ;; FIXME: We need to additionally return the info needed for the - ;; second part of completion-base-position. - (completion--nth-completion 2 string table pred point metadata)) +POINT is the position of point within STRING. The return value is a +list of completions and may contain the base-size in the last `cdr'. +The METADATA may be modified by the completion style. This function +has been superseded by `completion-filter-completions', which returns +richer information and supports deferred candidate highlighting." + (let ((completion--filter-completions nil) + (result (completion--nth-completion 2 string table + pred point metadata))) + (if (and result (consp (car result))) + ;; Give the completion styles some freedom! + ;; If they are targeting Emacs 28 upwards only, they + ;; may always return a result with deferred + ;; highlighting. We convert back to the old format + ;; here by applying the highlighting eagerly. + (nconc (funcall (cdr (assq 'highlight result)) + (cdr (assq 'completions result))) + (cdr (assq 'base result))) + result))) + +(defun completion-filter-completions (string table pred point metadata) + "Filter the possible completions of STRING in completion table TABLE. +Only the elements of table that satisfy predicate PRED are considered. +POINT is the position of point within STRING. The METADATA may be +modified by the completion style. The return value is a alist with +the keys: + +- base: Base position of the completion (from the start of STRING) +- end: End position of the completion (from the start of STRING) +- highlight: Highlighting function taking a list of completions and + returning a new list of new strings with applied highlighting. +- completions: The list of completions. + +This function supersedes the function `completion-all-completions'." + (let* ((completion--filter-completions t) + (result (completion--nth-completion 2 string table + pred point metadata))) + (if (and result (not (consp (car result)))) + ;; Deferred highlighting has been requested, but the completion + ;; style returned a non-deferred result. Convert the result to the + ;; new alist format. + (let* ((last (last result)) + (base (or (cdr last) 0))) + (setcdr last nil) + `((base . ,base) + (end . ,(length string)) + (highlight . identity) + (completions . ,result))) + result))) (defun minibuffer--bitset (modified completions exact) (logior (if modified 4 0) @@ -1114,9 +1181,8 @@ completion--replace ;; include upon insertion. (if minibuffer-allow-text-properties ;; If we're preserving properties, then just remove the faces - ;; and other properties added by the completion machinery. - (remove-text-properties 0 (length newtext) '(face completion-score) - newtext) + ;; added by the completion machinery. + (remove-text-properties 0 (length newtext) '(face nil) newtext) ;; Remove all text properties. (set-text-properties 0 (length newtext) nil newtext)) ;; Maybe this should be in subr.el. @@ -2021,34 +2087,48 @@ completion-hilit-commonality It returns a list with font-lock properties applied to each element, and with BASE-SIZE appended as the last element." (when completions - (let ((com-str-len (- prefix-len (or base-size 0)))) - (nconc - (mapcar - (lambda (elem) - (let ((str - ;; Don't modify the string itself, but a copy, since the - ;; the string may be read-only or used for other purposes. - ;; Furthermore, since `completions' may come from - ;; display-completion-list, `elem' may be a list. - (if (consp elem) - (car (setq elem (cons (copy-sequence (car elem)) - (cdr elem)))) - (setq elem (copy-sequence elem))))) - (font-lock-prepend-text-property - 0 - ;; If completion-boundaries returns incorrect - ;; values, all-completions may return strings - ;; that don't contain the prefix. - (min com-str-len (length str)) - 'face 'completions-common-part str) - (if (> (length str) com-str-len) - (font-lock-prepend-text-property com-str-len (1+ com-str-len) - 'face - 'completions-first-difference - str))) - elem) - completions) - base-size)))) + (nconc + (completion--hilit-commonality (- prefix-len (or base-size 0)) completions) + base-size))) + +(defun completion--hilit-commonality (com-size completions) + (mapcar + (lambda (elem) + (let ((str + ;; Don't modify the string itself, but a copy, since the + ;; the string may be read-only or used for other purposes. + ;; Furthermore, since `completions' may come from + ;; display-completion-list, `elem' may be a list. + (if (consp elem) + (car (setq elem (cons (copy-sequence (car elem)) + (cdr elem)))) + (setq elem (copy-sequence elem))))) + (font-lock-prepend-text-property + 0 + ;; If completion-boundaries returns incorrect + ;; values, all-completions may return strings + ;; that don't contain the prefix. + (min com-size (length str)) + 'face 'completions-common-part str) + (if (> (length str) com-size) + (font-lock-prepend-text-property com-size (1+ com-size) + 'face + 'completions-first-difference + str))) + elem) + completions)) + +(defun completion--deferred-hilit (completions prefix-len base end) + "Return completions in old format or new alist format. +If `completion--filter-completions' is non-nil use the new format." + (if completion--filter-completions + (when completions + `((base . ,base) + (end . ,end) + (highlight . ,(apply-partially #'completion--hilit-commonality + (- prefix-len base))) + (completions . ,completions))) + (completion-hilit-commonality completions prefix-len base))) (defun display-completion-list (completions &optional common-substring group-fun) "Display the list of completions, COMPLETIONS, using `standard-output'. @@ -2163,15 +2243,16 @@ minibuffer-completion-help (end (or end (point-max))) (string (buffer-substring start end)) (md (completion--field-metadata start)) - (completions (completion-all-completions - string - minibuffer-completion-table - minibuffer-completion-predicate - (- (point) start) - md))) + (filtered-completions (completion-filter-completions + string + minibuffer-completion-table + minibuffer-completion-predicate + (- (point) start) + md)) + (completions (alist-get 'completions filtered-completions))) (message nil) (if (or (null completions) - (and (not (consp (cdr completions))) + (and (not (cdr completions)) (equal (car completions) string))) (progn ;; If there are no completions, or if the current input is already @@ -2181,8 +2262,7 @@ minibuffer-completion-help (completion--message (if completions "Sole completion" "No completions"))) - (let* ((last (last completions)) - (base-size (or (cdr last) 0)) + (let* ((base-size (alist-get 'base filtered-completions)) (prefix (unless (zerop base-size) (substring string 0 base-size))) (all-md (completion--metadata (buffer-substring-no-properties start (point)) @@ -2226,9 +2306,10 @@ minibuffer-completion-help (body-function . ,#'(lambda (_window) (with-current-buffer mainbuf - ;; Remove the base-size tail because `sort' requires a properly - ;; nil-terminated list. - (when last (setcdr last nil)) + ;; Apply highlighting + (setq completions + (funcall (alist-get 'highlight filtered-completions) + completions)) ;; Sort first using the `display-sort-function'. ;; FIXME: This function is for the output of @@ -2267,13 +2348,10 @@ minibuffer-completion-help completions)))) (with-current-buffer standard-output - (setq-local completion-base-position - (list (+ start base-size) - ;; FIXME: We should pay attention to completion - ;; boundaries here, but currently - ;; completion-all-completions does not give us the - ;; necessary information. - end)) + (setq-local + completion-base-position + (list (+ start base-size) + (+ start (alist-get 'end filtered-completions)))) (setq-local completion-list-insert-choice-function (let ((ctable minibuffer-completion-table) (cpred minibuffer-completion-predicate) @@ -3223,10 +3301,11 @@ completion-emacs21-try-completion completion))) (defun completion-emacs21-all-completions (string table pred _point) - (completion-hilit-commonality + (completion--deferred-hilit (all-completions string table pred) (length string) - (car (completion-boundaries string table pred "")))) + (car (completion-boundaries string table pred "")) + (length string))) (defun completion-emacs22-try-completion (string table pred point) (let ((suffix (substring string point)) @@ -3249,11 +3328,12 @@ completion-emacs22-try-completion (cons (concat completion suffix) (length completion))))) (defun completion-emacs22-all-completions (string table pred point) - (let ((beforepoint (substring string 0 point))) - (completion-hilit-commonality + (let* ((beforepoint (substring string 0 point)) + (afterpoint (substring string point)) + (bounds (completion-boundaries beforepoint table pred afterpoint))) + (completion--deferred-hilit (all-completions beforepoint table pred) - point - (car (completion-boundaries beforepoint table pred ""))))) + point (car bounds) (+ point (cdr bounds))))) ;;; Basic completion. @@ -3312,7 +3392,7 @@ completion-basic-all-completions 'point (substring afterpoint 0 (cdr bounds))))) (all (completion-pcm--all-completions prefix pattern table pred))) - (completion-hilit-commonality all point (car bounds)))) + (completion--deferred-hilit all point (car bounds) (+ point (cdr bounds))))) ;;; Partial-completion-mode style completion. @@ -3504,13 +3584,25 @@ flex-score-match-tightness than the latter (which has two \"holes\" and three one-letter-long matches).") +(defun completion-pcm--deferred-hilit (pattern completions base end) + "Return completions in old format or new alist format. +If `completion--filter-completions' is non-nil use the new format." + (when completions + (if completion--filter-completions + `((base . ,base) + (end . ,end) + (highlight . ,(apply-partially + #'completion-pcm--hilit-commonality + pattern)) + (completions . ,completions)) + (nconc (completion-pcm--hilit-commonality pattern completions) base)))) + (defun completion-pcm--hilit-commonality (pattern completions) "Show where and how well PATTERN matches COMPLETIONS. PATTERN, a list of symbols and strings as seen `completion-pcm--merge-completions', is assumed to match every string in COMPLETIONS. Return a deep copy of COMPLETIONS where -each string is propertized with `completion-score', a number -between 0 and 1, and with faces `completions-common-part', +each string is propertized with faces `completions-common-part', `completions-first-difference' in the relevant segments." (when completions (let* ((re (completion-pcm--pattern->regex pattern 'group)) @@ -3525,6 +3617,54 @@ completion-pcm--hilit-commonality (error "Internal error: %s does not match %s" re str)) (let* ((pos (if point-idx (match-beginning point-idx) (match-end 0))) (match-end (match-end 0)) + (md (cddr (setq last-md (match-data t last-md)))) + (from 0)) + (while md + (add-face-text-property from (pop md) + 'completions-common-part + nil str) + (setq from (pop md))) + ;; If `pattern' doesn't have an explicit trailing any, the + ;; regex `re' won't produce match data representing the + ;; region after the match. We need to account to account + ;; for that extra bit of match (bug#42149). + (unless (= from match-end) + (add-face-text-property from match-end + 'completions-common-part + nil str)) + (if (> (length str) pos) + (add-face-text-property + pos (1+ pos) + 'completions-first-difference + nil str))) + str) + completions)))) + +(defun completion--flex-score (pattern completions) + "Compute how well PATTERN matches COMPLETIONS. +PATTERN, a list of strings is assumed to match every string in +COMPLETIONS. Return a copy of COMPLETIONS where each element is +a pair of a score and the completion string. The score lies in +the range between -1 and 0, where -1 corresponds to the full +match." + (when completions + (let* ((re (completion-pcm--pattern->regex pattern 'group)) + (case-fold-search completion-ignore-case) + last-md) + (mapcar + (lambda (str) + ;; The flex completion style requires the completion to match + ;; the pattern to compute the scoring. For quoted completion + ;; tables the completions are matched against the *unquoted + ;; input string*. However `completion-all-completions' and + ;; `completion-filter-completions' return a list of *quoted + ;; completions*, which is subsequently sorted. Therefore we + ;; obtain the unquoted completion string which is stored in + ;; the text property `completion--unquoted'. + (setq str (or (get-text-property 0 'completion--unquoted str) str)) + (unless (string-match re str) + (error "Internal error: %s does not match %s" re str)) + (let* ((match-end (match-end 0)) (md (cddr (setq last-md (match-data t last-md)))) (from 0) (end (length str)) @@ -3564,13 +3704,10 @@ completion-pcm--hilit-commonality ;; , where "len" is the string's length. (score-numerator 0) (score-denominator 0) - (last-b 0) - (update-score-and-face - (lambda (a b) - "Update score and face given match range (A B)." - (add-face-text-property a b - 'completions-common-part - nil str) + (last-b 0)) + (while md + (let ((a from) + (b (pop md))) (setq score-numerator (+ score-numerator (- b a))) (unless (or (= a last-b) @@ -3583,26 +3720,29 @@ completion-pcm--hilit-commonality (/ 1.0 flex-score-match-tightness))))) (setq - last-b b)))) - (while md - (funcall update-score-and-face from (pop md)) + last-b b)) (setq from (pop md))) ;; If `pattern' doesn't have an explicit trailing any, the ;; regex `re' won't produce match data representing the ;; region after the match. We need to account to account ;; for that extra bit of match (bug#42149). (unless (= from match-end) - (funcall update-score-and-face from match-end)) - (if (> (length str) pos) - (add-face-text-property - pos (1+ pos) - 'completions-first-difference - nil str)) - (unless (zerop (length str)) - (put-text-property - 0 1 'completion-score - (/ score-numerator (* end (1+ score-denominator)) 1.0) str))) - str) + (let ((a from) + (b match-end)) + (setq + score-numerator (+ score-numerator (- b a))) + (unless (or (= a last-b) + (zerop last-b) + (= a (length str))) + (setq + score-denominator (+ score-denominator + 1 + (expt (- a last-b 1) + (/ 1.0 + flex-score-match-tightness))))) + (setq + last-b b))) + (cons (- (/ score-numerator (* end (1+ score-denominator)) 1.0)) str))) completions)))) (defun completion-pcm--find-all-completions (string table pred point @@ -3700,11 +3840,11 @@ completion-pcm--find-all-completions (list pattern all prefix suffix))))) (defun completion-pcm-all-completions (string table pred point) - (pcase-let ((`(,pattern ,all ,prefix ,_suffix) + (pcase-let ((`(,pattern ,all ,prefix ,suffix) (completion-pcm--find-all-completions string table pred point))) - (when all - (nconc (completion-pcm--hilit-commonality pattern all) - (length prefix))))) + (completion-pcm--deferred-hilit pattern all + (length prefix) + (- (length string) (length suffix))))) (defun completion--common-suffix (strs) "Return the common suffix of the strings STRS." @@ -3885,8 +4025,8 @@ completion-pcm-try-completion ;;; Substring completion ;; Mostly derived from the code of `basic' completion. -(defun completion-substring--all-completions - (string table pred point &optional transform-pattern-fn) +(defun completion--pattern-compiler + (string table pred point transform-pattern-fn) "Match the presumed substring STRING to the entries in TABLE. Respect PRED and POINT. The pattern used is a PCM-style substring pattern, but it be massaged by TRANSFORM-PATTERN-FN, if @@ -3904,12 +4044,23 @@ completion-substring--all-completions (pattern (completion-pcm--optimize-pattern (if transform-pattern-fn (funcall transform-pattern-fn pattern) - pattern))) - (all (completion-pcm--all-completions prefix pattern table pred))) - (list all pattern prefix suffix (car bounds)))) + pattern)))) + (list pattern prefix suffix))) + +(defun completion-substring--all-completions + (string table pred point &optional transform-pattern-fn) + "Match the presumed substring STRING to the entries in TABLE. +Respect PRED and POINT. The pattern used is a PCM-style +substring pattern, but it be massaged by TRANSFORM-PATTERN-FN, if +that is non-nil." + (pcase-let (((and result `(,pattern ,prefix ,_suffix)) + (completion--pattern-compiler string table pred point + transform-pattern-fn))) + (cons (completion-pcm--all-completions prefix pattern table pred) + result))) (defun completion-substring-try-completion (string table pred point) - (pcase-let ((`(,all ,pattern ,prefix ,suffix ,_carbounds) + (pcase-let ((`(,all ,pattern ,prefix ,suffix) (completion-substring--all-completions string table pred point))) (if minibuffer-completing-file-name @@ -3917,12 +4068,12 @@ completion-substring-try-completion (completion-pcm--merge-try pattern all prefix suffix))) (defun completion-substring-all-completions (string table pred point) - (pcase-let ((`(,all ,pattern ,prefix ,_suffix ,_carbounds) + (pcase-let ((`(,all ,pattern ,prefix ,suffix) (completion-substring--all-completions string table pred point))) - (when all - (nconc (completion-pcm--hilit-commonality pattern all) - (length prefix))))) + (completion-pcm--deferred-hilit pattern all + (length prefix) + (- (length string) (length suffix))))) ;;; "flex" completion, also known as flx/fuzzy/scatter completion ;; Completes "foo" to "frodo" and "farfromsober" @@ -3932,42 +4083,40 @@ completion-flex-nospace :version "27.1" :type 'boolean) -(put 'flex 'completion--adjust-metadata 'completion--flex-adjust-metadata) - -(defun completion--flex-adjust-metadata (metadata) - (cl-flet - ((compose-flex-sort-fn - (existing-sort-fn) ; wish `cl-flet' had proper indentation... - (lambda (completions) - (let ((pre-sorted - (if existing-sort-fn - (funcall existing-sort-fn completions) - completions))) - (cond - ((or (not (window-minibuffer-p)) - ;; JT@2019-12-23: FIXME: this is still wrong. What - ;; we need to test here is "some input that actually - ;; leads to flex filtering", not "something after - ;; the minibuffer prompt". Among other - ;; inconsistencies, the latter is always true for - ;; file searches, meaning the next clauses will be - ;; ignored. - (> (point-max) (minibuffer-prompt-end))) - (sort - pre-sorted - (lambda (c1 c2) - (let ((s1 (get-text-property 0 'completion-score c1)) - (s2 (get-text-property 0 'completion-score c2))) - (> (or s1 0) (or s2 0)))))) - (t pre-sorted)))))) - `(metadata - (display-sort-function - . ,(compose-flex-sort-fn - (completion-metadata-get metadata 'display-sort-function))) - (cycle-sort-function - . ,(compose-flex-sort-fn - (completion-metadata-get metadata 'cycle-sort-function))) - ,@(cdr metadata)))) +(put 'flex 'completion--style-metadata 'completion--flex-style-metadata) + +(defun completion--flex-style-metadata (string table pred point metadata) + ;; Use the modified flex sorting function only for non-empty input. + ;; In an older version of `completion--flex-adjust-metadata', the + ;; check (> (point-max) (minibuffer-prompt-end))) was used instead. + (unless (eq string "") + (let ((pattern (car (completion--pattern-compiler + string table pred point + #'completion-flex--make-flex-pattern)))) + (cl-flet + ((compose-flex-sort-fn + (existing-sort-fn) ; wish `cl-flet' had proper indentation... + (lambda (completions) + (let* ((sorted (sort (completion--flex-score + pattern + (if existing-sort-fn + (funcall existing-sort-fn completions) + completions)) + #'car-less-than-car)) + (cell sorted)) + ;; Remove score decorations, reuse the list to avoid allocations. + (while cell + (setcar cell (cdar cell)) + (pop cell)) + sorted)))) + `(metadata + (display-sort-function + . ,(compose-flex-sort-fn + (completion-metadata-get metadata 'display-sort-function))) + (cycle-sort-function + . ,(compose-flex-sort-fn + (completion-metadata-get metadata 'cycle-sort-function))) + ,@(cdr metadata)))))) (defun completion-flex--make-flex-pattern (pattern) "Convert PCM-style PATTERN into PCM-style flex pattern. @@ -3989,7 +4138,7 @@ completion-flex--make-flex-pattern (defun completion-flex-try-completion (string table pred point) "Try to flex-complete STRING in TABLE given PRED and POINT." (unless (and completion-flex-nospace (string-search " " string)) - (pcase-let ((`(,all ,pattern ,prefix ,suffix ,_carbounds) + (pcase-let ((`(,all ,pattern ,prefix ,suffix) (completion-substring--all-completions string table pred point #'completion-flex--make-flex-pattern))) @@ -4006,13 +4155,13 @@ completion-flex-try-completion (defun completion-flex-all-completions (string table pred point) "Get flex-completions of STRING in TABLE, given PRED and POINT." (unless (and completion-flex-nospace (string-search " " string)) - (pcase-let ((`(,all ,pattern ,prefix ,_suffix ,_carbounds) + (pcase-let ((`(,all ,pattern ,prefix ,suffix) (completion-substring--all-completions string table pred point #'completion-flex--make-flex-pattern))) - (when all - (nconc (completion-pcm--hilit-commonality pattern all) - (length prefix)))))) + (completion-pcm--deferred-hilit pattern all + (length prefix) + (- (length string) (length suffix)))))) ;; Initials completion ;; Complete /ums to /usr/monnier/src or lch to list-command-history. @@ -4049,7 +4198,11 @@ completion-initials-expand (defun completion-initials-all-completions (string table pred _point) (let ((newstr (completion-initials-expand string table pred))) (when newstr - (completion-pcm-all-completions newstr table pred (length newstr))))) + (pcase-let ((`(,pattern ,all ,prefix ,_suffix) + (completion-pcm--find-all-completions newstr table + pred (length newstr)))) + (completion-pcm--deferred-hilit pattern all + (length prefix) (length string)))))) (defun completion-initials-try-completion (string table pred _point) (let ((newstr (completion-initials-expand string table pred))) diff --git a/test/lisp/minibuffer-tests.el b/test/lisp/minibuffer-tests.el index c3ba8f9a92..4ebf27fd1d 100644 --- a/test/lisp/minibuffer-tests.el +++ b/test/lisp/minibuffer-tests.el @@ -188,10 +188,6 @@ completion-all-sorted-completions '("some/alpha" "base/epsilon" "base/delta")) `("epsilon" "delta" "beta" "alpha" "gamma" . 5)))) -(defun completion--pcm-score (comp) - "Get `completion-score' from COMP." - (get-text-property 0 'completion-score comp)) - (defun completion--pcm-first-difference-pos (comp) "Get `completions-first-difference' from COMP." (cl-loop for pos = (next-single-property-change 0 'face comp) @@ -215,25 +211,12 @@ completion-pcm-test-2 "barfoobar"))) (ert-deftest completion-pcm-test-3 () - ;; Full match! - (should (eql - (completion--pcm-score - (car (completion-pcm-all-completions - "R" '("R" "hello") nil 1))) - 1.0))) - -(ert-deftest completion-pcm-test-4 () - ;; One fourth of a match and no match due to point being at the end - (should (eql - (completion--pcm-score - (car (completion-pcm-all-completions - "RO" '("RaOb") nil 1))) - (/ 1.0 4.0))) + ;; No match due to point being at the end (should (null (completion-pcm-all-completions "RO" '("RaOb") nil 2)))) -(ert-deftest completion-pcm-test-5 () +(ert-deftest completion-pcm-test-4 () ;; Since point is at the beginning, there is nothing that can really ;; be typed anymore (should (null @@ -241,7 +224,7 @@ completion-pcm-test-5 (car (completion-pcm-all-completions "f" '("few" "many") nil 0)))))) -(ert-deftest completion-pcm-test-6 () +(ert-deftest completion-pcm-test-5 () ;; Wildcards and delimiters work (should (equal (car (completion-pcm-all-completions @@ -252,26 +235,12 @@ completion-pcm-test-6 "li-pac*" '("do-not-list-packages") nil 7))))) (ert-deftest completion-substring-test-1 () - ;; One third of a match! (should (equal (car (completion-substring-all-completions "foo" '("hello" "world" "barfoobar") nil 3)) - "barfoobar")) - (should (eql - (completion--pcm-score - (car (completion-substring-all-completions - "foo" '("hello" "world" "barfoobar") nil 3))) - (/ 1.0 3.0)))) + "barfoobar"))) (ert-deftest completion-substring-test-2 () - ;; Full match! - (should (eql - (completion--pcm-score - (car (completion-substring-all-completions - "R" '("R" "hello") nil 1))) - 1.0))) - -(ert-deftest completion-substring-test-3 () ;; Substring match (should (equal (car (completion-substring-all-completions @@ -281,7 +250,7 @@ completion-substring-test-3 (car (completion-substring-all-completions "custgroup" '("customize-group") nil 5))))) -(ert-deftest completion-substring-test-4 () +(ert-deftest completion-substring-test-3 () ;; `completions-first-difference' should be at the right place (should (eql (completion--pcm-first-difference-pos @@ -306,14 +275,6 @@ completion-flex-test-1 "fabrobazo"))) (ert-deftest completion-flex-test-2 () - ;; Full match! - (should (eql - (completion--pcm-score - (car (completion-flex-all-completions - "R" '("R" "hello") nil 1))) - 1.0))) - -(ert-deftest completion-flex-test-3 () ;; Another fuzzy match, but more of a "substring" one (should (equal (car (completion-flex-all-completions @@ -331,5 +292,213 @@ completion-flex-test-3 "custgroup" '("customize-group-other-window") nil 9))) 15))) +(ert-deftest completion-flex-score-test-1 () + ;; Full match! + (should (equal + (completion--flex-score '(prefix "R") '("R")) + (list (cons -1.0 "R"))))) + +(ert-deftest completion-flex-score-test-2 () + ;; One third and half of a match! + (should (equal + (completion--flex-score '(prefix "foo") + '("barfoobar" "fooboo")) + (list (cons (/ -1.0 3.0) "barfoobar") + (cons (/ -1.0 2.0) "fooboo"))))) + +(ert-deftest completion-flex-score-test-3 () + ;; One fourth of a match + (should (eql + (caar (completion--flex-score '(prefix "R" point "O") + '("RaOb"))) + (/ -1.0 4.0)))) + +(ert-deftest completion-flex-score-test-4 () + ;; For quoted completion tables, score the unquoted completion string. + (should (equal + (completion--flex-score + '(prefix "R") + (list (propertize "X" 'completion--unquoted "R"))) + (list (cons -1.0 "R"))))) + +(defun completion--test-style (style string point table filtered) + (let* ((completion-styles (list style)) + (pred (lambda (x) (not (string-search "!" x)))) + (result (completion-filter-completions + string table pred point nil))) + (should (equal (alist-get 'base result) 0)) + (should (equal (alist-get 'end result) (length string))) + (should (equal (alist-get 'completions result) filtered)) + (should (not (memq (alist-get 'highlight result) '(nil identity)))) + (should (equal (completion-all-completions string table pred point) + (append filtered 0))))) + +(ert-deftest completion-basic-style-test-1 () + ;; point at the beginning |foo + (completion--test-style 'basic "foo" 0 + '("foobar" "foo!" "barfoo" "xfooy" "boobar") + '("foobar" "barfoo" "xfooy"))) + +(ert-deftest completion-basic-style-test-2 () + ;; point foo + (completion--test-style 'basic "foo" 2 + '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar") + '("foobar"))) + +(ert-deftest completion-substring-style-test () + (completion--test-style 'substring "foo" 1 + '("foobar" "foo!" "barfoo" "xfooy" "boobar") + '("foobar" "barfoo" "xfooy"))) + +(ert-deftest completion-emacs21-style-test () + (completion--test-style 'emacs21 "foo" 1 + '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar") + '("foobar"))) + +(ert-deftest completion-emacs22-style-test () + (completion--test-style 'emacs22 "fo0" 1 + '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar") + '("foobar" "fobar"))) ;; suffix ignored completely + +(ert-deftest completion-flex-style-test () + (completion--test-style 'flex "abc" 1 + '("abc" "abc!" "xaybzc" "xaybz") + '("abc" "xaybzc"))) + +(ert-deftest completion-initials-style-test () + (completion--test-style 'initials "abc" 1 + '("a-b-c" "a-b-c!" "ax-by-cz" "xax-by-cz") + '("a-b-c" "ax-by-cz"))) + +(ert-deftest completion-pcm-style-test () + (completion--test-style 'partial-completion "ax-b-c" 1 + '("ax-b-c" "ax-b-c!" "ax-by-cz" "xax-by-cz") + '("ax-b-c" "ax-by-cz"))) + +(ert-deftest completion-filter-completions-highlight-test () + ;; point at the beginning |foo + (let* ((completion-styles '(basic)) + (result (completion-filter-completions + "foo" '("foobar" "fbarfoo" "fxfooy" "bar") + nil 1 nil))) + (should (equal + (format "%S" (alist-get 'completions result)) + (format "%S" '("foobar" "fbarfoo" "fxfooy")))) + (should (equal + (format "%S" (funcall (alist-get 'highlight result) + (alist-get 'completions result))) + (format "%S" + '(#("foobar" 0 1 (face (completions-common-part)) + 1 2 (face (completions-first-difference))) + #("fbarfoo" 0 1 (face (completions-common-part)) + 1 2 (face (completions-first-difference))) + #("fxfooy" 0 1 (face (completions-common-part)) + 1 2 (face (completions-first-difference))))))))) + +(defun completion--test-boundaries (style string table result) + (let ((table + (lambda (str pred action) + (pcase action + (`(boundaries . ,suffix) `(boundaries + ,(1+ (string-match-p "<\\|/" str)) + . ,(or (string-search ">" suffix) (length suffix)))) + (_ (complete-with-action action table + (replace-regexp-in-string ".*[after" + '("other") nil) + (completion--test-boundaries 'emacs21 "beforeafter" + '("ainput>after" "input>after" "inpux>after" + "inxputy>after" "input>after2") + '((base . 7) + (end . 18) + (completions "input>after" "input>after2")))) + +(ert-deftest completion-emacs22-boundaries-test () + (completion--test-boundaries 'emacs22 "beforeafter" + '("other") nil) + (completion--test-boundaries 'emacs22 "beforeafter" + '("ainxxx" "inyy" "inzzz") + '((base . 7) + (end . 12) + (completions "inyy" "inzzz")))) + +(ert-deftest completion-basic-boundaries-test () + (completion--test-boundaries 'basic "beforeafter" + '("other") nil) + (completion--test-boundaries 'basic "beforeafter" + '("ainput" "input" "inpux" "inxputy") + '((base . 7) + (end . 12) + (completions "input" "inxputy")))) + +(ert-deftest completion-substring-boundaries-test () + (completion--test-boundaries 'substring "beforeafter" + '("other") nil) + (completion--test-boundaries 'substring "beforeafter" + '("ainputs" "inputs" "inpux" "inxputsy") + '((base . 7) + (end . 13) + (completions "ainputs" "inputs" "inxputsy")))) + +(ert-deftest completion-pcm-boundaries-test () + (completion--test-boundaries 'partial-completion "beforeafter" + '("other") nil) + (completion--test-boundaries 'partial-completion "beforeafter" + '("ain-pu-ts" "in-pts" "in-pu-ts" "in-px" "inx-ptsy") + '((base . 7) + (end . 12) + (completions "in-pts" "in-pu-ts" "inx-ptsy")))) + +(ert-deftest completion-initials-boundaries-test () + (completion--test-boundaries 'initials "/ip|t" + '("other") nil) + (completion--test-boundaries 'initials "/ip|t" + '("ain/pu/ts" "in/pts" "in/pu/ts" "a/in/pu/ts" + "in/pu/ts/foo" "in/px" "inx/ptsy") + '((base . 1) + (end . 4) + (completions "in/pu/ts" "in/pu/ts/foo")))) + +(defun completion-emacs22orig-all-completions (string table pred point) + (let ((beforepoint (substring string 0 point))) + (completion-hilit-commonality + (all-completions beforepoint table pred) + point + (car (completion-boundaries beforepoint table pred ""))))) + +(ert-deftest completion-upgrade-return-type-test () + ;; Test transparent upgrade of old completion style return value + ;; to new return value format. + (let ((completion-styles-alist + '((emacs22orig completion-emacs22-try-completion + completion-emacs22orig-all-completions nil)))) + (completion--test-boundaries 'emacs22orig "beforeafter" + '("ainxxx" "inyy" "inzzz") + '((base . 7) + ;; 18 is incorrect, should be 12! + ;; But the information is not available + ;; due to the completion-style upgrade. + (end . 18) + ;; Identity highlighting function. + (highlight . identity) + (completions "inyy" "inzzz"))))) + (provide 'minibuffer-tests) ;;; minibuffer-tests.el ends here -- 2.20.1 --------------3147CDE26CD3C1A11006A179-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Aug 2021 16:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: "emacs-devel@gnu.org" Cc: 48841@debbugs.gnu.org, Dmitry Gutov , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Stefan Monnier , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162869829113453 (code B ref 48841); Wed, 11 Aug 2021 16:12:02 +0000 Received: (at 48841) by debbugs.gnu.org; 11 Aug 2021 16:11:31 +0000 Received: from localhost ([127.0.0.1]:36384 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDqpG-0003Ut-SC for submit@debbugs.gnu.org; Wed, 11 Aug 2021 12:11:31 -0400 Received: from server.qxqx.de ([178.63.65.180]:60351 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDqpF-0003UZ-3i; Wed, 11 Aug 2021 12:11:29 -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:References:Cc:To:From: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=L9YD2Rbs2yUeev3cPOFCPRt64IqdN05dDBBAfML4R0Y=; b=PYVBp5sBBCAoJ4YvgPqbbwiiXL IuVLkgk+39f09D7qa9siQeSn5VpG+WNb4+9wvgzxTMubp8aXRfRL9GfhgFqd7ORoZhAwiv0T5G5KC i2ckBeXWHmESGnVZ3uZ7cQ/fP1vXU8fQja7S3gO1j634WEiBrgFDUNflZQz1n2BV8CGc=; From: Daniel Mendler References: Message-ID: Date: Wed, 11 Aug 2021 18:11:21 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/11/21 4:16 PM, Daniel Mendler wrote: > I prepared a patch which provides the API > `completion-filter-completions`. This function supports deferred > highlighting and returns additional data with the list of matching > completion candidates. The API supersedes the existing function > `completion-all-completions`. > > The main goal of the new API is to avoid expensive string allocations > and highlighting during completion. This is particularly relevant for > continuously updating completion UIs like Icomplete or Vertico. > Furthermore the end position of the completion boundaries is returned > with the completion results. This information is not provided by the > existing `completion-all-completions` API. > > See also the relevant bugs bug#47711 and bug#48841. I am looking forward > to your feedback. Thank you! There are currently two issues with the patch with regards to backward compatibility. Fortunately they are fixable with a little effort. 1. I would like to deprecate `completion-score' or remove it altogether, but unfortunately `completion-score' is used in the wild. In order to preserve `completion-score', bind `completion--filter-completions' in the highlighting functions. Add `completion-score' in `completion-pcm--hilit-commonality' when `completion--filter-completions' is nil. 2. In `completion--nth-completion' set `completion--filter-completions' to nil, unless `(memq style '(emacs21 emacs22 basic partial-completion initials flex))' such that custom completion styles which wrap the completion functions don't see the new return value format, except if the custom style opts in explicitly by binding `completion--filter-completions'. An alternative criterion is `(memq fun '(completion-emacs22-all-completions) ...)'. Unfortunately this approach will still not work if the user has advised a `completion-x-all-completions' function. The only 100% safe approach seems to transparently redirect calls to `completion-x-all-completions' to `completion--x-filter-completions', which returns the results in the new format. With these changes the patch should be 100% backward compatible. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Wed, 11 Aug 2021 16:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: 47711@debbugs.gnu.org, Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, "emacs-devel@gnu.org" Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162869864821796 (code B ref 48841); Wed, 11 Aug 2021 16:18:02 +0000 Received: (at 48841) by debbugs.gnu.org; 11 Aug 2021 16:17:28 +0000 Received: from localhost ([127.0.0.1]:36394 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDqv2-0005f0-5Q for submit@debbugs.gnu.org; Wed, 11 Aug 2021 12:17:28 -0400 Received: from mail-pj1-f52.google.com ([209.85.216.52]:42550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mDquz-0005ZI-D2; Wed, 11 Aug 2021 12:17:26 -0400 Received: by mail-pj1-f52.google.com with SMTP id mq2-20020a17090b3802b0290178911d298bso5839129pjb.1; Wed, 11 Aug 2021 09:17:25 -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=jA8E40VtlAuX0iMEkWlyJ13M+vYAfR9CULGNzYrMWuw=; b=nqcIq4vOrpqIwPVP+7LOt4OpWbiWWrogS1eHgcHDa+vtPH3Ha0L1qzKb8X4HN7V5s9 YZ0gwitcOOhmL8STj5M8Z+dbTpuziDlwrWH6eWNnp75JcAKnCAD+/Vh2y+yBNgzr3a10 YhROHr/KYUsOIcV/5Auj+FMbg2InwANm0FFPpUXlOktGbLo1376Vm2WL8kBg6PLjoUgX 3HEkWQg3QGPpF0tkSrmYTnchgUFZKmkaZOEXuJE/+qDE0cpoVjOaE2bzNLGJiX+iMQac lZNhoyzC7vgfvHed3pwZIAxGNM+hp5J29mlwnpKLsgpdGXVgOm2HtDlQonDhXSLUMuKs FduQ== 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=jA8E40VtlAuX0iMEkWlyJ13M+vYAfR9CULGNzYrMWuw=; b=SOA8e6x4uRSrmAteCOOcUkm3Wc//TKG1aUAO0VpyNZo23J9oLGpXKmrO4CwiWzawqq oMzOmbDbZwvpxK2fht4BSlDfbVlMVT5A4ResIlgi9MokNykxQJ83ObqmYUSrUayD9B/1 QdNn1r9/JhDMqAJAxod8u10v4bpt4OUDSLg/pm6c8eM+2Ogj4psMkTdfGlAyzHABjrFx dhg1Dt0hGftCHeyZ5qtbYX1RWkZwGaQnBeboDpBmkG5kwEHn7jeUFpkH0VDD7wqtypWk tk1mkGfjpL16Yu398Z8Oi6jf0W/p87EmReZnuO1tJaflpo/nnWtaAHAXDM3p3gIhxXyj 3bIg== X-Gm-Message-State: AOAM533lMhyMxqZtgJ6+NSfSSwwNOHnH5JlHjTOqTWHT4jh7pBDSCOAJ urUK93eFKxO3eU+2okNK5X1/EUPTFArte+8c/rw= X-Google-Smtp-Source: ABdhPJyP0fKKy0TCf0MVCKV4sAlwqv6ZxwwQMS5d//O3nf4QoGUYY3eWz0YesAADm/rqyracNgAd497dBs1yi5ai1Rg= X-Received: by 2002:aa7:9050:0:b029:3af:7e99:f48f with SMTP id n16-20020aa790500000b02903af7e99f48fmr29318366pfo.2.1628698639473; Wed, 11 Aug 2021 09:17:19 -0700 (PDT) MIME-Version: 1.0 References: In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Wed, 11 Aug 2021 17:17:07 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Perhaps you should first provide a patch with these 2 "little effort" chang= es, (that are presumably also backward compatible and don't affect the API) by themselves. Reading about these complex ideas isn't as clear as seeing them in actual code. Then it'll be easier to evaluate the merits of the patch you proposed in your first email. Jo=C3=A3o On Wed, Aug 11, 2021 at 5:11 PM Daniel Mendler wro= te: > > On 8/11/21 4:16 PM, Daniel Mendler wrote: > > I prepared a patch which provides the API > > `completion-filter-completions`. This function supports deferred > > highlighting and returns additional data with the list of matching > > completion candidates. The API supersedes the existing function > > `completion-all-completions`. > > > > The main goal of the new API is to avoid expensive string allocations > > and highlighting during completion. This is particularly relevant for > > continuously updating completion UIs like Icomplete or Vertico. > > Furthermore the end position of the completion boundaries is returned > > with the completion results. This information is not provided by the > > existing `completion-all-completions` API. > > > > See also the relevant bugs bug#47711 and bug#48841. I am looking forwar= d > > to your feedback. Thank you! > > There are currently two issues with the patch with regards to backward > compatibility. Fortunately they are fixable with a little effort. > > 1. I would like to deprecate `completion-score' or remove it altogether, > but unfortunately `completion-score' is used in the wild. In order to > preserve `completion-score', bind `completion--filter-completions' in > the highlighting functions. Add `completion-score' in > `completion-pcm--hilit-commonality' when > `completion--filter-completions' is nil. > > 2. In `completion--nth-completion' set `completion--filter-completions' > to nil, unless `(memq style '(emacs21 emacs22 basic > partial-completion initials flex))' such that custom completion > styles which wrap the completion functions don't see the new return > value format, except if the custom style opts in explicitly by > binding `completion--filter-completions'. An alternative criterion is > `(memq fun '(completion-emacs22-all-completions) ...)'. Unfortunately > this approach will still not work if the user has advised a > `completion-x-all-completions' function. The only 100% safe approach > seems to transparently redirect calls to > `completion-x-all-completions' to `completion--x-filter-completions', > which returns the results in the new format. > > With these changes the patch should be 100% backward compatible. > > Daniel --=20 Jo=C3=A3o T=C3=A1vora From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Aug 2021 08:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162875524128809 (code B ref 48841); Thu, 12 Aug 2021 08:01:02 +0000 Received: (at 48841) by debbugs.gnu.org; 12 Aug 2021 08:00:41 +0000 Received: from localhost ([127.0.0.1]:37406 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mE5do-0007UU-RS for submit@debbugs.gnu.org; Thu, 12 Aug 2021 04:00:41 -0400 Received: from eggs.gnu.org ([209.51.188.92]:46316) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mE5dl-0007U9-G8; Thu, 12 Aug 2021 04:00:38 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:58862) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mE5dd-0002GC-RB; Thu, 12 Aug 2021 04:00:29 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3162 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mE5dd-0008LK-Eb; Thu, 12 Aug 2021 04:00:29 -0400 Date: Thu, 12 Aug 2021 11:00:11 +0300 Message-Id: <837dgrdrec.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Mendler on Wed, 11 Aug 2021 16:16:57 +0200) References: MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) [I removed emacs-devel from the CC list, please don't cross-post to both emacs-devel and the bug tracker.] > From: Daniel Mendler > Date: Wed, 11 Aug 2021 16:16:57 +0200 > Cc: 48841@debbugs.gnu.org, Dmitry Gutov , > João Távora , > Stefan Monnier , 47711@debbugs.gnu.org > > I prepared a patch which provides the API > `completion-filter-completions`. This function supports deferred > highlighting and returns additional data with the list of matching > completion candidates. The API supersedes the existing function > `completion-all-completions`. Thanks. The discussion of this is still going on, and I don't consider myself an expert in this area of Emacs, so below please find only comments for minor formatting and documentation aspects. > Add a new `completion-filter-completions` API, which supersedes > `completion-all-completions`. The new API returns the matching > completion candidates and additional data. The return value is an > alist, with the keys `completions`, `base`, `end` and `highlight`. > The API can be extended in a backward compatible way later on thanks > to the use of an alist as return value. Please don't use Markdown-style quoting `like this` in our comments and log messages. We quote 'like this' in these places. > The `completions` value is the list of completion strings *without* > applied highlighting. The completion strings are returned unmodified, > which avoids allocations and results in performance gains for This is unclear: how can you return a list of strings which you produce without allocating the strings? > The value `base` is the base position of the completion. "Base position" where, or relative to what object? > Correspondingly the value `end` specifies the end position of the > completion counted from the beginning of the input strng. So the base position is also relative to the beginning of the input string? If so, please say so explicitly. > Finally the > `highlight` value is a function taking a list of completion strings > and returns a new list of new strings with highlighting applied. If you say "taking a list...", then for consistent style please also say "...and returning a new list...". > A continously updating UI can use the highlighting function to apply > highlighting only to the visible completions. Not, "visible", but "displayed", right? So I'd rephrase ...to apply highlighting only to the completions that are actually displayed. > (completion-basic-all-completions, > completion-emacs21-all-completions, > completion-emacs22-all-completions): Use it. That's incorrect format, I guess you did it by hand rather than letting change-log-mode do it for you? The correct format looks like this: (completion-basic-all-completions) (completion-emacs21-all-completions) (completion-emacs22-all-completions): use it. IOW, each line ends with a closing parentheses, not a comma. > +(defvar completion--filter-completions nil > + "Enable the new completions return value format. Using genitive construction should be limited to just 2 words. Here you have 4, which produces an awkward, hard to interpret phrase. Suggest to reword: If non-nil, return completions in `completion-filter-completions' format. Note that I also dropped the "new" part (which generally doesn't stand the test of time), and instead gave a hint as to what that format is. Btw, why is this an internal variable? Shouldn't all completion styles ideally support it? If so, it should be a public variable, documented in the ELisp manual. And the name should also end with -p, since it's a boolean. How about completion-filter-completions-format-p? > + New completion style functions may always return their > +results in the new alist format, since `completion-all-completions' > +transparently converts back to the old improper list of completions > +with base size in the last cdr.") "may" and "always" are a kind of contradiction. Also, I'd drop the "improper" part, as it sounds like a derogatory adjective. > (defun completion-try-completion (string table pred point &optional metadata) > "Try to complete STRING using completion table TABLE. > Only the elements of table that satisfy predicate PRED are considered. > -POINT is the position of point within STRING. > -The return value can be either nil to indicate that there is no completion, > -t to indicate that STRING is the only possible completion, > -or a pair (NEWSTRING . NEWPOINT) of the completed result string together with > -a new position for point." > +POINT is the position of point within STRING. The return value can be > +either nil to indicate that there is no completion, t to indicate that > +STRING is the only possible completion, or a pair (NEWSTRING . NEWPOINT) > +of the completed result string together with a new position for point. > +The METADATA may be modified by the completion style." Here you changed whitespace by filling, and that ruined the intentionally formatted doc string, which made it easy to find the various forms of the return value and the important parts of the doc string. Please keep the original formatting. > (defun completion-all-completions (string table pred point &optional metadata) > "List the possible completions of STRING in completion table TABLE. > Only the elements of table that satisfy predicate PRED are considered. > -POINT is the position of point within STRING. > -The return value is a list of completions and may contain the base-size > -in the last `cdr'." > - ;; FIXME: We need to additionally return the info needed for the > - ;; second part of completion-base-position. > - (completion--nth-completion 2 string table pred point metadata)) > +POINT is the position of point within STRING. The return value is a > +list of completions and may contain the base-size in the last `cdr'. > +The METADATA may be modified by the completion style. This function > +has been superseded by `completion-filter-completions', which returns > +richer information and supports deferred candidate highlighting." Likewise here. Also, the "This function has been superseded..." part should be a new paragraph, so that it stands out. (And I'm not yet sure we indeed want to say "superseded" here, but that's part of the on-going discussion. maybe use a more neutral language here, like "See also".) > + (if (and result (consp (car result))) > + ;; Give the completion styles some freedom! > + ;; If they are targeting Emacs 28 upwards only, they > + ;; may always return a result with deferred > + ;; highlighting. We convert back to the old format > + ;; here by applying the highlighting eagerly. "May always" again. How about "can always" instead? > + (nconc (funcall (cdr (assq 'highlight result)) > + (cdr (assq 'completions result))) > + (cdr (assq 'base result))) > + result))) > + > +(defun completion-filter-completions (string table pred point metadata) > + "Filter the possible completions of STRING in completion table TABLE. Is "filter" really the right word here (in the doc string)? "Filer" means you take a sequence and produce another sequence with some members removed. That's not what this API does, is it? Suggest to use a different name, like completion-completions-alist or completion-all-completions-as-alist. > +Only the elements of table that satisfy predicate PRED are considered. > +POINT is the position of point within STRING. The METADATA may be > +modified by the completion style. The return value is a alist with > +the keys: > + > +- base: Base position of the completion (from the start of STRING) "Base" here means the beginning? If so, why not call it "beg" or somesuch? > +This function supersedes the function `completion-all-completions'." Again, "supersedes" is too strong, IMO. I would say "is a variant of" instead, and explain why this variant could be better suited to some use cases. IOW, explain the upsides (and downsides, if any), and let the programmers decide whether they want this, instead of more-or-less forcing them to use it. > + ;; Deferred highlighting has been requested, but the completion > + ;; style returned a non-deferred result. Convert the result to the ^^ two spaces between sentences, please. > + ;; new alist format. "New" is not a good word here. > + ;; added by the completion machinery. Please start comments with a capital letter. > +(defun completion--deferred-hilit (completions prefix-len base end) > + "Return completions in old format or new alist format. > +If `completion--filter-completions' is non-nil use the new format." Again, please don't use "old" and "new" here, but instead describe explicitly the differences between them, or provide a hyperlink to where that is described. > + ;; Apply highlighting Please end each sentence in a comment with a period. > +(defun completion-pcm--deferred-hilit (pattern completions base end) > + "Return completions in old format or new alist format. > +If `completion--filter-completions' is non-nil use the new format." "Old" and "new" again. > (defun completion-pcm--hilit-commonality (pattern completions) > "Show where and how well PATTERN matches COMPLETIONS. > PATTERN, a list of symbols and strings as seen > `completion-pcm--merge-completions', is assumed to match every > string in COMPLETIONS. Return a deep copy of COMPLETIONS where > -each string is propertized with `completion-score', a number > -between 0 and 1, and with faces `completions-common-part', > +each string is propertized with faces `completions-common-part', > `completions-first-difference' in the relevant segments." Are we really losing the completion-score property here? If so, why? > + ;; If `pattern' doesn't have an explicit trailing any, This is confusing: what do you mean by "explicit trailing any" in the context of patterns? > +(defun completion--flex-score (pattern completions) > + "Compute how well PATTERN matches COMPLETIONS. > +PATTERN, a list of strings is assumed to match every string in > +COMPLETIONS. Is PATTERN really a list? It would be strange for a list to be called PATTERN, and how can a list "match every string in COMPLETIONS"? > Return a copy of COMPLETIONS where each element is > +a pair of a score and the completion string. What is "the completion string" in this case? is it the same string from COMPLETIONS, or is it something else? The doc string leaves that unclear. > The score lies in > +the range between -1 and 0, where -1 corresponds to the full > +match." What score could a partial match have, and what is the meaning of the numerical value for a partial match? From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Aug 2021 08:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16287580511545 (code B ref 48841); Thu, 12 Aug 2021 08:48:02 +0000 Received: (at 48841) by debbugs.gnu.org; 12 Aug 2021 08:47:31 +0000 Received: from localhost ([127.0.0.1]:37524 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mE6N8-0000Oq-OB for submit@debbugs.gnu.org; Thu, 12 Aug 2021 04:47:31 -0400 Received: from server.qxqx.de ([178.63.65.180]:51005 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mE6N5-0000OR-Aa; Thu, 12 Aug 2021 04:47:27 -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=i2BeI1W5p4ITvwSsYZbpZMP46bquNh7WtZnDbLxnDTs=; b=CkXnzKP04T4dpOSSH2ZJ+E38aD YyMJjNahZq7mYM0sODxvUmJLg0HxHEwRzrUnlWF+2rHz9e1q7O4WlG8pPrsbBCyJ/2rOY5IXaMZy5 AtgefXe2+civGL9/WP4+huRNqrnjQtnWrWEvRL+u+OnHMqHcrVrd8SGqA5EUYts6Zv/8=; References: <837dgrdrec.fsf@gnu.org> From: Daniel Mendler Message-ID: Date: Thu, 12 Aug 2021 10:47:17 +0200 MIME-Version: 1.0 In-Reply-To: <837dgrdrec.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli, thank you for your feedback and for pointing me to the mode which helps with the formatting. I will address the documentation and formatting issues as soon as the discussion has concluded. In the following I answer to a few of your questions about technical details. >> The `completions` value is the list of completion strings *without* >> applied highlighting. The completion strings are returned unmodified, >> which avoids allocations and results in performance gains for > > This is unclear: how can you return a list of strings which you > produce without allocating the strings? The function 'completion-filter-completions' receives a completion table as argument. The strings produced by this table are returned unmodified, but of course the completion table has to produce them. For a static completion table (e.g., in the simplest case a list of strings) the completion table itself will not allocate strings. In this scenario 'completion-filter-completions' will not perform any string allocations, only the list will be allocated. This is what leads to major performance gains. >> +(defvar completion--filter-completions nil >> + "Enable the new completions return value format. > > Btw, why is this an internal variable? Shouldn't all completion > styles ideally support it? If so, it should be a public variable, > documented in the ELisp manual. And the name should also end with -p, > since it's a boolean. How about completion-filter-completions-format-p? (As I understood the style guide '-p' is not a good idea for boolean variables, since a value is not a predicate in a strict sense.) To address your technical comment - this variable is precisely what one of the technical difficulties mentioned in my other mail is about. The question is how we can retain backward compatibility of the completion style 'all' functions, e.g., 'completion-basic-all-completions', while still allowing the function to return the newly introduced alist format with more data, which enables 'completion-filter-completions' to perform the efficient deferred highlighting. > Also, the "This function has been superseded..." part should be a new > paragraph, so that it stands out. (And I'm not yet sure we indeed > want to say "superseded" here, but that's part of the on-going > discussion. maybe use a more neutral language here, like "See also".) The new API 'completion-filter-completions' will substitute the existing API 'completion-all-completions'. I only didn't go as far as deprecating the 'completion-all-completions' API right away, but we could also do this. > Is "filter" really the right word here (in the doc string)? "Filer" > means you take a sequence and produce another sequence with some > members removed. That's not what this API does, is it? Suggest to > use a different name, like completion-completions-alist or > completion-all-completions-as-alist. "Filter" seems like exactly the right word to me. The function takes a list of strings (or a completion table) and returns a subset of matching completion strings without further modifications to the strings. See above what I wrote about allocations. >> +Only the elements of table that satisfy predicate PRED are considered. >> +POINT is the position of point within STRING. The METADATA may be >> +modified by the completion style. The return value is a alist with >> +the keys: >> + >> +- base: Base position of the completion (from the start of STRING) > > "Base" here means the beginning? If so, why not call it "beg" or > somesuch? Base position is a fixed term which is already used in minibuffer.el for completions. See also 'completion-base-position' for example. > Are we really losing the completion-score property here? If so, why? Yes, the property is removed in the current patch. It is not actually used for anything in the new implementation. But it is possible to restore the property such that 'completion-all-completions' always returns scored candidates as it does now. See my other mail regarding the caveats of the current patch. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 12 Aug 2021 09:25:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 47711@debbugs.gnu.org, 48841@debbugs.gnu.org Cc: Eli Zaretskii , Dmitry Gutov , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Stefan Monnier Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16287602735217 (code B ref 48841); Thu, 12 Aug 2021 09:25:02 +0000 Received: (at 48841) by debbugs.gnu.org; 12 Aug 2021 09:24:33 +0000 Received: from localhost ([127.0.0.1]:37603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mE6wy-0001M2-Pp for submit@debbugs.gnu.org; Thu, 12 Aug 2021 05:24:33 -0400 Received: from server.qxqx.de ([178.63.65.180]:51191 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mE6ww-0001Lj-MB; Thu, 12 Aug 2021 05:24:31 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID: References:Cc:To:Subject:From:Sender:Reply-To:Content-Transfer-Encoding: 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=1/NAMhdhCAQoAwSar/mnKa6p1gF9Kj9u70aQDXXvs/I=; b=Vz2rFSIR3R1syGGK8FyEjXXWQk /aE6HFJOEWGlR1lQj9n4TNnRltNSdvbHCDMhnPaAq8IYEUTYFvj1uDQnlDzsqR3DpSF4PTU0XrafO MGImMuwtL/NgyHisj+6aeYwg6SVQd9IpELjau6Kfk7qpXv1X4HMtV13SIwadGtDQjPaQ=; From: Daniel Mendler References: Message-ID: Date: Thu, 12 Aug 2021 11:24:22 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------4B3E2A198290BEF506AC64C4" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------4B3E2A198290BEF506AC64C4 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit On 8/11/21 6:11 PM, Daniel Mendler wrote: > 2. In `completion--nth-completion' set `completion--filter-completions' > to nil, unless `(memq style '(emacs21 emacs22 basic > partial-completion initials flex))' such that custom completion > styles which wrap the completion functions don't see the new return > value format, except if the custom style opts in explicitly by > binding `completion--filter-completions'. An alternative criterion is > `(memq fun '(completion-emacs22-all-completions) ...)'. Unfortunately > this approach will still not work if the user has advised a > `completion-x-all-completions' function. The only 100% safe approach > seems to transparently redirect calls to > `completion-x-all-completions' to `completion--x-filter-completions', > which returns the results in the new format. I attached two patch variants which can be placed on top of my previous patch to improve the backward compatibility of the internal API. Variant 1: Set 'completion--return-alist-flag' only for the existing completion styles, such that they transparently upgrade to the alist return format. If the variable is not set, the completion styles return the result as plain list retaining backward compatibility. The variable is purely for internal use, new completion styles should return their results as an alist on Emacs 28 and newer. Variant 2: Add an optional argument FILTER to each of the completion styles 'all' functions, e.g., 'completion-basic-all-completions'. In 'completion--nth-completion' try to call the function with the additional FILTER argument to upgrade to the alist return format. If this fails with a 'wrong-number-of-arguments' error, retry again without the argument. Daniel --------------4B3E2A198290BEF506AC64C4 Content-Type: text/plain; charset=UTF-8; name="variant1-restrict.el" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="variant1-restrict.el" RnJvbSA1NTM5ZWVhN2RmMTU3MGI2YjUwNDViZTJiMzgzZDJiZmJkNDQ3ODllIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgTWVuZGxlciA8bWFpbEBkYW5pZWwtbWVu ZGxlci5kZT4KRGF0ZTogVGh1LCAxMiBBdWcgMjAyMSAxMDoyMDoxMCArMDIwMApTdWJqZWN0 OiBbUEFUQ0hdIFNldCAnY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcnIG9ubHkgZm9y IHRoZSBleGlzdGluZwogc3R5bGVzCgpUaGlzIGF2b2lkcyBwcm9ibGVtcyBpZiBhIHBhY2th Z2Ugd3JhcHMgYW4gZXhpc3RpbmcgY29tcGxldGlvbgpzdHlsZSBmdW5jdGlvbiBpbiBhIGN1 c3RvbSBjb21wbGV0aW9uIHN0eWxlLgotLS0KIGxpc3AvbWluaWJ1ZmZlci5lbCB8IDY2ICsr KysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEgZmlsZSBj aGFuZ2VkLCAzNiBpbnNlcnRpb25zKCspLCAzMCBkZWxldGlvbnMoLSkKCmRpZmYgLS1naXQg YS9saXNwL21pbmlidWZmZXIuZWwgYi9saXNwL21pbmlidWZmZXIuZWwKaW5kZXggYmE4ODU1 YzRlYS4uMzI1NzM0OWExYSAxMDA2NDQKLS0tIGEvbGlzcC9taW5pYnVmZmVyLmVsCisrKyBi L2xpc3AvbWluaWJ1ZmZlci5lbApAQCAtMTAzOSwxNiArMTAzOSwxNiBAQCBjb21wbGV0aW9u LS1zdHlsZXMKICAgICAgICAgKGRlbGV0ZS1kdXBzIChhcHBlbmQgKGNkciBvdmVyKSAoY29w eS1zZXF1ZW5jZSBjb21wbGV0aW9uLXN0eWxlcykpKQogICAgICAgIGNvbXBsZXRpb24tc3R5 bGVzKSkpCiAKLShkZWZ2YXIgY29tcGxldGlvbi0tZmlsdGVyLWNvbXBsZXRpb25zIG5pbAor KGRlZnZhciBjb21wbGV0aW9uLS1yZXR1cm4tYWxpc3QtZmxhZyBuaWwKICAgIkVuYWJsZSB0 aGUgbmV3IGNvbXBsZXRpb25zIHJldHVybiB2YWx1ZSBmb3JtYXQuCiBJZiB0aGlzIHZhcmlh YmxlIGlzIG5vbi1uaWwgdGhlIGBhbGwtY29tcGxldGlvbnMnIGZ1bmN0aW9uIG9mIGEKIGNv bXBsZXRpb24gc3R5bGUgc2hvdWxkIHJldHVybiB0aGUgcmVzdWx0cyBpbiB0aGUgbmV3IGFs aXN0IGZvcm1hdCBvZgogYGNvbXBsZXRpb24tZmlsdGVyLWNvbXBsZXRpb25zJy4gIFRoaXMg dmFyaWFibGUgaXMgcHVyZWx5IG5lZWRlZCB0bwogZm9yIGJhY2t3YXJkIGNvbXBhdGliaWxp dHkgb2YgdGhlIGV4aXN0aW5nIGJ1aWx0aW4gY29tcGxldGlvbiBzdHlsZQotZnVuY3Rpb25z LiAgTmV3IGNvbXBsZXRpb24gc3R5bGUgZnVuY3Rpb25zIG1heSBhbHdheXMgcmV0dXJuIHRo ZWlyCi1yZXN1bHRzIGluIHRoZSBuZXcgYWxpc3QgZm9ybWF0LCBzaW5jZSBgY29tcGxldGlv bi1hbGwtY29tcGxldGlvbnMnCi10cmFuc3BhcmVudGx5IGNvbnZlcnRzIGJhY2sgdG8gdGhl IG9sZCBpbXByb3BlciBsaXN0IG9mIGNvbXBsZXRpb25zCi13aXRoIGJhc2Ugc2l6ZSBpbiB0 aGUgbGFzdCBjZHIuIikKK2Z1bmN0aW9ucyBhcyBvZiBFbWFjcyAyOC4gIE5ldyBjb21wbGV0 aW9uIHN0eWxlIGZ1bmN0aW9ucyBzaG91bGQKK2Fsd2F5cyByZXR1cm4gdGhlaXIgcmVzdWx0 cyBpbiB0aGUgbmV3IGFsaXN0IGZvcm1hdCwgc2luY2UKK2Bjb21wbGV0aW9uLWFsbC1jb21w bGV0aW9ucycgdHJhbnNwYXJlbnRseSBjb252ZXJ0cyBiYWNrIHRvIHRoZSBvbGQKK2ltcHJv cGVyIGxpc3Qgb2YgY29tcGxldGlvbnMgd2l0aCBiYXNlIHNpemUgaW4gdGhlIGxhc3QgY2Ry LiIpCiAKIChkZWZ1biBjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAobiBzdHJpbmcgdGFi bGUgcHJlZCBwb2ludCBtZXRhZGF0YSkKICAgIkNhbGwgdGhlIE50aCBtZXRob2Qgb2YgY29t cGxldGlvbiBzdHlsZXMuIgpAQCAtMTA4NCw3ICsxMDg0LDcgQEAgY29tcGxldGlvbi0tbnRo LWNvbXBsZXRpb24KICAgICAgICAgICAgICAgOzsgY29udHJhc3QgdG8gcGxhaW4gY29tcGxl dGlvbiB0YWJsZXMsIHRoZSBzYXZpbmdzIG9mCiAgICAgICAgICAgICAgIDs7IGRlZmVycmVk IGhpZ2hsaWdodGluZyB3b3VsZCBiZSBtaW5pbWFsIGluIHRoZSBjYXNlIG9mCiAgICAgICAg ICAgICAgIDs7IHF1b3RlZCBjb21wbGV0aW9uIHRhYmxlcy4KLSAgICAgICAgICAgICAgKHNl dHEgY29tcGxldGlvbi0tZmlsdGVyLWNvbXBsZXRpb25zIG5pbCkKKyAgICAgICAgICAgICAg KHNldHEgY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcgbmlsKQogICAgICAgICAgICAg ICAoc2V0cSBzdHJpbmcgKHBvcCBuZXcpKQogICAgICAgICAgICAgICAoc2V0cSB0YWJsZSAo cG9wIG5ldykpCiAgICAgICAgICAgICAgIChzZXRxIHBvaW50IChwb3AgbmV3KSkKQEAgLTEw OTMsMTggKzEwOTMsMzUgQEAgY29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24KICAgICAgICAg IChyZXN1bHQtYW5kLXN0eWxlCiAgICAgICAgICAgKGNvbXBsZXRpb24tLXNvbWUKICAgICAg ICAgICAgKGxhbWJkYSAoc3R5bGUpCi0gICAgICAgICAgICAgKGxldCAoKHByb2JlIChmdW5j YWxsIChudGggbiAoYXNzcSBzdHlsZQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgY29tcGxldGlvbi1zdHlsZXMtYWxpc3QpKQotICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkpKQor ICAgICAgICAgICAgIChsZXQqICgoZnVuIChudGggbiAoYXNzcSBzdHlsZSBjb21wbGV0aW9u LXN0eWxlcy1hbGlzdCkpKQorICAgICAgICAgICAgICAgICAgICA7OyBUcmFuc3BhcmVudGx5 IHVwZ3JhZGUgdGhlIHJldHVybiB2YWx1ZSBmb3IKKyAgICAgICAgICAgICAgICAgICAgOzsg ZXhpc3RpbmcgYnVpbHQtaW4gc3R5bGVzIGFzIG9mIEVtYWNzIDI4LiAgTm8KKyAgICAgICAg ICAgICAgICAgICAgOzsgbmV3IHN0eWxlcyBzaG91bGQgYmUgYWRkZWQgaGVyZS4gTmV3IGNv bXBsZXRpb24KKyAgICAgICAgICAgICAgICAgICAgOzsgc3R5bGVzIHNob3VsZCBkaXJlY3Rs eSByZXR1cm4gdGhlIG5ldworICAgICAgICAgICAgICAgICAgICA7OyBjb21wbGV0aW9uIGZv cm1hdC5lbAorICAgICAgICAgICAgICAgICAgICAoY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0 LWZsYWcKKyAgICAgICAgICAgICAgICAgICAgIChhbmQgY29tcGxldGlvbi0tcmV0dXJuLWFs aXN0LWZsYWcKKyAgICAgICAgICAgICAgICAgICAgICAgICAgKG1lbXEgc3R5bGUgJyhlbWFj czIxIGVtYWNzMjIgYmFzaWMgc3Vic3RyaW5nCisgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgcGFydGlhbC1jb21wbGV0aW9uIGluaXRpYWxzIGZsZXgpKSkpCisg ICAgICAgICAgICAgICAgICAgIChwcm9iZSAoZnVuY2FsbCBmdW4gc3RyaW5nIHRhYmxlIHBy ZWQgcG9pbnQpKSkKICAgICAgICAgICAgICAgIChhbmQgcHJvYmUgKGNvbnMgcHJvYmUgc3R5 bGUpKSkpCiAgICAgICAgICAgIChjb21wbGV0aW9uLS1zdHlsZXMgbWQpKSkKLSAgICAgICAg IChzdHlsZS1tZCAoZ2V0IChjZHIgcmVzdWx0LWFuZC1zdHlsZSkgJ2NvbXBsZXRpb24tLXN0 eWxlLW1ldGFkYXRhKSkpCisgICAgICAgICAoc3R5bGUtbWQgKGdldCAoY2RyIHJlc3VsdC1h bmQtc3R5bGUpICdjb21wbGV0aW9uLS1zdHlsZS1tZXRhZGF0YSkpCisgICAgICAgICAocmVz dWx0IChjYXIgcmVzdWx0LWFuZC1zdHlsZSkpKQogICAgICh3aGVuIChhbmQgc3R5bGUtbWQg bWV0YWRhdGEpCiAgICAgICAoc2V0Y2RyIG1ldGFkYXRhIChjZHIgKGZ1bmNhbGwgc3R5bGUt bWQKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBzdHJpbmcgdGFibGUg cHJlZCBwb2ludCBtZXRhZGF0YSkpKSkKKyAgICAod2hlbiAoYW5kIChub3QgY29tcGxldGlv bi0tcmV0dXJuLWFsaXN0LWZsYWcpICg9IG4gMikgKGNvbnNwIChjYXIgcmVzdWx0KSkpCisg ICAgICA7OyBHaXZlIHRoZSBjb21wbGV0aW9uIHN0eWxlcyBzb21lIGZyZWVkb20hICBJZiB0 aGV5IGFyZQorICAgICAgOzsgdGFyZ2V0aW5nIEVtYWNzIDI4IHVwd2FyZHMgb25seSwgdGhl eSBtYXkgcmV0dXJuIGEgcmVzdWx0CisgICAgICA7OyB3aXRoIGRlZmVycmVkIGhpZ2hsaWdo dGluZy4gIFdlIGNvbnZlcnQgYmFjayB0byB0aGUgb2xkCisgICAgICA7OyBmb3JtYXQgaGVy ZSBieSBhcHBseWluZyB0aGUgaGlnaGxpZ2h0aW5nIGVhZ2VybHkuCisgICAgICAoc2V0cSBy ZXN1bHQgKG5jb25jIChmdW5jYWxsIChjZHIgKGFzc3EgJ2hpZ2hsaWdodCByZXN1bHQpKQor ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChhc3NxICdjb21wbGV0 aW9ucyByZXN1bHQpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgKGNkciAoYXNzcSAn YmFzZSByZXN1bHQpKSkpKQogICAgIChpZiByZXF1b3RlCi0gICAgICAgIChmdW5jYWxsIHJl cXVvdGUgKGNhciByZXN1bHQtYW5kLXN0eWxlKSBuKQotICAgICAgKGNhciByZXN1bHQtYW5k LXN0eWxlKSkpKQorICAgICAgICAoZnVuY2FsbCByZXF1b3RlIHJlc3VsdCBuKQorICAgICAg cmVzdWx0KSkpCiAKIChkZWZ1biBjb21wbGV0aW9uLXRyeS1jb21wbGV0aW9uIChzdHJpbmcg dGFibGUgcHJlZCBwb2ludCAmb3B0aW9uYWwgbWV0YWRhdGEpCiAgICJUcnkgdG8gY29tcGxl dGUgU1RSSU5HIHVzaW5nIGNvbXBsZXRpb24gdGFibGUgVEFCTEUuCkBAIC0xMTI0LDE5ICsx MTQxLDggQEAgY29tcGxldGlvbi1hbGwtY29tcGxldGlvbnMKIFRoZSBNRVRBREFUQSBtYXkg YmUgbW9kaWZpZWQgYnkgdGhlIGNvbXBsZXRpb24gc3R5bGUuICBUaGlzIGZ1bmN0aW9uCiBo YXMgYmVlbiBzdXBlcnNlZGVkIGJ5IGBjb21wbGV0aW9uLWZpbHRlci1jb21wbGV0aW9ucycs IHdoaWNoIHJldHVybnMKIHJpY2hlciBpbmZvcm1hdGlvbiBhbmQgc3VwcG9ydHMgZGVmZXJy ZWQgY2FuZGlkYXRlIGhpZ2hsaWdodGluZy4iCi0gIChsZXQgKChjb21wbGV0aW9uLS1maWx0 ZXItY29tcGxldGlvbnMgbmlsKQotICAgICAgICAocmVzdWx0IChjb21wbGV0aW9uLS1udGgt Y29tcGxldGlvbiAyIHN0cmluZyB0YWJsZQotICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICBwcmVkIHBvaW50IG1ldGFkYXRhKSkpCi0gICAgKGlmIChhbmQg cmVzdWx0IChjb25zcCAoY2FyIHJlc3VsdCkpKQotICAgICAgICA7OyBHaXZlIHRoZSBjb21w bGV0aW9uIHN0eWxlcyBzb21lIGZyZWVkb20hCi0gICAgICAgIDs7IElmIHRoZXkgYXJlIHRh cmdldGluZyBFbWFjcyAyOCB1cHdhcmRzIG9ubHksIHRoZXkKLSAgICAgICAgOzsgbWF5IGFs d2F5cyByZXR1cm4gYSByZXN1bHQgd2l0aCBkZWZlcnJlZAotICAgICAgICA7OyBoaWdobGln aHRpbmcuICBXZSBjb252ZXJ0IGJhY2sgdG8gdGhlIG9sZCBmb3JtYXQKLSAgICAgICAgOzsg aGVyZSBieSBhcHBseWluZyB0aGUgaGlnaGxpZ2h0aW5nIGVhZ2VybHkuCi0gICAgICAgIChu Y29uYyAoZnVuY2FsbCAoY2RyIChhc3NxICdoaWdobGlnaHQgcmVzdWx0KSkKLSAgICAgICAg ICAgICAgICAgICAgICAgIChjZHIgKGFzc3EgJ2NvbXBsZXRpb25zIHJlc3VsdCkpKQotICAg ICAgICAgICAgICAgKGNkciAoYXNzcSAnYmFzZSByZXN1bHQpKSkKLSAgICAgIHJlc3VsdCkp KQorICAobGV0ICgoY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcgbmlsKSkKKyAgICAo Y29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24gMiBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBt ZXRhZGF0YSkpKQogCiAoZGVmdW4gY29tcGxldGlvbi1maWx0ZXItY29tcGxldGlvbnMgKHN0 cmluZyB0YWJsZSBwcmVkIHBvaW50IG1ldGFkYXRhKQogICAiRmlsdGVyIHRoZSBwb3NzaWJs ZSBjb21wbGV0aW9ucyBvZiBTVFJJTkcgaW4gY29tcGxldGlvbiB0YWJsZSBUQUJMRS4KQEAg LTExNTIsNyArMTE1OCw3IEBAIGNvbXBsZXRpb24tZmlsdGVyLWNvbXBsZXRpb25zCiAtIGNv bXBsZXRpb25zOiBUaGUgbGlzdCBvZiBjb21wbGV0aW9ucy4KIAogVGhpcyBmdW5jdGlvbiBz dXBlcnNlZGVzIHRoZSBmdW5jdGlvbiBgY29tcGxldGlvbi1hbGwtY29tcGxldGlvbnMnLiIK LSAgKGxldCogKChjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMgdCkKKyAgKGxldCog KChjb21wbGV0aW9uLS1yZXR1cm4tYWxpc3QtZmxhZyB0KQogICAgICAgICAgKHJlc3VsdCAo Y29tcGxldGlvbi0tbnRoLWNvbXBsZXRpb24gMiBzdHJpbmcgdGFibGUKICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIHByZWQgcG9pbnQgbWV0YWRhdGEp KSkKICAgICAoaWYgKGFuZCByZXN1bHQgKG5vdCAoY29uc3AgKGNhciByZXN1bHQpKSkpCkBA IC0yMTIwLDggKzIxMjYsOCBAQCBjb21wbGV0aW9uLS1oaWxpdC1jb21tb25hbGl0eQogCiAo ZGVmdW4gY29tcGxldGlvbi0tZGVmZXJyZWQtaGlsaXQgKGNvbXBsZXRpb25zIHByZWZpeC1s ZW4gYmFzZSBlbmQpCiAgICJSZXR1cm4gY29tcGxldGlvbnMgaW4gb2xkIGZvcm1hdCBvciBu ZXcgYWxpc3QgZm9ybWF0LgotSWYgYGNvbXBsZXRpb24tLWZpbHRlci1jb21wbGV0aW9ucycg aXMgbm9uLW5pbCB1c2UgdGhlIG5ldyBmb3JtYXQuIgotICAoaWYgY29tcGxldGlvbi0tZmls dGVyLWNvbXBsZXRpb25zCitJZiBgY29tcGxldGlvbi0tcmV0dXJuLWFsaXN0LWZsYWcnIGlz IG5vbi1uaWwgdXNlIHRoZSBuZXcgZm9ybWF0LiIKKyAgKGlmIGNvbXBsZXRpb24tLXJldHVy bi1hbGlzdC1mbGFnCiAgICAgICAod2hlbiBjb21wbGV0aW9ucwogICAgICAgICBgKChiYXNl IC4gLGJhc2UpCiAgICAgICAgICAgKGVuZCAuICxlbmQpCkBAIC0zNTg2LDkgKzM1OTIsOSBA QCBmbGV4LXNjb3JlLW1hdGNoLXRpZ2h0bmVzcwogCiAoZGVmdW4gY29tcGxldGlvbi1wY20t LWRlZmVycmVkLWhpbGl0IChwYXR0ZXJuIGNvbXBsZXRpb25zIGJhc2UgZW5kKQogICAiUmV0 dXJuIGNvbXBsZXRpb25zIGluIG9sZCBmb3JtYXQgb3IgbmV3IGFsaXN0IGZvcm1hdC4KLUlm IGBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMnIGlzIG5vbi1uaWwgdXNlIHRoZSBu ZXcgZm9ybWF0LiIKK0lmIGBjb21wbGV0aW9uLS1yZXR1cm4tYWxpc3QtZmxhZycgaXMgbm9u LW5pbCB1c2UgdGhlIG5ldyBmb3JtYXQuIgogICAod2hlbiBjb21wbGV0aW9ucwotICAgIChp ZiBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMKKyAgICAoaWYgY29tcGxldGlvbi0t cmV0dXJuLWFsaXN0LWZsYWcKICAgICAgICAgYCgoYmFzZSAuICxiYXNlKQogICAgICAgICAg IChlbmQgLiAsZW5kKQogICAgICAgICAgIChoaWdobGlnaHQgLiAsKGFwcGx5LXBhcnRpYWxs eQotLSAKMi4yMC4xCgo= --------------4B3E2A198290BEF506AC64C4 Content-Type: text/plain; charset=UTF-8; name="variant2-argument.el" Content-Transfer-Encoding: base64 Content-Disposition: attachment; filename="variant2-argument.el" RnJvbSBmMGRhMWYxZDkyZjIwZGY3ZDkyZDk3NjIyOTVhYzUxMzkwZmNlZTgzIE1vbiBTZXAg MTcgMDA6MDA6MDAgMjAwMQpGcm9tOiBEYW5pZWwgTWVuZGxlciA8bWFpbEBkYW5pZWwtbWVu ZGxlci5kZT4KRGF0ZTogVGh1LCAxMiBBdWcgMjAyMSAxMDoxMDowMiArMDIwMApTdWJqZWN0 OiBbUEFUQ0hdIFVzZSBGSUxURVIgYXJndW1lbnQgaW5zdGVhZCBvZiBnbG9iYWwKIGBjb21w bGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnNgCgotLS0KIGxpc3AvbWluaWJ1ZmZlci5lbCB8 IDExOSArKysrKysrKysrKysrKysrKysrKysrKystLS0tLS0tLS0tLS0tLS0tLS0tLS0KIDEg ZmlsZSBjaGFuZ2VkLCA2NCBpbnNlcnRpb25zKCspLCA1NSBkZWxldGlvbnMoLSkKCmRpZmYg LS1naXQgYS9saXNwL21pbmlidWZmZXIuZWwgYi9saXNwL21pbmlidWZmZXIuZWwKaW5kZXgg YmE4ODU1YzRlYS4uMGY4Yjg1ZGRkNCAxMDA2NDQKLS0tIGEvbGlzcC9taW5pYnVmZmVyLmVs CisrKyBiL2xpc3AvbWluaWJ1ZmZlci5lbApAQCAtMTAzOSwxOCArMTAzOSw3IEBAIGNvbXBs ZXRpb24tLXN0eWxlcwogICAgICAgICAoZGVsZXRlLWR1cHMgKGFwcGVuZCAoY2RyIG92ZXIp IChjb3B5LXNlcXVlbmNlIGNvbXBsZXRpb24tc3R5bGVzKSkpCiAgICAgICAgY29tcGxldGlv bi1zdHlsZXMpKSkKIAotKGRlZnZhciBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMg bmlsCi0gICJFbmFibGUgdGhlIG5ldyBjb21wbGV0aW9ucyByZXR1cm4gdmFsdWUgZm9ybWF0 LgotSWYgdGhpcyB2YXJpYWJsZSBpcyBub24tbmlsIHRoZSBgYWxsLWNvbXBsZXRpb25zJyBm dW5jdGlvbiBvZiBhCi1jb21wbGV0aW9uIHN0eWxlIHNob3VsZCByZXR1cm4gdGhlIHJlc3Vs dHMgaW4gdGhlIG5ldyBhbGlzdCBmb3JtYXQgb2YKLWBjb21wbGV0aW9uLWZpbHRlci1jb21w bGV0aW9ucycuICBUaGlzIHZhcmlhYmxlIGlzIHB1cmVseSBuZWVkZWQgdG8KLWZvciBiYWNr d2FyZCBjb21wYXRpYmlsaXR5IG9mIHRoZSBleGlzdGluZyBidWlsdGluIGNvbXBsZXRpb24g c3R5bGUKLWZ1bmN0aW9ucy4gIE5ldyBjb21wbGV0aW9uIHN0eWxlIGZ1bmN0aW9ucyBtYXkg YWx3YXlzIHJldHVybiB0aGVpcgotcmVzdWx0cyBpbiB0aGUgbmV3IGFsaXN0IGZvcm1hdCwg c2luY2UgYGNvbXBsZXRpb24tYWxsLWNvbXBsZXRpb25zJwotdHJhbnNwYXJlbnRseSBjb252 ZXJ0cyBiYWNrIHRvIHRoZSBvbGQgaW1wcm9wZXIgbGlzdCBvZiBjb21wbGV0aW9ucwotd2l0 aCBiYXNlIHNpemUgaW4gdGhlIGxhc3QgY2RyLiIpCi0KLShkZWZ1biBjb21wbGV0aW9uLS1u dGgtY29tcGxldGlvbiAobiBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBtZXRhZGF0YSkKKyhk ZWZ1biBjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAobiBzdHJpbmcgdGFibGUgcHJlZCBw b2ludCBtZXRhZGF0YSAmb3B0aW9uYWwgZmlsdGVyKQogICAiQ2FsbCB0aGUgTnRoIG1ldGhv ZCBvZiBjb21wbGV0aW9uIHN0eWxlcy4iCiAgIDs7IFdlIHByb3ZpZGUgc3BlY2lhbCBzdXBw b3J0IGZvciBxdW90aW5nL3VucXVvdGluZyBoZXJlIGJlY2F1c2UgaXQgY2Fubm90CiAgIDs7 IHJlbGlhYmx5IGJlIGRvbmUgd2l0aGluIHRoZSBub3JtYWwgY29tcGxldGlvbi10YWJsZSBy b3V0aW5lczogQ29tcGxldGlvbgpAQCAtMTA4NCw3ICsxMDczLDcgQEAgY29tcGxldGlvbi0t bnRoLWNvbXBsZXRpb24KICAgICAgICAgICAgICAgOzsgY29udHJhc3QgdG8gcGxhaW4gY29t cGxldGlvbiB0YWJsZXMsIHRoZSBzYXZpbmdzIG9mCiAgICAgICAgICAgICAgIDs7IGRlZmVy cmVkIGhpZ2hsaWdodGluZyB3b3VsZCBiZSBtaW5pbWFsIGluIHRoZSBjYXNlIG9mCiAgICAg ICAgICAgICAgIDs7IHF1b3RlZCBjb21wbGV0aW9uIHRhYmxlcy4KLSAgICAgICAgICAgICAg KHNldHEgY29tcGxldGlvbi0tZmlsdGVyLWNvbXBsZXRpb25zIG5pbCkKKyAgICAgICAgICAg ICAgKHNldHEgZmlsdGVyIG5pbCkKICAgICAgICAgICAgICAgKHNldHEgc3RyaW5nIChwb3Ag bmV3KSkKICAgICAgICAgICAgICAgKHNldHEgdGFibGUgKHBvcCBuZXcpKQogICAgICAgICAg ICAgICAoc2V0cSBwb2ludCAocG9wIG5ldykpCkBAIC0xMDkzLDE4ICsxMDgyLDM3IEBAIGNv bXBsZXRpb24tLW50aC1jb21wbGV0aW9uCiAgICAgICAgICAocmVzdWx0LWFuZC1zdHlsZQog ICAgICAgICAgIChjb21wbGV0aW9uLS1zb21lCiAgICAgICAgICAgIChsYW1iZGEgKHN0eWxl KQotICAgICAgICAgICAgIChsZXQgKChwcm9iZSAoZnVuY2FsbCAobnRoIG4gKGFzc3Egc3R5 bGUKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIGNv bXBsZXRpb24tc3R5bGVzLWFsaXN0KSkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpKSkKKyAgICAgICAgICAgICAobGV0KiAo KGZ1biAobnRoIG4gKGFzc3Egc3R5bGUgY29tcGxldGlvbi1zdHlsZXMtYWxpc3QpKSkKKyAg ICAgICAgICAgICAgICAgICAgKHByb2JlCisgICAgICAgICAgICAgICAgICAgICAoaWYgZmls dGVyCisgICAgICAgICAgICAgICAgICAgICAgICAgOzsgSW4gb3JkZXIgdG8gcmV0YWluIGJh Y2t3YXJkIGNvbXBhdGliaWxpdHkKKyAgICAgICAgICAgICAgICAgICAgICAgICA7OyBvZiB0 aGUgY2FsbGluZyBjb252ZW50aW9uIG9mIHRoZSBleGlzaXRpbmcKKyAgICAgICAgICAgICAg ICAgICAgICAgICA7OyBjb21wbGV0aW9uIHN0eWxlcywgYWRkIGEgZm91cnRoIEZJTFRFUgor ICAgICAgICAgICAgICAgICAgICAgICAgIDs7IGFyZ3VtZW50IHRvIG9wdC1pbiB0byB0aGUg bmV3IHJldHVybiB2YWx1ZQorICAgICAgICAgICAgICAgICAgICAgICAgIDs7IGZvcm1hdC4K KyAgICAgICAgICAgICAgICAgICAgICAgICAoY29uZGl0aW9uLWNhc2UgbmlsCisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChmdW5jYWxsIGZ1biBzdHJpbmcgdGFibGUgcHJlZCBw b2ludCBmaWx0ZXIpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAod3JvbmctbnVtYmVy LW9mLWFyZ3VtZW50cworICAgICAgICAgICAgICAgICAgICAgICAgICAgIChmdW5jYWxsIGZ1 biBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkpKQorICAgICAgICAgICAgICAgICAgICAgICAo ZnVuY2FsbCBmdW4gc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpKSkpCiAgICAgICAgICAgICAg ICAoYW5kIHByb2JlIChjb25zIHByb2JlIHN0eWxlKSkpKQogICAgICAgICAgICAoY29tcGxl dGlvbi0tc3R5bGVzIG1kKSkpCi0gICAgICAgICAoc3R5bGUtbWQgKGdldCAoY2RyIHJlc3Vs dC1hbmQtc3R5bGUpICdjb21wbGV0aW9uLS1zdHlsZS1tZXRhZGF0YSkpKQorICAgICAgICAg KHN0eWxlLW1kIChnZXQgKGNkciByZXN1bHQtYW5kLXN0eWxlKSAnY29tcGxldGlvbi0tc3R5 bGUtbWV0YWRhdGEpKQorICAgICAgICAgKHJlc3VsdCAoY2FyIHJlc3VsdC1hbmQtc3R5bGUp KSkKICAgICAod2hlbiAoYW5kIHN0eWxlLW1kIG1ldGFkYXRhKQogICAgICAgKHNldGNkciBt ZXRhZGF0YSAoY2RyIChmdW5jYWxsIHN0eWxlLW1kCiAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQgbWV0YWRhdGEpKSkpCisg ICAgKHdoZW4gKGFuZCAobm90IGZpbHRlcikgKD0gbiAyKSAoY29uc3AgKGNhciByZXN1bHQp KSkKKyAgICAgIDs7IEdpdmUgdGhlIGNvbXBsZXRpb24gc3R5bGVzIHNvbWUgZnJlZWRvbSEg IElmIHRoZXkgYXJlCisgICAgICA7OyB0YXJnZXRpbmcgRW1hY3MgMjggdXB3YXJkcyBvbmx5 LCB0aGV5IG1heSByZXR1cm4gYSByZXN1bHQKKyAgICAgIDs7IHdpdGggZGVmZXJyZWQgaGln aGxpZ2h0aW5nLiAgV2UgY29udmVydCBiYWNrIHRvIHRoZSBvbGQKKyAgICAgIDs7IGZvcm1h dCBoZXJlIGJ5IGFwcGx5aW5nIHRoZSBoaWdobGlnaHRpbmcgZWFnZXJseS4KKyAgICAgIChz ZXRxIHJlc3VsdCAobmNvbmMgKGZ1bmNhbGwgKGNkciAoYXNzcSAnaGlnaGxpZ2h0IHJlc3Vs dCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgIChjZHIgKGFzc3EgJ2Nv bXBsZXRpb25zIHJlc3VsdCkpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAoY2RyIChh c3NxICdiYXNlIHJlc3VsdCkpKSkpCiAgICAgKGlmIHJlcXVvdGUKLSAgICAgICAgKGZ1bmNh bGwgcmVxdW90ZSAoY2FyIHJlc3VsdC1hbmQtc3R5bGUpIG4pCi0gICAgICAoY2FyIHJlc3Vs dC1hbmQtc3R5bGUpKSkpCisgICAgICAgIChmdW5jYWxsIHJlcXVvdGUgcmVzdWx0IG4pCisg ICAgICByZXN1bHQpKSkKIAogKGRlZnVuIGNvbXBsZXRpb24tdHJ5LWNvbXBsZXRpb24gKHN0 cmluZyB0YWJsZSBwcmVkIHBvaW50ICZvcHRpb25hbCBtZXRhZGF0YSkKICAgIlRyeSB0byBj b21wbGV0ZSBTVFJJTkcgdXNpbmcgY29tcGxldGlvbiB0YWJsZSBUQUJMRS4KQEAgLTExMjQs MTkgKzExMzIsNyBAQCBjb21wbGV0aW9uLWFsbC1jb21wbGV0aW9ucwogVGhlIE1FVEFEQVRB IG1heSBiZSBtb2RpZmllZCBieSB0aGUgY29tcGxldGlvbiBzdHlsZS4gIFRoaXMgZnVuY3Rp b24KIGhhcyBiZWVuIHN1cGVyc2VkZWQgYnkgYGNvbXBsZXRpb24tZmlsdGVyLWNvbXBsZXRp b25zJywgd2hpY2ggcmV0dXJucwogcmljaGVyIGluZm9ybWF0aW9uIGFuZCBzdXBwb3J0cyBk ZWZlcnJlZCBjYW5kaWRhdGUgaGlnaGxpZ2h0aW5nLiIKLSAgKGxldCAoKGNvbXBsZXRpb24t LWZpbHRlci1jb21wbGV0aW9ucyBuaWwpCi0gICAgICAgIChyZXN1bHQgKGNvbXBsZXRpb24t LW50aC1jb21wbGV0aW9uIDIgc3RyaW5nIHRhYmxlCi0gICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHByZWQgcG9pbnQgbWV0YWRhdGEpKSkKLSAgICAoaWYg KGFuZCByZXN1bHQgKGNvbnNwIChjYXIgcmVzdWx0KSkpCi0gICAgICAgIDs7IEdpdmUgdGhl IGNvbXBsZXRpb24gc3R5bGVzIHNvbWUgZnJlZWRvbSEKLSAgICAgICAgOzsgSWYgdGhleSBh cmUgdGFyZ2V0aW5nIEVtYWNzIDI4IHVwd2FyZHMgb25seSwgdGhleQotICAgICAgICA7OyBt YXkgYWx3YXlzIHJldHVybiBhIHJlc3VsdCB3aXRoIGRlZmVycmVkCi0gICAgICAgIDs7IGhp Z2hsaWdodGluZy4gIFdlIGNvbnZlcnQgYmFjayB0byB0aGUgb2xkIGZvcm1hdAotICAgICAg ICA7OyBoZXJlIGJ5IGFwcGx5aW5nIHRoZSBoaWdobGlnaHRpbmcgZWFnZXJseS4KLSAgICAg ICAgKG5jb25jIChmdW5jYWxsIChjZHIgKGFzc3EgJ2hpZ2hsaWdodCByZXN1bHQpKQotICAg ICAgICAgICAgICAgICAgICAgICAgKGNkciAoYXNzcSAnY29tcGxldGlvbnMgcmVzdWx0KSkp Ci0gICAgICAgICAgICAgICAoY2RyIChhc3NxICdiYXNlIHJlc3VsdCkpKQotICAgICAgcmVz dWx0KSkpCisgIChjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAyIHN0cmluZyB0YWJsZSBw cmVkIHBvaW50IG1ldGFkYXRhKSkKIAogKGRlZnVuIGNvbXBsZXRpb24tZmlsdGVyLWNvbXBs ZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludCBtZXRhZGF0YSkKICAgIkZpbHRlciB0 aGUgcG9zc2libGUgY29tcGxldGlvbnMgb2YgU1RSSU5HIGluIGNvbXBsZXRpb24gdGFibGUg VEFCTEUuCkBAIC0xMTUyLDkgKzExNDgsOCBAQCBjb21wbGV0aW9uLWZpbHRlci1jb21wbGV0 aW9ucwogLSBjb21wbGV0aW9uczogVGhlIGxpc3Qgb2YgY29tcGxldGlvbnMuCiAKIFRoaXMg ZnVuY3Rpb24gc3VwZXJzZWRlcyB0aGUgZnVuY3Rpb24gYGNvbXBsZXRpb24tYWxsLWNvbXBs ZXRpb25zJy4iCi0gIChsZXQqICgoY29tcGxldGlvbi0tZmlsdGVyLWNvbXBsZXRpb25zIHQp Ci0gICAgICAgICAocmVzdWx0IChjb21wbGV0aW9uLS1udGgtY29tcGxldGlvbiAyIHN0cmlu ZyB0YWJsZQotICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg cHJlZCBwb2ludCBtZXRhZGF0YSkpKQorICAobGV0KiAoKHJlc3VsdCAoY29tcGxldGlvbi0t bnRoLWNvbXBsZXRpb24gMiBzdHJpbmcgdGFibGUKKyAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIHByZWQgcG9pbnQgbWV0YWRhdGEgJ2ZpbHRlcikpKQog ICAgIChpZiAoYW5kIHJlc3VsdCAobm90IChjb25zcCAoY2FyIHJlc3VsdCkpKSkKICAgICAg ICAgOzsgRGVmZXJyZWQgaGlnaGxpZ2h0aW5nIGhhcyBiZWVuIHJlcXVlc3RlZCwgYnV0IHRo ZSBjb21wbGV0aW9uCiAgICAgICAgIDs7IHN0eWxlIHJldHVybmVkIGEgbm9uLWRlZmVycmVk IHJlc3VsdC4gQ29udmVydCB0aGUgcmVzdWx0IHRvIHRoZQpAQCAtMjExOCwxMCArMjExMywx MCBAQCBjb21wbGV0aW9uLS1oaWxpdC1jb21tb25hbGl0eQogICAgICBlbGVtKQogICAgY29t cGxldGlvbnMpKQogCi0oZGVmdW4gY29tcGxldGlvbi0tZGVmZXJyZWQtaGlsaXQgKGNvbXBs ZXRpb25zIHByZWZpeC1sZW4gYmFzZSBlbmQpCisoZGVmdW4gY29tcGxldGlvbi0tZGVmZXJy ZWQtaGlsaXQgKGNvbXBsZXRpb25zIHByZWZpeC1sZW4gYmFzZSBlbmQgZmlsdGVyKQogICAi UmV0dXJuIGNvbXBsZXRpb25zIGluIG9sZCBmb3JtYXQgb3IgbmV3IGFsaXN0IGZvcm1hdC4K LUlmIGBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMnIGlzIG5vbi1uaWwgdXNlIHRo ZSBuZXcgZm9ybWF0LiIKLSAgKGlmIGNvbXBsZXRpb24tLWZpbHRlci1jb21wbGV0aW9ucwor SWYgRklMVEVSIGlzIG5vbi1uaWwgdXNlIHRoZSBuZXcgZm9ybWF0LiIKKyAgKGlmIGZpbHRl cgogICAgICAgKHdoZW4gY29tcGxldGlvbnMKICAgICAgICAgYCgoYmFzZSAuICxiYXNlKQog ICAgICAgICAgIChlbmQgLiAsZW5kKQpAQCAtMzMwMCwxMiArMzI5NSwxNCBAQCBjb21wbGV0 aW9uLWVtYWNzMjEtdHJ5LWNvbXBsZXRpb24KICAgICAgICAgKGNvbnMgY29tcGxldGlvbiAo bGVuZ3RoIGNvbXBsZXRpb24pKQogICAgICAgY29tcGxldGlvbikpKQogCi0oZGVmdW4gY29t cGxldGlvbi1lbWFjczIxLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgX3Bv aW50KQorKGRlZnVuIGNvbXBsZXRpb24tZW1hY3MyMS1hbGwtY29tcGxldGlvbnMgKHN0cmlu ZyB0YWJsZSBwcmVkIF9wb2ludAorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAmb3B0aW9uYWwgZmlsdGVyKQogICAoY29tcGxldGlvbi0tZGVm ZXJyZWQtaGlsaXQKICAgIChhbGwtY29tcGxldGlvbnMgc3RyaW5nIHRhYmxlIHByZWQpCiAg ICAobGVuZ3RoIHN0cmluZykKICAgIChjYXIgKGNvbXBsZXRpb24tYm91bmRhcmllcyBzdHJp bmcgdGFibGUgcHJlZCAiIikpCi0gICAobGVuZ3RoIHN0cmluZykpKQorICAgKGxlbmd0aCBz dHJpbmcpCisgICBmaWx0ZXIpKQogCiAoZGVmdW4gY29tcGxldGlvbi1lbWFjczIyLXRyeS1j b21wbGV0aW9uIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkKICAgKGxldCAoKHN1ZmZpeCAo c3Vic3RyaW5nIHN0cmluZyBwb2ludCkpCkBAIC0zMzI3LDEzICszMzI0LDE0IEBAIGNvbXBs ZXRpb24tZW1hY3MyMi10cnktY29tcGxldGlvbgogICAgICAgICAgIChzZXRxIHN1ZmZpeCAo c3Vic3RyaW5nIHN1ZmZpeCAxKSkpCiAgICAgICAoY29ucyAoY29uY2F0IGNvbXBsZXRpb24g c3VmZml4KSAobGVuZ3RoIGNvbXBsZXRpb24pKSkpKQogCi0oZGVmdW4gY29tcGxldGlvbi1l bWFjczIyLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpCisoZGVm dW4gY29tcGxldGlvbi1lbWFjczIyLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHBy ZWQgcG9pbnQKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgJm9wdGlvbmFsIGZpbHRlcikKICAgKGxldCogKChiZWZvcmVwb2ludCAoc3Vic3Ry aW5nIHN0cmluZyAwIHBvaW50KSkKICAgICAgICAgIChhZnRlcnBvaW50IChzdWJzdHJpbmcg c3RyaW5nIHBvaW50KSkKICAgICAgICAgIChib3VuZHMgKGNvbXBsZXRpb24tYm91bmRhcmll cyBiZWZvcmVwb2ludCB0YWJsZSBwcmVkIGFmdGVycG9pbnQpKSkKICAgICAoY29tcGxldGlv bi0tZGVmZXJyZWQtaGlsaXQKICAgICAgKGFsbC1jb21wbGV0aW9ucyBiZWZvcmVwb2ludCB0 YWJsZSBwcmVkKQotICAgICBwb2ludCAoY2FyIGJvdW5kcykgKCsgcG9pbnQgKGNkciBib3Vu ZHMpKSkpKQorICAgICBwb2ludCAoY2FyIGJvdW5kcykgKCsgcG9pbnQgKGNkciBib3VuZHMp KSBmaWx0ZXIpKSkKIAogOzs7IEJhc2ljIGNvbXBsZXRpb24uCiAKQEAgLTMzODEsNyArMzM3 OSw4IEBAIGNvbXBsZXRpb24tYmFzaWMtdHJ5LWNvbXBsZXRpb24KICAgICAgICAgICAgIChz ZXRxIGFsbCAoY29tcGxldGlvbi1wY20tLWZpbGVuYW1lLXRyeS1maWx0ZXIgYWxsKSkpCiAg ICAgICAgIChjb21wbGV0aW9uLXBjbS0tbWVyZ2UtdHJ5IHBhdHRlcm4gYWxsIHByZWZpeCBz dWZmaXgpKSkpKQogCi0oZGVmdW4gY29tcGxldGlvbi1iYXNpYy1hbGwtY29tcGxldGlvbnMg KHN0cmluZyB0YWJsZSBwcmVkIHBvaW50KQorKGRlZnVuIGNvbXBsZXRpb24tYmFzaWMtYWxs LWNvbXBsZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludAorICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgJm9wdGlvbmFsIGZpbHRlcikKICAg KGxldCogKChiZWZvcmVwb2ludCAoc3Vic3RyaW5nIHN0cmluZyAwIHBvaW50KSkKICAgICAg ICAgIChhZnRlcnBvaW50IChzdWJzdHJpbmcgc3RyaW5nIHBvaW50KSkKICAgICAgICAgIChi b3VuZHMgKGNvbXBsZXRpb24tYm91bmRhcmllcyBiZWZvcmVwb2ludCB0YWJsZSBwcmVkIGFm dGVycG9pbnQpKQpAQCAtMzM5Miw3ICszMzkxLDkgQEAgY29tcGxldGlvbi1iYXNpYy1hbGwt Y29tcGxldGlvbnMKICAgICAgICAgICAgICAgICAgICAgICAgICAgICAncG9pbnQKICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoc3Vic3RyaW5nIGFmdGVycG9pbnQgMCAoY2RyIGJv dW5kcykpKSkpCiAgICAgICAgICAoYWxsIChjb21wbGV0aW9uLXBjbS0tYWxsLWNvbXBsZXRp b25zIHByZWZpeCBwYXR0ZXJuIHRhYmxlIHByZWQpKSkKLSAgICAoY29tcGxldGlvbi0tZGVm ZXJyZWQtaGlsaXQgYWxsIHBvaW50IChjYXIgYm91bmRzKSAoKyBwb2ludCAoY2RyIGJvdW5k cykpKSkpCisgICAgKGNvbXBsZXRpb24tLWRlZmVycmVkLWhpbGl0IGFsbCBwb2ludAorICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAoY2FyIGJvdW5kcykgKCsgcG9pbnQgKGNk ciBib3VuZHMpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWx0ZXIpKSkK IAogOzs7IFBhcnRpYWwtY29tcGxldGlvbi1tb2RlIHN0eWxlIGNvbXBsZXRpb24uCiAKQEAg LTM1ODQsMTEgKzM1ODUsMTEgQEAgZmxleC1zY29yZS1tYXRjaC10aWdodG5lc3MKIHRoYW4g dGhlIGxhdHRlciAod2hpY2ggaGFzIHR3byBcImhvbGVzXCIgYW5kIHRocmVlCiBvbmUtbGV0 dGVyLWxvbmcgbWF0Y2hlcykuIikKIAotKGRlZnVuIGNvbXBsZXRpb24tcGNtLS1kZWZlcnJl ZC1oaWxpdCAocGF0dGVybiBjb21wbGV0aW9ucyBiYXNlIGVuZCkKKyhkZWZ1biBjb21wbGV0 aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgKHBhdHRlcm4gY29tcGxldGlvbnMgYmFzZSBlbmQg ZmlsdGVyKQogICAiUmV0dXJuIGNvbXBsZXRpb25zIGluIG9sZCBmb3JtYXQgb3IgbmV3IGFs aXN0IGZvcm1hdC4KLUlmIGBjb21wbGV0aW9uLS1maWx0ZXItY29tcGxldGlvbnMnIGlzIG5v bi1uaWwgdXNlIHRoZSBuZXcgZm9ybWF0LiIKK0lmIEZJTFRFUiBpcyBub24tbmlsIHVzZSB0 aGUgbmV3IGZvcm1hdC4iCiAgICh3aGVuIGNvbXBsZXRpb25zCi0gICAgKGlmIGNvbXBsZXRp b24tLWZpbHRlci1jb21wbGV0aW9ucworICAgIChpZiBmaWx0ZXIKICAgICAgICAgYCgoYmFz ZSAuICxiYXNlKQogICAgICAgICAgIChlbmQgLiAsZW5kKQogICAgICAgICAgIChoaWdobGln aHQgLiAsKGFwcGx5LXBhcnRpYWxseQpAQCAtMzgzOSwxMiArMzg0MCwxNCBAQCBjb21wbGV0 aW9uLXBjbS0tZmluZC1hbGwtY29tcGxldGlvbnMKICAgICAgICAgICAoc2lnbmFsIChjYXIg Zmlyc3RlcnJvcikgKGNkciBmaXJzdGVycm9yKSkKICAgICAgICAgKGxpc3QgcGF0dGVybiBh bGwgcHJlZml4IHN1ZmZpeCkpKSkpCiAKLShkZWZ1biBjb21wbGV0aW9uLXBjbS1hbGwtY29t cGxldGlvbnMgKHN0cmluZyB0YWJsZSBwcmVkIHBvaW50KQorKGRlZnVuIGNvbXBsZXRpb24t cGNtLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgcG9pbnQKKyAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmb3B0aW9uYWwgZmlsdGVy KQogICAocGNhc2UtbGV0ICgoYCgscGF0dGVybiAsYWxsICxwcmVmaXggLHN1ZmZpeCkKICAg ICAgICAgICAgICAgIChjb21wbGV0aW9uLXBjbS0tZmluZC1hbGwtY29tcGxldGlvbnMgc3Ry aW5nIHRhYmxlIHByZWQgcG9pbnQpKSkKICAgICAoY29tcGxldGlvbi1wY20tLWRlZmVycmVk LWhpbGl0IHBhdHRlcm4gYWxsCiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAobGVuZ3RoIHByZWZpeCkKLSAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICgtIChsZW5ndGggc3RyaW5nKSAobGVuZ3RoIHN1ZmZpeCkpKSkpCisgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAoLSAobGVuZ3RoIHN0cmluZykgKGxlbmd0aCBzdWZm aXgpKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgZmlsdGVyKSkpCiAK IChkZWZ1biBjb21wbGV0aW9uLS1jb21tb24tc3VmZml4IChzdHJzKQogICAiUmV0dXJuIHRo ZSBjb21tb24gc3VmZml4IG9mIHRoZSBzdHJpbmdzIFNUUlMuIgpAQCAtNDA2NywxMyArNDA3 MCwxNSBAQCBjb21wbGV0aW9uLXN1YnN0cmluZy10cnktY29tcGxldGlvbgogICAgICAgICAo c2V0cSBhbGwgKGNvbXBsZXRpb24tcGNtLS1maWxlbmFtZS10cnktZmlsdGVyIGFsbCkpKQog ICAgIChjb21wbGV0aW9uLXBjbS0tbWVyZ2UtdHJ5IHBhdHRlcm4gYWxsIHByZWZpeCBzdWZm aXgpKSkKIAotKGRlZnVuIGNvbXBsZXRpb24tc3Vic3RyaW5nLWFsbC1jb21wbGV0aW9ucyAo c3RyaW5nIHRhYmxlIHByZWQgcG9pbnQpCisoZGVmdW4gY29tcGxldGlvbi1zdWJzdHJpbmct YWxsLWNvbXBsZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludAorICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICZvcHRpb25hbCBmaWx0 ZXIpCiAgIChwY2FzZS1sZXQgKChgKCxhbGwgLHBhdHRlcm4gLHByZWZpeCAsc3VmZml4KQog ICAgICAgICAgICAgICAgKGNvbXBsZXRpb24tc3Vic3RyaW5nLS1hbGwtY29tcGxldGlvbnMK ICAgICAgICAgICAgICAgICBzdHJpbmcgdGFibGUgcHJlZCBwb2ludCkpKQogICAgIChjb21w bGV0aW9uLXBjbS0tZGVmZXJyZWQtaGlsaXQgcGF0dGVybiBhbGwKICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgIChsZW5ndGggcHJlZml4KQotICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgKC0gKGxlbmd0aCBzdHJpbmcpIChsZW5ndGggc3VmZml4 KSkpKSkKKyAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICgtIChsZW5ndGgg c3RyaW5nKSAobGVuZ3RoIHN1ZmZpeCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICBmaWx0ZXIpKSkKIAogOzs7ICJmbGV4IiBjb21wbGV0aW9uLCBhbHNvIGtub3du IGFzIGZseC9mdXp6eS9zY2F0dGVyIGNvbXBsZXRpb24KIDs7IENvbXBsZXRlcyAiZm9vIiB0 byAiZnJvZG8iIGFuZCAiZmFyZnJvbXNvYmVyIgpAQCAtNDE1Miw3ICs0MTU3LDggQEAgY29t cGxldGlvbi1mbGV4LXRyeS1jb21wbGV0aW9uCiAgICAgICA7OyAiZmFyZnJvbXNvYmVyIi4K ICAgICAgIChjb21wbGV0aW9uLXBjbS0tbWVyZ2UtdHJ5IHBhdHRlcm4gYWxsIHByZWZpeCBz dWZmaXgpKSkpCiAKLShkZWZ1biBjb21wbGV0aW9uLWZsZXgtYWxsLWNvbXBsZXRpb25zIChz dHJpbmcgdGFibGUgcHJlZCBwb2ludCkKKyhkZWZ1biBjb21wbGV0aW9uLWZsZXgtYWxsLWNv bXBsZXRpb25zIChzdHJpbmcgdGFibGUgcHJlZCBwb2ludAorICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmb3B0aW9uYWwgZmlsdGVyKQogICAiR2V0 IGZsZXgtY29tcGxldGlvbnMgb2YgU1RSSU5HIGluIFRBQkxFLCBnaXZlbiBQUkVEIGFuZCBQ T0lOVC4iCiAgICh1bmxlc3MgKGFuZCBjb21wbGV0aW9uLWZsZXgtbm9zcGFjZSAoc3RyaW5n LXNlYXJjaCAiICIgc3RyaW5nKSkKICAgICAocGNhc2UtbGV0ICgoYCgsYWxsICxwYXR0ZXJu ICxwcmVmaXggLHN1ZmZpeCkKQEAgLTQxNjEsNyArNDE2Nyw4IEBAIGNvbXBsZXRpb24tZmxl eC1hbGwtY29tcGxldGlvbnMKICAgICAgICAgICAgICAgICAgICMnY29tcGxldGlvbi1mbGV4 LS1tYWtlLWZsZXgtcGF0dGVybikpKQogICAgICAgKGNvbXBsZXRpb24tcGNtLS1kZWZlcnJl ZC1oaWxpdCBwYXR0ZXJuIGFsbAogICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgKGxlbmd0aCBwcmVmaXgpCi0gICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAoLSAobGVuZ3RoIHN0cmluZykgKGxlbmd0aCBzdWZmaXgpKSkpKSkKKyAgICAgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICgtIChsZW5ndGggc3RyaW5nKSAobGVuZ3RoIHN1 ZmZpeCkpCisgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICBmaWx0ZXIpKSkp CiAKIDs7IEluaXRpYWxzIGNvbXBsZXRpb24KIDs7IENvbXBsZXRlIC91bXMgdG8gL3Vzci9t b25uaWVyL3NyYyBvciBsY2ggdG8gbGlzdC1jb21tYW5kLWhpc3RvcnkuCkBAIC00MTk1LDE0 ICs0MjAyLDE2IEBAIGNvbXBsZXRpb24taW5pdGlhbHMtZXhwYW5kCiAgICAgICAgICAgICAo Y29uY2F0IChzdWJzdHJpbmcgc3RyIDAgKGNhciBib3VuZHMpKQogICAgICAgICAgICAgICAg ICAgICAobWFwY29uY2F0ICdzdHJpbmcgKHN1YnN0cmluZyBzdHIgKGNhciBib3VuZHMpKSBz ZXApKSkpKSkpKQogCi0oZGVmdW4gY29tcGxldGlvbi1pbml0aWFscy1hbGwtY29tcGxldGlv bnMgKHN0cmluZyB0YWJsZSBwcmVkIF9wb2ludCkKKyhkZWZ1biBjb21wbGV0aW9uLWluaXRp YWxzLWFsbC1jb21wbGV0aW9ucyAoc3RyaW5nIHRhYmxlIHByZWQgX3BvaW50CisgICAgICAg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAmb3B0aW9uYWwg ZmlsdGVyKQogICAobGV0ICgobmV3c3RyIChjb21wbGV0aW9uLWluaXRpYWxzLWV4cGFuZCBz dHJpbmcgdGFibGUgcHJlZCkpKQogICAgICh3aGVuIG5ld3N0cgogICAgICAgKHBjYXNlLWxl dCAoKGAoLHBhdHRlcm4gLGFsbCAscHJlZml4ICxfc3VmZml4KQogICAgICAgICAgICAgICAg ICAgIChjb21wbGV0aW9uLXBjbS0tZmluZC1hbGwtY29tcGxldGlvbnMgbmV3c3RyIHRhYmxl CiAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgICBwcmVkIChsZW5ndGggbmV3c3RyKSkpKQogICAgICAgICAoY29tcGxldGlvbi1wY20t LWRlZmVycmVkLWhpbGl0IHBhdHRlcm4gYWxsCi0gICAgICAgICAgICAgICAgICAgICAgICAg ICAgICAgICAgICAgICAgKGxlbmd0aCBwcmVmaXgpIChsZW5ndGggc3RyaW5nKSkpKSkpCisg ICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgKGxlbmd0aCBwcmVmaXgp IChsZW5ndGggc3RyaW5nKQorICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAgICAg ICAgIGZpbHRlcikpKSkpCiAKIChkZWZ1biBjb21wbGV0aW9uLWluaXRpYWxzLXRyeS1jb21w bGV0aW9uIChzdHJpbmcgdGFibGUgcHJlZCBfcG9pbnQpCiAgIChsZXQgKChuZXdzdHIgKGNv bXBsZXRpb24taW5pdGlhbHMtZXhwYW5kIHN0cmluZyB0YWJsZSBwcmVkKSkpCi0tIAoyLjIw LjEKCg== --------------4B3E2A198290BEF506AC64C4-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 10:39:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: 47711@debbugs.gnu.org, 48841@debbugs.gnu.org Cc: Eli Zaretskii , Dmitry Gutov , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Stefan Monnier Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162885112727784 (code B ref 48841); Fri, 13 Aug 2021 10:39:01 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 10:38:47 +0000 Received: from localhost ([127.0.0.1]:40553 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEUaL-0007E2-I8 for submit@debbugs.gnu.org; Fri, 13 Aug 2021 06:38:47 -0400 Received: from server.qxqx.de ([178.63.65.180]:41947 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEUaD-0007DS-NT; Fri, 13 Aug 2021 06:38:42 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=qxqx.de; s=mail1392553390; h=Content-Type:In-Reply-To:MIME-Version:Date:Message-ID: References:Cc:To:From:Subject:Sender:Reply-To:Content-Transfer-Encoding: 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=SOhFQ1wSTJnkfn/KBMxtDxfjGodK9cPP6BpCAVQ3Lfs=; b=IEjg+aZkC1HrwtTiwHLxhnp3JL JJ35+RmaX6JZqCW3bXdtO3LJrxwz+CsVgnEjjo5GKq6XPoPo4xYp437AFb0l7RscfmEDM4jtCZM+m ehIxls6ebgDm8mqhfIY5wqjVe4ZmcRKzTR06jd9pMG4FQqNPBK400UfmBk6qrYndGUhM=; From: Daniel Mendler References: Message-ID: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> Date: Fri, 13 Aug 2021 12:38:28 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: multipart/mixed; boundary="------------E6B7393FF90421271E72F100" Content-Language: en-US X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) This is a multi-part message in MIME format. --------------E6B7393FF90421271E72F100 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit I attached the overhauled patch, which addresses most of the comments by Eli. In comparison to my last patch, the patch is fully backward compatible and preserves all existing tests. As before, there are tests which check the new functionality for each existing completion style. Daniel --------------E6B7393FF90421271E72F100 Content-Type: text/x-diff; charset=UTF-8; name="0001-Add-new-completion-filter-completions-API-and-deferr.patch" Content-Transfer-Encoding: 7bit Content-Disposition: attachment; filename*0="0001-Add-new-completion-filter-completions-API-and-deferr.pa"; filename*1="tch" >From 30ca42b49d5b5316abb3ebad38b0e9629eb52920 Mon Sep 17 00:00:00 2001 From: Daniel Mendler Date: Mon, 12 Jul 2021 21:40:32 +0200 Subject: [PATCH] Add new 'completion-filter-completions' API and deferred highlighting Fix bug#47711. Add a new 'completion-filter-completions' API, which supersedes 'completion-all-completions'. The new API returns the matching completion candidates and additional data. The return value is an alist, with the keys 'completions', 'base', 'end' and 'highlight'. The API can be extended in a backward compatible way later on thanks to the use of an alist as return value. The 'completions' value is the list of completion strings *without* applied highlighting. The completion strings are returned unmodified, which avoids allocations and results in performance gains for continuously updating completion UIs, like Icomplete or Vertico (GNU ELPA). The value 'base' is the base position of the completion relative to the beginning of the input string. Correspondingly the value 'end' specifies the end position of the completion relative to the beginning of the input string. In comparison, the old function 'completion-all-completions' only returned the base position in the last cdr of the returned completions list, which complicated usage. The 'end' position was not provided by 'completion-all-completions'. Given the new API the 'completion-base-position' can be set accurately. Finally the 'highlight' value is a function taking a list of completion strings and returns a new list of new strings with highlighting applied. A continously updating UI can use the highlighting function to apply highlighting only to the visible completions. * lisp/minibuffer.el: (completion--adjust-metadata): Rename to 'completion--style-metadata' due to change of calling convention. (completion--nth-completion): Call renamed metadata adjustment function. Ignore the old property 'completion--adjust-metadata'. (completion--flex-adjust-metadata): Rename function. (completion--twq-all): Attach 'completion--unquoted' text property to quoted completion strings. (completion--flex-score-1): Extract new function from 'completion-pcm--hilit-commonality'. (completion-pcm--hilit-commonality): Use it. Add SCORE argument. (completion--flex-score): Use 'completion--flex-score-1'. Use 'completion--unquoted' text property. (completion--flex-style-metadata): Use it. (completion--pattern-compiler): New function. (completion-substring--all-completions) (completion--flex-score): Use it. (completion--hilit-commonality): New function. (completion-hilit-commonality): Use it. (completion--deferred-hilit): New function. (completion-basic-all-completions) (completion-emacs21-all-completions) (completion-emacs22-all-completions): Use it. (completion--pcm-deferred-hilit): New function. (completion-pcm-all-completions) (completion-flex-all-completions) (completion-initials-all-completions) (completion-substring-all-completions): Use it. (completion--return-alist-flag): New variable to conditionally enable the new alist completions result format. This variable is for internal use to preserve the existing calling convention of the completion style 'all' functions. (completion-filter-completions): New API which returns the completion strings and additional data as an an alist. Transparently convert old list completion style results to the new alist format. (completion-all-completions): Transparently convert the new alist completion style result to the old list format. (minibuffer-completion-help): Use the new API, set 'completion-base-position' correctly. (completion-try-completion) (completion-all-completions): Update doc string. (completion--replace): Fix property removal. * test/lisp/minibuffer-tests.el: (completion--test-style) (completion--test-boundaries): New test helper function. (completion-emacs22orig-all-completions): New function. (completion-flex-score-test-*): Add new scoring test functions. (completion-*-style-test): Add new API tests for each built-in completion style. (completion-*-boundaries-test): New boundary tests for each built-in completion style. (completion-filter-completions-highlight-test): New API test. (completion-upgrade-return-type-test): New test of transparent completion style return value upgrade. --- lisp/minibuffer.el | 580 +++++++++++++++++++++++----------- test/lisp/minibuffer-tests.el | 217 ++++++++++++- 2 files changed, 603 insertions(+), 194 deletions(-) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index 9f327df28f..66ac6b3763 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -692,6 +692,10 @@ completion--twq-all 'completions-common-part) qprefix)))) (qcompletion (concat qprefix qnew))) + ;; Attach unquoted completion string, which is needed + ;; to score the completion in `completion--flex-score'. + (put-text-property 0 1 'completion--unquoted + completion qcompletion) ;; FIXME: Similarly here, Cygwin's mapping trips this ;; assertion. ;;(cl-assert @@ -1035,6 +1039,17 @@ completion--styles (delete-dups (append (cdr over) (copy-sequence completion-styles))) completion-styles))) +(defvar completion--return-alist-flag nil + "Non-nil means to return completions in alist format. +If this variable is non-nil the `all-completions' function of a +completion style should return the results in the alist format of +`completion-filter-completions'. This variable is purely needed to +for backward compatibility of the existing builtin completion style +functions as of Emacs 28. Newer completion style functions should +always return their results in the alist format, since +`completion-all-completions' transparently converts back to a list of +completions with base size in the last cdr.") + (defun completion--nth-completion (n string table pred point metadata) "Call the Nth method of completion styles." ;; We provide special support for quoting/unquoting here because it cannot @@ -1061,6 +1076,15 @@ completion--nth-completion ;; the original table, in that case! (functionp table)) (let ((new (funcall table string point 'completion--unquote))) + ;; FIXME For now do not attempt deferred highlighting if + ;; quoting is used. Not doing deferred highlighting is + ;; not too severe in this case, since + ;; `completion--twq-all' is already an expensive + ;; function, which allocates all completion strings. In + ;; contrast to plain completion tables, the savings of + ;; deferred highlighting would be minimal in the case of + ;; quoted completion tables. + (setq completion--return-alist-flag nil) (setq string (pop new)) (setq table (pop new)) (setq point (pop new)) @@ -1069,17 +1093,35 @@ completion--nth-completion (result-and-style (completion--some (lambda (style) - (let ((probe (funcall (nth n (assq style - completion-styles-alist)) - string table pred point))) + (let* ((fun (nth n (assq style completion-styles-alist))) + ;; Transparently upgrade the return value for + ;; existing built-in styles as of Emacs 28. No + ;; new styles should be added here. New completion + ;; styles should directly return the new + ;; completion format.el + (completion--return-alist-flag + (and completion--return-alist-flag + (memq style '(emacs21 emacs22 basic substring + partial-completion initials flex)))) + (probe (funcall fun string table pred point))) (and probe (cons probe style)))) (completion--styles md))) - (adjust-fn (get (cdr result-and-style) 'completion--adjust-metadata))) - (when (and adjust-fn metadata) - (setcdr metadata (cdr (funcall adjust-fn metadata)))) + (style-md (get (cdr result-and-style) 'completion--style-metadata)) + (result (car result-and-style))) + (when (and style-md metadata) + (setcdr metadata (cdr (funcall style-md + string table pred point metadata)))) + (when (and (not completion--return-alist-flag) (= n 2) (consp (car result))) + ;; Give the completion styles some freedom! If they are + ;; targeting Emacs 28 upwards only, they may return a result + ;; with deferred highlighting. We convert back to the old + ;; format here by applying the highlighting eagerly. + (setq result (nconc (funcall (cdr (assq 'highlight result)) + (cdr (assq 'completions result))) + (cdr (assq 'base result))))) (if requote - (funcall requote (car result-and-style) n) - (car result-and-style)))) + (funcall requote result n) + result))) (defun completion-try-completion (string table pred point &optional metadata) "Try to complete STRING using completion table TABLE. @@ -1088,7 +1130,8 @@ completion-try-completion The return value can be either nil to indicate that there is no completion, t to indicate that STRING is the only possible completion, or a pair (NEWSTRING . NEWPOINT) of the completed result string together with -a new position for point." +a new position for point. +The METADATA may be modified by the completion style." (completion--nth-completion 1 string table pred point metadata)) (defun completion-all-completions (string table pred point &optional metadata) @@ -1096,10 +1139,47 @@ completion-all-completions Only the elements of table that satisfy predicate PRED are considered. POINT is the position of point within STRING. The return value is a list of completions and may contain the base-size -in the last `cdr'." - ;; FIXME: We need to additionally return the info needed for the - ;; second part of completion-base-position. - (completion--nth-completion 2 string table pred point metadata)) +in the last `cdr'. +The METADATA may be modified by the completion style. + +This function has been superseded by `completion-filter-completions', +which returns richer information and supports deferred candidate +highlighting." + (let ((completion--return-alist-flag nil)) + (completion--nth-completion 2 string table pred point metadata))) + +(defun completion-filter-completions (string table pred point metadata) + "Filter the possible completions of STRING in completion table TABLE. +Only the elements of table that satisfy predicate PRED are considered. +POINT is the position of point within STRING. +The METADATA may be modified by the completion style. +The return value is a alist with the keys: + +- base: Base position of the completion (from the start of STRING) +- end: End position of the completion (from the start of STRING) +- highlight: Highlighting function taking a list of completions and + returning a new list of new strings with applied highlighting. +- completions: The list of completions. + +This function supersedes the function `completion-all-completions', +which does not provide the `end' position of the completion and does +not support deferred highlighting." + (let* ((completion--return-alist-flag t) + (result (completion--nth-completion 2 string table + pred point metadata))) + (if (and result (not (consp (car result)))) + ;; Deferred highlighting has been requested, but the + ;; completion style returned a non-deferred result. Convert + ;; the result to the alist format of + ;; `completion-filter-completions'. + (let* ((last (last result)) + (base (or (cdr last) 0))) + (setcdr last nil) + `((base . ,base) + (end . ,(length string)) + (highlight . identity) + (completions . ,result))) + result))) (defun minibuffer--bitset (modified completions exact) (logior (if modified 4 0) @@ -1115,7 +1195,8 @@ completion--replace (if minibuffer-allow-text-properties ;; If we're preserving properties, then just remove the faces ;; and other properties added by the completion machinery. - (remove-text-properties 0 (length newtext) '(face completion-score) + (remove-text-properties 0 (length newtext) + '(face nil completion-score nil) newtext) ;; Remove all text properties. (set-text-properties 0 (length newtext) nil newtext)) @@ -2021,34 +2102,49 @@ completion-hilit-commonality It returns a list with font-lock properties applied to each element, and with BASE-SIZE appended as the last element." (when completions - (let ((com-str-len (- prefix-len (or base-size 0)))) - (nconc - (mapcar - (lambda (elem) - (let ((str - ;; Don't modify the string itself, but a copy, since the - ;; the string may be read-only or used for other purposes. - ;; Furthermore, since `completions' may come from - ;; display-completion-list, `elem' may be a list. - (if (consp elem) - (car (setq elem (cons (copy-sequence (car elem)) - (cdr elem)))) - (setq elem (copy-sequence elem))))) - (font-lock-prepend-text-property - 0 - ;; If completion-boundaries returns incorrect - ;; values, all-completions may return strings - ;; that don't contain the prefix. - (min com-str-len (length str)) - 'face 'completions-common-part str) - (if (> (length str) com-str-len) - (font-lock-prepend-text-property com-str-len (1+ com-str-len) - 'face - 'completions-first-difference - str))) - elem) - completions) - base-size)))) + (nconc + (completion--hilit-commonality (- prefix-len (or base-size 0)) completions) + base-size))) + +(defun completion--hilit-commonality (com-size completions) + (mapcar + (lambda (elem) + (let ((str + ;; Don't modify the string itself, but a copy, since the + ;; the string may be read-only or used for other purposes. + ;; Furthermore, since `completions' may come from + ;; display-completion-list, `elem' may be a list. + (if (consp elem) + (car (setq elem (cons (copy-sequence (car elem)) + (cdr elem)))) + (setq elem (copy-sequence elem))))) + (font-lock-prepend-text-property + 0 + ;; If completion-boundaries returns incorrect + ;; values, all-completions may return strings + ;; that don't contain the prefix. + (min com-size (length str)) + 'face 'completions-common-part str) + (if (> (length str) com-size) + (font-lock-prepend-text-property com-size (1+ com-size) + 'face + 'completions-first-difference + str))) + elem) + completions)) + +(defun completion--deferred-hilit (completions prefix-len base end) + "Return completions as a list or as an alist. +If `completion--return-alist-flag' is non-nil use the alist format of +`completion-filter-completions'." + (if completion--return-alist-flag + (when completions + `((base . ,base) + (end . ,end) + (highlight . ,(apply-partially #'completion--hilit-commonality + (- prefix-len base))) + (completions . ,completions))) + (completion-hilit-commonality completions prefix-len base))) (defun display-completion-list (completions &optional common-substring group-fun) "Display the list of completions, COMPLETIONS, using `standard-output'. @@ -2163,15 +2259,16 @@ minibuffer-completion-help (end (or end (point-max))) (string (buffer-substring start end)) (md (completion--field-metadata start)) - (completions (completion-all-completions - string - minibuffer-completion-table - minibuffer-completion-predicate - (- (point) start) - md))) + (filtered-completions (completion-filter-completions + string + minibuffer-completion-table + minibuffer-completion-predicate + (- (point) start) + md)) + (completions (alist-get 'completions filtered-completions))) (message nil) (if (or (null completions) - (and (not (consp (cdr completions))) + (and (not (cdr completions)) (equal (car completions) string))) (progn ;; If there are no completions, or if the current input is already @@ -2181,8 +2278,7 @@ minibuffer-completion-help (completion--message (if completions "Sole completion" "No completions"))) - (let* ((last (last completions)) - (base-size (or (cdr last) 0)) + (let* ((base-size (alist-get 'base filtered-completions)) (prefix (unless (zerop base-size) (substring string 0 base-size))) (all-md (completion--metadata (buffer-substring-no-properties start (point)) @@ -2226,9 +2322,12 @@ minibuffer-completion-help (body-function . ,#'(lambda (_window) (with-current-buffer mainbuf - ;; Remove the base-size tail because `sort' requires a properly - ;; nil-terminated list. - (when last (setcdr last nil)) + ;; Apply highlighting using the deferred + ;; highlighting function provided by + ;; `completion-format-completions'. + (setq completions + (funcall (alist-get 'highlight filtered-completions) + completions)) ;; Sort first using the `display-sort-function'. ;; FIXME: This function is for the output of @@ -2267,13 +2366,10 @@ minibuffer-completion-help completions)))) (with-current-buffer standard-output - (setq-local completion-base-position - (list (+ start base-size) - ;; FIXME: We should pay attention to completion - ;; boundaries here, but currently - ;; completion-all-completions does not give us the - ;; necessary information. - end)) + (setq-local + completion-base-position + (list (+ start base-size) + (+ start (alist-get 'end filtered-completions)))) (setq-local completion-list-insert-choice-function (let ((ctable minibuffer-completion-table) (cpred minibuffer-completion-predicate) @@ -3223,10 +3319,11 @@ completion-emacs21-try-completion completion))) (defun completion-emacs21-all-completions (string table pred _point) - (completion-hilit-commonality + (completion--deferred-hilit (all-completions string table pred) (length string) - (car (completion-boundaries string table pred "")))) + (car (completion-boundaries string table pred "")) + (length string))) (defun completion-emacs22-try-completion (string table pred point) (let ((suffix (substring string point)) @@ -3249,11 +3346,12 @@ completion-emacs22-try-completion (cons (concat completion suffix) (length completion))))) (defun completion-emacs22-all-completions (string table pred point) - (let ((beforepoint (substring string 0 point))) - (completion-hilit-commonality + (let* ((beforepoint (substring string 0 point)) + (afterpoint (substring string point)) + (bounds (completion-boundaries beforepoint table pred afterpoint))) + (completion--deferred-hilit (all-completions beforepoint table pred) - point - (car (completion-boundaries beforepoint table pred ""))))) + point (car bounds) (+ point (cdr bounds))))) ;;; Basic completion. @@ -3312,7 +3410,7 @@ completion-basic-all-completions 'point (substring afterpoint 0 (cdr bounds))))) (all (completion-pcm--all-completions prefix pattern table pred))) - (completion-hilit-commonality all point (car bounds)))) + (completion--deferred-hilit all point (car bounds) (+ point (cdr bounds))))) ;;; Partial-completion-mode style completion. @@ -3504,13 +3602,26 @@ flex-score-match-tightness than the latter (which has two \"holes\" and three one-letter-long matches).") -(defun completion-pcm--hilit-commonality (pattern completions) +(defun completion-pcm--deferred-hilit (pattern completions base end) + "Return completions as a list or as an alist. +If `completion--return-alist-flag' is non-nil use the alist format of +`completion-filter-completions'." + (when completions + (if completion--return-alist-flag + `((base . ,base) + (end . ,end) + (highlight . ,(apply-partially + #'completion-pcm--hilit-commonality + pattern)) + (completions . ,completions)) + (nconc (completion-pcm--hilit-commonality pattern completions 'score) base)))) + +(defun completion-pcm--hilit-commonality (pattern completions &optional score) "Show where and how well PATTERN matches COMPLETIONS. PATTERN, a list of symbols and strings as seen `completion-pcm--merge-completions', is assumed to match every string in COMPLETIONS. Return a deep copy of COMPLETIONS where -each string is propertized with `completion-score', a number -between 0 and 1, and with faces `completions-common-part', +each string is propertized with faces `completions-common-part', `completions-first-difference' in the relevant segments." (when completions (let* ((re (completion-pcm--pattern->regex pattern 'group)) @@ -3527,84 +3638,143 @@ completion-pcm--hilit-commonality (match-end (match-end 0)) (md (cddr (setq last-md (match-data t last-md)))) (from 0) - (end (length str)) - ;; To understand how this works, consider these simple - ;; ascii diagrams showing how the pattern "foo" - ;; flex-matches "fabrobazo", "fbarbazoo" and - ;; "barfoobaz": - - ;; f abr o baz o - ;; + --- + --- + - - ;; f barbaz oo - ;; + ------ ++ - - ;; bar foo baz - ;; +++ - - ;; "+" indicates parts where the pattern matched. A - ;; "hole" in the middle of the string is indicated by - ;; "-". Note that there are no "holes" near the edges - ;; of the string. The completion score is a number - ;; bound by ]0..1]: the higher the better and only a - ;; perfect match (pattern equals string) will have - ;; score 1. The formula takes the form of a quotient. - ;; For the numerator, we use the number of +, i.e. the - ;; length of the pattern. For the denominator, it - ;; first computes - ;; - ;; hole_i_contrib = 1 + (Li-1)^(1/tightness) - ;; - ;; , for each hole "i" of length "Li", where tightness - ;; is given by `flex-score-match-tightness'. The - ;; final value for the denominator is then given by: - ;; - ;; (SUM_across_i(hole_i_contrib) + 1) * len - ;; - ;; , where "len" is the string's length. - (score-numerator 0) - (score-denominator 0) - (last-b 0) - (update-score-and-face - (lambda (a b) - "Update score and face given match range (A B)." - (add-face-text-property a b - 'completions-common-part - nil str) - (setq - score-numerator (+ score-numerator (- b a))) - (unless (or (= a last-b) - (zerop last-b) - (= a (length str))) - (setq - score-denominator (+ score-denominator - 1 - (expt (- a last-b 1) - (/ 1.0 - flex-score-match-tightness))))) - (setq - last-b b)))) + (len (length str))) + (when (and score (/= 0 len)) + (put-text-property + 0 1 'completion-score (- (completion--flex-score-1 md match-end len)) str)) (while md - (funcall update-score-and-face from (pop md)) + (add-face-text-property from (pop md) + 'completions-common-part + nil str) (setq from (pop md))) ;; If `pattern' doesn't have an explicit trailing any, the ;; regex `re' won't produce match data representing the ;; region after the match. We need to account to account ;; for that extra bit of match (bug#42149). (unless (= from match-end) - (funcall update-score-and-face from match-end)) - (if (> (length str) pos) + (add-face-text-property from match-end + 'completions-common-part + nil str)) + (if (> len pos) (add-face-text-property pos (1+ pos) 'completions-first-difference - nil str)) - (unless (zerop (length str)) - (put-text-property - 0 1 'completion-score - (/ score-numerator (* end (1+ score-denominator)) 1.0) str))) + nil str))) str) completions)))) +(defun completion--flex-score-1 (md match-end len) + "Compute matching score of completion. +The score lies in the range between-1 and 0, where -1 corresponds to +the full match. +MD is the match data. +MATCH-END is the end of the match. +LEN is the length of the completion string." + (let* ((from 0) + ;; To understand how this works, consider these simple + ;; ascii diagrams showing how the pattern "foo" + ;; flex-matches "fabrobazo", "fbarbazoo" and + ;; "barfoobaz": + + ;; f abr o baz o + ;; + --- + --- + + + ;; f barbaz oo + ;; + ------ ++ + + ;; bar foo baz + ;; +++ + + ;; "+" indicates parts where the pattern matched. A + ;; "hole" in the middle of the string is indicated by + ;; "-". Note that there are no "holes" near the edges + ;; of the string. The completion score is a number + ;; bound by ]0..1]: the higher the better and only a + ;; perfect match (pattern equals string) will have + ;; score 1. The formula takes the form of a quotient. + ;; For the numerator, we use the number of +, i.e. the + ;; length of the pattern. For the denominator, it + ;; first computes + ;; + ;; hole_i_contrib = 1 + (Li-1)^(1/tightness) + ;; + ;; , for each hole "i" of length "Li", where tightness + ;; is given by `flex-score-match-tightness'. The + ;; final value for the denominator is then given by: + ;; + ;; (SUM_across_i(hole_i_contrib) + 1) * len + ;; + ;; , where "len" is the string's length. + (score-numerator 0) + (score-denominator 0) + (last-b 0)) + (while md + (let ((a from) + (b (pop md))) + (setq + score-numerator (+ score-numerator (- b a))) + (unless (or (= a last-b) + (zerop last-b) + (= a len)) + (setq + score-denominator (+ score-denominator + 1 + (expt (- a last-b 1) + (/ 1.0 + flex-score-match-tightness))))) + (setq + last-b b)) + (setq from (pop md))) + ;; If `pattern' doesn't have an explicit trailing any, the + ;; regex `re' won't produce match data representing the + ;; region after the match. We need to account to account + ;; for that extra bit of match (bug#42149). + (unless (= from match-end) + (let ((a from) + (b match-end)) + (setq + score-numerator (+ score-numerator (- b a))) + (unless (or (= a last-b) + (zerop last-b) + (= a len)) + (setq + score-denominator (+ score-denominator + 1 + (expt (- a last-b 1) + (/ 1.0 + flex-score-match-tightness))))) + (setq + last-b b))) + (- (/ score-numerator (* len (1+ score-denominator)) 1.0)))) + +(defun completion--flex-score (pattern completions) + "Compute how well PATTERN matches COMPLETIONS. +PATTERN, a pcm pattern is assumed to match every string in the +COMPLETIONS list. Return a copy of COMPLETIONS where each element is +a pair of a score and the string. The score lies in the range between +-1 and 0, where -1 corresponds to the full match." + (when completions + (let* ((re (completion-pcm--pattern->regex pattern 'group)) + (case-fold-search completion-ignore-case) + last-md) + (mapcar + (lambda (str) + ;; The flex completion style requires the completion to match + ;; the pattern to compute the scoring. For quoted completion + ;; tables the completions are matched against the *unquoted + ;; input string*. However `completion-all-completions' and + ;; `completion-filter-completions' return a list of *quoted + ;; completions*, which is subsequently sorted. Therefore we + ;; obtain the unquoted completion string which is stored in + ;; the text property `completion--unquoted'. + (let ((unquoted (or (get-text-property 0 'completion--unquoted str) str))) + (unless (string-match re unquoted) + (error "Internal error: %s does not match %s" re unquoted)) + (cons (completion--flex-score-1 (cddr (setq last-md (match-data t last-md))) + (match-end 0) (length unquoted)) + str))) + completions)))) + (defun completion-pcm--find-all-completions (string table pred point &optional filter) "Find all completions for STRING at POINT in TABLE, satisfying PRED. @@ -3700,11 +3870,11 @@ completion-pcm--find-all-completions (list pattern all prefix suffix))))) (defun completion-pcm-all-completions (string table pred point) - (pcase-let ((`(,pattern ,all ,prefix ,_suffix) + (pcase-let ((`(,pattern ,all ,prefix ,suffix) (completion-pcm--find-all-completions string table pred point))) - (when all - (nconc (completion-pcm--hilit-commonality pattern all) - (length prefix))))) + (completion-pcm--deferred-hilit pattern all + (length prefix) + (- (length string) (length suffix))))) (defun completion--common-suffix (strs) "Return the common suffix of the strings STRS." @@ -3885,8 +4055,8 @@ completion-pcm-try-completion ;;; Substring completion ;; Mostly derived from the code of `basic' completion. -(defun completion-substring--all-completions - (string table pred point &optional transform-pattern-fn) +(defun completion--pattern-compiler + (string table pred point transform-pattern-fn) "Match the presumed substring STRING to the entries in TABLE. Respect PRED and POINT. The pattern used is a PCM-style substring pattern, but it be massaged by TRANSFORM-PATTERN-FN, if @@ -3904,12 +4074,23 @@ completion-substring--all-completions (pattern (completion-pcm--optimize-pattern (if transform-pattern-fn (funcall transform-pattern-fn pattern) - pattern))) - (all (completion-pcm--all-completions prefix pattern table pred))) - (list all pattern prefix suffix (car bounds)))) + pattern)))) + (list pattern prefix suffix))) + +(defun completion-substring--all-completions + (string table pred point &optional transform-pattern-fn) + "Match the presumed substring STRING to the entries in TABLE. +Respect PRED and POINT. The pattern used is a PCM-style +substring pattern, but it be massaged by TRANSFORM-PATTERN-FN, if +that is non-nil." + (pcase-let (((and result `(,pattern ,prefix ,_suffix)) + (completion--pattern-compiler string table pred point + transform-pattern-fn))) + (cons (completion-pcm--all-completions prefix pattern table pred) + result))) (defun completion-substring-try-completion (string table pred point) - (pcase-let ((`(,all ,pattern ,prefix ,suffix ,_carbounds) + (pcase-let ((`(,all ,pattern ,prefix ,suffix) (completion-substring--all-completions string table pred point))) (if minibuffer-completing-file-name @@ -3917,12 +4098,12 @@ completion-substring-try-completion (completion-pcm--merge-try pattern all prefix suffix))) (defun completion-substring-all-completions (string table pred point) - (pcase-let ((`(,all ,pattern ,prefix ,_suffix ,_carbounds) + (pcase-let ((`(,all ,pattern ,prefix ,suffix) (completion-substring--all-completions string table pred point))) - (when all - (nconc (completion-pcm--hilit-commonality pattern all) - (length prefix))))) + (completion-pcm--deferred-hilit pattern all + (length prefix) + (- (length string) (length suffix))))) ;;; "flex" completion, also known as flx/fuzzy/scatter completion ;; Completes "foo" to "frodo" and "farfromsober" @@ -3932,42 +4113,53 @@ completion-flex-nospace :version "27.1" :type 'boolean) -(put 'flex 'completion--adjust-metadata 'completion--flex-adjust-metadata) - -(defun completion--flex-adjust-metadata (metadata) - (cl-flet - ((compose-flex-sort-fn - (existing-sort-fn) ; wish `cl-flet' had proper indentation... - (lambda (completions) - (let ((pre-sorted - (if existing-sort-fn - (funcall existing-sort-fn completions) - completions))) - (cond - ((or (not (window-minibuffer-p)) - ;; JT@2019-12-23: FIXME: this is still wrong. What - ;; we need to test here is "some input that actually - ;; leads to flex filtering", not "something after - ;; the minibuffer prompt". Among other - ;; inconsistencies, the latter is always true for - ;; file searches, meaning the next clauses will be - ;; ignored. - (> (point-max) (minibuffer-prompt-end))) - (sort - pre-sorted - (lambda (c1 c2) - (let ((s1 (get-text-property 0 'completion-score c1)) - (s2 (get-text-property 0 'completion-score c2))) - (> (or s1 0) (or s2 0)))))) - (t pre-sorted)))))) - `(metadata - (display-sort-function - . ,(compose-flex-sort-fn - (completion-metadata-get metadata 'display-sort-function))) - (cycle-sort-function - . ,(compose-flex-sort-fn - (completion-metadata-get metadata 'cycle-sort-function))) - ,@(cdr metadata)))) +(put 'flex 'completion--style-metadata 'completion--flex-style-metadata) + +(defun completion--flex-style-metadata (string table pred point metadata) + ;; Use the modified flex sorting function only for non-empty input. + ;; In an older version of `completion--flex-adjust-metadata', the + ;; check (> (point-max) (minibuffer-prompt-end))) was used instead. + (unless (eq string "") + (let ((pattern (car (completion--pattern-compiler + string table pred point + #'completion-flex--make-flex-pattern)))) + (cl-flet + ((compose-flex-sort-fn + (existing-sort-fn) ; wish `cl-flet' had proper indentation... + (lambda (completions) + (let ((pre-sorted (if existing-sort-fn + (funcall existing-sort-fn completions) + completions))) + ;; If `completion-scores' are already present use + ;; those instead of recomputing the scores with + ;; `completion--flex-score'. The scores are already + ;; present, when the candidates have been computed by + ;; `completion-all-completions'. In contrast, the + ;; score is not yet present, when the candidates have + ;; been computed by `completion-filter-completions'. + (if (and (car pre-sorted) + (get-text-property 0 'completion-score (car pre-sorted))) + (sort + pre-sorted + (lambda (c1 c2) + (> (or (get-text-property 0 'completion-score c1) 0) + (or (get-text-property 0 'completion-score c2) 0)))) + (let* ((sorted (sort (completion--flex-score pattern pre-sorted) + #'car-less-than-car)) + (cell sorted)) + ;; Remove score decorations, reuse the list to avoid allocations. + (while cell + (setcar cell (cdar cell)) + (pop cell)) + sorted)))))) + `(metadata + (display-sort-function + . ,(compose-flex-sort-fn + (completion-metadata-get metadata 'display-sort-function))) + (cycle-sort-function + . ,(compose-flex-sort-fn + (completion-metadata-get metadata 'cycle-sort-function))) + ,@(cdr metadata)))))) (defun completion-flex--make-flex-pattern (pattern) "Convert PCM-style PATTERN into PCM-style flex pattern. @@ -3989,7 +4181,7 @@ completion-flex--make-flex-pattern (defun completion-flex-try-completion (string table pred point) "Try to flex-complete STRING in TABLE given PRED and POINT." (unless (and completion-flex-nospace (string-search " " string)) - (pcase-let ((`(,all ,pattern ,prefix ,suffix ,_carbounds) + (pcase-let ((`(,all ,pattern ,prefix ,suffix) (completion-substring--all-completions string table pred point #'completion-flex--make-flex-pattern))) @@ -4006,13 +4198,13 @@ completion-flex-try-completion (defun completion-flex-all-completions (string table pred point) "Get flex-completions of STRING in TABLE, given PRED and POINT." (unless (and completion-flex-nospace (string-search " " string)) - (pcase-let ((`(,all ,pattern ,prefix ,_suffix ,_carbounds) + (pcase-let ((`(,all ,pattern ,prefix ,suffix) (completion-substring--all-completions string table pred point #'completion-flex--make-flex-pattern))) - (when all - (nconc (completion-pcm--hilit-commonality pattern all) - (length prefix)))))) + (completion-pcm--deferred-hilit pattern all + (length prefix) + (- (length string) (length suffix)))))) ;; Initials completion ;; Complete /ums to /usr/monnier/src or lch to list-command-history. @@ -4049,7 +4241,11 @@ completion-initials-expand (defun completion-initials-all-completions (string table pred _point) (let ((newstr (completion-initials-expand string table pred))) (when newstr - (completion-pcm-all-completions newstr table pred (length newstr))))) + (pcase-let ((`(,pattern ,all ,prefix ,_suffix) + (completion-pcm--find-all-completions newstr table + pred (length newstr)))) + (completion-pcm--deferred-hilit pattern all + (length prefix) (length string)))))) (defun completion-initials-try-completion (string table pred _point) (let ((newstr (completion-initials-expand string table pred))) diff --git a/test/lisp/minibuffer-tests.el b/test/lisp/minibuffer-tests.el index c3ba8f9a92..22de3c9ff5 100644 --- a/test/lisp/minibuffer-tests.el +++ b/test/lisp/minibuffer-tests.el @@ -28,8 +28,7 @@ (require 'ert) (require 'ert-x) - -(eval-when-compile (require 'cl-lib)) +(require 'cl-lib) (ert-deftest completion-test1 () (with-temp-buffer @@ -331,5 +330,219 @@ completion-flex-test-3 "custgroup" '("customize-group-other-window") nil 9))) 15))) +(ert-deftest completion-flex-score-test-1 () + ;; Full match! + (should (equal + (completion--flex-score '(prefix "R") '("R")) + (list (cons -1.0 "R"))))) + +(ert-deftest completion-flex-score-test-2 () + ;; One third and half of a match! + (should (equal + (completion--flex-score '(prefix "foo") + '("barfoobar" "fooboo")) + (list (cons (/ -1.0 3.0) "barfoobar") + (cons (/ -1.0 2.0) "fooboo"))))) + +(ert-deftest completion-flex-score-test-3 () + ;; One fourth of a match + (should (eql + (caar (completion--flex-score '(prefix "R" point "O") + '("RaOb"))) + (/ -1.0 4.0)))) + +(ert-deftest completion-flex-score-test-4 () + ;; For quoted completion tables, score the unquoted completion string. + (should (equal + (completion--flex-score + '(prefix "R") + (list (propertize "X" 'completion--unquoted "R"))) + (list (cons -1.0 "X"))))) + +(defun completion--test-style (style string point table filtered) + (let* ((completion-styles (list style)) + (pred (lambda (x) (not (string-search "!" x)))) + (result (completion-filter-completions + string table pred point nil))) + (should (equal (alist-get 'base result) 0)) + (should (equal (alist-get 'end result) (length string))) + (should (equal (alist-get 'completions result) filtered)) + ;; The highlighting function should be present. + (should (not (memq (alist-get 'highlight result) '(nil identity)))) + ;; Equal results as `completion-all-completions'. + (should (equal (completion-all-completions string table pred point) + (append filtered 0))) + ;; The returned strings should be identical to the original strings. + ;; The `completion-filter-completions' function avoids allocations! + (should (cl-intersection (alist-get 'completions result) + table :test #'eq)))) + +(ert-deftest completion-basic-style-test-1 () + ;; point at the beginning |foo + (completion--test-style 'basic "foo" 0 + '("foobar" "foo!" "barfoo" "xfooy" "boobar") + '("foobar" "barfoo" "xfooy"))) + +(ert-deftest completion-basic-style-test-2 () + ;; point foo + (completion--test-style 'basic "foo" 2 + '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar") + '("foobar"))) + +(ert-deftest completion-substring-style-test () + (completion--test-style 'substring "foo" 1 + '("foobar" "foo!" "barfoo" "xfooy" "boobar") + '("foobar" "barfoo" "xfooy"))) + +(ert-deftest completion-emacs21-style-test () + (completion--test-style 'emacs21 "foo" 1 + '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar") + '("foobar"))) + +(ert-deftest completion-emacs22-style-test () + (completion--test-style 'emacs22 "fo0" 1 + '("foobar" "foo!" "fobar" "barfoo" "xfooy" "boobar") + '("foobar" "fobar"))) ;; suffix ignored completely + +(ert-deftest completion-flex-style-test () + (completion--test-style 'flex "abc" 1 + '("abc" "abc!" "xaybzc" "xaybz") + '("abc" "xaybzc"))) + +(ert-deftest completion-initials-style-test () + (completion--test-style 'initials "abc" 1 + '("a-b-c" "a-b-c!" "ax-by-cz" "xax-by-cz") + '("a-b-c" "ax-by-cz"))) + +(ert-deftest completion-pcm-style-test () + (completion--test-style 'partial-completion "ax-b-c" 1 + '("ax-b-c" "ax-b-c!" "ax-by-cz" "xax-by-cz") + '("ax-b-c" "ax-by-cz"))) + +(ert-deftest completion-filter-completions-highlight-test () + ;; point at the beginning |foo + (let* ((completion-styles '(basic)) + (result (completion-filter-completions + "foo" '("foobar" "fbarfoo" "fxfooy" "bar") + nil 1 nil))) + (should (equal + (format "%S" (alist-get 'completions result)) + (format "%S" '("foobar" "fbarfoo" "fxfooy")))) + (should (equal + (format "%S" (funcall (alist-get 'highlight result) + (alist-get 'completions result))) + (format "%S" + '(#("foobar" 0 1 (face (completions-common-part)) + 1 2 (face (completions-first-difference))) + #("fbarfoo" 0 1 (face (completions-common-part)) + 1 2 (face (completions-first-difference))) + #("fxfooy" 0 1 (face (completions-common-part)) + 1 2 (face (completions-first-difference))))))))) + +(defun completion--test-boundaries (style string table result) + (let ((table + (lambda (str pred action) + (pcase action + (`(boundaries . ,suffix) `(boundaries + ,(1+ (string-match-p "<\\|/" str)) + . ,(or (string-search ">" suffix) (length suffix)))) + (_ (complete-with-action action table + (replace-regexp-in-string ".*[after" + '("other") nil) + (completion--test-boundaries 'emacs21 "beforeafter" + '("ainput>after" "input>after" "inpux>after" + "inxputy>after" "input>after2") + '((base . 7) + (end . 18) + (completions "input>after" "input>after2")))) + +(ert-deftest completion-emacs22-boundaries-test () + (completion--test-boundaries 'emacs22 "beforeafter" + '("other") nil) + (completion--test-boundaries 'emacs22 "beforeafter" + '("ainxxx" "inyy" "inzzz") + '((base . 7) + (end . 12) + (completions "inyy" "inzzz")))) + +(ert-deftest completion-basic-boundaries-test () + (completion--test-boundaries 'basic "beforeafter" + '("other") nil) + (completion--test-boundaries 'basic "beforeafter" + '("ainput" "input" "inpux" "inxputy") + '((base . 7) + (end . 12) + (completions "input" "inxputy")))) + +(ert-deftest completion-substring-boundaries-test () + (completion--test-boundaries 'substring "beforeafter" + '("other") nil) + (completion--test-boundaries 'substring "beforeafter" + '("ainputs" "inputs" "inpux" "inxputsy") + '((base . 7) + (end . 13) + (completions "ainputs" "inputs" "inxputsy")))) + +(ert-deftest completion-pcm-boundaries-test () + (completion--test-boundaries 'partial-completion "beforeafter" + '("other") nil) + (completion--test-boundaries 'partial-completion "beforeafter" + '("ain-pu-ts" "in-pts" "in-pu-ts" "in-px" "inx-ptsy") + '((base . 7) + (end . 12) + (completions "in-pts" "in-pu-ts" "inx-ptsy")))) + +(ert-deftest completion-initials-boundaries-test () + (completion--test-boundaries 'initials "/ip|t" + '("other") nil) + (completion--test-boundaries 'initials "/ip|t" + '("ain/pu/ts" "in/pts" "in/pu/ts" "a/in/pu/ts" + "in/pu/ts/foo" "in/px" "inx/ptsy") + '((base . 1) + (end . 4) + (completions "in/pu/ts" "in/pu/ts/foo")))) + +(defun completion-emacs22orig-all-completions (string table pred point) + (let ((beforepoint (substring string 0 point))) + (completion-hilit-commonality + (all-completions beforepoint table pred) + point + (car (completion-boundaries beforepoint table pred ""))))) + +(ert-deftest completion-upgrade-return-type-test () + ;; Test transparent upgrade of list completion style return value + ;; to the alist return value format of `completion-format-completions'. + (let ((completion-styles-alist + '((emacs22orig completion-emacs22-try-completion + completion-emacs22orig-all-completions nil)))) + (completion--test-boundaries 'emacs22orig "beforeafter" + '("ainxxx" "inyy" "inzzz") + '((base . 7) + ;; 18 is incorrect, should be 12! + ;; But the information is not available + ;; due to the completion-style upgrade. + (end . 18) + ;; Identity highlighting function. + (highlight . identity) + (completions "inyy" "inzzz"))))) + (provide 'minibuffer-tests) ;;; minibuffer-tests.el ends here -- 2.20.1 --------------E6B7393FF90421271E72F100-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 10:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Eli Zaretskii , Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16288522395343 (code B ref 48841); Fri, 13 Aug 2021 10:58:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 10:57:19 +0000 Received: from localhost ([127.0.0.1]:40568 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEUsJ-0001O1-B4 for submit@debbugs.gnu.org; Fri, 13 Aug 2021 06:57:19 -0400 Received: from mail-pj1-f53.google.com ([209.85.216.53]:50818) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEUsH-0001Nj-0K; Fri, 13 Aug 2021 06:57:17 -0400 Received: by mail-pj1-f53.google.com with SMTP id bo18so14781595pjb.0; Fri, 13 Aug 2021 03:57: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=dSemysIFcr8EOxC+zmRqh0RfmCQlAPXj3PR3O0OqjzY=; b=SqubbkDLKuatuVjfKoJQjDb01671J7SAVkAWFgMGPssDNfl+XOjqCEss4W9U97TluU n1xJdbjlqGJ1Mj1WhF5MN+ma5y3HnwSBQMUEaAOAjuOyqjQAQavfhX7lVdrYQHDS8EXP Gl31ZgY5JLaBP/bQel4FeetOLzBJKAT1ynhYVwIej4H9fOmCtW8yb9dsnRO1ReNForXQ GiQFOPO41g/QwAR85Es4hB2/LPoIDSo5mFPJijI6ptl5uJSNY9IrpQRaw9rxcBk2Fyzs Y6kk0pfHMFXrKQo+XVgkxRoTawnBf8r3xw5U9plE3Shu1T9ME2GkKjAQbo+mjc0V/1YX yR4w== 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=dSemysIFcr8EOxC+zmRqh0RfmCQlAPXj3PR3O0OqjzY=; b=NTQOAVAo1TY2fEroNfNGTntDeXFhg7x7yWweDS2OXVVmtDuuVF28EDOha3kRVMrEqf laGHQhPHesf9JMefAa+1FD2bvqX6L21uVLGLTvhZGUG3FY28r3PoAjXEsuo3NITeatP0 aSReToSpb9CQo+3PaUcKXBLeP1O/z943YGXtjY9dhUdLp8Fp4jAKfkpedlflGw+x75Ex E5bHAqLYnd37uC9K6SBRjOp/8+WhJm2rBM5FhfQvgP9Uloqjk943gW5OP20NWL+Jiy6g 5CkggSl1auOIe20sy4lq72G9S4N6zbIUfclRVbKOlx4DMkCZAsV0V2lIehmd+AjgqWri 8vdA== X-Gm-Message-State: AOAM531XFDNPfEYScjVKT2NWHKrwVe/B05k0HPjP5zzDov/lMVwCXExH D5k3adbNTjhyrthvgFvnZ0DIsRXzcm2Nfjj3aJc= X-Google-Smtp-Source: ABdhPJxe/IE4MLihlfvr0Vhji16fJ+zz8X6GRYFjDtC5ScQ9Kf+7vIgbgXzMBZ7NcW8mfhlhyvK1dz3EAnhzzSNx9hY= X-Received: by 2002:a63:c0a:: with SMTP id b10mr1803467pgl.447.1628852231016; Fri, 13 Aug 2021 03:57:11 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> In-Reply-To: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Fri, 13 Aug 2021 11:56:59 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > In comparison to my last patch, the patch is fully backward > compatible and preserves all existing tests. This a very good thing (the fact that the patch is fully backward compatibl= e, I mean). It is quite a large patch that touches many completion internals. I'd like some time to look it over. I've read the discussion and am indeed aware of some non-neglibile performance problems in the flex and pcm completion styles since they need to copy strings around. Other -- completely different -- performance problems affect fido-mode specifically (but not fido-vertical-mode, curiously). In some conversation with Dmitry bug#48841: fido-mode is slower than ido-mode with similar settings We discussed this. There was also talk of removing the string copying with minimal (but not nu= ll) backward compatibility breakage. I recall Dmitry saying it was easy to fix on the completion frontend side. Many such frontends live in Emacs or GNU Elpa. On the other hand, the patch that we (or at least I) envisioned in that discussion was almost certainly much, much simpler than the one being presented here, and thus much easier to reason about and discuss. But to avoid comparing apples to oranges, I would you to summarize exactly, perhaps in the forms of code snippets, and/or benchmarks exactly what probl= ems your large patch solves. State the problem(s) first, then the solution (to each). If there are multiple problems, then there's a good chance that multiple pa= tches that address each of these are preferred. Thank you very much. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 11:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162885370316128 (code B ref 48841); Fri, 13 Aug 2021 11:22:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 11:21:43 +0000 Received: from localhost ([127.0.0.1]:40603 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEVFu-0004C3-K5 for submit@debbugs.gnu.org; Fri, 13 Aug 2021 07:21:42 -0400 Received: from server.qxqx.de ([178.63.65.180]:58693 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEVFs-0004Bk-QI; Fri, 13 Aug 2021 07:21:41 -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=8hwFNV/aAe3vVUeLSmkDH/7Bo2a4jUM3hyldTTf1mXU=; b=Z0MtMaK/toFejKLtw4dwCcoPv3 YNf2RJn82xqwC1SZfFohhyetqlPs/IpcFa3HdDwI5YKS+gW480ebGSmW/RKlFSpKr28QVEAgSI7l0 N4x0J9Nv6N7kXDletNpixpVp6ik9P4RYvzuI/yqa79S6KsPlVCLjehZWNnB0PA5aAHmA=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> From: Daniel Mendler Message-ID: <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> Date: Fri, 13 Aug 2021 13:21:32 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/13/21 12:56 PM, João Távora wrote: > I've read the discussion and am indeed aware of some non-neglibile > performance problems in the flex and pcm completion styles since > they need to copy strings around. Other -- completely different -- > performance problems affect fido-mode specifically (but not > fido-vertical-mode, curiously). > > In some conversation with Dmitry > > bug#48841: fido-mode is slower than ido-mode with similar settings > > We discussed this. I've read the discussion. You are probably aware of my efforts to in Vertico to implement deferred highlighting. The patch I implemented here implements the deferred highlighting in a clean way. > There was also talk of removing the string copying with minimal (but not null) > backward compatibility breakage. I recall Dmitry saying it was easy > to fix on the > completion frontend side. Many such frontends live in Emacs or GNU Elpa. > On the other hand, the patch that we (or at least I) envisioned in > that discussion > was almost certainly much, much simpler than the one being presented here, > and thus much easier to reason about and discuss. No, this is not the case. There is no simple fix of the allocation issue on the frontend side. The existing API `completion-all-completions` necessarily has to allocate all the strings in order to attach highlighting and scoring. The new API solves this in a clean way by both deferring highlighting and scoring. I claim that my patch is easy to reason about and refactors the existing code to address the exact problem we are having. Please take some time in reviewing it. > But to avoid comparing apples to oranges, I would you to summarize exactly, > perhaps in the forms of code snippets, and/or benchmarks exactly what problems > your large patch solves. State the problem(s) first, then the solution > (to each). The main problem is that `completion-all-completions` allocates all the strings every time the completions are filtered. This is the same performance issue you encountered in fido-mode/icomplete-mode. The second problem addressed by the new API `completion-filter-completions` is that `completion-all-completions` is limited in what it can return. For example it cannot return the end position of the completion. This is also solved by the new API. The new API is a clean extensible way forward. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 12:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162885637829450 (code B ref 48841); Fri, 13 Aug 2021 12:07:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 12:06:18 +0000 Received: from localhost ([127.0.0.1]:40680 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEVx0-0007ek-FK for submit@debbugs.gnu.org; Fri, 13 Aug 2021 08:06:18 -0400 Received: from mail-pl1-f176.google.com ([209.85.214.176]:36863) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEVwr-0007dy-3b; Fri, 13 Aug 2021 08:06:09 -0400 Received: by mail-pl1-f176.google.com with SMTP id f3so11648504plg.3; Fri, 13 Aug 2021 05:06:05 -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=njSiQZeqjhLp38f+q1STdsHcPKVcgTrEHylx+LpFmXQ=; b=mRybdEqQZZnXQ+wU8nuO02C7OgdE70ro+46P0pATdrPTNswOqyV8UJ8PUS9VtW0SPf VzMVuQpMif7UNSR5qytOEKul+S5kzXJw5cRg0YDCVjkJpi7cBM9PcqAplrtBnUCQw3wo NLnASLQXzEy4e6KCvPgVgHnmGImAeETOsALWq5E3R4V1DL/XuzYwwdKoHXJzIm46fikI nEAdAoPQXgB0jaarEGkweITDlYPwhyv2TLda0XFpXP6+UutpTkTXhusniX90baGjkHNV BugikjEx/lXJhnWusr5PLPs6oddB10h+b4g+Hz+GKa0DpV+k5xP7pCNxlLPprpZiBO7a m0kw== 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=njSiQZeqjhLp38f+q1STdsHcPKVcgTrEHylx+LpFmXQ=; b=W/imYrU92wciOyw2t/wJhW/DXkxz4KZI31KIKn0N8EWDDO4Qa/2DY0ZRyWfzxdd2XA vPd8KbhcfWqhhCgaTU4AqniQocifXMsCpcqILOUCFveLitTTKAJkah0bCEfHfNnzBcGZ lrPimWfTG84qiWMykUPaAM3yAINbVI7gVDmC+DZemRiVcb5OjMzH6Pj4rflBrycpYetu koVLblfSjjYwte4sCIY0/8Umw8o1vgkmSuZ1l8DWvz5B33opDq3Gz/F7EkgRJSfk3iqo D8alBpqI2rNfcx7LqGavxxxDsS/xbjJivMNgRqqjNAWv/0xujzpCy8r6YZ/MMKUYpc23 jCZQ== X-Gm-Message-State: AOAM533qhNr1IbKcVGH0kbevY5VqsnO9AGh+bm1INMIzJtDOdesWCtca 9Rjs+vA2DLBrTkkZhbJriucb9ffWcVR31B9ykwc= X-Google-Smtp-Source: ABdhPJyQMdCxprMZ56Ulp2KcbQOQamn6j8Gk84j90A/p0TH9H4ZILhFxlt32JRNgYDIOHmjKvSOaUG0hjQuyC993JyM= X-Received: by 2002:a17:90b:14b:: with SMTP id em11mr2340093pjb.125.1628856359053; Fri, 13 Aug 2021 05:05:59 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> In-Reply-To: <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Fri, 13 Aug 2021 13:05:47 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Aug 13, 2021 at 12:21 PM Daniel Mendler wr= ote: > No, this is not the case. There is no simple fix of the allocation issue > on the frontend side. I didn't claim that. At all. I claimed that the frontends that would be affected by the (small) backend patch are easy to adapt. I think you completely read past my idea. > The existing API `completion-all-completions` > necessarily has to allocate all the strings in order to attach > highlighting and scoring. The new API solves this in a clean way by > both deferring highlighting and scoring. I'm not sure you understand my alternative idea. As far as I understand (and have actually measured) the lines: ;; Don't modify the string itself. (setq str (copy-sequence str)) in minibuffer.el, in the function completion-pcm--hilit-commonality Are the cause of the problem that _I am talking about_ and that I have actually measured. Again you may be referring to a _different_ problem that I am unaware of. If one removes these lines, the process becomes much faster, but there is a problem with highlighting. My idea is indeed to defer highlighting by not setting the 'face property directly on that shared string, but some other property that is read later from the shared string by compliant frontents. If you have understood this idea, can you comment on it? (Preferably in terms of less adjectification regarding "cleanliness", but i= n terms of actual drawbacks/advantages?) The drawback that I can see in it is that frontends directly relying on 'face are broken by that patch. But according to Dmitry (and I tend to agree), it's quite easy to address those frontends. Most of them live in Emacs core or GNU Elpa. The advantage that I see is that those adaptations apart, it is a small localized and effective change. > I claim that my patch is easy to reason about and refactors the existing > code to address the exact problem we are having. Please take some time > in reviewing it. I am already taking some time. I need your assistance in explaining the problems first. I take into account your claims of cleanliness and elegance= , but in terms of their power of persuasion, they are much more limited than hard material evidence. > The main problem is that `completion-all-completions` allocates all the > strings every time the completions are filtered. This is the same > performance issue you encountered in fido-mode/icomplete-mode. OK. I encountered at least two different performance problems there, with quite different causes. So let's stick to the string-allocation problem. P= ost a code snippet that demonstrates the problem the way you see it/experience = it? Some benchmark code would be very welcome. You can probably grab my benchmarking code from that other bug. Then it becomes easy to study multiple solutions to that problem and choose the best one! > The second problem addressed by the new API > `completion-filter-completions` is that `completion-all-completions` is > limited in what it can return. For example it cannot return the end > position of the completion. And why is this a problem? Can you post an example of something you'd like to do, but can't? Regardless, it does seem indeed like a "second" pro= blem (as you state) so perhaps something that can be addressed separately. Is your particular solution to this second problem instrumental in solving the "main problem" > This is also solved by the new API. The new API is a clean extensible wa= y forward. I understand you've put time and effort into producing this work. We are all indebted and I promise to read it. But every API writer in history of programming has claimed those things and reality often shows otherwise. So it's not that your work can't be those things you claim, maybe it is, bu= t generally the larger and broader the work the harder it is to reason about. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 12:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162885738631065 (code B ref 48841); Fri, 13 Aug 2021 12:24:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 12:23:06 +0000 Received: from localhost ([127.0.0.1]:40703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEWDG-00084v-SP for submit@debbugs.gnu.org; Fri, 13 Aug 2021 08:23:06 -0400 Received: from server.qxqx.de ([178.63.65.180]:52851 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEWDB-000847-Ko; Fri, 13 Aug 2021 08:23:01 -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=No8L/5f/jqE7VfR4Zr8RQeJNpAlnovp34dfprC2OpIA=; b=NVDxqieGZDnqxkTN6bD1l5Lybk XKH0kqn8ciZRmZw+/MId68EnF9wrXz5XBq9PW3+NEGcLSSbkH7oZ/LvNHUVkYBB3G2MrmqMEWev05 59CczGWRQCHXazW65/zaniWkgZYzTYafVKgjWRWtqAl9idZuD1K3RAOU5YOdF7dQHWx0=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> From: Daniel Mendler Message-ID: <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> Date: Fri, 13 Aug 2021 14:22:48 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/13/21 2:05 PM, João Távora wrote: >> The existing API `completion-all-completions` >> necessarily has to allocate all the strings in order to attach >> highlighting and scoring. The new API solves this in a clean way by >> both deferring highlighting and scoring. > > I'm not sure you understand my alternative idea. As far as I > understand (and have actually measured) the lines: > > ;; Don't modify the string itself. > (setq str (copy-sequence str)) > > in minibuffer.el, in the function completion-pcm--hilit-commonality > > Are the cause of the problem that _I am talking about_ and that > I have actually measured. Again you may be referring to a > _different_ problem that I am unaware of. You are right that the call to `copy-sequence` is a major bottleneck in the filtering. However you are wrong that this line can simply be removed/disabled and the candidates can be modified. The API guarantees and has always guaranteed that the candidate strings are not mutated. It is important to keep this property since this will preclude many bugs due to string mutation. By separating the filtering and mutation (highlighting, scoring) my patch addresses the problem at hand in the proper way. Note that the UI also has no possibility to opt-out of the mutation. The UI is actually not the one being concerned about the mutation here, it is the backends (completion tables), which produce the strings. If one starts mutating these strings you will see bugs cropping up throughout Emacs where shared strings suddenly have spurious additional properties due to the completion filtering. Mutation would be a reasonable choice here if the problem could not be solved in a proper way. But in fact it can be solved in a proper way without mutating the strings at all as my patch shows. > If one removes these lines, the process becomes much faster, but there is a > problem with highlighting. My idea is indeed to defer highlighting by not > setting the 'face property directly on that shared string, but some > other property > that is read later from the shared string by compliant frontents. This solution is much more ad-hoc and you still mutate the string which is not allowed. > The advantage that I see is that those adaptations apart, it is a small > localized and effective change. Note that your idea also does not address the other issues which are addressed by my patch. The new API `completion-filter-completions` returns data which hasn't been available before, e.g., the end position, which cannot be fixed given the existing API. >> The main problem is that `completion-all-completions` allocates all the >> strings every time the completions are filtered. This is the same >> performance issue you encountered in fido-mode/icomplete-mode. > > OK. I encountered at least two different performance problems there, with > quite different causes. So let's stick to the string-allocation problem. Post > a code snippet that demonstrates the problem the way you see it/experience it? You can try my Vertico completion UI, which is available on GNU ELPA. It implements deferred highlighting and there the performance difference is perceivable. Currently Vertico uses an advice-based hack to avoid the over-eager string-allocations and the highlighting. >> The second problem addressed by the new API >> `completion-filter-completions` is that `completion-all-completions` is >> limited in what it can return. For example it cannot return the end >> position of the completion. > > And why is this a problem? Can you post an example of something you'd > like to do, but can't? Regardless, it does seem indeed like a "second" problem > (as you state) so perhaps something that can be addressed separately. Please look at the FIXMEs in minibuffer.el which address this. Currently only the beginning position of the completion boundary is returned, which is only half of the information. > I understand you've put time and effort into producing this work. We are > all indebted and I promise to read it. But every API writer in history of > programming has claimed those things and reality often shows otherwise. > So it's not that your work can't be those things you claim, maybe it is, but > generally the larger and broader the work the harder it is to reason about. I stand by my claim and I also stand by the claim that removing/disabling `copy-sequence` is not a proper way to address the issues at hand and will introduce many bugs in the long run. Please take your time to look at the patch in earnest. I would also like to see others chime in here with their opinion. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 12:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.1628858279345 (code B ref 48841); Fri, 13 Aug 2021 12:38:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 12:37:59 +0000 Received: from localhost ([127.0.0.1]:40779 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEWRi-00005O-Lf for submit@debbugs.gnu.org; Fri, 13 Aug 2021 08:37:59 -0400 Received: from mail-pj1-f54.google.com ([209.85.216.54]:50968) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEWRh-00004t-9k; Fri, 13 Aug 2021 08:37:57 -0400 Received: by mail-pj1-f54.google.com with SMTP id bo18so15156570pjb.0; Fri, 13 Aug 2021 05:37:57 -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=tlFNsJoHhRBkUHPWY4LrARaxXuMGniqUKbtu2G0qdXU=; b=W2jhGqYmQiddIO9xrhNq+mgLhNpZDrXgB7E3Nq9ikxl01hbFX3Xd7DKIjge5nk70Vk TJ6lEut6rRtmflXg2bZWmdKRLTVld535iIGhkPNPkR2iE5mzIBImO16T3hpJMGEAqQv7 Yhr8k8CWpX1DATiwscnuWOKn8mfY2+OzkPrdykjc/3wfXZb8o3M/yKk0NdfzqtI6ymFg 0kPcVTzA66bPapJPUHB8ZIrhZztHJy3tmpAGVeMOUngbv1wGsxMvUTRwlZe1YsLBzK6+ KKaqcpLVT2U+JgodurScZY/iVu9Yzg7kQaUXfr3xSsiXh8bXW9UwtkjVdPzFp2sSSxI8 eG/w== 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=tlFNsJoHhRBkUHPWY4LrARaxXuMGniqUKbtu2G0qdXU=; b=MSUMwNM1xDgUgyDOyycbk6t2dYHgo4sV0XHsatXgNpSvKZ9YH34CNMmfKZKZ19xLfW M7OfsOt3tHBGN3g95s2YqHPo6swiNlHncTqBJrwIhlJcrTT2Yqx8BiHduUuMGrutw5+h VUeHt52P8EcFYZFdgNbtZbLToqq+Mru0MghAtWGYwpI5CyRZYrKB2qesDKpv+vcfIwUs HqVtM54gdxBnGzPgKeGuu/W9kkqKyhdTwRmhsDGfwz8NTTfconxgRhFcjaOOvO6agmaz Y6MlnngG4cM0S3vjLFWM/gIDIcDQBZbxVY3BzPILmCN2m9RRa5DOVhWCY1DpRJ5s9kZN NgPA== X-Gm-Message-State: AOAM533LyFHgkB8NdTtQk9u31KuoZZ2wotSW8j8BVW/NqfHWrsnUup2m aSTQuKFoIbnP+NZEcJXQVbU1f7js7LJI7X9N18w= X-Google-Smtp-Source: ABdhPJydEtmy84BK6Wfd+Bbslze/kSoY9HX0jvqeGGlmCcf/udvaNVKD9YyLf4HvKp8/XJpyzqs4997sPyThwdhiEiE= X-Received: by 2002:a62:5c6:0:b029:341:e0b1:a72c with SMTP id 189-20020a6205c60000b0290341e0b1a72cmr2220586pff.71.1628858271491; Fri, 13 Aug 2021 05:37:51 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> In-Reply-To: <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Fri, 13 Aug 2021 13:37:38 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler wro= te: > It is important to keep this property since this will preclude many bugs > due to string mutation. I am aware of this, of course. Can you give examples of these "many bugs"? Perhaps other than the one I already described and addressed? > By separating the filtering and mutation > (highlighting, scoring) my patch addresses the problem at hand in the > proper way. >[ ... ] > Mutation would be a reasonable choice here if the problem could not be > solved in a proper way. But in fact it can be solved in a proper way > without mutating the strings at all as my patch shows. "proper" is just an reasonably empty adjective. There are different ways t= o go about this, of course. What's "proper" and isn't is hard to debate objectively. > This solution is much more ad-hoc and you still mutate the string which > is not allowed. It's also difficult to debate "ad-hoc" or not. If you've studied the problem, what makes you say that mutating the string (in this case, adding a 'completion--style-face' property to it) is not allowed? What negative thin= gs would derive from it. > > The advantage that I see is that those adaptations apart, it is a small > > localized and effective change. > > Note that your idea also does not address the other issues which are > addressed by my patch. That's for sure. My patch idea addresses only that single problem. I think this is a good property of patches: to solve one thing, not many. We can make more patches to solve other problems, once we identify them clearly. > The new API `completion-filter-completions` > returns data which hasn't been available before, e.g., the end position, > which cannot be fixed given the existing API. > > >> The main problem is that `completion-all-completions` allocates all th= e > >> strings every time the completions are filtered. This is the same > >> performance issue you encountered in fido-mode/icomplete-mode. > > > > OK. I encountered at least two different performance problems there, wi= th > > quite different causes. So let's stick to the string-allocation problem= . Post > > a code snippet that demonstrates the problem the way you see it/experie= nce it? Look, one needs to evaluate things quantitively. Your patch is not to Vertico, it's to Emacs. I'm concerned with changes to Emacs and their effect on all completion frontends. So trying Vertico isn't very useful. If you're solving a performance problem (and it seems that you are, among other things) we really need benchmarks, a description of an experiment who= se results can be reproduced independently. It's the normal scientific method. Something like: "before my patch, this code takes 123 seconds to run, after my patch it takes 12." > >> The second problem addressed by the new API > >> `completion-filter-completions` is that `completion-all-completions` i= s > >> limited in what it can return. For example it cannot return the end > >> position of the completion. > > > > And why is this a problem? Can you post an example of something you'd > > like to do, but can't? Regardless, it does seem indeed like a "second"= problem > > (as you state) so perhaps something that can be addressed separately. > > Please look at the FIXMEs in minibuffer.el which address this. > Currently only the beginning position of the completion boundary is > returned, which is only half of the information. OK. It does seem like a separate problem, so maybe open a new bug for it? Jo=C3=A3o T=C3=A1vora From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 12:57:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162885941910575 (code B ref 48841); Fri, 13 Aug 2021 12:57:01 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 12:56:59 +0000 Received: from localhost ([127.0.0.1]:40818 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEWk2-0002kP-DQ for submit@debbugs.gnu.org; Fri, 13 Aug 2021 08:56:58 -0400 Received: from server.qxqx.de ([178.63.65.180]:56345 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEWjw-0002k2-Bh; Fri, 13 Aug 2021 08:56:53 -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=a89yZI6TfoUJ6rLAH1MakLAhc71tO9b1C8U/CHdpsC8=; b=N4MIoo3oh97UH6pQB1pEy7f66+ 9sONgkN7OIXHdBdyqVEavbTl7vLSVNa0DJfEcPc+jLn1uMcJhu7xLnmEPYWbWDt0Zjt5Xil5g4Qt5 sgbdZcDkgu7zBVoSKBaf+jKohOVq31IKqv9Yz5dnImPysQjXCqiE1zInTEHWiTn5Mu34=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> From: Daniel Mendler Message-ID: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> Date: Fri, 13 Aug 2021 14:56:38 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/13/21 2:37 PM, João Távora wrote: > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler wrote: > >> It is important to keep this property since this will preclude many bugs >> due to string mutation. > > I am aware of this, of course. Can you give examples of these "many bugs"? > Perhaps other than the one I already described and addressed? No, João, this is not how it goes. I don't have to prove to you that your idea introduces bugs. You have to show that mutation of the completion table strings (which are not supposed to be mutated) will not lead to bugs, which are hard to find. In contrast with the new API `completion-filter-completions` this entire class of bugs is avoided by construction of the API. Furthermore the `completion-filter-completions` API is easy to use in comparison to your idea, where "compliant" backends have to apply string manipulations to apply the highlighting and revert the strings back to their old pristine state. The only thing the API user has to do is to call the `highlight` function returned in the alist by `completion-filter-completions`. >> By separating the filtering and mutation >> (highlighting, scoring) my patch addresses the problem at hand in the >> proper way. >> [ ... ] >> Mutation would be a reasonable choice here if the problem could not be >> solved in a proper way. But in fact it can be solved in a proper way >> without mutating the strings at all as my patch shows. > > "proper" is just an reasonably empty adjective. There are different ways to > go about this, of course. What's "proper" and isn't is hard to debate > objectively. You are contradicting yourself here. You agree that string mutation is better be avoid. If we define "proper" as avoids string mutation if this is easily possible, then my patch implements a proper solution to the problem. >>> The advantage that I see is that those adaptations apart, it is a small >>> localized and effective change. >> >> Note that your idea also does not address the other issues which are >> addressed by my patch. > > That's for sure. My patch idea addresses only that single problem. > I think this is a good property of patches: to solve one thing, not many. No, this is not necessarily true. This is only good if the problem is solved in a way which is future proof. The idea of mutating the strings is a hack and not a solution. In contrast, I am presenting a future-proof new API as solution which addresses multiple problems. If you look at the patch, only 196 new lines are added to minibuffer.el. Furthermore the patch adds 213 lines of new tests. > Look, one needs to evaluate things quantitively. Your patch is not > to Vertico, it's to Emacs. I'm concerned with changes to Emacs and their > effect on all completion frontends. So trying Vertico isn't very useful. > > If you're solving a performance problem (and it seems that you are, among > other things) we really need benchmarks, a description of an experiment whose > results can be reproduced independently. It's the normal scientific method. João, you don't have to lecture me on these things. Of course I can provide such numbers. You cannot reasonably make the claim that `copy-sequence` is the problem and at the same time claim that my patch does not solve the performance issues, when in fact my patch avoids this exact string copying. >>>> The second problem addressed by the new API >>>> `completion-filter-completions` is that `completion-all-completions` is >>>> limited in what it can return. For example it cannot return the end >>>> position of the completion. >>> >>> And why is this a problem? Can you post an example of something you'd >>> like to do, but can't? Regardless, it does seem indeed like a "second" problem >>> (as you state) so perhaps something that can be addressed separately. >> >> Please look at the FIXMEs in minibuffer.el which address this. >> Currently only the beginning position of the completion boundary is >> returned, which is only half of the information. > > OK. It does seem like a separate problem, so maybe open a new bug for it? There is already a FIXME in minibuffer.el, so I assume Stefan Monnier is well aware of these issues. It is an additional win of the new API that such open problems can be fixed too. As I see it, a new API is the way to go here. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 13:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162886180231523 (code B ref 48841); Fri, 13 Aug 2021 13:37:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 13:36:42 +0000 Received: from localhost ([127.0.0.1]:40917 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEXMY-0008CH-B5 for submit@debbugs.gnu.org; Fri, 13 Aug 2021 09:36:42 -0400 Received: from mail-pl1-f179.google.com ([209.85.214.179]:43911) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEXMV-0008Bw-1X; Fri, 13 Aug 2021 09:36:40 -0400 Received: by mail-pl1-f179.google.com with SMTP id e19so12007291pla.10; Fri, 13 Aug 2021 06:36:38 -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=tvhjGLLU6CrPIl2BruGEyiA2A8Y1z7e+RBKklFm3qaY=; b=WO6Qd/orW+L6sc7R1/ProxKfGtNTRSoLWOpPCBg2HsS4hNQN0IfFCM9vtuwahg7YSc y5j9j8J5pFb7pZXkCmI5hJO73LhiVAQA9zwBpVbTCh5w41gt7X/C7slXlMm8cxfhzZVk t78oUsxDQXpqMBzVTKenBQTnAQC5LAvIUruT4OBagHR7s35sQXBrrAwUqkjHjz6UcyYa uBdIxbgTQ/wP9xejKyFASJfY4Xlvv45tPw55SXPaqn3qXjJ6Q5j4VBnpfDA8GH+Cr+zQ PmvqBJHw0y+T5zUd5debsLzFCMKOAkYZQ+zl8/YuyaW0TUIAetq0n859qgTHbpcNY27E uEAQ== 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=tvhjGLLU6CrPIl2BruGEyiA2A8Y1z7e+RBKklFm3qaY=; b=nr+vEnLGKC33Ilcv1/hcPHgqXiNnUKl+mvSF94J3uwqYpp/Ne2P+cJzvzNwfZpw92k cdfkGO2BM96+oxkMY+QffGxZDEKJXBfG2p/BodDe+Xvl1MrZJMqXQWma0LRdtZ7Ey0GC Va2bOGXHhocqRmn4pGVW8HDObXeOsF2ZXRDZk7ECgiyjMb30j4eGOSJpjTwXF5CHQQ65 HMzjz2e08rrA80Y7LAnOo9IjPlPzimx4FfJVbWaZi2Rfa1HunW5WdhJKVDqiJ8t5UjBP 9P22quEBpM+96aq0KYdjgIK8MvYA7ISrKT80Ujv5wOWJwUhgDcjHNu2MS1ucGLO5gBi1 1nsA== X-Gm-Message-State: AOAM531aKxIK6KX97S4/wGTRppidvp8nrLKDrhYgnZ+xSMX6Vzu5Ulaz ZFeANigcxIyqNHQaoxKIf+cxQsigik5eI8TlwB8= X-Google-Smtp-Source: ABdhPJyqcaYJLJRUlMaexDe0u7Fuq1zPF1MfteXDQLEs+nt9W0IdOoXkavODVEBpwkrwjUcylKHzniBr4TbNfnLRSis= X-Received: by 2002:aa7:9050:0:b029:3af:7e99:f48f with SMTP id n16-20020aa790500000b02903af7e99f48fmr2534645pfo.2.1628861793055; Fri, 13 Aug 2021 06:36:33 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> In-Reply-To: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Fri, 13 Aug 2021 14:36:21 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) didnOn Fri, Aug 13, 2021 at 1:56 PM Daniel Mendler wrote: > > On 8/13/21 2:37 PM, Jo=C3=A3o T=C3=A1vora wrote: > > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler = wrote: > > > >> It is important to keep this property since this will preclude many bu= gs > >> due to string mutation. > > > > I am aware of this, of course. Can you give examples of these "many bu= gs"? > > Perhaps other than the one I already described and addressed? > > No, Jo=C3=A3o, this is not how it goes. I don't have to prove to you tha= t > your idea introduces bugs. So you just say it and I have to believe it? Then I could say the same to you, right? I won't of course, that would be silly. You have to show that mutation of the > completion table strings (which are not supposed to be mutated) will not > lead to bugs, which are hard to find. > > In contrast with the new API `completion-filter-completions` this entire > class of bugs is avoided by construction of the API. Furthermore the > `completion-filter-completions` API is easy to use in comparison to your > idea, where "compliant" backends have to apply string manipulations to > apply the highlighting and revert the strings back to their old pristine > state. The only thing the API user has to do is to call the `highlight` > function returned in the alist by `completion-filter-completions`. > > >> By separating the filtering and mutation > >> (highlighting, scoring) my patch addresses the problem at hand in the > >> proper way. > >> [ ... ] > >> Mutation would be a reasonable choice here if the problem could not be > >> solved in a proper way. But in fact it can be solved in a proper way > >> without mutating the strings at all as my patch shows. > > > > "proper" is just an reasonably empty adjective. There are different wa= ys to > > go about this, of course. What's "proper" and isn't is hard to debate > > objectively. > > You are contradicting yourself here. You agree that string mutation is > better be avoid. If we define "proper" as avoids string mutation if this > is easily possible, then my patch implements a proper solution to the> pr= oblem. I didn't say it's better avoided, though of course I will avoid _any_ chang= e if I can. I said I have identified one drawback with doing it. Then I have addressed that drawback. So that's what I said. I am unaware of _other_ drawbacks. They might exist, but I am unaware of them. Perhaps you are, and indeed you state they exist, but you refuse to let me know about them. Or perhaps others know of them and will let me kno= w. In my long-running discussion with Dmitry they were not presented (again, except for the one I identified). > > That's for sure. My patch idea addresses only that single problem. > > I think this is a good property of patches: to solve one thing, not man= y. > No, this is not necessarily true. This is only good if the problem is > solved in a way which is future proof. OK, but what thing of the future, real or academic, do you envision that would bring back the problem, or create other problems? > The idea of mutating the strings is a hack and not a solution. Without facts to back it up, I have to take this as gratuitous disparagemen= t. Nicht so gut. > In contrast, I am presenting a > future-proof new API as solution which addresses multiple problems. That's the issue. The completion system is very complex and there are many good ideas, different, floated by many people. But if you make a patch to address "multiple" fuzzily-described problems, it's hard to judge how good your ideas even are! Maybe they are indeed very good, I never said they weren't. No need to get worked up about it! Again, my proposal is to first focus on the performance problems caused by string allocation. _That_ problem is well understood, at least by me (but = it would help to settle on convenient benchmarks understood by others, too). Then we can go from there. > you look at the patch, only 196 new lines are added to minibuffer.el. > Furthermore the patch adds 213 lines of new tests. It's a large patch, over 1000 lines. One does not review a patch merely by looking at lines added, when one needs to read much more, to understand implications, = etc. It needs documentation, for one, much more than just docstrings, on how to use the new API. > Jo=C3=A3o, you don't have to lecture me on these things. Of course I can > provide such numbers. Then please do! Not meaning to lecture you, just that your suggestion that I try Vertico UI as a substitution for these numbers seemed completely misguided. So if you have them (or "can provide them") let's see them. All I'm asking, preferably from Emacs -Q recipe. > You cannot reasonably make the claim that > `copy-sequence` is the problem and at the same time claim that my patch > does not solve the performance issues, when in fact my patch avoids this > exact string copying. I didn't say it didn't solve them! Now, where did I say that? I would like to see a benchmark so that I can witness it _and_ study alternative solutions. With that, there's a better chance that I will be persuaded there are none as elegant, clean, proper, pure, etc as yours! Maybe others review patches on other aspects that's fine. Maybe others will. Eli reviewed on minor formatting and documentation aspects. I review them on substance, using numbers and conducting my own experiments and tests. This takes time and help from the scientist on the other end. Simple and in summary, let's hope your next reply has some benchmarks so we can make progress. Thanks, Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 14:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162886342120483 (code B ref 48841); Fri, 13 Aug 2021 14:04:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 14:03:41 +0000 Received: from localhost ([127.0.0.1]:42774 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEXma-0005KF-Ut for submit@debbugs.gnu.org; Fri, 13 Aug 2021 10:03:40 -0400 Received: from server.qxqx.de ([178.63.65.180]:52349 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEXmV-0005Jq-Ns; Fri, 13 Aug 2021 10:03:36 -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=U+7jHgcxqSUV0RHeOu3QFSoRtGe0iLwvU6TC36yrcVI=; b=EcPIMUnEp4uE8O01Mqno6vFAsl rUQgFBQ6At+ydR0XwESZnD/Q1mhooK6GNCJmS6WcUPXOPRR//qIGlTuFIPoxXHXt5ps4KrGh8Fs0W muuQwa8s1CF0tqEG9JJpzW/GomDGoT7mDRug2LZ73hg4xE0AWTjiLc32Ot2ecxPYC9EI=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> From: Daniel Mendler Message-ID: Date: Fri, 13 Aug 2021 16:03:21 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/13/21 3:36 PM, João Távora wrote: >> You are contradicting yourself here. You agree that string mutation is >> better be avoid. If we define "proper" as avoids string mutation if this >> is easily possible, then my patch implements a proper solution to the> problem. > > I didn't say it's better avoided, though of course I will avoid _any_ change if > I can. I said I have identified one drawback with doing it. Then I > have addressed > that drawback. So that's what I said. > > I am unaware of _other_ drawbacks. They might exist, but I am unaware of > them. Perhaps you are, and indeed you state they exist, but you refuse to > let me know about them. Or perhaps others know of them and will let me know. > In my long-running discussion with Dmitry they were not presented (again, > except for the one I identified). In the discussion with Dmitry, I already pointed out that there is an alternative principled approach implemented by my Vertico UI, which is in fact the same approach as implemented in this patch. If there are other useful conclusions from the discussion I will adopt them here for this patch. >>> That's for sure. My patch idea addresses only that single problem. >>> I think this is a good property of patches: to solve one thing, not many. >> No, this is not necessarily true. This is only good if the problem is >> solved in a way which is future proof. > > OK, but what thing of the future, real or academic, do you envision that > would bring back the problem, or create other problems? > >> The idea of mutating the strings is a hack and not a solution. > > Without facts to back it up, I have to take this as gratuitous disparagement. > Nicht so gut. João, your whole answers are "nicht so gut" or not useful. What is your point? Please give constructive technical feedback instead of such empty phrases. >> In contrast, I am presenting a >> future-proof new API as solution which addresses multiple problems. > > That's the issue. The completion system is very complex and there are many > good ideas, different, floated by many people. But if you make a patch to > address "multiple" fuzzily-described problems, it's hard to judge how good > your ideas even are! Maybe they are indeed very good, I never said > they weren't. No need to get worked up about it! > > Again, my proposal is to first focus on the performance problems caused by > string allocation. _That_ problem is well understood, at least by me (but it > would help to settle on convenient benchmarks understood by others, too). > Then we can go from there. No, it is not the correct approach to fix larger issues by applying localized patches. We both have identified the string allocations and highlighting as problem. My patch resolves the problem, by exposing just the right pieces of the already existing completion machinery. More about this below. >> you look at the patch, only 196 new lines are added to minibuffer.el. >> Furthermore the patch adds 213 lines of new tests. > > It's a large patch, over 1000 lines. One does not review a patch > merely by looking at > lines added, when one needs to read much more, to understand implications, etc. > It needs documentation, for one, much more than just docstrings, on > how to use the > new API. I suggest you take a step back here and try to understand the high-level idea first. It seems that you are misjudging the complexity of the patch. The minibuffer completion machinery is already constructed such that filtering and highlighting are separate. If you look at `completion-basic-all-completions` for example, there is first a filtering step and then the highlighting is applied in a second step by the function `completion-hilit-commonality`. This separation exists for all completion styles. My patch does nothing else than separating these two processing steps. The new API `completion-filter-completions` returns the filtered list and a function to apply highlighting afterwards only to the actually displayed candidates where highlighting is needed. In contrast your idea totally misses this. > Maybe others review patches on other aspects that's fine. Maybe > others will. Eli reviewed on minor formatting and documentation aspects. I am looking forward to more reviews by other people. Your desire for benchmarks is understandable, but I doubt that it will lead to progress in the discussion here and I doubt that it will convince you. The outcome of the benchmark is the following - my patch only filters and does not mutate the strings, so it will be slightly faster than your idea where the strings are mutated first and afterwards the mutation has to be undone again. However the mutations are of course not expensive, so the differences will be small. The discussion we should be having here is about technical details and internals and not about the numbers which won't give any guidance in this case regarding the correct API design. You seem to always come back to the "scientific method". Note that there is not only statistics, there is only "scientific reasoning" and mathematics, which allows to reason about transformations and drawing conclusions from that. If you don't do this, you are only doing half of the science. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 14:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162886390721318 (code B ref 48841); Fri, 13 Aug 2021 14:12:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 14:11:47 +0000 Received: from localhost ([127.0.0.1]:42801 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEXuV-0005Xh-0J for submit@debbugs.gnu.org; Fri, 13 Aug 2021 10:11:47 -0400 Received: from mail-pl1-f171.google.com ([209.85.214.171]:36497) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEXuT-0005XO-29; Fri, 13 Aug 2021 10:11:45 -0400 Received: by mail-pl1-f171.google.com with SMTP id f3so12149386plg.3; Fri, 13 Aug 2021 07:11:45 -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=eUEMG04mECiWu+Pg/59yRQTqKhWPV24mxZW+MGMR83g=; b=e0f+5n9o+qdDSb6F+N45qk8yKvmMSb2FY0vmM6rOqaQ9Of2rVABsOw2yLQmY1B55RM xHfmICGG/kxNCAEieMkU0QAsM2Unu1ed14G1om4axInaVgwLGIez0yHGwSNFkGRT70ga 1QCFtv5Q+j66S1hQoWh+ZQNoJ0y9xHKXSvisZUZRaavrATVjtkF3TBk14aXrWLqtoBIK mwBpxpbYWzOaaONZjQAbAQhHMD8sKQ9BNiRNVLu7Iz/bpPh04kSvZSXzYE96MdokBnl2 zUY1ALHN61ayUWTMkkqancqmZ/RgHXM9RWdgt+DrbRzKSX17hvauxv+OrR19KcmSUQhx 2mgw== 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=eUEMG04mECiWu+Pg/59yRQTqKhWPV24mxZW+MGMR83g=; b=J/9AhrCpLYmciMdutRi9PDAJajvqL/gilhZdFhaXGr2ADnMBmc9qEAH198VozeP1v4 6XTttn6CRnlPbnKg9UGrAmz9HmSkWUyxTBYkhaK8IIpBsEoNm0FIgEmyt3SR4ZqfLgHq NV32ZrN7xropCfI0xmSz3mitrTJkQ/DMKN5ZzDXkXxvmy6pRIckUTIQ7LWS1EqfHnyRi tAQmT/novzlG9cHZQ5o8HTUWNUuQSclIbEmVplEe0C37yi3vYK6uvyG+ToUK0FjTNGKT ezQ1Xl2R/vxcQv3/U1tsOwAPESkhwj+IKzb1KIQWJ3MkiV+RcfeeNtxtON8zYOelSdLG VAyw== X-Gm-Message-State: AOAM532ALRMS4yIKbKle8NmtPEbllZ4lSqVlD8eB8GWn5LVcVqSbmMv6 s4N9pJUY/0XfYgNwZDAdhiccWf19JhMtTsg1jsM= X-Google-Smtp-Source: ABdhPJwpc22f6+4Nexy2mgyEQcZGioFJ083PVKOOgX27jXzg9BK7q63Zr5o/xaX4+lJyfg9OXQ4JKsxOZ5QXUcxfbR8= X-Received: by 2002:a17:90a:a091:: with SMTP id r17mr2830007pjp.56.1628863899134; Fri, 13 Aug 2021 07:11:39 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Fri, 13 Aug 2021 15:11:27 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Fri, Aug 13, 2021 at 3:03 PM Daniel Mendler wro= te: > > Without facts to back it up, I have to take this as gratuitous disparag= ement. > > Nicht so gut. > > Jo=C3=A3o, your whole answers are "nicht so gut" or not useful. What is = your > point? Please give constructive technical feedback instead of such > empty phrases. Look, you disparaged an idea of mine without absolutely any facts. I don't = think that's good. "Nicht so gut" was a lighthearted way of pointing it out. Lighten up. Post the benchmarks you say you have and stop the pompous handwaving. Bye, Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Fri, 13 Aug 2021 14:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Dmitry Gutov , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162886547232189 (code B ref 48841); Fri, 13 Aug 2021 14:38:02 +0000 Received: (at 48841) by debbugs.gnu.org; 13 Aug 2021 14:37:52 +0000 Received: from localhost ([127.0.0.1]:42850 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEYJj-0008N6-PY for submit@debbugs.gnu.org; Fri, 13 Aug 2021 10:37:51 -0400 Received: from server.qxqx.de ([178.63.65.180]:42485 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEYJh-0008Mn-4w; Fri, 13 Aug 2021 10:37:50 -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=xG1wTRTLJhDNwXgVcJFmihoxCZwFJ4j6Wekup9FM4LM=; b=w8l5uwURr2DI8wfigMtIRnxeqk XJjqcryeSPLognhKMP8t7idXRiybmfBIhfmDcAk0T0QQZ/gs58g/Ava2RVZMTKDabQ26uPZdz8zXQ 5v9yaXw+fkdL9H2JxFxGERF90chAe7wGIpHbtp8F/7pcfLg1OBsYao8/z/z/4FYZ5b4Q=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> From: Daniel Mendler Message-ID: <61963a69-1b1c-a635-97dc-a665ecb07a6b@daniel-mendler.de> Date: Fri, 13 Aug 2021 16:37:38 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/13/21 4:11 PM, João Távora wrote: > On Fri, Aug 13, 2021 at 3:03 PM Daniel Mendler wrote: > >>> Without facts to back it up, I have to take this as gratuitous disparagement. >>> Nicht so gut. >> >> João, your whole answers are "nicht so gut" or not useful. What is your >> point? Please give constructive technical feedback instead of such >> empty phrases. > > Look, you disparaged an idea of mine without absolutely any facts. I don't think > that's good. "Nicht so gut" was a lighthearted way of pointing it out. > Lighten up. > Post the benchmarks you say you have and stop the pompous handwaving. João, the way you argue is not in any way "lighthearted". It also depends on what the other party receives as the message. And here you just repeat this style by calling my reasoning "pompous handwaving". This is not a fair way to discuss. In contrast my arguments were generally of a technical nature. I propose we both calm down a bit and let others chime in here. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 02:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Daniel Mendler Cc: Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162890927420762 (code B ref 48841); Sat, 14 Aug 2021 02:48:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 02:47:54 +0000 Received: from localhost ([127.0.0.1]:43367 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEjiD-0005Om-GA for submit@debbugs.gnu.org; Fri, 13 Aug 2021 22:47:53 -0400 Received: from mail-wm1-f45.google.com ([209.85.128.45]:40490) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEjiC-0005OW-1a; Fri, 13 Aug 2021 22:47:52 -0400 Received: by mail-wm1-f45.google.com with SMTP id f12-20020a05600c4e8c00b002e6bdd6ffe2so5160108wmq.5; Fri, 13 Aug 2021 19:47:51 -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=YJw6OlV4lASsh/tUTN6SzIwACHP933YFdLTFK0MkuqM=; b=Vidv7X/VQNIy18MEfGR9+nO2HYx3p9uH5yds3+TK7an4SST2+36hNaFlToeGos1yzU ZXPEaOpJzr5nAm2atp8TRLaxcrJx59uNbGTcfk7ElXQLM6craANPxqMRQ/TJbw12OkVS lC0+2s9E6OgAmxOnj8t2Qhui612cejdqTiSIhupU9/FRSTtmV0qUYMJmda0IWsImEzbn DKsFPCnqf7m0sx09tPSKXKlkBvncG41XVJ6Cq3K5sANAomQJa8sH4P9GAr6+2fVnmIX9 w8xO/J7VMNT6j80LLgl56LJNAtV57ifHaDToXoKmypw3CPOhSfbrl6x7N0bZIfhRQ7xR 2TFg== 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=YJw6OlV4lASsh/tUTN6SzIwACHP933YFdLTFK0MkuqM=; b=nR1zS8Nn309e6wVeitw1G4GtSPeEcG9GrIwjnVhWO70ig2C6FOM97NZkOHB4MyExCs X/DPOTnUIk77LeUS5ETxtYZRizhEKjozvMkKAiWOH2VOxkBTWoJpsbeZaq+BtGp+eKeb hWvDeoVOCZ4faOBObfh9j2PgNAW6clgferd+ak0/cx8HUE1Hg706HUK32wirZWauT4zm kXzquiRez+FniGAL7lf5pkd26FbkrmgB03mTjrER/KDSwJUHGzKVEOdhV5LJ1EvlTmox JC592hdQW9AUDUNbVJncKNQoJ7tR8XDlj9TeiZ/OFnLqvYBmYDc5LvJDilhju+ZeA8n/ yhLw== X-Gm-Message-State: AOAM531g56FoYOaYmEL8muZY8+YnZJw7nkYCU37bqilNQgOB1iu8oIO1 4oK+xKI7C2XpW2L5of8woHtOyR7P9XU= X-Google-Smtp-Source: ABdhPJzxplFEaS0USQ1x53CqyR9NU8Z7vLpfrynY2I7Tg+tlEzk6uUD8ELyaLrcjfBvTR/qCtD+o/w== X-Received: by 2002:a1c:a743:: with SMTP id q64mr5205240wme.74.1628909266069; Fri, 13 Aug 2021 19:47:46 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l2sm3072055wme.28.2021.08.13.19.47.44 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 19:47:45 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> From: Dmitry Gutov Message-ID: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> Date: Sat, 14 Aug 2021 05:47:43 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hi folks, Sorry I'm late to this party. On 13.08.2021 16:36, João Távora wrote: >>>> By separating the filtering and mutation >>>> (highlighting, scoring) my patch addresses the problem at hand in the >>>> proper way. >>>> [ ... ] >>>> Mutation would be a reasonable choice here if the problem could not be >>>> solved in a proper way. But in fact it can be solved in a proper way >>>> without mutating the strings at all as my patch shows. >>> "proper" is just an reasonably empty adjective. There are different ways to >>> go about this, of course. What's "proper" and isn't is hard to debate >>> objectively. >> You are contradicting yourself here. You agree that string mutation is >> better be avoid. If we define "proper" as avoids string mutation if this >> is easily possible, then my patch implements a proper solution to the> problem. > I didn't say it's better avoided, though of course I will avoid_any_ change if > I can. I said I have identified one drawback with doing it. Then I > have addressed > that drawback. So that's what I said. > > I am unaware of_other_ drawbacks. They might exist, but I am unaware of > them. Perhaps you are, and indeed you state they exist, but you refuse to > let me know about them. Or perhaps others know of them and will let me know. > In my long-running discussion with Dmitry they were not presented (again, > except for the one I identified). I thought I explained the problem with this previously. It's basically this: we cannot mutate what we don't own. Across all of completion functions out there, there will be such that return "shared" strings (meaning, not copied or newly allocated) from their completion tables. And modifying them is bad, with consequences which can present themselves in unexpected, often subtle ways. Since up until now completion-pcm--hilit-commonality copied all strings before modifying, completion tables such as described (with "shared" strings) have all been "legal". Suddenly deciding to stop supporting them would be a major API breakage with consequences that are hard to predict. And while I perhaps agree that it's an inconvenience, I don't think it's a choice we can simply make as this stage in c-a-p-f's development. To give an example of a subtle consequence: 1. (setq s (symbol-name 'car)) 2. (put-text-property 1 3 'face 'error s) 3. Switch to a buffer in fundamental mode 4. (insert (symbol-name 'car)) --> see the error face in the buffer Now imagine that some completion table collects symbol names by passing obarray through #'symbol-name rather than #'all-completions, and voila, if the completion machinery adds properties (any properties, not just face) to those strings, you have just modified a bunch of global values. That's not good. And in the example above, the values are those that the lispref/objects.texi says we should not change (though it gives (symbol-name 'cons) as example). "Not mutable", in its parlance. IIRC the related discussions mentioned that modifying such values could lead to a segfault in some previous Emacs versions. Maybe not anymore, but it's still not a good idea. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 02:56:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Daniel Mendler Cc: Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162890972721445 (code B ref 48841); Sat, 14 Aug 2021 02:56:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 02:55:27 +0000 Received: from localhost ([127.0.0.1]:43374 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEjpW-0005Zo-OV for submit@debbugs.gnu.org; Fri, 13 Aug 2021 22:55:26 -0400 Received: from mail-wr1-f45.google.com ([209.85.221.45]:41909) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEjpV-0005ZW-9A; Fri, 13 Aug 2021 22:55:25 -0400 Received: by mail-wr1-f45.google.com with SMTP id x10so9434671wrt.8; Fri, 13 Aug 2021 19:55:25 -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=RrMsSouFaapPEAk74ymKj85jn+NHe8o5ot//bYK6Y7U=; b=COd7ecBI7d9wbKFTROI+mvyr0iWMzOONcICvbmCVXLgz+ledAdeUe7APuGkKWgY+Jd cKsB6Jw6eN/FU+3FG1D22/HfwNJ37eVjpsMDWYBDzOFQ33B+gnUrNiWG7HAPSPBVy+TD LIFLJl9g1H6dWbm0aNq9GbrEMbmydt6KJElf76D0Y0ryFayy2XtAhagdDsb82l7IM0Gv AXgGm9CDZUH2mKmqSHTwx0ylFJGJ6STudzscB+U0ktueqX+C9ZE/CBlb8qtoKEikHWHf 5Gig5+TFtb6dIWj1juymBsPFdhWkzWF3UrFHfF+Squ/YfPDI9z/3SpouUUAv8unDrq2J 2rqg== 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=RrMsSouFaapPEAk74ymKj85jn+NHe8o5ot//bYK6Y7U=; b=H8t6MI28Sl2fTK2O/up2bWmS2nA5jTdWxCXMHw/hgaQ8CJ6IjlrgyieaUq18wfzWaP ormbF0YU/riADgVwyVjUdLGqLVopAtKUIudbrwehAa/era4Ni968D0EdyYJEViHr+kMY xI7UEMU4t37EeV7+U2HFf03vpDFyKHoeB5H0zRIbikpvCjBIp4+iS3/kO9q7ySMDW6Er N36ABqbcjdD7heNtjBHKRsLSyO5mkUkr8hxCJe/cVkG1brBWeD21cdduhgd2+KDOIQtg M/RJTlyur1ts58M5pHNttNRB8Q5M0j0hLy6kTHRfYeJw1VQQYb/EyckDzT9cCXFkvrJh 4CqQ== X-Gm-Message-State: AOAM533+KR1BiRY9V2JtmxhPQVfKusq2NE2SrPcn9jFrhGB1VypJuezz xcLAqjo8jnh1E/Qz3ZjR+4Hk+9kaqD0= X-Google-Smtp-Source: ABdhPJxpWonVHMT/qpjjgzVsfYxYiCwu8gMPFaSBLngN8O5F+J1FfE4DFsuty8mw7DKIAbbIYwXJGw== X-Received: by 2002:adf:9c8c:: with SMTP id d12mr6159409wre.71.1628909719415; Fri, 13 Aug 2021 19:55:19 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i21sm3353014wrb.62.2021.08.13.19.55.18 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 19:55:19 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> From: Dmitry Gutov Message-ID: <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> Date: Sat, 14 Aug 2021 05:55:17 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Aside from the mutability/ownership issue, On 13.08.2021 15:05, João Távora wrote: > If one removes these lines, the process becomes much faster, but there is a > problem with highlighting. My idea is indeed to defer highlighting by not > setting the 'face property directly on that shared string, but some > other property > that is read later from the shared string by compliant frontents. I haven't done any direct benchmarking, but I'm pretty sure that this approach cannot, by definition, be as fast as the non-mutating one. Because you go through the whole list and mutate all of its elements, you have to perform a certain bit of work W x N times, where N is the size of the whole list. Whereas the deferred-mutation approach will only have to do its bit (which is likely more work, like, WWW) only 20 times, or 100 times, or however many completions are displayed. And this is usually negligible. However big the difference is going to be, I can't say in advance, of course, or whether it's going to be shadowed by some other performance costs. But the non-mutating approach should have the best optimization potential when the list is long. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 03:12:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler , "emacs-devel@gnu.org" Cc: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162891069622983 (code B ref 48841); Sat, 14 Aug 2021 03:12:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 03:11:36 +0000 Received: from localhost ([127.0.0.1]:43390 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEk5A-0005yc-34 for submit@debbugs.gnu.org; Fri, 13 Aug 2021 23:11:36 -0400 Received: from mail-wr1-f48.google.com ([209.85.221.48]:40583) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEk58-0005yJ-2K; Fri, 13 Aug 2021 23:11:34 -0400 Received: by mail-wr1-f48.google.com with SMTP id k29so15760049wrd.7; Fri, 13 Aug 2021 20:11:34 -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=8qJF3v8JbwJAZ15jhDdtLSeHlHSTougNt1Um+Emevgs=; b=uhb3Yu2G/KwF7e23ESrN4j/Fh07Y51CsdrtrHwzY2W3mXnf2hTJ+nyFKDVb1cB09t0 utWlFJEmCtPOi1lSSISjfuadcx1seTUW8FNXGAaXP5GYHuCrgxhEkyoeckULXB6hYw1d hcMvXWlpglvE1U6x6dBxhqqoIqspz8DoK5OFzxfkWH+VOFzUb6sncRrvYWMd8FcL3riD LYupotBinwmXxXkps3k3UKa+IArjNeeQ2/uLlBOSckA5X0FT+wanYvp8tuwcWDbT4VW9 Php/VN8Fu0s0SkbB3WNC4779V6VFZgYoovzxA2+33u//UtCPTPUdPX4iszORMtaq10TC tZrQ== 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=8qJF3v8JbwJAZ15jhDdtLSeHlHSTougNt1Um+Emevgs=; b=WQ1H4EbH4EBesGEw0wHtd400mwrs92osOVMjjQS6bKOq1DgBNSZ1KkttUCw5401CLQ W2sTz3+tIB4ClHZw3QIM0lOgleBfPRJZ17yei489eI/448D/YnGgO0Y6HP6Paf7IJ6M6 Lboe/kXXMTljbtRK+JZxXA1PSil9uyzBqkb3JW8v+rIT5zkBLXuNNQBgDZx25U02BJ/u AMWT+SPigIwEnyx+XJ1o4F5utwEQMZNt0PIFtiqn6OLArZv/0cGwPwpDqw3O1hqtCYby 55S8SrGaju4iC2mjMmWQJqEdJE79D7Ty+UfdacCoq9/4WH5H7GJA+8/8e1vlSIgL+GUl OVyg== X-Gm-Message-State: AOAM530YfUQaXZJZVwpeDnHEmo8GDF4SVgH5Gk3XV9KcnbXOKmbabtL2 sVBNDKeYQ//8MXSUpsICGxxQgiUBchc= X-Google-Smtp-Source: ABdhPJxsO782oJW6/wOSeAg58zlmFyQfHKUIV+YHUBe0p3NUhjFYEMpSgTKZfhOE8W+l2fTU/YsL6Q== X-Received: by 2002:a5d:42c2:: with SMTP id t2mr6137986wrr.49.1628910688214; Fri, 13 Aug 2021 20:11:28 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id z126sm3235705wmc.11.2021.08.13.20.11.27 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 13 Aug 2021 20:11:27 -0700 (PDT) References: From: Dmitry Gutov Message-ID: <5dba40c7-681b-392d-486a-ae71090d27f4@yandex.ru> Date: Sat, 14 Aug 2021 06:11:26 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) Hi Daniel, I haven't yet read the patch in detail, but it sounds like a move in the right direction (even if it doesn't include the long-overdue overhaul of the whole API). A few notes on the new stuff: > Finally the `highlight` value is a function taking a list of completion strings and returns a new list of new strings with highlighting applied. First of all, I'd really like it to be a function that applies to individual completion strings, not the whole collection. That would make it much easier to use in company-capf without having to rewrite a lot of code in the presentation layer. Second, perhaps instead of modifying the strings themselves it could return some data (like a list of faces-intervals tuples) that could be used to do so? Again, in company-capf's we end up parsing the face properties in the string, so those modifications are just extra work for CPU which we could eliminate. This is less critical, though. On 11.08.2021 19:11, Daniel Mendler wrote: > There are currently two issues with the patch with regards to backward > compatibility. Fortunately they are fixable with a little effort. > > 1. I would like to deprecate `completion-score' or remove it altogether, > but unfortunately `completion-score' is used in the wild. In order to > preserve `completion-score', bind `completion--filter-completions' in > the highlighting functions. Add `completion-score' in > `completion-pcm--hilit-commonality' when > `completion--filter-completions' is nil. And third: I think completion-score could ultimately use the same treatment as 'highlight'. Meaning, being returned up the stack together with completions, so other bits of code could look up those values. I don't have a clear picture of this yet, but see the recently filed bug#49888. If we want to be able to combine matching scores with recency scores, simply sorting the completions after matching is not going to cut it. Not sure if this is something we can tackle now, but keeping this possible evolution in mind could help us make good choices in the current migration. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 06:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16289224429269 (code B ref 48841); Sat, 14 Aug 2021 06:28:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 06:27:22 +0000 Received: from localhost ([127.0.0.1]:43445 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEn8b-0002PL-OB for submit@debbugs.gnu.org; Sat, 14 Aug 2021 02:27:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:47728) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEn8Y-0002P1-Ah; Sat, 14 Aug 2021 02:27:20 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43570) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEn8Q-0002HA-RY; Sat, 14 Aug 2021 02:27:10 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3865 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEn8Q-0005wA-CI; Sat, 14 Aug 2021 02:27:10 -0400 Date: Sat, 14 Aug 2021 09:27:00 +0300 Message-Id: <83mtpkbky3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Mendler on Thu, 12 Aug 2021 10:47:17 +0200) References: <837dgrdrec.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 48841@debbugs.gnu.org, dgutov@yandex.ru, joaotavora@gmail.com, > monnier@iro.umontreal.ca, 47711@debbugs.gnu.org > From: Daniel Mendler > Date: Thu, 12 Aug 2021 10:47:17 +0200 > > >> The `completions` value is the list of completion strings *without* > >> applied highlighting. The completion strings are returned unmodified, > >> which avoids allocations and results in performance gains for > > > > This is unclear: how can you return a list of strings which you > > produce without allocating the strings? > > The function 'completion-filter-completions' receives a completion table > as argument. The strings produced by this table are returned > unmodified, but of course the completion table has to produce them. For > a static completion table (e.g., in the simplest case a list of strings) > the completion table itself will not allocate strings. In this scenario > 'completion-filter-completions' will not perform any string allocations, > only the list will be allocated. This is what leads to major > performance gains. My point was that at least some of this should be in the description, otherwise it will leave the reader wondering. > >> +(defvar completion--filter-completions nil > >> + "Enable the new completions return value format. > > > > Btw, why is this an internal variable? Shouldn't all completion > > styles ideally support it? If so, it should be a public variable, > > documented in the ELisp manual. And the name should also end with -p, > > since it's a boolean. How about completion-filter-completions-format-p? > > (As I understood the style guide '-p' is not a good idea for boolean > variables, since a value is not a predicate in a strict sense.) > > To address your technical comment - this variable is precisely what one > of the technical difficulties mentioned in my other mail is about. The > question is how we can retain backward compatibility of the completion > style 'all' functions, e.g., 'completion-basic-all-completions', while > still allowing the function to return the newly introduced alist format > with more data, which enables 'completion-filter-completions' to perform > the efficient deferred highlighting. I understand, but given that we provide this for other packages, it shouldn't be an internal variable. > > Also, the "This function has been superseded..." part should be a new > > paragraph, so that it stands out. (And I'm not yet sure we indeed > > want to say "superseded" here, but that's part of the on-going > > discussion. maybe use a more neutral language here, like "See also".) > > The new API 'completion-filter-completions' will substitute the existing > API 'completion-all-completions'. That's your hope, and I understand. But we as a project didn't yet decide to deprecate the original APIs, so talking about superseding is premature. > > Is "filter" really the right word here (in the doc string)? "Filer" > > means you take a sequence and produce another sequence with some > > members removed. That's not what this API does, is it? Suggest to > > use a different name, like completion-completions-alist or > > completion-all-completions-as-alist. > > "Filter" seems like exactly the right word to me. The function takes a > list of strings (or a completion table) and returns a subset of matching > completion strings without further modifications to the strings. See > above what I wrote about allocations. But the name says "filter completions". Which would mean you take a list of completions and filter out some of them. A completion table is much more general object than a list of strings. Thus, I think using "filter" here is sub-optimal. > >> +Only the elements of table that satisfy predicate PRED are considered. > >> +POINT is the position of point within STRING. The METADATA may be > >> +modified by the completion style. The return value is a alist with > >> +the keys: > >> + > >> +- base: Base position of the completion (from the start of STRING) > > > > "Base" here means the beginning? If so, why not call it "beg" or > > somesuch? > > Base position is a fixed term which is already used in minibuffer.el for > completions. See also 'completion-base-position' for example. Well, we don't have to keep bad habits indefinitely. It's okay to lose them and use better terminology. Or at least to explain that terminology in parentheses the first time it is used in some context. > > Are we really losing the completion-score property here? If so, why? > > Yes, the property is removed in the current patch. It is not actually > used for anything in the new implementation. But it is possible to > restore the property such that 'completion-all-completions' always > returns scored candidates as it does now. See my other mail regarding > the caveats of the current patch. I'd prefer not to lose existing features, because that'd potentially make the changes backward-incompatible. Thanks. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 06:46:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: dgutov@yandex.ru, monnier@iro.umontreal.ca, joaotavora@gmail.com, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162892352910999 (code B ref 48841); Sat, 14 Aug 2021 06:46:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 06:45:29 +0000 Received: from localhost ([127.0.0.1]:43455 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEnQ9-0002rL-EE for submit@debbugs.gnu.org; Sat, 14 Aug 2021 02:45:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:48858) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEnQ7-0002r6-Sw; Sat, 14 Aug 2021 02:45:28 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43728) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEnQ1-0000b7-A2; Sat, 14 Aug 2021 02:45:21 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4976 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEnPz-0004qn-W4; Sat, 14 Aug 2021 02:45:20 -0400 Date: Sat, 14 Aug 2021 09:45:09 +0300 Message-Id: <83k0kobk3u.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> (message from Daniel Mendler on Fri, 13 Aug 2021 12:38:28 +0200) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Mendler > Cc: Eli Zaretskii , João Távora > , Stefan Monnier , > Dmitry Gutov > Date: Fri, 13 Aug 2021 12:38:28 +0200 > > I attached the overhauled patch, which addresses most of the comments by > Eli. In comparison to my last patch, the patch is fully backward > compatible and preserves all existing tests. As before, there are tests > which check the new functionality for each existing completion style. Thanks. You were faster than me, so I sent a few more comments to the old patch today. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 07:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: 48841@debbugs.gnu.org, dgutov@yandex.ru, joaotavora@gmail.com, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162892453912624 (code B ref 48841); Sat, 14 Aug 2021 07:03:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 07:02:19 +0000 Received: from localhost ([127.0.0.1]:43463 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEngN-0003HS-5f for submit@debbugs.gnu.org; Sat, 14 Aug 2021 03:02:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50200) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEngH-0003H8-Ok; Sat, 14 Aug 2021 03:02:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43850) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEngB-0006iO-5Y; Sat, 14 Aug 2021 03:02:03 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2015 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEngA-0003L8-2Y; Sat, 14 Aug 2021 03:02:03 -0400 Date: Sat, 14 Aug 2021 10:01:48 +0300 Message-Id: <83im08bjc3.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> (message from Daniel Mendler on Fri, 13 Aug 2021 14:56:38 +0200) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Daniel Mendler > Date: Fri, 13 Aug 2021 14:56:38 +0200 > Cc: 47711@debbugs.gnu.org, Stefan Monnier , > 48841@debbugs.gnu.org, Dmitry Gutov > > On 8/13/21 2:37 PM, João Távora wrote: > > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler wrote: > > > >> It is important to keep this property since this will preclude many bugs > >> due to string mutation. > > > > I am aware of this, of course. Can you give examples of these "many bugs"? > > Perhaps other than the one I already described and addressed? > > No, João, this is not how it goes. I don't have to prove to you that > your idea introduces bugs. You have to show that mutation of the > completion table strings (which are not supposed to be mutated) will not > lead to bugs, which are hard to find. Please calm down, both of you. No one has to prove anything to anyone here, that's not how Emacs development works. We need to see which idea is better, and if none is significantly better, we will probably have both of them living side by side. And while asking for an example of potential bugs is reasonable, asking for a proof that a change will NOT lead to bugs isn't. So how about a couple of examples where having original strings unchanged is important, which could then be discussed? > >> Note that your idea also does not address the other issues which are > >> addressed by my patch. > > > > That's for sure. My patch idea addresses only that single problem. > > I think this is a good property of patches: to solve one thing, not many. > > No, this is not necessarily true. This is only good if the problem is > solved in a way which is future proof. The idea of mutating the strings > is a hack and not a solution. Just to make sure we are on the same page: adding a text property to a string doesn't mutate a string. Lisp programs that process these strings will not necessarily see any difference, and displaying those strings will also not show any difference if the property is not related to display. So the assumption that seems to be made here, that adding a property is the same as mutating a string, is IMO inaccurate if not incorrect. And once again: please tone down your responses, both of you. TIA. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 07:14:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: mail@daniel-mendler.de, 47711@debbugs.gnu.org, joaotavora@gmail.com, 48841@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162892519313622 (code B ref 48841); Sat, 14 Aug 2021 07:14:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 07:13:13 +0000 Received: from localhost ([127.0.0.1]:43472 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEnqy-0003XZ-Sh for submit@debbugs.gnu.org; Sat, 14 Aug 2021 03:13:13 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51076) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEnqx-0003X9-3n; Sat, 14 Aug 2021 03:13:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:43950) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEnqr-0007Pp-6e; Sat, 14 Aug 2021 03:13:05 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2698 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEnqq-0006TB-UW; Sat, 14 Aug 2021 03:13:05 -0400 Date: Sat, 14 Aug 2021 10:12:54 +0300 Message-Id: <83h7fsbitl.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> (message from Dmitry Gutov on Sat, 14 Aug 2021 05:47:43 +0300) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Dmitry Gutov > Date: Sat, 14 Aug 2021 05:47:43 +0300 > Cc: Stefan Monnier , 48841@debbugs.gnu.org, > 47711@debbugs.gnu.org > > I thought I explained the problem with this previously. > > It's basically this: we cannot mutate what we don't own. Across all of > completion functions out there, there will be such that return "shared" > strings (meaning, not copied or newly allocated) from their completion > tables. And modifying them is bad, with consequences which can present > themselves in unexpected, often subtle ways. > > Since up until now completion-pcm--hilit-commonality copied all strings > before modifying, completion tables such as described (with "shared" > strings) have all been "legal". Suddenly deciding to stop supporting > them would be a major API breakage with consequences that are hard to > predict. And while I perhaps agree that it's an inconvenience, I don't > think it's a choice we can simply make as this stage in c-a-p-f's > development. This sounds like an argument against Daniel's approach as well, no? Because if a completion API returns strings it "doesn't own", there will be restrictions on Lisp programs that use those strings, because those Lisp programs previously could do anything they liked with those strings, and now they cannot. Or am I missing something? > 1. (setq s (symbol-name 'car)) > > 2. (put-text-property 1 3 'face 'error s) > > 3. Switch to a buffer in fundamental mode > > 4. (insert (symbol-name 'car)) --> see the error face in the buffer > > Now imagine that some completion table collects symbol names by passing > obarray through #'symbol-name rather than #'all-completions, and voila, > if the completion machinery adds properties (any properties, not just > face) to those strings, you have just modified a bunch of global values. > That's not good. How is this different from Daniel's proposal of returning the original strings? AFAIU, he just shifts the responsibility from the completion code to the caller of the completion code, but basically leaves the problem still very much real and pretty much into our face. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 07:17:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: mail@daniel-mendler.de, 47711@debbugs.gnu.org, joaotavora@gmail.com, 48841@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162892538714006 (code B ref 48841); Sat, 14 Aug 2021 07:17:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 07:16:27 +0000 Received: from localhost ([127.0.0.1]:43480 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEnu6-0003dl-QD for submit@debbugs.gnu.org; Sat, 14 Aug 2021 03:16:27 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51596) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEnu4-0003dS-7x; Sat, 14 Aug 2021 03:16:25 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44022) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEntz-0001rd-33; Sat, 14 Aug 2021 03:16:19 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2898 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEnty-0006r5-Iw; Sat, 14 Aug 2021 03:16:18 -0400 Date: Sat, 14 Aug 2021 10:16:08 +0300 Message-Id: <83fsvcbio7.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> (message from Dmitry Gutov on Sat, 14 Aug 2021 05:55:17 +0300) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Dmitry Gutov > Date: Sat, 14 Aug 2021 05:55:17 +0300 > Cc: Stefan Monnier , 48841@debbugs.gnu.org, > 47711@debbugs.gnu.org > > On 13.08.2021 15:05, João Távora wrote: > > If one removes these lines, the process becomes much faster, but there is a > > problem with highlighting. My idea is indeed to defer highlighting by not > > setting the 'face property directly on that shared string, but some > > other property > > that is read later from the shared string by compliant frontents. > > I haven't done any direct benchmarking, but I'm pretty sure that this > approach cannot, by definition, be as fast as the non-mutating one. Daniel seems to think otherwise, AFAIU. > Because you go through the whole list and mutate all of its elements, > you have to perform a certain bit of work W x N times, where N is the > size of the whole list. > > Whereas the deferred-mutation approach will only have to do its bit > (which is likely more work, like, WWW) only 20 times, or 100 times, or > however many completions are displayed. And this is usually negligible. > > However big the difference is going to be, I can't say in advance, of > course, or whether it's going to be shadowed by some other performance > costs. But the non-mutating approach should have the best optimization > potential when the list is long. So I guess the suggestion to have a benchmark is still useful, because the estimations of which approach has better performance vary between you three. So maybe producing such benchmarks would be a good step? From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 08:24:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162892942520714 (code B ref 48841); Sat, 14 Aug 2021 08:24:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 08:23:45 +0000 Received: from localhost ([127.0.0.1]:43508 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEoxB-0005Nv-6r for submit@debbugs.gnu.org; Sat, 14 Aug 2021 04:23:44 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:36492) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEox5-0005NY-7j; Sat, 14 Aug 2021 04:23:39 -0400 Received: by mail-wr1-f49.google.com with SMTP id b13so16406279wrs.3; Sat, 14 Aug 2021 01:23:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=PbE/O458f4w1AgSVDgGeifvLtJWnYHfLvklmc66ifKw=; b=r4GFs6/YIoNbxO9A3AhZshKw8xKPXEi/GCsoOt5lD/zXIZpM4PN5Of0jkm5/MD40LB SMUM7p6C0w6y3voUSs52UydRmLrkM0b5KGQPF3FUkDnmIg8dz9Q3EjiK+jzqsGIKdnN2 ibfngZ3SqmKXAwkybP1fnLcmuKL3bNBfTJBPxRohx+mFHYBTiGCEN4T6wLlujbOkcXqW kZN/waUTySLyUJERyOs8+feDDU4zT6TPvi/usj22Y+rMp8J/m/iydEb9TsqoZUFqPrFm 8kKe7eUrrMtP+uRUyYD8kCwFqsWKQbSX3bufB1YoWRxBonZ+pDRdbFQMBFQEz5izjd3R XyVQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=PbE/O458f4w1AgSVDgGeifvLtJWnYHfLvklmc66ifKw=; b=S7Vj7+9BJ0Xy25H7WuASDth3Q6fVU0VMVNO0H+tWZbBELCcTYRuaGfFLbxTZUHCuU+ cGE3kzEKOqFz3NCCcrAwx14U6zW43oszTaqmQc2RJdys6vyv2AGhvy3wuYYYNJzfyyG0 2hXRw/S4+Rrk1OKSS9PHg4WH9ukxZSIPRGajrkd+qzG7Z21IGx7ZxNAkzwfItlYV1XY5 zkecBvBbjqM599sd06u6QoKHGg1pbXvzknk3Vgj+CbhKdCUOKBbG2nr4/EQFmLbJxtzm MYWBtGNuBgamqYXW48LbzKIuk/ulqt262W2ipbHqzM8Cwqy5QDNH+IeYvg/ekYm16Xqz 5/lg== X-Gm-Message-State: AOAM532NYOQFPTnIyonOt0s6zM3IRmISYCtLsvuxCVYvz1izjrnP3Cgt WRfipPNgR6ru+2YMkgQccD9cTAkgFlc= X-Google-Smtp-Source: ABdhPJw13EjCIKhW4B0XX0PCwubNK8eU02A7Jj4+dq420uMlLn626Rrwj8Ocwoi2pBUWwsK9BH6wMg== X-Received: by 2002:adf:d085:: with SMTP id y5mr7301176wrh.209.1628929408907; Sat, 14 Aug 2021 01:23:28 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id x18sm3687486wmc.17.2021.08.14.01.23.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Aug 2021 01:23:27 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> Date: Sat, 14 Aug 2021 09:23:25 +0100 In-Reply-To: <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> (Dmitry Gutov's message of "Sat, 14 Aug 2021 05:55:17 +0300") Message-ID: <87sfzca0zm.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > Aside from the mutability/ownership issue, > > On 13.08.2021 15:05, Jo=C3=A3o T=C3=A1vora wrote: >> If one removes these lines, the process becomes much faster, but there i= s a >> problem with highlighting. My idea is indeed to defer highlighting by n= ot >> setting the 'face property directly on that shared string, but some >> other property >> that is read later from the shared string by compliant frontents. > > I haven't done any direct benchmarking, but I'm pretty sure that this > approach cannot, by definition, be as fast as the non-mutating one. > > Because you go through the whole list and mutate all of its elements, > you have to perform a certain bit of work W x N times, where N is the > size of the whole list. Let's call W the work that you perform N times in this istuation. In the non-mutation, let's call it Z. So W <=3D Z, because Z not only propertizes the string with a calculation of faces but _also copies its character contents_. Also I think it's better to start about copying rather than mutating. As Eli points out, putting a text property in a string (my idea) is not equivalent with "mutating" it. > Whereas the deferred-mutation approach will only have to do its bit > (which is likely more work, like, WWW) only 20 times, or 100 times, or > however many completions are displayed. And this is usually > negligible. I think you're going in the same fallacy you went briefly in the other bug report. The flex and pcm styles (meaning completion-pcm--hilit-commonality) has to go through all the completions when deciding the score to atribute to each completion that we already know matches the pattern. That's because this scoring is essential to sorting. That's a given in both scenarios, copying and non-copying. Then, it's true that only a very small set of those eventually have to be displayed to the user, depending on where wants she wants her scrolling page to be. So that's when you have to apply 'face' to, say 20 strings, and that can indeed be pretty fast. But where does the information come from? - Currently, it comes from the string's 'face' itself, which was copied entirely. - In the non-copying approach, it must come from somewhere else. One idea is that it comes from a new "private" property 'lazy-face', also in the string itselv, but which was _not_ copied. Another idea is just to remember the pattern and re-match it to those 20 strings. I think the second alternative is always faster. > However big the difference is going to be, I can't say in advance, of > course, or whether it's going to be shadowed by some other performance > costs. But the non-mutating approach should have the best optimization > potential when the list is long. Don't think so. I'm doing benchmarks, will post soon. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 09:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Daniel Mendler , dgutov@yandex.ru, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162893452729234 (code B ref 48841); Sat, 14 Aug 2021 09:49:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 09:48:47 +0000 Received: from localhost ([127.0.0.1]:43573 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEqHT-0007bL-MA for submit@debbugs.gnu.org; Sat, 14 Aug 2021 05:48:47 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:53088) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEqHO-0007at-6L; Sat, 14 Aug 2021 05:48:42 -0400 Received: by mail-wm1-f49.google.com with SMTP id f10so5259283wml.2; Sat, 14 Aug 2021 02:48:38 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version; bh=IS4QwsDKH6F4eWyXx6K0rL7ucoThMsH5rpcQmB+fRc8=; b=OJdEtXu9nvilRpB8PfhTS6L2QOIUYP043g1Fv82poBBkAx3FMobRNV1sXK/U6hBEuz CKZNa6is7lzW4Tc8z0noc1ahwfzUYbJu8Qo2MiDd5klm3iID/SnCbJ+BYOgX3ZYUPBGK TnJrQV1xxyrmdgekIX5EmLf2LoCJHWkWIOPldExlzNAGIpGurhdpVN4wZtU2/Ik4QaiC 6vdRwmIGFh6WJWO7XhZjO9M+2FLA/OuyI8Mf3VozvOW1idEThkzIyRiJNb7OpeTdFWAk 8jN8fsvCY/l8DMmY2i50pWkJ9BU5cV726+1CZ4YyRYHAkPTFvOU16GIxTUWcuKgqnQJN WF/g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version; bh=IS4QwsDKH6F4eWyXx6K0rL7ucoThMsH5rpcQmB+fRc8=; b=DK8hkUSafjUj7HKuFo4qv4tNEUmLFRwhLN3rddJVozkV8G/tJ8S5f8AHWKyR7agxEu A4hCPcrjHp9iexu1GSoqWHGZpFqLzav63fEkQTwLIaoNk/qGHP1xW+MQh4GzG9fvBrMh DrHGm/ZG4CQwdmbb5iff6n2UlKGZZTt/L3KAx/QWb2RRrRSquqS6sZmkRaA4Ht8/Jyes Fwk0B7jl0q22cTlxji/VcEsHf3Yadm09Joj8GWVPkotFYkEjWkmmqrO1OxkxEqYKeAhQ 6SRKGr3sgTauMPM/U7Rmo0kliW93TfixyKbcPVi3Dro7StRKP67J6IPCBDX6sF5d22Gz bn4Q== X-Gm-Message-State: AOAM532MiwwLhW9luFJ652V2YTeSeZbH3+gc2Vdf/XmOVqBtXUOODx90 I/S+h2kmUbxiX81Mmrvt4Ms= X-Google-Smtp-Source: ABdhPJzMOTtxnVBtJYFETxD9xrGT4o4DfULs9PSItYoSoGFyQeGQPc+agS/dVtKe8a52F5XjCb+cug== X-Received: by 2002:a1c:9852:: with SMTP id a79mr6632045wme.2.1628934512004; Sat, 14 Aug 2021 02:48:32 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id c15sm3983732wrw.93.2021.08.14.02.48.30 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Aug 2021 02:48:31 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <83im08bjc3.fsf@gnu.org> Date: Sat, 14 Aug 2021 10:48:28 +0100 In-Reply-To: <83im08bjc3.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Aug 2021 10:01:48 +0300") Message-ID: <877dgo8ihf.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="=-=-=" X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) --=-=-= Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Eli Zaretskii writes: >> > On Fri, Aug 13, 2021 at 1:22 PM Daniel Mendler wrote: >> >=20 >> >> It is important to keep this property since this will preclude many b= ugs >> >> due to string mutation. >> > I am aware of this, of course. Can you give examples of these "many b= ugs"? >> > Perhaps other than the one I already described and addressed? >> No, Jo=C3=A3o, this is not how it goes. I don't have to prove to you th= at >> your idea introduces bugs. You have to show that mutation of the >> completion table strings (which are not supposed to be mutated) will not >> lead to bugs, which are hard to find. > Please calm down, both of you. No one has to prove anything to anyone > here, that's not how Emacs development works. We need to see which > idea is better, and if none is significantly better, we will probably > have both of them living side by side. > > And while asking for an example of potential bugs is reasonable, > asking for a proof that a change will NOT lead to bugs isn't. As far as I remember, I have done the first. I found bugs and addressed them. I cannot _prove_ that my change will not leads to bugs indeed: no-one can with any change. I've just stated repeteadly that I'm not aware of any such bugs. I can understand intuition" for bugs to a certain extent (everyone has intuition), but this intuition must always resolve into actual reality to be useful in the end. > So how > about a couple of examples where having original strings unchanged is > important, which could then be discussed? Good idea, so in the absence of any controlled benchmarks I did some of my own, using the most controlled environment I could devise. I start Emacs like so: ~/Source/Emacs/emacs/src/emacs -Q -f fido-mode -f fido-vertical-mode -l = ~/tmp/benchmark.el ~/tmp/benchmark.el I prime the obarry with lots of symblos to make completion purposedly slow: (require 'cl-lib) (cl-loop repeat 300000 do (intern (symbol-name (gensym)))) I attach the file. Then I try a run of 10 invocations of ;; Press C-u C-x C-e C-m quickly to produce a sample.=20=20 (benchmark-run (completing-read "" obarray)) This, I think, is a good representation of the responsiveness of the completion system. It always prints well after I finish typing, so I don't think I'm inducing any artificial slowdows while it waits for my input. When not measuring quantitatively, I also feel the difference in responsiveness between different approaches. Summarized results with an assortment of Emacs builds. - the current master (254dc6ab4ca8e6a549a795f9eaf45378ce51b61f). 20.25 seconds total =20=20=20 - Applying Daniel's patch over 254dc6. 23.41 seconds total =20=20=20 - The theoretical best situation where we don't highlight in completion-pcm--hilit-commonality (like 254dc6, but just removed the copy-sequence) 10.70 seconds total - Experimental patch published in scratch/icomplete-lazy-highlight-attempt-2 (not finished, still needs a way for frontends to opt into the optimization). 10.80 seconds total I invite you all to reproduce these results. In conclusion, I don't think Daniel's patch is going in the right direction, *performance-wise*, for the kind of responsiveness scenarios that I am concerned with, and which were discussed with Dmitry in bug#48841. It seems to slow down the process by about 10%. Note 1: there may be *other* performance scenarios that I am not aware of, where Daniel's patch excels. I've requested these benchmarks, regrettably without any success. Note 2: doesn't mean that there aren't *other* merits to Daniel's patch, but I have not understood these yet. That is due to the stated fact that the patch is very long, and seems to comprise performance improvements, refactorings, and API redesign. It has no documentation in manual and/or examples on how to use the new API. >> >> Note that your idea also does not address the other issues which are >> >> addressed by my patch. >> >=20 >> > That's for sure. My patch idea addresses only that single problem. >> > I think this is a good property of patches: to solve one thing, not ma= ny. >>=20 >> No, this is not necessarily true. This is only good if the problem is >> solved in a way which is future proof. The idea of mutating the strings >> is a hack and not a solution. > > Just to make sure we are on the same page: adding a text property to a > string doesn't mutate a string. Lisp programs that process these > strings will not necessarily see any difference, and displaying those > strings will also not show any difference if the property is not > related to display. So the assumption that seems to be made here, > that adding a property is the same as mutating a string, is IMO > inaccurate if not incorrect. Yes, in Lisp it is very common to attach a "private" property to an object. If no-one else knows about the existence of that property, then attaching it is not harmful. Generally, of course: there are situations where adding a private property brings side-effects to other parts of the code. But IMO that other code is in the wrong, not the one that adds properties. Also, to be clear, attaching a different property (as in, not 'face') to the completion string is only _one_ of the ways of the ways to bypass copying. According to my measurements, performance doesn't seem to be decided by property attachments, but by copying or not copying of the character data of said strings in completion-pcm--hilit-commonality. Jo=C3=A3o --=-=-= Content-Type: application/emacs-lisp Content-Disposition: attachment; filename=benchmark.el Content-Transfer-Encoding: quoted-printable Content-Description: benchmark.el (require 'cl-lib) ;; Introduce 300 000 new symbols to slow things down. Probably more ;; than most non-Spacemancs people will have :-) (cl-loop repeat 300000 do (intern (symbol-name (gensym)))) (when nil ;; Press C-u C-x C-e C-m quickly to produce a sample (benchmark-run (completing-read "bla" obarray)) ;; scratch/icomplete-lazy-highlight-attempt-2 (dbfe6f72e3608db4488bbc9bbc= 22d876746b1012) (cl-reduce #'+ '((1.060225172 4 0.40529085799999987) (1.084274293 4 0.40401850100000036) (1.075857223 4 0.4066735760000002) (1.096181884 4 0.41024331699999994) (1.090617755 4 0.4027740900000003) (1.092172347 4 0.4073497049999997) (1.064530759 4 0.40525715400000006) (1.088796966 4 0.4075235989999997) (1.052578979 4 0.39851351000000035) (1.0952534230000002 4 0.4396319659999999)) :key #'car);; 10.800488801 ;; Current situation origin/master (254dc6ab4ca8e6a549a795f9eaf45378ce51b= 61f) (cl-reduce #'+ '((2.094681183 15 1.299947048) (2.061771249 14 1.248384553000001) (1.9915545579999998 14 1.1808336689999983) (2.1072676080000003 15 1.2833755230000001) (2.100205698 15 1.2943715630000003) (1.940760815 14 1.1518027680000005) (1.919338815 14 1.127410448) (2.0683418259999997 14 1.272936392) (1.9932618739999999 15 1.1983156959999999) (1.969784269 17 1.140629235)) :key #'car) ;; 20.246967895000004 ;; Daniel's patch from Mon, 12 Jul 2021 21:40:32 +0200 (cl-reduce #'+ '((2.371949053 12 1.0679449390000002) (2.411950542 12 1.0926466229999985) (2.3595232590000004 12 1.0562706020000006) (2.386636212 12 1.0797333340000002) (2.37649102 12 1.0579168220000001) (2.315395413 12 0.9729727209999997) (2.310257558 12 0.9982636050000004) (2.283203076 12 0.9730703639999998) (2.302582002 13 0.9867599240000002) (2.292846619 15 0.9585957429999998)) :key #'car) ;; 23.410834754 ;; Theoretical best (don't care about highlighting, so don't copy) (cl-reduce #'+ '((1.090906703 4 0.40746227999999984) (1.052931397 4 0.4143886020000007) (1.114877434 4 0.42559067599999967) (1.0578293460000001 4 0.40872522) (1.086898854 4 0.4109444489999996) (1.0749850980000002 4 0.41140822900000007) (1.076554257 4 0.4121859250000002) (0.998330274 4 0.3969351310000002) (1.064626675 4 0.4286588339999997) (1.079113392 4 0.44295618700000006)) :key #'car) ;; 10.69705343 ) --=-=-=-- From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 10:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162893740910447 (code B ref 48841); Sat, 14 Aug 2021 10:37:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 10:36:49 +0000 Received: from localhost ([127.0.0.1]:43631 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEr1x-0002iM-II for submit@debbugs.gnu.org; Sat, 14 Aug 2021 06:36:49 -0400 Received: from mail-wr1-f54.google.com ([209.85.221.54]:37387) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEr1s-0002i1-Db; Sat, 14 Aug 2021 06:36:44 -0400 Received: by mail-wr1-f54.google.com with SMTP id r6so16717117wrt.4; Sat, 14 Aug 2021 03:36:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Bh27k0LEsx5DFXwN7gWYs7DxXUNYaLIjbu6ommRbxA8=; b=kY3CHHhQPgxYfZeYOt4QG8fG3N2dFqnffJS3kMYkIjvl+wEvD+BS/sHE2NuChbqzAa D4HElyd6MqwzNTwVJaeT6FQ6LKwoqIKm4g0yKJ3oQpeBsg4se6oPjNTzKkumbkDBYGpr pjpnT5CF3bNOU14bbK7Z2PbQs0inEKQOge+OABAkZsSrm69W2Hp4yc5MSP9N6BQzM9Ay LK/z2biTj28/xjdOe/Q7EGHgiTIdxCks/Rm5TSYR+fIYJAtdABmAaXaKpNb0Qh/aDkrt YhWQHObfly+w0+D5TeJFYHrObATriUCqu6NsJcCTmE+SqBx+ywu14VGjwCJE0W4iVReh 6oKA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Bh27k0LEsx5DFXwN7gWYs7DxXUNYaLIjbu6ommRbxA8=; b=GFi1kooyF9K6kD5WOhruUZCsgahBUr/OtCP0+7FSU4jMRgCUT6On70fIkPBpX0QiVd DSQF9O01zrwPhfVtlaTtoNwZIdsEYL8sSU48VjrsGEuylvv0ScV16TI78DjjF6Gl4MPW 7uc0ZaMetXeX0R9jmqJZS/KK1VfAE6oeFERbBdiSB12UiNLyK6uPZORmgaZI0h3okVnV ExRZsX7kjA47zhr9wEv9fN2+wJiXGarW4fHTn6qL74nzAB44Cfi85e89eUF1La2eEqjq Y5VoXqiAZfNBlt1o+FIzmxdM7uAGXnUBVrUqOXYHwfeGAsfJrj4SXO9x9g7JgotTECeH UlHQ== X-Gm-Message-State: AOAM531Hp91nzm9zqA0llTP2Yx2Ujt2//uZ1QKC4J1UNmCeNa/NwU7Lk bhax5eEIMhKH6PrY6j4mit5GwNMgdfM= X-Google-Smtp-Source: ABdhPJzhS09Z/f61UZIaCPeue+OeZ21p0Mzyvuu4983LqVr6GkAUSlSIt2ZLLV39lmhe7drkDbsGBg== X-Received: by 2002:adf:e107:: with SMTP id t7mr7755483wrz.165.1628937394463; Sat, 14 Aug 2021 03:36:34 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id z137sm4350807wmc.14.2021.08.14.03.36.33 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Aug 2021 03:36:33 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> Date: Sat, 14 Aug 2021 11:36:32 +0100 In-Reply-To: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> (Dmitry Gutov's message of "Sat, 14 Aug 2021 05:47:43 +0300") Message-ID: <87y29471ov.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > It's basically this: we cannot mutate what we don't own. Across all of > completion functions out there, there will be such that return > "shared" strings (meaning, not copied or newly allocated) from their > completion tables. And modifying them is bad, with consequences which > can present themselves in unexpected, often subtle ways. I agree with this premise. But would you call putting a uniquely named text property in them a modification or mutation of said strings? I don't. > Since up until now completion-pcm--hilit-commonality copied all > strings before modifying, completion tables such as described (with > "shared" strings) have all been "legal". Again, if I take one of this shared strings, in whichever environment running row now, and I secretly attach a privatte "joaot/blargh" property to it, there is very very low likelyhood that that will hurt anybody. You seem to be worrying about re-setting the 'face' property (a public property by excellence) and that's the very same bug I experienced and have described early. It's not even a hard bug to see. Just remove the copy-sequence in `completion-pcm--hilit-commonality' and see strange stuff happening. But if you set some other property, _that_ bug _doesn't_ occur. Do some other bugs occur? I don't know, I don't think we'll ever know, for _any_ change. Furthermore, there are other ways to forego the copying in `completion-pcm--hilit-commonality and not even touch _ANY_ string property. > Suddenly deciding to stop supporting them would be a major API > breakage with consequences that are hard to predict. And while I > perhaps agree that it's an inconvenience, I don't think it's a choice > we can simply make as this stage in c-a-p-f's development. > > To give an example of a subtle consequence: > > 1. (setq s (symbol-name 'car)) > > 2. (put-text-property 1 3 'face 'error s) > > 3. Switch to a buffer in fundamental mode > > 4. (insert (symbol-name 'car)) --> see the error face in the buffer It's not even subtle :-) Yes this is why have seen from the beginning in bug#48841. I think it was even I who reported it to you. The principle to follow can be summarized as this: "Don't touch values of properties you don't own in objects you don't own." So just don't touch the 'face' property in things you don't own! But feel free to touch the "dmitry/blargh" property even in objects you don't own. So 'c-p--h-l' doesn't "own" face. So it must either create an object that it owns or set something that it does own. 'completion-score' is "owned" by 'c-p--h-l'. Only it can write it (though others can read it). > Now imagine that some completion table collects symbol names by > passing obarray through #'symbol-name rather than #'all-completions, > and voila, if the completion machinery adds properties (any > properties, not just face) to those strings, you have just modified a > bunch of global values. That's not good. Why? Maybe I'm missing something. Why is adding properties -- that no-one but the completion machinery knows about -- to those shared strings "not good"? What bad thing can happen if I do? > And in the example above, the values are those that the > lispref/objects.texi says we should not change (though it gives > (symbol-name 'cons) as example). "Not mutable", in its parlance. IIRC > the related discussions mentioned that modifying such values could > lead to a segfault in some previous Emacs versions. Maybe not anymore, > but it's still not a good idea. You're extrapolating "change" to also include attaching properties to symbols. I think that document just means that you can't do stuff like (aset "cons" 0 ?z) or (aset (symbol-name 'cons) 0 ?z) I don't think it means you can't (put-text-property 0 1 'joaot/muahahah 42 (symbol-name 'cons)) But maybe Eli or someone else more knowledgeable in the deep internals of Emacs can correct me. If indeed I'm wrong, there are other ways to forego the copying in `c-p---hilit-commonality` and still don't incurr in any such "mutation". We must keep our eyes on the prize: copying -- not property-attaching -- is the real bummer here. scratch/icomplete-lazy-highlight-attempt-2, although still incomplete, is one such approach, though it still sets `completion-score` on the "shared" string, used later for sorting. But also that could be prevented (again, only if it turns out to be actually problematic IMO). Jo=C3=A3o PS: Maybe I've not stated it clearly enough: I *don't* object to -- or endorse -- Daniel's patch. My point was solely that it mixes too many things for me to be intellectually able to review its functional merits, and that those things should be separated into multiple problems and patches to make this evaluation easier. Maybe someone with superior intellecutal capacity can review -- on substance -- as it stands. See my other reply containing benchmarks. Daniel's patch doesn't perform well there, but for all I know, it can co-exist with my non-copying approach, and we can all have our cake. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 11:23:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mail@daniel-mendler.de, 47711@debbugs.gnu.org, joaotavora@gmail.com, 48841@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162894013723575 (code B ref 48841); Sat, 14 Aug 2021 11:23:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 11:22:17 +0000 Received: from localhost ([127.0.0.1]:43677 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mErk0-000686-OA for submit@debbugs.gnu.org; Sat, 14 Aug 2021 07:22:17 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:45664) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mErjw-00067h-K4; Sat, 14 Aug 2021 07:22:14 -0400 Received: by mail-wr1-f49.google.com with SMTP id v4so9665078wro.12; Sat, 14 Aug 2021 04:22:12 -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=2lzMRiTN9L+ibgaMoQVjLU1cDSXr8p2TDREAUlYpyHw=; b=KtOGOSadTAivI+sMaG6Z6n5tKwV9ww1gyYmNIGTGVZyB97ya1xbDJRnwcp0kzKRZEY PoNmwXjiN84dxzXXdFsLHZu1dY+dFGi8R+G7VsmF9uu75doIV470wK+vvrNkIGqq5oF7 5lXdH2Zh87DLnGcJWdKBHcoSyjd4NDQ54LKV96L/lCRfqUtrWjC2IEgBG8CnZBX/LVse Ge/J716dgLZRPAGc9w0Pg4X5tYrIVs7if5uWoY04HN0OQ42Hq3L9HIAtXaoT1kwoF8Vq ZfznUT8rQWZZEA50PfQhafBRFekQ+zBB+4N3WW2a5D48rjEUVEaxUnb1zKX8Qtxk+LVd YErw== 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=2lzMRiTN9L+ibgaMoQVjLU1cDSXr8p2TDREAUlYpyHw=; b=dfPwo/eCR6EhPrIzmHuvvv2z/+3RiB3BL5GJU7psxKEWglwZY+MelPg/7InHoF1C2F XQTY8yYAyKsBBxRcSSpb0tEgGiwLMg1AVnu28OXDWCDqiYs2wg4IH+7Q1wlDqo3wR1ZM PoLwudx744Lbh1EScmPHWOc1C5nOVA7lBhOm4qB6qYyNOJnLntHO1TBqA0trcAvCHvG9 vG9ECTnNVytY7e2ukBDICfLhCe4fjeIto10DmM442xQrlqfi1RTqtiBN3R8tlL3lcpsm AWAha/yueYlnE43yJ8NQgrX0I3BvoLnsU1bN3/vhJUATlXq1WXdcmTJ89gojqf/frn4n lL2A== X-Gm-Message-State: AOAM533B540ekMmbfMcfwwVHVzpDJYcrGbRmNq8CI3zwJAy4vletyysy goddsQyHDv4WAT5dFtbWduf10t6/YhI= X-Google-Smtp-Source: ABdhPJzjf7FPFGHs13PIjXxd+flbf6DnhuFohEbMnGizSM9H9gQDNOAyBHclQjs/QeqAc28qCLDrEA== X-Received: by 2002:a05:6000:18a4:: with SMTP id b4mr8133637wri.162.1628940126633; Sat, 14 Aug 2021 04:22:06 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q75sm4370937wme.40.2021.08.14.04.22.05 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sat, 14 Aug 2021 04:22:05 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <83h7fsbitl.fsf@gnu.org> From: Dmitry Gutov Message-ID: <1982cc2e-f955-7f15-0781-65cdbbe96759@yandex.ru> Date: Sat, 14 Aug 2021 14:22:04 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83h7fsbitl.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 14.08.2021 10:12, Eli Zaretskii wrote: >> From: Dmitry Gutov >> Date: Sat, 14 Aug 2021 05:47:43 +0300 >> Cc: Stefan Monnier , 48841@debbugs.gnu.org, >> 47711@debbugs.gnu.org >> >> I thought I explained the problem with this previously. >> >> It's basically this: we cannot mutate what we don't own. Across all of >> completion functions out there, there will be such that return "shared" >> strings (meaning, not copied or newly allocated) from their completion >> tables. And modifying them is bad, with consequences which can present >> themselves in unexpected, often subtle ways. >> >> Since up until now completion-pcm--hilit-commonality copied all strings >> before modifying, completion tables such as described (with "shared" >> strings) have all been "legal". Suddenly deciding to stop supporting >> them would be a major API breakage with consequences that are hard to >> predict. And while I perhaps agree that it's an inconvenience, I don't >> think it's a choice we can simply make as this stage in c-a-p-f's >> development. > > This sounds like an argument against Daniel's approach as well, no? > Because if a completion API returns strings it "doesn't own", there > will be restrictions on Lisp programs that use those strings, because > those Lisp programs previously could do anything they liked with those > strings, and now they cannot. Or am I missing something? Good question. It is not. The completion tables described above have all been doing "legal" things, in our general understanding. But any callers of completion-all-completions were never really allowed to modify the returned strings (those still were strings that code "doesn't own"). Of course, some of those callers (I don't know any, though) might have taken advantage of being able to modify the strings with impunity because of completion-all-completions' implementation detail, but they'll have a chance to clean up their act when switching to completion-filter-completions. >> 1. (setq s (symbol-name 'car)) >> >> 2. (put-text-property 1 3 'face 'error s) >> >> 3. Switch to a buffer in fundamental mode >> >> 4. (insert (symbol-name 'car)) --> see the error face in the buffer >> >> Now imagine that some completion table collects symbol names by passing >> obarray through #'symbol-name rather than #'all-completions, and voila, >> if the completion machinery adds properties (any properties, not just >> face) to those strings, you have just modified a bunch of global values. >> That's not good. > > How is this different from Daniel's proposal of returning the original > strings? AFAIU, he just shifts the responsibility from the completion > code to the caller of the completion code, but basically leaves the > problem still very much real and pretty much into our face. This is a shift of responsibility in the right direction. The callers might as well do the string copying when needed, but the fact of the matter is, they usually only need to "copy" 20-100 strings (or however many is displayed), if they need to modify them at all. That's where we win: copying 100 strings is better than copying 10000. Gotta run now, will reply to other email later. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 11:30:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: mail@daniel-mendler.de, 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162894058424278 (code B ref 48841); Sat, 14 Aug 2021 11:30:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 11:29:44 +0000 Received: from localhost ([127.0.0.1]:43685 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mErrA-0006JL-2N for submit@debbugs.gnu.org; Sat, 14 Aug 2021 07:29:44 -0400 Received: from eggs.gnu.org ([209.51.188.92]:60850) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mErr0-0006Iv-6Q; Sat, 14 Aug 2021 07:29:34 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47960) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mErqu-0006q2-Cr; Sat, 14 Aug 2021 07:29:24 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2620 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mErqt-0007lR-5U; Sat, 14 Aug 2021 07:29:24 -0400 Date: Sat, 14 Aug 2021 14:29:03 +0300 Message-Id: <837dgob6yo.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87y29471ov.fsf@gmail.com> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Sat, 14 Aug 2021 11:36:32 +0100) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Sat, 14 Aug 2021 11:36:32 +0100 > Cc: Daniel Mendler , > Stefan Monnier , 48841@debbugs.gnu.org, > 47711@debbugs.gnu.org > > > And in the example above, the values are those that the > > lispref/objects.texi says we should not change (though it gives > > (symbol-name 'cons) as example). "Not mutable", in its parlance. IIRC > > the related discussions mentioned that modifying such values could > > lead to a segfault in some previous Emacs versions. Maybe not anymore, > > but it's still not a good idea. > > You're extrapolating "change" to also include attaching properties to > symbols. I think that document just means that you can't do stuff like > > (aset "cons" 0 ?z) > > or > > (aset (symbol-name 'cons) 0 ?z) > > I don't think it means you can't > > (put-text-property 0 1 'joaot/muahahah 42 (symbol-name 'cons)) > > But maybe Eli or someone else more knowledgeable in the deep internals > of Emacs can correct me. Text properties are stored separately from the string, so I don't think adding properties can in general be referred to as "change". Whether in some particular situation that could count as a "change" depends on that situation and on the particular property, of course. I'm not sure in the context of completion there's any reason to count as "change" adding properties that don't affect display. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 12:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mail@daniel-mendler.de, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , 48841@debbugs.gnu.org, dgutov@yandex.ru, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16289431664236 (code B ref 48841); Sat, 14 Aug 2021 12:13:02 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 12:12:46 +0000 Received: from localhost ([127.0.0.1]:43759 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEsWs-00016A-A3 for submit@debbugs.gnu.org; Sat, 14 Aug 2021 08:12:46 -0400 Received: from quimby.gnus.org ([95.216.78.240]:60890) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEsWq-00015s-7p; Sat, 14 Aug 2021 08:12:45 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=0UbbhNCk79EjpLVHOt6hx3/gHrhJ7w9EVHreQXcmOmM=; b=BH2dmC+23gOI7SFNcwIj5Z8c5/ wkI9ex0yyU6NSnPqlJd/i4K71qa6frp2RdleRovoYKHAODzMfMra3TYC+G4KDjb3mCLqXK4KKq5N6 RvhQ13CyKxpF1ei1JreFEIIqef0neg38gPSm2QJhfi1oxK9FLpg/sRlvWMjdaLuAR32w=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mEsWe-0000TL-42; Sat, 14 Aug 2021 14:12:36 +0200 From: Lars Ingebrigtsen References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> Date: Sat, 14 Aug 2021 14:12:31 +0200 In-Reply-To: <837dgob6yo.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Aug 2021 14:29:03 +0300") Message-ID: <87wnootec0.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > Text properties are stored separately from the string, so I don't > think adding properties can in general be referred to as "change". > > Whether in some particular situation that could count as a [...] Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > Text properties are stored separately from the string, so I don't > think adding properties can in general be referred to as "change". > > Whether in some particular situation that could count as a "change" > depends on that situation and on the particular property, of course. > I'm not sure in the context of completion there's any reason to count > as "change" adding properties that don't affect display. It is a destructive change, but we may just declare that completion functions are allowed to destructively change the inputs in certain very prescribed ways. I'd rather avoid that, though, if at all possible, because it may lead to subtle bugs all over the place. Stefan just reminded me (in a different bug report) that we've long meant to extend the text property machinery with a "namespace" or "plane" concept. The impetus for this is really the font locking machinery which wants to manage some text properties that other packages also want to manage. The idea is that the display machinery would combine all the planes before displaying, but each package would just manage its own "plane". If we had something like this, then using this mechanism in the completion context would make sense -- we could then say that completion isn't allowed to alter anything except text properties in its private plane. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 12:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen Cc: mail@daniel-mendler.de, joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162894482223682 (code B ref 48841); Sat, 14 Aug 2021 12:41:01 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 12:40:22 +0000 Received: from localhost ([127.0.0.1]:43800 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEsxV-00069l-T1 for submit@debbugs.gnu.org; Sat, 14 Aug 2021 08:40:22 -0400 Received: from eggs.gnu.org ([209.51.188.92]:41018) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEsxM-00069G-3k; Sat, 14 Aug 2021 08:40:12 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:49494) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mEsxE-00057C-Rp; Sat, 14 Aug 2021 08:40:00 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3166 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mEsxE-0002mD-Bm; Sat, 14 Aug 2021 08:40:00 -0400 Date: Sat, 14 Aug 2021 15:39:51 +0300 Message-Id: <8335rcb3oo.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87wnootec0.fsf@gnus.org> (message from Lars Ingebrigtsen on Sat, 14 Aug 2021 14:12:31 +0200) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> MIME-version: 1.0 Content-type: text/plain; charset=iso-8859-1 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: Lars Ingebrigtsen > Cc: João Távora , > mail@daniel-mendler.de, > dgutov@yandex.ru, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, > 47711@debbugs.gnu.org > Date: Sat, 14 Aug 2021 14:12:31 +0200 > > Stefan just reminded me (in a different bug report) that we've long > meant to extend the text property machinery with a "namespace" or > "plane" concept. The impetus for this is really the font locking > machinery which wants to manage some text properties that other packages > also want to manage. > > The idea is that the display machinery would combine all the planes > before displaying, but each package would just manage its own "plane". > If we had something like this, then using this mechanism in the > completion context would make sense -- we could then say that completion > isn't allowed to alter anything except text properties in its private > plane. How can that work if at display time all the "planes" are combined? It would mean that the code which produced the original strings will get them displayed differently after completion. Anyway, I'm not sure why you are talking about display here: the properties which are supposed to store the information about completion aren't supposed to affect display. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Lars Ingebrigtsen Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 14 Aug 2021 13:30:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mail@daniel-mendler.de, joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162894775928030 (code B ref 48841); Sat, 14 Aug 2021 13:30:03 +0000 Received: (at 48841) by debbugs.gnu.org; 14 Aug 2021 13:29:19 +0000 Received: from localhost ([127.0.0.1]:43842 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEtix-0007Hx-0q for submit@debbugs.gnu.org; Sat, 14 Aug 2021 09:29:19 -0400 Received: from quimby.gnus.org ([95.216.78.240]:33192) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mEtiu-0007He-5k; Sat, 14 Aug 2021 09:29:16 -0400 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnus.org; s=20200322; h=Content-Type:MIME-Version:Message-ID:In-Reply-To:Date: References:Subject:Cc:To:From:Sender:Reply-To:Content-Transfer-Encoding: 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=xRxGA7F4YEqXq+8FnWlqiVa/Azmuq2pSfPDNleoGrRI=; b=kMAw8LpeatKL2Th0QxC+E7FaCO ODH/dK4iF4cu9p9iDHlsF/HGLhfoQ7xmvEcPFkvE/O8AsGxteVztzDc5kf2k3iR0dwIW2DE0wqqjz 6HGmoD4+4s42x8R5pqGcD5nG8VevB6IWk+Rgag96VKrs6YS5v4iiskLIDe/YFTPZds/s=; Received: from [84.212.220.105] (helo=elva) by quimby.gnus.org with esmtpsa (TLS1.3:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1mEtii-0001Or-36; Sat, 14 Aug 2021 15:29:08 +0200 From: Lars Ingebrigtsen References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <8335rcb3oo.fsf@gnu.org> Date: Sat, 14 Aug 2021 15:29:03 +0200 In-Reply-To: <8335rcb3oo.fsf@gnu.org> (Eli Zaretskii's message of "Sat, 14 Aug 2021 15:39:51 +0300") Message-ID: <87a6lktasg.fsf@gnus.org> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain X-Spam-Report: Spam detection software, running on the system "quimby.gnus.org", has NOT identified this incoming email as spam. The original message has been attached to this so you can view it or label similar future email. If you have any questions, see @@CONTACT_ADDRESS@@ for details. Content preview: Eli Zaretskii writes: > How can that work if at display time all the "planes" are combined? > It would mean that the code which produced the original strings will > get them displayed differently after completion. Content analysis details: (-2.9 points, 5.0 required) pts rule name description ---- ---------------------- -------------------------------------------------- -1.0 ALL_TRUSTED Passed through trusted hosts only via SMTP -1.9 BAYES_00 BODY: Bayes spam probability is 0 to 1% [score: 0.0000] X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) Eli Zaretskii writes: > How can that work if at display time all the "planes" are combined? > It would mean that the code which produced the original strings will > get them displayed differently after completion. That's in the font-lock context, where font-lock will do faces on its "plane" while other packages can do faces on their own "planes", and they'll be combined on display. It not relevant in the context of this bug report, but I thought I'd just mention the general design. -- (domestic pets only, the antidote for overdose, milk.) bloggy blog: http://lars.ingebrigtsen.no From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Aug 2021 00:04:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Daniel Mendler , dgutov@yandex.ru, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162898580924327 (code B ref 48841); Sun, 15 Aug 2021 00:04:02 +0000 Received: (at 48841) by debbugs.gnu.org; 15 Aug 2021 00:03:29 +0000 Received: from localhost ([127.0.0.1]:45530 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mF3ce-0006KI-TN for submit@debbugs.gnu.org; Sat, 14 Aug 2021 20:03:29 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:35501) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mF3cd-0006K3-D0; Sat, 14 Aug 2021 20:03:27 -0400 Received: by mail-wr1-f41.google.com with SMTP id q10so18386833wro.2; Sat, 14 Aug 2021 17:03:27 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=qklDJ5gPDaNiJGUeObEycQTArsmErnSMftxyioCEZWM=; b=PkFu5fYdl2NYm+8n3UE2+ICJducbUpqKse/nlXI8HXlbJGdqcCRbcquZlGnn6X5QcT e7XtwTnz1Sq1PASmhDX01c7fHkacEXNzA0HFMdRp8ZxoJetF/K392SngIsF+bJeP6r6m 1xR8DQbrgYmBKYfgWiao1ra/iJYqjd4ah4SD8+0S4u7nXOuMiDEjrzzFY5/Tbv0AI6Ez xXkD8Nr/JPcWKTOq9XvBepPEts5F6Qm1j0wTkfpamcUX5IPZBjoPumdwtw9YoEoRtae9 oN2MIGqCxj5PYezGZJQvKeFXxcron1zG+pGHh+CcTcQmOQqmW4ABGxeSfg4YKm3tT6PS EE0A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=qklDJ5gPDaNiJGUeObEycQTArsmErnSMftxyioCEZWM=; b=VXdJWx8IWM31cFiVoetwVhjgcgy5w+4V3qiX0sPb7iHvAgDorxQPewjVrF006QoCMl 11pLQq0thVvSLgSKVPIEeTFKjV8D9SxsR15fOrFBNlNpffhEimRe0BjshZPTEgh5tnqa oEW7elD1CeUGjmlnc3JW8f/CnmqeMqBC956RKI3SDZcsVKrlplbgIjLPgkmF0cjdhBTZ pIPEy7IZc79CvRSpc5E1NjryF+SUirnesXy/Jq9rT2xFAhLuKraJFK/lOkQ0tKIQr+Rj TAGcq2w6qs4EL6HaW189LRZxc5PDxLGBQdRQF92/6rta6BPFbObeFGGvgA9sZ+lZYeXb OqdA== X-Gm-Message-State: AOAM531YwnxOY6+u54svB3iSQvSON3xlihLMnL+lRdrT2vEKLKKWS5hB RcKqe5mqGBrck55u9wXvMt0= X-Google-Smtp-Source: ABdhPJyUCZaxxxOBi9K8i35OHATog1u0JejE8y4B2qRfotNjDgBltcumqscOgQDXq2Tgy/t0KO4vRQ== X-Received: by 2002:a5d:5703:: with SMTP id a3mr10510017wrv.333.1628985801441; Sat, 14 Aug 2021 17:03:21 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id s10sm7598232wrv.54.2021.08.14.17.03.19 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 14 Aug 2021 17:03:20 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <83im08bjc3.fsf@gnu.org> <877dgo8ihf.fsf@gmail.com> Date: Sun, 15 Aug 2021 01:03:18 +0100 In-Reply-To: <877dgo8ihf.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sat, 14 Aug 2021 10:48:28 +0100") Message-ID: <87tujr7ewp.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > in the absence of any controlled benchmarks I did some of > my own, using the most controlled environment I could devise. I start > Emacs like so: > > ~/Source/Emacs/emacs/src/emacs -Q -f fido-mode -f fido-vertical-mode -= l ~/tmp/benchmark.el ~/tmp/benchmark.el I have know tweaked the benchmark slightly to make it easier to evaluate speed qualitatively. Here's what I've been using. (require 'cl-lib) =20=20=20=20 (fido-mode 1) (fido-vertical-mode 1) =20=20=20=20 ;; Introduce 150 000 new functions to really slow things down. ;; Probably more than most non-Spacemancs people will have :-) (defmacro lotsoffunctions () `(progn ,@(cl-loop repeat 150000 collect `(defun ,(intern (symbol-name (gensym "heyhey")))= () 42)))) =20=20=20=20 (lotsoffunctions) =20=20=20=20 (when nil ;; Press C-u C-x C-e C-m quickly to produce a quantitative sample (benchmark-run (completing-read "" obarray)) =20=20=20=20 ;; Or just press C-h f to experience how fast/slow completion is. ) The results are the same as the ones I reported in the previous email. I've also cleaned up my previous patch of the scratch/icomplete-lazy-highlight-attempt-2 branch slightly. It is now fully opt-in for frontends and completion-styles, so the backward compatibility problems which I speculated seem to have been exaggerated. I'm still studying it for flaws, but anyone can have a look. And, of course, there are many different ways to realize the "opt-in" for frontends/styles. I just chose the one that seemed the simplest given the current completion framework. The performance is still very good, it reduces the usual waiting time in long lists of completions to about half of what it currently is. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Make fido-mode about as fast as ido-mode even with many completions Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 15 Aug 2021 18:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , eliz@gnu.org, Stefan Monnier , 48841@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162905238912117 (code B ref 48841); Sun, 15 Aug 2021 18:34:02 +0000 Received: (at 48841) by debbugs.gnu.org; 15 Aug 2021 18:33:09 +0000 Received: from localhost ([127.0.0.1]:47766 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFKwX-00039K-54 for submit@debbugs.gnu.org; Sun, 15 Aug 2021 14:33:09 -0400 Received: from mail-wm1-f52.google.com ([209.85.128.52]:43768) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFKwO-00038g-UZ for 48841@debbugs.gnu.org; Sun, 15 Aug 2021 14:33:07 -0400 Received: by mail-wm1-f52.google.com with SMTP id k5-20020a05600c1c85b02902e699a4d20cso10234977wms.2 for <48841@debbugs.gnu.org>; Sun, 15 Aug 2021 11:33:00 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=YXF2qUVvdzM5o/nGSed59SKJ2JnjtUpemwnqCaYD6XI=; b=HRKCSIpdjOWm2BjHlj2WKN1k58iy6jzHg+nQYSi10QP920YBc/fwEHhuSklU8zM8nj BjJwdqVOjFV+x5fIy3M9btjCdzNHCh6oKn/mmTV8j079l5huHf0fTdIXJfp9A6q00KWh 3m3E5KwAj0uLPKUW8Hq+h7Q+nSQ0tLXK1b+D1c1MfbhqQw1D7sR8Yy1irJdTgpFqx+5f jJGKnJN8zEsd+Ju5e/elawySgh5FOgu/+YDmwMCTtcfZ1vLs3NuKAJsvtdEaEJJaMet7 nvUSdiO/hL2ExHeNcbAtBvl0kJ6520bPY6fq7Fht1pIfrpD88Ea8SwuF3Ks7QwZ5hZMg aJEg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=YXF2qUVvdzM5o/nGSed59SKJ2JnjtUpemwnqCaYD6XI=; b=lrUvs+ASWtTRRDXsMggVH11qc/2hEGJo7gamD7L3ooz5iHzqKzoDQi5dQzxYM2N6pl ozUq6lNhZCJQB2pSaic90Mm0mMyBiQH0iKL9zg2e+P9ENQZU1il4nJx99FtPgXMQ4Klp YZyHdU+YR1Bk8A3ss2Xd8Fu8MVWVVFoOSTyOCP6YhFR/ao/NLrPYYQrM+EfQ7VwOHXy0 TDi+gvHa6P81cNfKzBqcy08qvniTTZh/6+82n4q9SC7WG7D3ltlIXxHG3VJsYQRv5lsD ykz4Ar6cGYt+5sLzjJM+r/WxErqfjukZJWg+8jcLcNxjOcNK0n70aQxt9o4xJNnGW08K x7+w== X-Gm-Message-State: AOAM530Lq6abUxJNIyxoZM3BzgaVd9r/SkypFzCUYkZTszSrCOgmK8tz T5+AnTALtyrVl2kp6wZpk2g= X-Google-Smtp-Source: ABdhPJwgiX4E67CgM53aewsBqIzI2P790G+knOG9mdQFast9rhJ9EhzJ4w6H0J4ZryqucrRwX5HS9Q== X-Received: by 2002:a1c:804a:: with SMTP id b71mr11758170wmd.141.1629052374991; Sun, 15 Aug 2021 11:32:54 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id h11sm9784614wmc.23.2021.08.15.11.32.53 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Aug 2021 11:32:54 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> Date: Sun, 15 Aug 2021 19:32:51 +0100 In-Reply-To: <87y29471ov.fsf@gmail.com> ("=?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?="'s message of "Sat, 14 Aug 2021 11:36:32 +0100") Message-ID: <87sfzaimng.fsf_-_@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) [I've removed bug#47711 from the list, since I haven't read the bug. This is only directly concerned with this report bug#48841 about speed differences between fido-mode and ido-mode.] Jo=C3=A3o T=C3=A1vora writes: > scratch/icomplete-lazy-highlight-attempt-2, although still incomplete, > is one such approach, though it still sets `completion-score` on the > "shared" string, used later for sorting. But also that could be > prevented (again, only if it turns out to be actually problematic > IMO). I have tested the patch more thoroughly now, and have not found any problems. It's now opt-in for both frontends and completion styles. Used four combinations: - For adhering styles (substring, pcm and flex) and adhering frontends (icomplete-mode and fido-mode). - For adherint styles with non-adhering but style-respecting frontends (company and "vanilla" completion). - Non-adhering styles with adhering frontends, also no problems. - Non-adhering styles and non-adhering frontends, also no problems. As for performance, I'm using the usual simple benchmark from Emacs -Q (require 'cl-lib) (fido-mode 1) (fido-vertical-mode 1) (defmacro lotsoffunctions () `(progn ,@(cl-loop repeat 300000 collect `(defun ,(intern (symbol-name (gensym "heyhey")))= () 42)))) (lotsoffunctions) I then press C-u C-x C-e C-m (benchmark-run (completing-read "" obarray)) To get a quantitative benchmark or just C-h f to get a qualitative one. Without the optimization this takes about 5s to evaluate, with the optimization is usually around 2.6s. I also tested ido-mode on this, with (ido-mode) (ido-ubiquitous-mode) (setq ido-enable-flex-matching t) But it seems with ido-ubiquitous-mode, C-h f gives up around 20000 functions. So I tested around that mark and found: * ido-mode to be minutely faster still in displaying the first set though it isn't as well sorted by recency, size and alphanumericity. However, I don't now if I'm seeing correctly ifo-mode=20 * ido-mode to be slower in responding to quick input (C-h f a), for example. There's some flickering. It's also problematic when quitting with C-g (almost hanging sometimes). All in all I'm satisfied with the speed increase imparted to fido-mode and fido-vertical mode. In particular, the sluggishness reported for short inputs (which makes the flex style consider a great deal of matches) seems to be completely gone. I'll let people try this out and review the patch, which is after my sig. If there's one thing I'm not crazy about, it's the opt-in interface for frontends which requires them to somehow explain to the completion machinery what constitutes a completion "session". That, of course, is essential to allow any caches to be invalidated. I don't know if the current completion framework has any better mechanism than the one explained in the docstring of `completion-lazy-hilit'. Maybe Stefan can speak to that, maybe the table "metadata" is a good place, but that object seems complicated to access and manipuate. Other than that detail, the fact that the opt-in is just a variable and a function call seems simple enough, in my opinion. Another note: the actual cache implementation is done with "private", non-display-related string properties on non-copied strings. That's somewhat of a bad practice to some us, but not to others. I haven't seen any evidence of mischief, real or academic, but if it ever comes forward, the implementation can use some off-string caching mechanism (likely just a hash-table). Jo=C3=A3o diff --git a/lisp/icomplete.el b/lisp/icomplete.el index cd1979d04a..d69cb7568d 100644 --- a/lisp/icomplete.el +++ b/lisp/icomplete.el @@ -494,6 +494,7 @@ icomplete-minibuffer-setup (setq-local icomplete--initial-input (icomplete--field-string)) (setq-local completion-show-inline-help nil) (setq icomplete--scrolled-completions nil) + (setq completion-lazy-hilit (cl-gensym)) (use-local-map (make-composed-keymap icomplete-minibuffer-map (current-local-map))) (add-hook 'post-command-hook #'icomplete-post-command-hook nil t) @@ -800,7 +801,9 @@ icomplete--render-vertical (cl-return-from icomplete--render-vertical (concat " \n" - (mapconcat #'identity torender icomplete-separator)))) + (mapconcat #'identity + (mapcar #'completion-lazy-hilit torender) + icomplete-separator)))) for (comp prefix) in triplets maximizing (length prefix) into max-prefix-len maximizing (length comp) into max-comp-len @@ -812,7 +815,7 @@ icomplete--render-vertical (cl-loop for (comp prefix suffix) in triplets concat prefix concat (make-string (- max-prefix-len (length prefix)) ? ) - concat comp + concat (completion-lazy-hilit comp) concat (make-string (- max-comp-len (length comp)) ? ) concat suffix concat icomplete-separator)))) @@ -962,7 +965,8 @@ icomplete-completions (if (< prospects-len prospects-max) (push comp prospects) (setq limit t))) - (setq prospects (nreverse prospects)) + (setq prospects + (nreverse (mapcar #'completion-lazy-hilit prospects)= )) ;; Decorate first of the prospects. (when prospects (let ((first (copy-sequence (pop prospects)))) diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el index f335a9e13b..c21f234053 100644 --- a/lisp/minibuffer.el +++ b/lisp/minibuffer.el @@ -3512,6 +3512,54 @@ flex-score-match-tightness than the latter (which has two \"holes\" and three one-letter-long matches).") =20 +(defvar-local completion-lazy-hilit nil + "If non-nil, request lazy highlighting of completion matches. + +Completion-presenting frontends may opt to bind this variable to +a unique non-nil value in the context of completion-producing +calls (such as `completion-all-sorted-completions'). This hints +the intervening completion styles that they do not need to +propertize completion strings with the `face' property. + +When doing so, it is the frontend -- not the style -- who becomes +responsible for `face'-propertizing the completion matches meant +to be displayed to the user, frequently a small subset of all +completion matches. This can be done by calling the function +`completion-lazy-hilit' which returns a `face'-propertized +string. + +The value stored in this variable by the completion frontend must +be unique to each completion attempt/session. For instance, +frontends which utilize the minibuffer as the locus of completion +may set it to a buffer-local value returned by `gensym'. For +frontends operating within a recursive command loop, let-binding +it to `gensym' is appropriate. + +Note that the optimization enabled by variable is only actually +performed some completions styles. To others, it is a harmless +and useless hint. To author a completion style that takes +advantage of this, look in the source of +`completion-pcm--hilit-commonality' for ideas.") + +(defun completion-lazy-hilit (str) + "Return a copy of completion STR that is `face'-propertized. +See documentation for variable `completion-lazy-hilit' for more +details." + (let* ((str (copy-sequence str)) + (data (get-text-property 0 'completion-lazy-hilit-data str)) + (re (and + completion-lazy-hilit + (eq completion-lazy-hilit (car data)) (cdr data))) + (md (and re (string-match re str) (cddr (match-data t)))) + (me (and md (match-end 0))) + (from 0)) + (while md + (add-face-text-property from (pop md) 'completions-common-part nil s= tr) + (setq from (pop md))) + (unless (or (not me) (=3D from me)) + (add-face-text-property from me 'completions-common-part nil str)) + str)) + (defun completion-pcm--hilit-commonality (pattern completions) "Show where and how well PATTERN matches COMPLETIONS. PATTERN, a list of symbols and strings as seen @@ -3527,8 +3575,10 @@ completion-pcm--hilit-commonality last-md) (mapcar (lambda (str) - ;; Don't modify the string itself. - (setq str (copy-sequence str)) + (unless completion-lazy-hilit + ;; Make a copy of `str' since in this case we're about to + ;; `face'-propertize it. + (setq str (copy-sequence str))) (unless (string-match re str) (error "Internal error: %s does not match %s" re str)) (let* ((pos (if point-idx (match-beginning point-idx) (match-end = 0))) @@ -3576,9 +3626,10 @@ completion-pcm--hilit-commonality (update-score-and-face (lambda (a b) "Update score and face given match range (A B)." - (add-face-text-property a b - 'completions-common-part - nil str) + (unless completion-lazy-hilit + (add-face-text-property a b + 'completions-common-part + nil str)) (setq score-numerator (+ score-numerator (- b a))) (unless (or (=3D a last-b) @@ -3601,7 +3652,10 @@ completion-pcm--hilit-commonality ;; for that extra bit of match (bug#42149). (unless (=3D from match-end) (funcall update-score-and-face from match-end)) - (if (> (length str) pos) + (put-text-property 0 1 'completion-lazy-hilit-data + (cons completion-lazy-hilit re) str) + (if (and (> (length str) pos) + (not completion-lazy-hilit)) (add-face-text-property pos (1+ pos) 'completions-first-difference From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 03:18:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: mail@daniel-mendler.de, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162908386328066 (code B ref 48841); Mon, 16 Aug 2021 03:18:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 03:17:43 +0000 Received: from localhost ([127.0.0.1]:48052 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFT8B-0007IX-0c for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:17:43 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:37399) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFT88-0007IE-6k; Sun, 15 Aug 2021 23:17:41 -0400 Received: by mail-wm1-f49.google.com with SMTP id c8-20020a7bc008000000b002e6e462e95fso1142688wmb.2; Sun, 15 Aug 2021 20:17:40 -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=wrMjrV8qQgdb2hCWp4i6jVb0kXGOCWq9X7R/gxFJh3Y=; b=VQC7CqZ+QlIdgYzmvEB0JUixt++PP0zheGv4CEg4hvEsfzG9p5Y4uQILjNneEIrOx8 ExwG3fJCrZRmAyALE57A3jadmlCTJAvYf9Bg4+Hc8jYHRYRx0ZuKuO8MEmlpZ1sx9O0f hiotEmN03kV+SeOq3AEEs7o4h/r7cLhHjBBQRDmwPxUchUghIFWRTivbsJdNrkQ+rVas WedqUQP8bixNccyZr/s3K9/ED1PurhYinE0NHv1/ZKAIEeNFGip/dqbVem+1DCnIfayH kxv2+ilYSV2k2aaGbs3G8pFHfmggYnG256fqqpjEaOI6n5tDiFq2oAI9ZGvhaJ9L0nAd ppTA== 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=wrMjrV8qQgdb2hCWp4i6jVb0kXGOCWq9X7R/gxFJh3Y=; b=gseS7LRraWC/6zNmf/ty8ve+frcEEkECEnOuzrarIgH0IXUa3hPxBozRbyanPziqJ+ 2lBk60tBlbr2WzCyEFO8/tzqYpwNPhmyO+aSPK9axpPYTbfewp+0qX+7EClGk/2TxxZv Ve7SZyhHt+qstnWO/SfoVgwVAcCOJg46beyI8/4wde5b4OF5rzaP2r0Ddy8CoBxT5iD1 fPDKmqymXCyej4En8g3otnseZvVV2tKsa3s/t7FJXcx+/Sb3/wbpAxExdrPm5wIkhxtG WkvuWp73jpoWeAn4P1XpUj2aJTNN58A0R8NwFAADAPGS3xPHMv3idLWboyfcC55YlOx1 rNkw== X-Gm-Message-State: AOAM531VIB3hR06EuH2+ua0+S8m4Gvrbl63wFDlOUCjtE3LE0dTNjXUA jtIh3MQJxtHMRFXf6tuy3aZuOxe4Peg= X-Google-Smtp-Source: ABdhPJxXaa7rFIciOBkeaJ/YuFNR6EPpQeJNc0JVHlj3aG5kcC4JpzQNtsbWqxWHLS47LPB219CJBQ== X-Received: by 2002:a05:600c:a08:: with SMTP id z8mr13420412wmp.165.1629083854298; Sun, 15 Aug 2021 20:17:34 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b20sm9724439wmj.20.2021.08.15.20.17.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:17:33 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> From: Dmitry Gutov Message-ID: <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> Date: Mon, 16 Aug 2021 06:17:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <837dgob6yo.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 14.08.2021 14:29, Eli Zaretskii wrote: > Text properties are stored separately from the string, so I don't > think adding properties can in general be referred to as "change". Are you thinking of C strings? Lisp strings carry text properties in addition to the array of characters. It doesn't really matter where in the memory the properties and the characters reside. > Whether in some particular situation that could count as a "change" > depends on that situation and on the particular property, of course. I was talking in the general sense: modifying a value. One can talk about whether a certain modification matters in certain situations, but that's not the way to discount a general principle. > I'm not sure in the context of completion there's any reason to count > as "change" adding properties that don't affect display. For the context in question, whether the properties affect display is not particularly important. Properties affecting display just make it easier to notice that something's wrong. Bug involving other properties should be more difficult to investigate. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 03:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Lars Ingebrigtsen , Eli Zaretskii Cc: mail@daniel-mendler.de, 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162908408728524 (code B ref 48841); Mon, 16 Aug 2021 03:22:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 03:21:27 +0000 Received: from localhost ([127.0.0.1]:48065 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTBm-0007Pv-VL for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:21:27 -0400 Received: from mail-wr1-f51.google.com ([209.85.221.51]:38463) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTBj-0007Pc-Us; Sun, 15 Aug 2021 23:21:24 -0400 Received: by mail-wr1-f51.google.com with SMTP id u16so4428362wrn.5; Sun, 15 Aug 2021 20:21:23 -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=/SDdnV/qJpRL1tdLDLIG8DzV4voetJU/pAmP2OsCwmQ=; b=INK893s60seq21i3Dj5Kh+rfJDiOwPaCCk5Nt1TrGFQjLttNjPcyQKwFkedSi0/JMg ZFiWptBDGU+IByd4h1QasfSz6f+mYeFU5EKKnQ0Vxz7cVhQtV7BwN8G0MnhSecJkpmK+ 8lPEBsaRhE+PXj5zlPjj8IHHCsrliEQ97zZeNBZGCopMFfsHf199L0HVcNMu96mb0zKb VV6Cs/FYyM7+XhvSCqY4IQk4u76cYXN1KTPCJqQhD+Y+jXneHJJW2gaLCW8udzkqmtZI nhioPrrSSlcWpO2NqKVgHY/OKuvEFJKVuWa+ClvlGjfCMLTfMdcyXmVVbpv4zXWIOj6I +Pnw== 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=/SDdnV/qJpRL1tdLDLIG8DzV4voetJU/pAmP2OsCwmQ=; b=FvfOUWi83UiAk17HICrLJ0e/yOyEEklfNwN7ztrDR5znOUlKO3x01nD5u71kiwdlbl i5MpjUF3sBkS5b8IWyQTBbtR55G1spk7YBJi6rHpw3aNfddt37SNsKAQK1sd5O6ctee6 Eyb2E3eid0Dzj3bvKmZmoo9rJMIUohkGcxsEpuxzt8s4xmE9ybUJ9idnStg6GdufdpSL IgTgZ9bbCwLEvFGztA81nKsNwbhU5hhmbcPPx6JAz68/CfPRHhiT4XkvpcgIKlmqbqaR 1n+PVo+cDGgggqsagvTjvVPwonRbMjtmKoDQXMbJFnc3A3bO1PdOpU9dD6Z8paVPXjEo 6WVw== X-Gm-Message-State: AOAM530/V20OZR4i60nwdh+3tIhEHQ57/yHb2+gudBKxnAOSpJ6a2xK6 eV8Ug9IJNx0PQpJAWONdxffnRsVDli8= X-Google-Smtp-Source: ABdhPJyYmnt+dnaCSXEoR1/rysVo1gOgb6lV5DwDleVLpb2yhlFNUeLcnSxtUgUrJ9JW8l/NArVtyA== X-Received: by 2002:adf:e9c3:: with SMTP id l3mr16098689wrn.300.1629084078386; Sun, 15 Aug 2021 20:21:18 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id t14sm9177633wmj.2.2021.08.15.20.21.17 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:21:18 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> From: Dmitry Gutov Message-ID: <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> Date: Mon, 16 Aug 2021 06:21:16 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87wnootec0.fsf@gnus.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 14.08.2021 15:12, Lars Ingebrigtsen wrote: > It is a destructive change, but we may just declare that completion > functions are allowed to destructively change the inputs in certain very > prescribed ways. I'd rather avoid that, though, if at all possible, > because it may lead to subtle bugs all over the place. That would be a breaking change, but it's a possibility, of course. If we couldn't find a better way to implement this. > Stefan just reminded me (in a different bug report) that we've long > meant to extend the text property machinery with a "namespace" or > "plane" concept. The impetus for this is really the font locking > machinery which wants to manage some text properties that other packages > also want to manage. "Planes" for text properties are just prefixed properties, I guess? That's different from the situation with font-lock. > The idea is that the display machinery would combine all the planes > before displaying, but each package would just manage its own "plane". > If we had something like this, then using this mechanism in the > completion context would make sense -- we could then say that completion > isn't allowed to alter anything except text properties in its private > plane. Yes, if the code makes sure to only use prefixed properties, that would limit the damage. It could still affect repeated (parallel?) uses of the same values in the same piece of code. And even if the effects are usually not serious, are we really okay with evaluating (symbol-name 'car) someday and seeing lots of properties attached to it? From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 03:28:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Daniel Mendler Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162908442829032 (code B ref 48841); Mon, 16 Aug 2021 03:28:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 03:27:08 +0000 Received: from localhost ([127.0.0.1]:48071 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTHH-0007YB-My for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:27:07 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:38856) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTHG-0007Xe-IW; Sun, 15 Aug 2021 23:27:07 -0400 Received: by mail-wr1-f46.google.com with SMTP id u16so4439971wrn.5; Sun, 15 Aug 2021 20:27:06 -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=64L5cJPDoPRrS5Chh6NOZfcomFk5jztUAvnroYkjfPw=; b=fjigDKyawAO1shNmVuscU1AZyAArtiQcs3PVAS0Mjv7CNg3gjLc3yHODK92qHMvI58 JF3oBPpCnX+GMDfDUAJ1DPsPjJqwI51Iduo+Yb6n9WlxLr/5VuR0sWUK9tuHJKCpCjG1 Q6Ja3KSzknM09G57DfuwxJkapSfRgSrDnAV3VxQqn52bM8JLIfXliv4nvnecRO6myTKP SSKGYJ1gisG+ItQzxULAPnPQNo3KqZByKmpbeo/Y7qZvhSNnFhnDq60ErRdRXX6YLpc6 GD01nHMdFi2KzvRIFrtD5BqJUXBRSAFzLlfwnwLZbjfKkjMkoVV5RfcWOUJhwqhbVezt v6iA== 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=64L5cJPDoPRrS5Chh6NOZfcomFk5jztUAvnroYkjfPw=; b=lfY0aJqX17pgr/KrwQCcFcMWfz3tabLDvv3zzbArJInSdEmf0bKTz2JudhHfKWME7W OGGtlaqnkk9/a5l3c1brL0jnduDuyG1Qshl5KSszNTPciar7XoXqItV7eD9e9xKGyqw+ YJYT8y/42KDgX5iJpmkdyrxbnuKVwKOwps3Y5K6mX2T6kPdAa5vg1dAx6d7SiXZp+dh4 w73aFMSrb3RsmJTQW2wVEccBkomnU733IgkCTNKQjAnM4ZjT+cfrkK4rMlRhlTrhcZbd CzThntPdqSBA5lRLnKKT0JXpYw682Lp7Bq7ZEel+N8/T4uf8hMPa2njfbU9mj3cN8SWv HxBQ== X-Gm-Message-State: AOAM531cbP5wQeWDiV2WLKFlqzSkeVTfh3xzMFnqJIM7nkmq5oVfVCPm 5AJpsOgZaQgtEHMk+UMw/pV+MP+gk3I= X-Google-Smtp-Source: ABdhPJyVliP1KOFR+r10ppj6J661h+p0H9YHW7C15qmTn8R30bpVXr/AWYkT/eZbqJK87JFYDpFk0w== X-Received: by 2002:a5d:42c9:: with SMTP id t9mr15847021wrr.356.1629084420779; Sun, 15 Aug 2021 20:27:00 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n10sm4316110wms.3.2021.08.15.20.26.59 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:27:00 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <83im08bjc3.fsf@gnu.org> From: Dmitry Gutov Message-ID: <42a56dff-197d-d223-a2d8-12db8577b505@yandex.ru> Date: Mon, 16 Aug 2021 06:26:58 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83im08bjc3.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 14.08.2021 10:01, Eli Zaretskii wrote: > Just to make sure we are on the same page: adding a text property to a > string doesn't mutate a string. Lisp programs that process these > strings will not necessarily see any difference, and displaying those > strings will also not show any difference if the property is not > related to display. So the assumption that seems to be made here, > that adding a property is the same as mutating a string, is IMO > inaccurate if not incorrect. This is nonsense. A program won't necessarily see a difference in *any* changed value, as long as some part of it stays the same. I can zero out the tail of a string, and have a program that only looks at its first few characters. It wouldn't mean that a string hasn't changed. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 03:28:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, Lars Ingebrigtsen , Eli Zaretskii , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162908446329093 (code B ref 48841); Mon, 16 Aug 2021 03:28:03 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 03:27:43 +0000 Received: from localhost ([127.0.0.1]:48076 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTHr-0007ZA-60 for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:27:43 -0400 Received: from mail-pj1-f46.google.com ([209.85.216.46]:46777) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTHp-0007Yt-65; Sun, 15 Aug 2021 23:27:41 -0400 Received: by mail-pj1-f46.google.com with SMTP id w13-20020a17090aea0db029017897a5f7bcso25217295pjy.5; Sun, 15 Aug 2021 20:27:41 -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=THe/EBE3o/Xs+vLnOgxL99jiwYDsHvA1ibY5VWm72UY=; b=fzHWbgWng70CfutZoXzUKkyXJxUAsZSl+l+ZNERBDBX384D7ydjcYu60ae7YI+H+j3 aFM+gZCJoUQsgHkyySd5hk2bov0kD8JmOG4L/7ipBw5thIExJNbaa1gpd+2/B65jgSj6 YX2xUf+vcktPbLMlvOYSMqBOyaHmpjHIoWMxO75oiykqvd3c/rScuk0WyIqwEOpx7l0q Bygx1Wz3ymfMf13dPJubTVOH3PsbqPI+XB+4zakkg+gyQK5FvXOOCMGWEvAhhP7+p0HT YtsIKduwKwquuS4lHOLY/3XLBe04R90OOCaqlT+6s+BdoIZpsN9xz2rE9hilebURUcDD VqSg== 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=THe/EBE3o/Xs+vLnOgxL99jiwYDsHvA1ibY5VWm72UY=; b=fsg/YDRktpY+ph5JCTW/Y5FFP1RMoUjBr7LeFcsX/u92vj3vvRUqoeQgsPjBPpgfJ0 xd5lHBvFYi2LKuxjsYITMXOzr2CJHbMCBxS5vL+eBTQlR7zfQgqyelrKFNbc0O7IjP0o QCWsVOiJJxpM8Ylh4L87w4lPStGFF/MbIKl09+49PgCKeXaTOPjLh4utf1YlsnPF3oXK epvQ0ZEj+xLGfK4rBhSZVac4hW04fPZrKs11SCZKRxIY+VYrkDrHOhWcPeGVN3R8t/i6 ASLNASSEntuO4PFpJoFU0WfnkDfu7I0ZxF/DfmOkdC+53dnHYKQ2Y62BkMo5nlGaT4J3 vHyQ== X-Gm-Message-State: AOAM533Sa3sPbdxdq7a9t4IR7WUifyVTApJ6PAekQ5usD7PZgG5mo6JD vXSXCeU9Tadh8JU9h7laqx9YsJoLrb1ac8HZ14w= X-Google-Smtp-Source: ABdhPJwXRDNZqcDvyWUJ5GYKbhiWoBmi1myOucrCSy0TmEivEx6WflHuw7taqOWFHuBAAKTnEVndnpFTM+iiaRliSsA= X-Received: by 2002:a17:90a:a091:: with SMTP id r17mr15138587pjp.56.1629084455343; Sun, 15 Aug 2021 20:27:35 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> In-Reply-To: <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 04:27:24 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 4:21 AM Dmitry Gutov wrote: > And even if the effects are usually not serious, are we really okay with > evaluating (symbol-name 'car) someday and seeing lots of properties > attached to it? I wouldn't mind that at all. For me, it's quite the same as evaluating (symbol-plist 'car) and seeing (is-vehicle t number-of-wheels 4) along with all the other byte-compilation stuff already there. Jo=C3=A3o T=C3=A1vora From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 03:33:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , Lars Ingebrigtsen , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16290847233317 (code B ref 48841); Mon, 16 Aug 2021 03:33:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 03:32:03 +0000 Received: from localhost ([127.0.0.1]:48088 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTM3-0000r8-A7 for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:32:03 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:40778) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTM1-0000m2-Lm; Sun, 15 Aug 2021 23:32:01 -0400 Received: by mail-wm1-f44.google.com with SMTP id f12-20020a05600c4e8c00b002e6bdd6ffe2so8144551wmq.5; Sun, 15 Aug 2021 20:32:01 -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=ikPRGbaH3/T2gGcoVYmunjrKkikyMmJTvMUt584VY4I=; b=iIfQZmfyfMVyTpotHKPgmDG7rIQ2SMt6UBKrylUWrdOvlrS2Hc6rSZ9Hak4TgEOA4r jccMDFFPaj0mQFKQZ52r+NbjrBaDS20QdtX3vftpWxv6LjepuzuVSHw/lmh/ghAaxaSL M8p39tboRwQSoAVtVLGMc4buz2hwFZJu6VfkzPdXnseY+vG08LjlDZvZ7s4AlCbUhKTz V9cfn+WxodEhVPThycfwtdZpc28iBGas/iUf8jE4rTWNdOY/gaLFyOUXeKTH8aI36FhE +BH1jiSfAHIxUf3YFIRDFAy6Oq4ZJVluaEbqbExMqyHP3bpVJD4WOxgk1T6BUyEI3s2y /28w== 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=ikPRGbaH3/T2gGcoVYmunjrKkikyMmJTvMUt584VY4I=; b=BjIq7Y+OO4TeMJl9+/8lOZGK+r7tVpycAniHCtYVYDNo1ymBhgnUIMr3vRgDqAWozQ kgQxWRr82gEkMLo/U6BKz2lEoz6IPbOYSjjY31RTQDldq3X3/CKXnyU6XlmJM/tRjzOl o4KbF5xUg8lffGrSQxxZ0ef3F/1TPaXqdQccwKLNb95taAEEGKfkmD7XDFRBo8XlobZR SRMTvbQTJrnSyctsTjOf3zKx+n1lrsRf093Brdg86vbLnQue7npns7RvJFnryu/CKbci BGgmfh7d/cwqLDvlbQtgo314OwErguZQauipJRiYR8Jw80HY6+bq0QDexqDWMdSWHmyG NMiQ== X-Gm-Message-State: AOAM531TCQ1swcCXqFGVAkRuN0uLTZAWDATKMYE7Ic8HJ7aIv0cvY5tq GtKNZX6XlD0HI+BjaBp27JBfd8Kzz5A= X-Google-Smtp-Source: ABdhPJxugN+DM7cE2KdKXkpqgIStJhRdl+Gc8od4Jjtp1AYYyonSZT49wfzzPkDubtYeDStakZRJcA== X-Received: by 2002:a1c:f002:: with SMTP id a2mr13478861wmb.79.1629084715969; Sun, 15 Aug 2021 20:31:55 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id w1sm8830714wmc.19.2021.08.15.20.31.54 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:31:55 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> From: Dmitry Gutov Message-ID: <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> Date: Mon, 16 Aug 2021 06:31:54 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 06:27, João Távora wrote: > I wouldn't mind that at all. For me, it's quite the same as evaluating > (symbol-plist 'car) and seeing (is-vehicle t number-of-wheels 4) along with > all the other byte-compilation stuff already there. Those serve a real purpose, not just work as an accidental cache for some earlier computation. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 03:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16290857236844 (code B ref 48841); Mon, 16 Aug 2021 03:49:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 03:48:43 +0000 Received: from localhost ([127.0.0.1]:48105 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTcB-0001mF-3M for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:48:43 -0400 Received: from mail-wr1-f52.google.com ([209.85.221.52]:38864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTc8-0001lu-BW; Sun, 15 Aug 2021 23:48:41 -0400 Received: by mail-wr1-f52.google.com with SMTP id u16so4479636wrn.5; Sun, 15 Aug 2021 20:48:40 -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=4BWckHAxffwgEJeyO1tLFsBqmwUJUtAVqNgNJVrxWAE=; b=jsbczeL+xRdtbkDfx2OONBFi8nnmGKmvDJrYBWgftiiAkmrTxXcmzpyzxiPp7SceT6 wKzyI5XCQzD9OulT8irby/BG6oQ6ssjdKHpwYxos9Jmk2U2iyePILe7uJwHS6sSEt8B5 M4nu3n4vTUbP6Spq8eVsQogrMgHMIPKHKFKNbU7+0Txx+qrdWvL7Qfs+VGv/n5MrLiYc ViuvDD15+KDI8dbQP/vlEAHUhzyXNOwhAShVausuAEr5aNe9n9pKCQolkU5w2eF8x+B4 UqlqzstE31+koKHRbQ8OSxTIQ/1E0uveoh6k1GuV5D3gRMURlZJw491L9dgjjuYRBu8L 64IQ== 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=4BWckHAxffwgEJeyO1tLFsBqmwUJUtAVqNgNJVrxWAE=; b=BRWu+dSCBHDXsCg86UsWqpo58D4BHIpDSaBhlIy6nXcxxHcym44MlPOhwoySf9ZYXN upMEF92CA8jGM0cmGoC8xwvJ2K+dH+FH/U3bSEtiC+2fCbcYceg29yUITJAQ1lKEh9hg ejnCKHnn8Hzx4CZ2Z88YEhNP3GA98KKgyi9/XK450pX0MqEDAiULsa3n/RJzOqT5kFA1 9xXgwSuXCd3vemTG/VNpRFk+Sxq/l4aSPlqpy5ldXXwy2VEkGPQKCOkT4UpJcmOxdGUh R8SgMKM3M4zRIQtykkIaX8ooabSSlRki//Kp2iMzr6HtX8OAXqdvjcyUCelJJKCNu7Bk JDkw== X-Gm-Message-State: AOAM531dtKQD07GdL5LFqcyyYitjJvFBHEeZpBuBFbXgPBss6sAwoEe1 cwf5JrEVS8srZF4DRR5h8BAecTWyzJk= X-Google-Smtp-Source: ABdhPJww1P+mqruluBF5QDFEvKw6xiYCIYpTpexCH/wDiRNgTNbouR7y2gWmehFel0dbkwksXZvfVA== X-Received: by 2002:a5d:6386:: with SMTP id p6mr15956716wru.143.1629085714223; Sun, 15 Aug 2021 20:48:34 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id l7sm9468851wmj.9.2021.08.15.20.48.33 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:48:33 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> <87sfzca0zm.fsf@gmail.com> From: Dmitry Gutov Message-ID: <4cac92d2-056d-e7fb-0664-2dbccb5f980c@yandex.ru> Date: Mon, 16 Aug 2021 06:48:32 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87sfzca0zm.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 14.08.2021 11:23, João Távora wrote: > Dmitry Gutov writes: > >> Aside from the mutability/ownership issue, >> >> On 13.08.2021 15:05, João Távora wrote: >>> If one removes these lines, the process becomes much faster, but there is a >>> problem with highlighting. My idea is indeed to defer highlighting by not >>> setting the 'face property directly on that shared string, but some >>> other property >>> that is read later from the shared string by compliant frontents. >> >> I haven't done any direct benchmarking, but I'm pretty sure that this >> approach cannot, by definition, be as fast as the non-mutating one. >> >> Because you go through the whole list and mutate all of its elements, >> you have to perform a certain bit of work W x N times, where N is the >> size of the whole list. > > Let's call W the work that you perform N times in this istuation. In > the non-mutation, let's call it Z. So > > W <= Z, because Z not only propertizes the string with a calculation of > faces but _also copies its character contents_. As I pointed out later in the email you're replying to, copying won't happen N times. > Also I think it's better to start about copying rather than mutating. > As Eli points out, putting a text property in a string (my idea) is not > equivalent with "mutating" it. In common industry terms, that's mutation. Lisp strings are not C strings, they are aggregate objects. >> Whereas the deferred-mutation approach will only have to do its bit >> (which is likely more work, like, WWW) only 20 times, or 100 times, or >> however many completions are displayed. And this is usually >> negligible. > > I think you're going in the same fallacy you went briefly in the other > bug report. The flex and pcm styles (meaning > completion-pcm--hilit-commonality) has to go through all the completions > when deciding the score to atribute to each completion that we already > know matches the pattern. That's because this scoring is essential to > sorting. That's a given in both scenarios, copying and non-copying. First of all, note that scoring is only essential to the 'flex' style. Whereas the improvements we're discussing should benefit all, and can be more pronounced if the scoring don't need to be performed. But ok, let's talk about flex in particular. > Then, it's true that only a very small set of those eventually have to > be displayed to the user, depending on where wants she wants her > scrolling page to be. So that's when you have to apply 'face' to, say > 20 strings, and that can indeed be pretty fast. But where does the > information come from? > > - Currently, it comes from the string's 'face' itself, which was copied > entirely. > > - In the non-copying approach, it must come from somewhere else. One > idea is that it comes from a new "private" property 'lazy-face', also > in the string itselv, but which was _not_ copied. Another idea is > just to remember the pattern and re-match it to those 20 strings. Let's say that the cost to compute the score (on one completion) is S. And the cost to highlight it is H. The cost to copy a string is C (that would be amortized cost, including the subsequent GCs). The current algorithm costs: N x (C + S + H) C is unavoidable because of the existing API guarantees. A non-mutating algorithm can cost: N x S (for sorting) + 100 x (C + S + H) (let's say we didn't even cache the scoring info) ...where 100 is the number of displayed completions (the number is usually lower). As we measured previously, copying is quite expensive. Even in the above, not-caching approach we win ((N - 100) x (C + H)), and, okay, lose 100 x S. For high values of N, it should be a clear win. > I think the second alternative is always faster. > >> However big the difference is going to be, I can't say in advance, of >> course, or whether it's going to be shadowed by some other performance >> costs. But the non-mutating approach should have the best optimization >> potential when the list is long. > > Don't think so. I'm doing benchmarks, will post soon. I'm guessing you just skip the C step in your benchmarks? Which is something that breaks our current contract. Still, Daniel's patch should provide a comparable performance improvement. If you're saying it doesn't give numbers as good, I'll have to give it a more thorough read and testing tomorrow to comment on that. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 03:55:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Lars Ingebrigtsen , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16290860657355 (code B ref 48841); Mon, 16 Aug 2021 03:55:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 03:54:25 +0000 Received: from localhost ([127.0.0.1]:48110 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFThd-0001uU-UX for submit@debbugs.gnu.org; Sun, 15 Aug 2021 23:54:25 -0400 Received: from mail-pj1-f48.google.com ([209.85.216.48]:53780) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFThY-0001uB-Q7; Sun, 15 Aug 2021 23:54:20 -0400 Received: by mail-pj1-f48.google.com with SMTP id j1so24399797pjv.3; Sun, 15 Aug 2021 20:54: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=5U8epICC1itkFK7Ot8G6B3eKqRd2LOVPQEmirX1WEQI=; b=jxdnZS1FpAM8YS/mMD7kzFj0mtHzMu3zXrle8ijqhVn4K8vxhSEBK8XBDTWW5Ulfal 1TfJ53Kp3XMldOSbitiN1Wg8G2YOSOcGxcnRVWaerr3OoosNzJnnf955hL4RUyKe0qnc pocnoLbXK8bt8JipFWmDnGkiseoDYsLDDgzFgawd/myMJ61DeVRPE05EZi0OU8p6iZbp FaAlPsllupTojXEf9QoNZqfHyMs19zhExBmB5bo6KorUm1or2z4LOwsb8vL9+a/GZjvX T+6TWRp6Z3Nmys42lvybHuoLEeYKHCsl2lks6DL8f8IyHUzvyRYJ/1tHc019p1kIEHTx IpPA== 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=5U8epICC1itkFK7Ot8G6B3eKqRd2LOVPQEmirX1WEQI=; b=bF6ZSo/YG7xb1vO4uR3HlVYbBRgLpSHjvkM7xk9QUc0jMxZQMnQnMFj9qE2bBFESSA cAnV7A+sAqZ/JvtFxM2wTF2RjMzDl3qBHPfbvSz2edHNBH6lkhmLd1+2CtxyeNRKOrl0 Lx06gyypEbtaho7INdSwX+vf+iIY0OsagTRA3It5apmrOIECO8yk6bYTV7YlVApp8tb/ N4cx8A6mP/FY6PEyT7nOmXjl8JOPLZljrdQeGXYrscZlyAReewtWyiDGMrhc7OHlcMzD A8UNBKTBhmaV3f0PD6n4Ro6q6frFnfysi/o52/pwbTAeQt71rk2AYkTwmMZqs+aE5biV sGDA== X-Gm-Message-State: AOAM533jrgNLT+djLmOQNZLGETco2HSzVqy8msbSi8ntCgP5HyurBjIC 5Hm2rPp0A5bBhc+WVdDjLsOIPrWHBeUKfGLdGtg= X-Google-Smtp-Source: ABdhPJw/eF2aVy16C6VGDXYzzJxISRy2gtTQ/5B/MqJg9pUwG0KUwr2/9Dw/q+u73fbyzqNfFi+1CZaXBjlEq2mMRkA= X-Received: by 2002:a17:902:d487:b0:12d:89d3:a6b with SMTP id c7-20020a170902d48700b0012d89d30a6bmr11825580plg.52.1629086050783; Sun, 15 Aug 2021 20:54:10 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> In-Reply-To: <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 04:53:59 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 4:31 AM Dmitry Gutov wrote: > > On 16.08.2021 06:27, Jo=C3=A3o T=C3=A1vora wrote: > > I wouldn't mind that at all. For me, it's quite the same as evaluating > > (symbol-plist 'car) and seeing (is-vehicle t number-of-wheels 4) along = with > > all the other byte-compilation stuff already there. > > Those serve a real purpose, not just work as an accidental cache for > some earlier computation. Caches also serve "a real purpose". the gv-expander there would be the "cache of an earlier computation". And I'm not sure what "accidental" means, but if it means "implementation detail for something I don't care about", I agree `completion-score` is "accidental". Should it be called `completion-score-internal-cache-dont-look-here`? Maybe. Bottom line here is that an outside observer has no clue, and shouldn't need or want to have a clue, on what "foreign" properties attached to strings or symbols are meant. This is why Eli says, and I agree, that if the property isn't display related, it's all good. No-one but the setter and reader of that particular property mind. The CL systems I've worked with use package qualifiers to fine-grain this even further, but they use the same principle. That Elisp allows a string property list doesn't really make a difference IMO. And none of this really really matters to the discussion. If we absolutely had to store these associations away from the string plist, (for some aesthetic reason, I guess), we could just use hash-tables. Then we could return the string unchanged (and uncopied) and largely keep performance intact. But why do it, since a string plist is a such a nice place to do these associations and there's -- apart from your aesthetics considerations -- 0 drawbacks identified? Jo=C3=A3o T=C3=A1vora From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 04:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , Lars Ingebrigtsen , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16290864047968 (code B ref 48841); Mon, 16 Aug 2021 04:01:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 04:00:04 +0000 Received: from localhost ([127.0.0.1]:48127 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTn9-00024N-Fv for submit@debbugs.gnu.org; Mon, 16 Aug 2021 00:00:03 -0400 Received: from mail-wr1-f43.google.com ([209.85.221.43]:34705) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFTn6-00022i-P2; Mon, 16 Aug 2021 00:00:01 -0400 Received: by mail-wr1-f43.google.com with SMTP id h13so21678016wrp.1; Sun, 15 Aug 2021 21:00:00 -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=d2GuwYH/OdC8HDu+lSnSMT9xRK5kCYBVEDUP4oi0MZM=; b=uTwWVwq4ZwGlWV/QY+WWaC8zZdUtdrnMW7LZNN7A6oxjyGTz6i/Mi/EJFAMjZ3sCQy Y9HMXUX7mZLng+6YhcypmAt+lbIxItyAaMXmYoKljh6dsRiTlM2vysk0k+L/Y57kFpk1 3VjdJvGo6TMcE8thEvKr0vhx24C7noEeEs8oLH1JhqWeYqIVxNqoy/iB+eSc59RztqzW m0pVPXwYeD79jyHok3Q2RBM/n//yKAMO6R+sHG44XT/Qkx6cM1L83WObolhoM9sOv6Bm bd1CFviTzdi1VfS4ubKpBSRei8k5wkFGmL29QLVeH95u5tjWlI+mQfvoyMjCgoh2Tidi Jo7Q== 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=d2GuwYH/OdC8HDu+lSnSMT9xRK5kCYBVEDUP4oi0MZM=; b=ZDiKvHD2WjjKr4AZcSAZyvIo7a0u9Ch0cEXAwiiVytZ7zKJGg+GBiP8Lh5L0QHwzC7 0PmDlmzMW7aK6w5jPH1eouJ64wdY9+Fosp6EbPbrvRnO1ZrTM9hRBsK/s8+WlM3ZiXK5 tn36pr900UI7kMXzHZXAEdoQuoK67qkxBax55KUnS2giTp9ehM1P6QVC694rp5hblA9b Kjv3t1i4q02IKtp+llpF0I0qabBOpWSPRlaOtMxej7juE3laHMjbwcgxkHN+KzYw2HE4 nLNwVGC1Tnf0C8H1lUPTl6SAiy9OE/PEJ8lzLXw/90ddK24kEOFHj762j/AOjbVbcCrm rsrw== X-Gm-Message-State: AOAM530maPgAi6saT69UVtan49cOEQX7LAWWQvz4sXyemPkSEex/azla LHi5XuSMmnLA38IQtzsD1jDxor0Sny8= X-Google-Smtp-Source: ABdhPJzngxCUGZ9JhdYE4wBXFsHbXyxA7ML1nlcykdFMllRAkl5xfvw4blwUoYUviuVfwu/2ARNv8g== X-Received: by 2002:a5d:64ef:: with SMTP id g15mr9422616wri.135.1629086394957; Sun, 15 Aug 2021 20:59:54 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f17sm10074999wrt.49.2021.08.15.20.59.53 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Sun, 15 Aug 2021 20:59:54 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> From: Dmitry Gutov Message-ID: Date: Mon, 16 Aug 2021 06:59:52 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 06:53, João Távora wrote: > But why do it, since a string plist is a such a nice place to do these > associations and there's -- apart from your aesthetics considerations > -- 0 drawbacks identified? You read all the explanations, and THAT'S your conclusion? From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 04:21:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16290876379989 (code B ref 48841); Mon, 16 Aug 2021 04:21:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 04:20:37 +0000 Received: from localhost ([127.0.0.1]:48148 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFU73-0002ax-F8 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 00:20:37 -0400 Received: from mail-wr1-f47.google.com ([209.85.221.47]:43672) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFU70-0002ae-HF; Mon, 16 Aug 2021 00:20:35 -0400 Received: by mail-wr1-f47.google.com with SMTP id z9so21578529wrh.10; Sun, 15 Aug 2021 21:20:34 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=6ORklZy2oh7+mIpgyzo/CZybnxRFNWUtbViQ+U+jU1o=; b=YL5LwTo17TvVYrpoNbfomTr0onwcObAQEtAFYSujsdtf3kybfR4RNg/AzbmC5d788V zc5R/0Y8+ufO/IID9VNIkX2GvdpcnyOgq5kjZseX1rU+wKLKZLqGJAHroIZC052u/FCj WDQ6B/rmVuklCfE0hq+U83kfr3WOby+DUsKNQ6lvCNh0bs5wfUUwZ4Bz+r1ZZuWjsDtX CUEErG7fzFY0hLaiTmP+zp1cZVqMsoNV7Hkp/ByhGeI1jTAjYDXwvEsEVjd0AOnX8rcA tERmS+PVbO+OSntEBAcOd4w9oN2v7WEe7KASbC3pLMK57/kdKLnNlyZXHWrgYcuDSRA7 4vyQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=6ORklZy2oh7+mIpgyzo/CZybnxRFNWUtbViQ+U+jU1o=; b=KJ3WsdoN2n2fLipF6wF8qJEj4G+jfR82z2Zf5RsyVrnB6vhdqXiRlzOlnCQcmo5oFZ j2v/X4x3Venyn/nfV7QoTO8nmtlTEEHwIOuezJxDxEDvY/a4CIW0ACGTkKIOe09eUI2g D9kIkPLivLeqQKoKfYZc0TFpjLqqvsaRMbD8TIztxdiTcB9oJ9NPc7z6J4WbOhRTxfWl 4ToFnMzPX0vLqViF6w9JrWOvAXpH9zIs0/Z5gRu1vdh5HFAnCk0tdPdvWXCp06QyHkQa ZW244N0vnmp8M9PxPsoz0W8S6IacO3yS82VYOqGTwbB23zmtg2wCuF3AXmV57jyGl5wJ 8QzA== X-Gm-Message-State: AOAM531ygnM6WIZS7Z2O3kRYBi7mtNGRCIjgGB63VxqfsNQdTpXMchOG U7iDVkWMWHMbo7lBlduqbhi6/NkN3cw= X-Google-Smtp-Source: ABdhPJyqbcT14E1S1SsGdjfOZya8JhfeBXkq4rBHSUaGdB+Ob/fDPByYkpxDCFR/yApduR3DU7+9dg== X-Received: by 2002:a5d:6da4:: with SMTP id u4mr16291268wrs.50.1629087628279; Sun, 15 Aug 2021 21:20:28 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id k13sm1619589wms.33.2021.08.15.21.20.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Aug 2021 21:20:27 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> <87sfzca0zm.fsf@gmail.com> <4cac92d2-056d-e7fb-0664-2dbccb5f980c@yandex.ru> Date: Mon, 16 Aug 2021 05:20:25 +0100 In-Reply-To: <4cac92d2-056d-e7fb-0664-2dbccb5f980c@yandex.ru> (Dmitry Gutov's message of "Mon, 16 Aug 2021 06:48:32 +0300") Message-ID: <87eeauhvg6.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > As I pointed out later in the email you're replying to, copying won't > happen N times. _Currently_, as in origin/master, it happens N times. In my patch, when a frontend adheres to the thing, it happens D times where D is the amount of strings you need to display. I guess if you do the work to adapt a frontend to work with the new API proposed in Daniel's patch it will be about the same (though likely in many more lines of Elisp). > First of all, note that scoring is only essential to the 'flex' > style. Whereas the improvements we're discussing should benefit all, > and can be more pronounced if the scoring don't need to be performed. Yep, I agree. But I don't see why the same principles I espouse -- which really amount to: let the style know it doesn't need to face-propertize -- can't be applied to other styles that don't need scoring. Although those don't seem to suffer from any performance problems, at least I haven't seens any complaints/reports/mesurements like you did for bug#48841. > But ok, let's talk about flex in particular. Yes, I think that is important since it is the style known to be least performant by its very lax nature. > I'm guessing you just skip the C step in your benchmarks? Which is > something that breaks our current contract. Right. Skipping the 'C =3D Copying step' is the whole point. It breaks our contract because the completion styles currently promise to "face"-propertize the string. So this is why I propose to let the completion-style know that it doesn't need to. When it is told of that, it is relieved of the necessity of copying the string. It is the frontend that will do that copy just before face-propertizing and displaying the string. As you note, and reality shows, that's much faster. There is no disagreement here. > Still, Daniel's patch should provide a comparable performance Kinf of, from what I've read, it _should_ open the way for that to happen. From what I understand, you must then change the frontend (in a big way?) to stop using completion-all-completions and start using the new thing. That work has not been done, as far as I know. Whereas in my proposal (which is now a patch posted to bug#48841) you change the frontend in a very minor way, and that work _has_ been done. Icomplete was very easy to adapt. I can try adapting company soon. In practice, we can't kill off completion-all-completions and start everyone on completion-filter-completions (if that's what it's called). So if the latter does turn out to be a step in the right direction (I'm mostly waiting on Stefan to chime in), then I also don't see why we couldn't have, as Eli suggested, both strategies for lazy highlighting at some point in the future. > improvement. If you're saying it doesn't give numbers as good, I'll > have to give it a more thorough read and testing tomorrow to comment > on that. It's not me who is saying it, it's my Emacs :-) The real problem is that with Daniel's patch, the frontends using the current API (as in icomplete/fido) measurably become _slower_. Though not by much (around 10%), it is still a shame. Yes, do your testing and please, as always, try to report as quantitatively as possible, so that we can really compare apples to apples. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 04:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Lars Ingebrigtsen , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162908795410553 (code B ref 48841); Mon, 16 Aug 2021 04:26:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 04:25:54 +0000 Received: from localhost ([127.0.0.1]:48155 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFUCA-0002k4-Fv for submit@debbugs.gnu.org; Mon, 16 Aug 2021 00:25:54 -0400 Received: from mail-wm1-f50.google.com ([209.85.128.50]:41724) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFUC9-0002jm-34; Mon, 16 Aug 2021 00:25:53 -0400 Received: by mail-wm1-f50.google.com with SMTP id c129-20020a1c35870000b02902e6b6135279so9318558wma.0; Sun, 15 Aug 2021 21:25:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=xraikt2tOdI1hqt2PIK4lpMWEd383AhNGIeQUFzgCYk=; b=RB9s5ay9cJpj3JfZmyhyoSLYIFXMT5ydIoSYNM3u6zCL6QlpGmZP2oNQCpch40raog TOHiW70m6WVmD1IdrZCxKZvAscX+UzO9wJoo6ghAtyTj45PA1Jl5cvDG4tscWaKO7bJ2 uGZPLmpv17sXGuYZBXWjxtzMqJjA9n/ww+/yYF9L11+dKO8YBO5X6FNDu9dM7rnBFDQE 8I+yDwSiE1yPsJdptldyXf05QGVlN9T1nIC79gqv1bjkPHylki2GlSf2awZCMQogspE8 SjmoZD3rlPMNfNvr2gyqsxtqCb8FiK0Ljy+5mEH25TYDBKppS4hi+YI7kUzX6RdbGpG6 mq5g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=xraikt2tOdI1hqt2PIK4lpMWEd383AhNGIeQUFzgCYk=; b=CvDHKtql6GmxrOse1+WhX89HKeZrb34/WTjTgbhKm1YPXvb1ojuVaJs2I9hIRJYOkV ZnDWQ2U2+hj+q6JkeqayGwPKvuz3dOmh2gxyx/gXqKhItaaQMZW7fNiKEEDHm519mNdK Sh9TKdowX/dqYMTokHDMk2gtNtGJP1yfB2eJg9jMtxQBkHRKr2S9Ob3EFNVutDW+bO+A qKxEI4TzsrvHYq844jcP8gPbixvXtAMvRiqVsMcS6Ypw+dzt0ija4EPQZ3ivR4pp61gi 6NH8269JDqwZaiwXYLgXFNmpqCVa/3F3po5XyOBomdkqTlONKxxmQF7R9ygvOSuiNP9B lB1g== X-Gm-Message-State: AOAM530kcnA4Y8lnn3jgc7WPsnLOC4ljT8TdBk6AxMlp4YY9VEneglkf r1Tv6KRyjY7CKd8bnnOqZFLyr9MU12M= X-Google-Smtp-Source: ABdhPJwbYccrVXXTamaDRZJRM8ivS1HWK5Mr3M7d3sOwlkIhGYiqetskN2G/SF/Q/F6yYHq7PvDBLA== X-Received: by 2002:a7b:cf0c:: with SMTP id l12mr13322338wmg.62.1629087946912; Sun, 15 Aug 2021 21:25:46 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id h11sm9847108wrq.64.2021.08.15.21.25.45 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sun, 15 Aug 2021 21:25:46 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> Date: Mon, 16 Aug 2021 05:25:44 +0100 In-Reply-To: (Dmitry Gutov's message of "Mon, 16 Aug 2021 06:59:52 +0300") Message-ID: <87a6lihv7b.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 16.08.2021 06:53, Jo=C3=A3o T=C3=A1vora wrote: >> But why do it, since a string plist is a such a nice place to do these >> associations and there's -- apart from your aesthetics considerations >> -- 0 drawbacks identified? > > You read all the explanations, and THAT'S your conclusion? Yes, I currently conclude that there are 0 drawbacks identified to creating, _via_ string properties, an association of, say, property 'joaot/answer' with value '42' to _any_ string in my current and future Emacs runtimes. I conclude that because --- apart from your aesthetics considerations ("do we really want to see...") --- I have not seen identification of such drawbacks. Have I missed any? Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 08:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 48841@debbugs.gnu.org, dgutov@yandex.ru, joaotavora@gmail.com, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162910364613072 (code B ref 48841); Mon, 16 Aug 2021 08:48:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 08:47:26 +0000 Received: from localhost ([127.0.0.1]:48430 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYHC-0003Oh-8x for submit@debbugs.gnu.org; Mon, 16 Aug 2021 04:47:26 -0400 Received: from server.qxqx.de ([178.63.65.180]:58513 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYH6-0003OM-6C; Mon, 16 Aug 2021 04:47:21 -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=DXzv+Bnip6z/cdxMuTfEFoOWdakNTpWYQig4GgvIjnQ=; b=SSb5x9ZQ8ZsoUGdP+4TKoqrmPu ZYbOzyMx0c2frl89WsNnyvckcXnI8XtekCQ7ngPYb/Gy4u7jhZmLioX5utXVEh9JpCKi5V4Dlvama vU534OzP73bchDa85/UD87Ofk9BEUOkTgly/TVFZR7Q3P8TYwOPHHO3IvPry6oxzNsl8=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <83im08bjc3.fsf@gnu.org> From: Daniel Mendler Message-ID: <1d8ac48c-1627-cfa0-640c-9c1371612787@daniel-mendler.de> Date: Mon, 16 Aug 2021 10:47:06 +0200 MIME-Version: 1.0 In-Reply-To: <83im08bjc3.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/14/21 9:01 AM, Eli Zaretskii wrote: > Just to make sure we are on the same page: adding a text property to a > string doesn't mutate a string. Lisp programs that process these > strings will not necessarily see any difference, and displaying those > strings will also not show any difference if the property is not > related to display. So the assumption that seems to be made here, > that adding a property is the same as mutating a string, is IMO > inaccurate if not incorrect. While I agree that adding text properties is not mutation of the string text itself it still mutates the string data structure. Dmitry made a good point about this - if a completion table uses obarray as backend to the completion table you suddenly attach text properties to symbol names. This is not a good idea. I actually had such an issue once in a package I developed, where I accidentally attached text properties (via the mutating put-text-property API) to some strings I didn't own. This lead to unexpected side effects at other places where I didn't expect the strings to have properties attached. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 08:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Dmitry Gutov Cc: 47711@debbugs.gnu.org, joaotavora@gmail.com, 48841@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162910371913209 (code B ref 48841); Mon, 16 Aug 2021 08:49:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 08:48:39 +0000 Received: from localhost ([127.0.0.1]:48439 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYIN-0003Qr-87 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 04:48:39 -0400 Received: from server.qxqx.de ([178.63.65.180]:33607 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYIE-0003QR-3v; Mon, 16 Aug 2021 04:48:30 -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=JPHtbETPUUl+hbFRN+vAcwY4jQIo9t7zr8cK40eYWmA=; b=lILtorBIeUZejadXdlsAZAftz8 GwSlbBDxMmVJt4+9lA1546PwKiCUr1waQRx+VDMgjqBTQNwCo+X/f+bx1+8upDNzUPuRR5jbBnxTd dicn2cjyHJ1hNMTJJApMyqelX3Z8nI3ocxPk2/+29uxlHkpj/Oqr6YHgExJhoXIYGomM=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <83h7fsbitl.fsf@gnu.org> From: Daniel Mendler Message-ID: <75ce4b68-240f-2f0e-3953-c1f74962c3cd@daniel-mendler.de> Date: Mon, 16 Aug 2021 10:48:19 +0200 MIME-Version: 1.0 In-Reply-To: <83h7fsbitl.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/14/21 9:12 AM, Eli Zaretskii wrote: >> Since up until now completion-pcm--hilit-commonality copied all strings >> before modifying, completion tables such as described (with "shared" >> strings) have all been "legal". Suddenly deciding to stop supporting >> them would be a major API breakage with consequences that are hard to >> predict. And while I perhaps agree that it's an inconvenience, I don't >> think it's a choice we can simply make as this stage in c-a-p-f's >> development. > > This sounds like an argument against Daniel's approach as well, no? > Because if a completion API returns strings it "doesn't own", there > will be restrictions on Lisp programs that use those strings, because > those Lisp programs previously could do anything they liked with those > strings, and now they cannot. Or am I missing something? No, in my patch the displayed candidate strings are still copied before the text properties are attached. The strings are kept intact as they are now. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 08:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Dmitry Gutov Cc: Eli Zaretskii , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162910402013735 (code B ref 48841); Mon, 16 Aug 2021 08:54:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 08:53:40 +0000 Received: from localhost ([127.0.0.1]:48466 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYNI-0003ZO-Hf for submit@debbugs.gnu.org; Mon, 16 Aug 2021 04:53:40 -0400 Received: from server.qxqx.de ([178.63.65.180]:34305 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYNH-0003Z0-16; Mon, 16 Aug 2021 04:53:39 -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=fpp4hAYM18zw+5pcKevICIykRc1pCDf5Y3PkSL0tb7Y=; b=OUfE89ov3IcQQzb6hGevkjrz8P irOW11NZG7k5ND6knED5g+woz2oU8VIk/25SMlkYTUj+A4ClRHUTENivqvtCtQYR7OMjQ6z54W1uz xZ3v5s46ROs3ffVlLWiC1fxMPMWTfBoIaAegq2FvWkOf9Bm07J/8O8F4YR+5R83t1EXE=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <328f87eb-6474-1442-e1ca-9ae8deb2a84a@yandex.ru> <87sfzca0zm.fsf@gmail.com> <4cac92d2-056d-e7fb-0664-2dbccb5f980c@yandex.ru> <87eeauhvg6.fsf@gmail.com> From: Daniel Mendler Message-ID: <62d4ebdd-8d9c-13d3-77d2-df36352d4803@daniel-mendler.de> Date: Mon, 16 Aug 2021 10:53:31 +0200 MIME-Version: 1.0 In-Reply-To: <87eeauhvg6.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/16/21 6:20 AM, João Távora wrote: > It's not me who is saying it, it's my Emacs :-) The real problem is that > with Daniel's patch, the frontends using the current API (as in > icomplete/fido) measurably become _slower_. Though not by much (around > 10%), it is still a shame. I have to check this. I claim that 'completion-all-completions' should not get slower with my patch. If it gets indeed slower as your benchmark shows, this should be fixed and can be fixed since I am not doing something else than decomposing the highlighting and filtering processes, which are already present in the current machinery. The amount of work stays the same. However in the case the new 'completion-filter-completions' API is used, the filtering will get much faster since no highlighting and copying takes place. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 09:09:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Dmitry Gutov Cc: Lars Ingebrigtsen , Eli Zaretskii , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162910493515337 (code B ref 48841); Mon, 16 Aug 2021 09:09:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 09:08:55 +0000 Received: from localhost ([127.0.0.1]:48490 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYc3-0003zC-4M for submit@debbugs.gnu.org; Mon, 16 Aug 2021 05:08:55 -0400 Received: from server.qxqx.de ([178.63.65.180]:33691 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFYbn-0003ye-BM; Mon, 16 Aug 2021 05:08:40 -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=GJcT/T5DVTuHMs67rjtK1AoQVRPLwkXyW16s1GuaJfQ=; b=mcXl/177spo4DFSgMO5rICqYIR 75/3YzAOxMWILnRCf6B7BUnCXi26il3qrnACsZKMwWM3/SAgDOzvgyBXxl68lpbg2q0raDMtzo6mp gQxuCbALUXXoCHXyqhjjJZKsttKSS9itzkbIzlbycWfYXP53dAxFWI7m7QnRnQHu90EU=; References: <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> From: Daniel Mendler Message-ID: <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> Date: Mon, 16 Aug 2021 11:08:31 +0200 MIME-Version: 1.0 In-Reply-To: <87a6lihv7b.fsf@gmail.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/16/21 6:25 AM, João Távora wrote: > Yes, I currently conclude that there are 0 drawbacks identified to > creating, _via_ string properties, an association of, say, property > 'joaot/answer' with value '42' to _any_ string in my current and future > Emacs runtimes. > > I conclude that because --- apart from your aesthetics considerations > ("do we really want to see...") --- I have not seen identification of > such drawbacks. Have I missed any? There are serious drawbacks of attaching "private" string properties to arbitrary strings. For once it complicates debugging seriously if there are suddenly string properties attached to symbol names. It also leads to a potential memory leak. But even if we could chose this approach with global side-effects I don't see a reason to do it given the approach I am proposing in my patch, which avoids these problems entirely. 1. My approach decomposes the already existing completion machinery into two steps: 1. filtering and 2. highlighting. It does not change the fundamentals of the completion machinery. This decomposition of the existing infrastructure is also what leads to the small number of added lines to minibuffer.el, even if the patch itself is not as small as we would like to have it. 2. Why take the chances of introducing potentially harmful global side effects by attaching string properties to arbitrary strings if we can avoid it easily? 3. The `completion-filter-completions` API is the fastest possible API for filtering since it does not change the strings at all, it does not attach string properties or modify the strings in any other way. By construction, it is a pure function which only filters the list of candidates. This makes the function easy to use and easy to reason about. An API which adds private properties to the strings cannot be as fast and non-intrusive. 4. If 'completion-all-completions' does indeed get slower thanks to my patch, it is a performance regression of my patch. I will fix this. And I thank you João for bringing this to my attention. However one should also consider that in the end, 'fido-mode' and 'icomplete-mode' should move to the new API 'completion-filter-completions' such that they benefit from the fast filtering and only copy and highlight the actually displayed strings. Given this a potential regression of 'completion-all-completions' would matter less for the incrementally updating UIs. But of course I feel the same way as João - a performance regression in the API 'completion-all-completions' is unacceptable. It will be fixed. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 09:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 48841@debbugs.gnu.org, 47711@debbugs.gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162910696818890 (code B ref 48841); Mon, 16 Aug 2021 09:43:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 09:42:48 +0000 Received: from localhost ([127.0.0.1]:48559 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFZ8c-0004uK-KL for submit@debbugs.gnu.org; Mon, 16 Aug 2021 05:42:47 -0400 Received: from server.qxqx.de ([178.63.65.180]:43069 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFZ8Y-0004ts-8W; Mon, 16 Aug 2021 05:42:31 -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=C6FYAFTRxF50v0M2jWCYcMTMDZouKfxCvDwJMzz16sk=; b=FKUNVDxD41IMLfHD0mdoT3ASsD n3JSH3Cw1ZWQxsEb4xxFSb6GITypglkL0jp1mlqd/9S4aom7WFdGcGAWDwvHSV8H39mwsQ19mtL0i lUt0Wz1Rm2H835cMHlsoIZuWmt8e9ySFM5KF6+UFScatCxCtVJ3u0ijJPUX5qTV2hHcM=; References: <837dgrdrec.fsf@gnu.org> <83mtpkbky3.fsf@gnu.org> From: Daniel Mendler Message-ID: Date: Mon, 16 Aug 2021 11:42:22 +0200 MIME-Version: 1.0 In-Reply-To: <83mtpkbky3.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: 0.3 (/) Hello Eli, here I respond to the comments you sent out after I've already sent the overhauled patch. On 8/14/21 8:27 AM, Eli Zaretskii wrote: >> The function 'completion-filter-completions' receives a completion table >> as argument. The strings produced by this table are returned >> unmodified, but of course the completion table has to produce them. For >> a static completion table (e.g., in the simplest case a list of strings) >> the completion table itself will not allocate strings. In this scenario >> 'completion-filter-completions' will not perform any string allocations, >> only the list will be allocated. This is what leads to major >> performance gains. > > My point was that at least some of this should be in the description, > otherwise it will leave the reader wondering. I agree with this. The documentation should be improved. >>>> +(defvar completion--filter-completions nil >>>> + "Enable the new completions return value format. >>> >>> Btw, why is this an internal variable? Shouldn't all completion >>> styles ideally support it? If so, it should be a public variable, >>> documented in the ELisp manual. And the name should also end with -p, >>> since it's a boolean. How about completion-filter-completions-format-p? >> >> (As I understood the style guide '-p' is not a good idea for boolean >> variables, since a value is not a predicate in a strict sense.) >> >> To address your technical comment - this variable is precisely what one >> of the technical difficulties mentioned in my other mail is about. The >> question is how we can retain backward compatibility of the completion >> style 'all' functions, e.g., 'completion-basic-all-completions', while >> still allowing the function to return the newly introduced alist format >> with more data, which enables 'completion-filter-completions' to perform >> the efficient deferred highlighting. > > I understand, but given that we provide this for other packages, it > shouldn't be an internal variable. No, we explicitly don't provide this variable for other packages. It is explicitly only meant to be used for the existing completion styles emacs21, emacs22, basic, substring, partial-completion, initials and flex to opt-in in a backward-compatible/calling convention preserving way to the alist return format. The idea is to keep the existing APIs fully backward compatible. Other packages should select the format returned from the completion styles differently. They should return the alist format on Emacs 28 or if the API 'completion-filter-completions' API is present. In the not so near future external packages which support only Emacs 28 and upwards will then only return the alist format and don't have to perform any detection anymore. >>> Also, the "This function has been superseded..." part should be a new >>> paragraph, so that it stands out. (And I'm not yet sure we indeed >>> want to say "superseded" here, but that's part of the on-going >>> discussion. maybe use a more neutral language here, like "See also".) >> >> The new API 'completion-filter-completions' will substitute the existing >> API 'completion-all-completions'. > > That's your hope, and I understand. But we as a project didn't yet > decide to deprecate the original APIs, so talking about superseding is > premature. It is not the hope - it is the explicit goal. The API has been designed to replace the existing API 'completion-all-completions'. We can of course tone this down. However I, as a package author, would appreciate if Emacs tells me when a newer API aims to replace another API and when the documentation is explicit about it. Of course if you decide to have the doc strings written in a different tone, I will adapt my patch accordingly. Here I am just explaining why I chose the word "superseded" instead of a more neutral word. >>> Is "filter" really the right word here (in the doc string)? "Filer" >>> means you take a sequence and produce another sequence with some >>> members removed. That's not what this API does, is it? Suggest to >>> use a different name, like completion-completions-alist or >>> completion-all-completions-as-alist. >> >> "Filter" seems like exactly the right word to me. The function takes a >> list of strings (or a completion table) and returns a subset of matching >> completion strings without further modifications to the strings. See >> above what I wrote about allocations. > > But the name says "filter completions". Which would mean you take a > list of completions and filter out some of them. A completion table > is much more general object than a list of strings. Thus, I think > using "filter" here is sub-optimal. Okay, you are right about this. But I think even if the name 'completion-filter-completions' is not 100% precise it still conveys what the API is about. 'completion-completions-alist' or 'completion-all-completions-as-alist' are valid names of course, but I dislike them for their verbosity. Already 'completion-all-completions' is quite verbose. A strong argument to use this long name is that the completion style functions are still called 'completion-basic-all-completions' etc. But if we accept that the new API 'completion-filter-completions' will actually supersede the existing API 'completion-all-completions' it makes sense to use a name which will not hurt our eyes in the long run. However this is of course just a personal preference of mine. I don't want to spent much time with name bikeshedding discussions. If you decide on a name, I will adapt my patch accordingly. >>>> +Only the elements of table that satisfy predicate PRED are considered. >>>> +POINT is the position of point within STRING. The METADATA may be >>>> +modified by the completion style. The return value is a alist with >>>> +the keys: >>>> + >>>> +- base: Base position of the completion (from the start of STRING) >>> >>> "Base" here means the beginning? If so, why not call it "beg" or >>> somesuch? >> >> Base position is a fixed term which is already used in minibuffer.el for >> completions. See also 'completion-base-position' for example. > > Well, we don't have to keep bad habits indefinitely. It's okay to > lose them and use better terminology. Or at least to explain that > terminology in parentheses the first time it is used in some context. Okay, I agree. However I tried to avoid including superfluous changes with my patch set. We should add more context and documentation and then rename the variables in another patch if we decide that we want to go through with it. >>> Are we really losing the completion-score property here? If so, why? >> >> Yes, the property is removed in the current patch. It is not actually >> used for anything in the new implementation. But it is possible to >> restore the property such that 'completion-all-completions' always >> returns scored candidates as it does now. See my other mail regarding >> the caveats of the current patch. > > I'd prefer not to lose existing features, because that'd potentially > make the changes backward-incompatible. The overhauled patch (version 2) ensures that no features are lost. The patch is fully backward compatible. There is a potential performance regression in 'completion-all-completions' as identified by João. I have yet to confirm this regression. In any case, it should be fixable since the refactored 'completion-all-completions' API does precisely the same amount of work as it does now. Furthermore more documentation should be added to my patch. As of now 'completion-all-completions' is not mentioned in the info manual and 'completion-filter-completions' is also not added there. We may want to improve the documentation of that. But for now I would like to limit my documentation improvements to expanding the doc strings of the functions involved in my patch. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 10:17:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Lars Ingebrigtsen , 47711@debbugs.gnu.org, Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162910896422287 (code B ref 48841); Mon, 16 Aug 2021 10:17:01 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 10:16:04 +0000 Received: from localhost ([127.0.0.1]:48601 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFZey-0005mk-9P for submit@debbugs.gnu.org; Mon, 16 Aug 2021 06:16:04 -0400 Received: from mail-pj1-f49.google.com ([209.85.216.49]:50939) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFZep-0005mL-7s; Mon, 16 Aug 2021 06:15:55 -0400 Received: by mail-pj1-f49.google.com with SMTP id bo18so25799769pjb.0; Mon, 16 Aug 2021 03:15:51 -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=oCu4cbI2ZHBlH+viXbn57tCqpQanGyFP2VKCGfxLh0g=; b=pOBU+OJWKVLpM+bgIOsSX7qDT6wD3fmisZzaVMYPZY7PDkcACW5A4vLnHqDhy/2MMB cKa8u/42PbX9UHUY5IPmRJN7xoGPyMJVXy7+ssfrBYza39Py4cN70Ltty0/DVuAelM17 Eehl2glcdmfPy3QfEap7uc/uXKbDEcUTOjefFFcchyPcFGh/jpG5ubBq8cRFkkXIsDu+ L2fpHWh1F6k/W8lpOiF0UfrvxZNuX42ApNTInrgGbuxY0kPrA3R2I+cNsmsP/ghLg8Dn bf3gRVr7KA/jsQbQGrRV2ecDJLP8NdjjrUx3a6pArAjDAeGhm3lgjU8fSsc6S4j20sHY WViQ== 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=oCu4cbI2ZHBlH+viXbn57tCqpQanGyFP2VKCGfxLh0g=; b=rhsHunsSCjvFv79B7foeYQKAK33wUzmRtqIkwHeKwcGA0vIBqBBQhEcdFPNyRGGpvy AarweVcTNTI4eF7fs2Hrf/C9fDOqJAWOGrNj2BYLOl5ywiVtDuqMOZ7QjwEE1aSHrJIZ OeE2ok2O9/3kVtu2V1rWp93Omyz87sjZ/sAGxnSfSC7sZCUUUizxMn2PTkIt1gtuvDij XTjYmDTLvcTnDalrduCKomn72KtbJGg2vE6LSCLFPfwRDhxf8oGRGjWTcvi6RBI9Id8K FYZjGLtFEZyoLxnXvtcWwyA0xwZf99NiJ+j7QwnkUcqMl5WdH48UBDn7U6J1mfOaj1OW R8Ew== X-Gm-Message-State: AOAM530AAvV6A9459vlqXfrpFbwyQEfKBEcNBC6HESsdiu8ZXx1H0t+S qVUNecWQJwViMsgQdHcOuAXcWvBn4x5XTuxHwk0= X-Google-Smtp-Source: ABdhPJywDmMGd3lrQvu/IRBaYjuAjSKHTu2VbM9Pbf95ULRtVPqyQviOnAxC5kaOj1E9zxtJfwHeTrP7lYUHnU5kk9E= X-Received: by 2002:a17:90a:3849:: with SMTP id l9mr5591552pjf.7.1629108945143; Mon, 16 Aug 2021 03:15:45 -0700 (PDT) MIME-Version: 1.0 References: <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> In-Reply-To: <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 11:15:33 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler wr= ote: > There are serious drawbacks of attaching "private" string properties to > arbitrary strings. For once it complicates debugging seriously if there > are suddenly string properties attached to symbol names. It also leads > to a potential memory leak. Please, in the name of the sanity of this discussion, justify these two statements with examples or follow them with a clause like "because...". > 3. The `completion-filter-completions` API is the fastest possible API Again that's quite a statement that I cannot evaluate the veracity of without hard proof. What I _can_ evaluate is the material you have put forward, and using your patch and your Vertico completion software, version 0.14, the very latest one. I try emacs -Q -f package-initialize benchmark.el where benchmark.el is: (setq completion-styles '(flex)) (defmacro heyhey () `(progn ,@(cl-loop repeat 300000 collect `(defun ,(intern (symbol-name (gensym "heyhey"))) () 42)= ))) (heyhey) I then turn on vertico-mode and press C-h f. It takes about 4-5 seconds. It's *faster* than if I do the same with fido-vertical-mode and the current master, but is noticeably *slower* than if I do the same with the patch provided earlier and available at scratch/icomplete-lazy-highlight-attempt-= 2. Unfortunately, I cannot measure quantitatively here, because I don't know how to tell Vertico to wait until it gets the correct result. In other words, take this form: (completing-read "bla" obarray) if you type C-u C-x C-e C-m veeery s-l-o-w-l-y in Vertico, if prints , correctly, the character "%". But if you evaluate it quickly wrapped in a benchmark-run, it returns immediately and prints "". In fido-mode, it always waits blockinly until it prints the correct result and the time it took it to achieve that result. Not questioning if this is a bug in Vertico, but it would help if it could do the same, or be configured to do the same, so that we can measure. Without that, we can't evaluate the speed of Vertico where, presumably, the fastest API in the world is being used right now. > 4. If 'completion-all-completions' does indeed get slower thanks to my > patch, it is a performance regression of my patch. I will fix this. And > I thank you Jo=C3=A3o for bringing this to my attention. However one shou= ld > also consider that in the end, 'fido-mode' and 'icomplete-mode' should > move to the new API 'completion-filter-completions' such that they > benefit from the fast filtering and only copy and highlight the actually > displayed strings. Maybe they will, maybe they will. But it's still quite early to decide if we're going to move all frontends to that API. There's no manual documentation for it. Conceivably, if you appreciate your API so, you could demonstrate in practice us how easy it is to use by providing a separate patch that adapts icomplete-mode and fido-mode to use it. Then, I or other fido-mode users could test it for a while, evaluating its speed and correctness. If it performs well and the completion API architects have a good outlook for it, I see no reason why it shouldn't be merged and eventually supersede the new one. In the meantime, there is a patch with a measured and documented performance boost where fido-mode and icomplete-mode move opt-in to a new `completion-lazy-hilit` feature in the "old" API with a total or four 1-line changes. That patch lives in the branch scratch/icomplete-lazy-highlight-attempt-2. I think we should move to that, solving the bug#48841 while we do the evaluation of all aspects of your contributions. Jo=C3=A3o T=C3=A1vora From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 10:54:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov , Lars Ingebrigtsen , Eli Zaretskii , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911118926913 (code B ref 48841); Mon, 16 Aug 2021 10:54:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 10:53:09 +0000 Received: from localhost ([127.0.0.1]:48621 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFaEv-0006zz-GY for submit@debbugs.gnu.org; Mon, 16 Aug 2021 06:53:09 -0400 Received: from server.qxqx.de ([178.63.65.180]:42099 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFaEt-0006zS-Mq; Mon, 16 Aug 2021 06:53:08 -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=/fVONndn1d2yojf57smO1XDuVRiSgpuk9VBMHyJfqo0=; b=IG5RSU61Y3C7Qtn3VtFY1CebtN +QPuxDouSXj1jJDLk3YuN8NerQGacWg826fbv27K1W4K4SkfLPHt6nBueSDh5KslUAx1/MigfCm+o USkrYrDdUGpOqnmNw6GjAa54BOEu+YC3aOsZg6Zvz6MbuekLzZ8IqlAsoY3ZQ21Bv2QQ=; References: <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> From: Daniel Mendler Message-ID: Date: Mon, 16 Aug 2021 12:52:58 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/16/21 12:15 PM, João Távora wrote: > On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler wrote: > >> There are serious drawbacks of attaching "private" string properties to >> arbitrary strings. For once it complicates debugging seriously if there >> are suddenly string properties attached to symbol names. It also leads >> to a potential memory leak. > > Please, in the name of the sanity of this discussion, justify these two > statements with examples or follow them with a clause like "because...". João, I am giving hard examples here. What is not an example about "memory leak" or making debugging output verbose thanks to the attached string properties? You always repeat your demands but whatever I write it is not satisfactory for you. Is it possible to convince you? Can you try to interpret my arguments in a positive and constructive light somehow and fill them with meaning such that it makes sense to you? My goal is not to be right here just for the sake of being right. As Eli said, nobody has to prove anything. >> 3. The `completion-filter-completions` API is the fastest possible API > > Again that's quite a statement that I cannot evaluate the veracity of > without hard proof. As I said, I will ensure that my API does not introduce performance regressions. And since my new API performs strictly less work than your proposal it will necessarily be faster if you consider only the filtering, which is what matters for incrementally updating UIs. >> 4. If 'completion-all-completions' does indeed get slower thanks to my >> patch, it is a performance regression of my patch. I will fix this. And >> I thank you João for bringing this to my attention. However one should >> also consider that in the end, 'fido-mode' and 'icomplete-mode' should >> move to the new API 'completion-filter-completions' such that they >> benefit from the fast filtering and only copy and highlight the actually >> displayed strings. > > Maybe they will, maybe they will. But it's still quite early to decide if > we're going to move all frontends to that API. There's no manual > documentation for it. Conceivably, if you appreciate your API so, you > could demonstrate in practice us how easy it is to use by providing > a separate patch that adapts icomplete-mode and fido-mode to use it. There is also no manual documentation of 'completion-all-completions'. Of course you are right that it is early to make these decisions, but the new API 'completion-filter-completions' is designed in a way to allow adoption by 'icomplete-mode'. It is important to design the API such that adoption is possible. I have a patch for Vertico which shows this. I can provide patches for 'icomplete-mode' separately later on. > In the meantime, there is a patch with a measured and documented > performance boost where fido-mode and icomplete-mode move > opt-in to a new `completion-lazy-hilit` feature in the "old" API with > a total or four 1-line changes. That patch lives in the branch > scratch/icomplete-lazy-highlight-attempt-2. As argued multiple times here now, the change you are proposing is fragile. It will lead to problems later on. The goal is not to find the smallest change which leads to a performance boost, all API violations allowed. Attaching "private" string properties to arbitrary strings is an API violation which we will regret later and which will make Emacs harder to debug and harder to use. > I think we should move to that, solving the bug#48841 while we > do the evaluation of all aspects of your contributions. No, we should not merge this problematic patch of yours. See the many arguments against this proposal. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 11:38:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov , Lars Ingebrigtsen , Eli Zaretskii , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291138587186 (code B ref 48841); Mon, 16 Aug 2021 11:38:01 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 11:37:38 +0000 Received: from localhost ([127.0.0.1]:48659 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFavx-0001rj-T5 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 07:37:38 -0400 Received: from mail-pl1-f170.google.com ([209.85.214.170]:38758) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFavv-0001rO-AX; Mon, 16 Aug 2021 07:37:36 -0400 Received: by mail-pl1-f170.google.com with SMTP id a5so20376640plh.5; Mon, 16 Aug 2021 04:37:35 -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=PP4sRFsXGoPRO3HMfAeZVAdQ65nsBuQPmVZTfft17hA=; b=GoSaAsmAvDaJ2uEnFUQL2xDzpkjCEOWINaIWLQb4j4gnIQT1XIeWP15QWTop+vtWrL dIqyXjGuNSjWTDDIRcm+rc+qvpNOFBTaUa50EZ0knZaSAyqLTEHe+0D7YeafD/auQ5X2 RGKP9WaXJNwr3rFIgUo2eiYBkX/TPV9UyskbbMV9y9jkEXr/90eVe3j7sM1zqpV5/F2R sEAeJib5PBjWZ4elaJdCAyv7vRPZSPdvAn8JxOtmS8PjwAVgtnwE0mWXt99s7LZh3Xde JklCLkX8moxJ/d9NNSghPMprtnY3Ek7bHEBYuda8rUPe2EJWhiwj3b13giMQrvGSMq4H rfzA== 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=PP4sRFsXGoPRO3HMfAeZVAdQ65nsBuQPmVZTfft17hA=; b=DQ/vdrTLsgX8WvR6REAhrMlk+Zc2S53hChzhYTrRE3NU3Q1OhK0INHm3avRoSSHrRK cKtUbaATb0UvCf04ttBCdspBczfm0tDC/b1uyCRmPNTYPHMxdZxCJf8I1vofSsXkFCMo KiBRZEryMrydzoDVzmqw7oBE5b4VQSc9TvPkd97nMFuQKzl6YRhBsRfb/e0mq5r0ymhT bJkkWSk+LZSfV2oD4B0d8wtCofyxXgSaYgcosPV6GhARXRZtUb2HkmT/g93HSvFd2sem uoFdDWUQuUEfDuwKwMxkej3afL7yeUYRDSWNR+CdwkPRcRoNOyaL9UZAGW3IbnC5lqfZ i16A== X-Gm-Message-State: AOAM533DyepoAsd/XxbhrdehaJxKWlhYtH1ZnjfHNXiRhmemoTb1hQe0 b/1O+8nTXOLEsSRlf97XeuSfiCOOJIKpj8KzcCg= X-Google-Smtp-Source: ABdhPJw7BaRbhM71Xp9pUzVXJR+YVQTSu9Q0LemJBUf+41xxZ6Cjz3cWVrjUel5I3GCBaZtwjQzU2ns366mJJydGD10= X-Received: by 2002:aa7:9050:0:b029:3af:7e99:f48f with SMTP id n16-20020aa790500000b02903af7e99f48fmr15986526pfo.2.1629113849377; Mon, 16 Aug 2021 04:37:29 -0700 (PDT) MIME-Version: 1.0 References: <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 12:37:17 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 11:53 AM Daniel Mendler wr= ote: > >> There are serious drawbacks of attaching "private" string properties t= o > >> arbitrary strings. For once it complicates debugging seriously if ther= e > >> are suddenly string properties attached to symbol names. It also leads > >> to a potential memory leak. > > Please, in the name of the sanity of this discussion, justify these two > > statements with examples or follow them with a clause like "because..."= . > Jo=C3=A3o, I am giving hard examples here. If I say to you: "It's quite obvious your patch breaks all Git repositorie= s in Kathmandu, Nepal" I am expected to demonstrate how a patch to Emacs, leads to a obscure security flaw in the Linux operating system, that tickles a butterfly at a certain angle that causes an earthquake in the Kathmandu data center, literally breaking their Git repositories. This is the the kind of statement you are making to me and the kind of logical reasoning I'm looking for. Alternatively, you can provide an actual experiment I can run in my computer that demonstrates the bug. I am not a native English speaker, and maybe you don't understand my language. Another way to explain what I am talking is to talk about "bug reproduction". You say there's a bug in my patch, I am asking you for a "bug reproduction recipe" as defined by most, if not all, the result= s you get by searching "bug reproduction recipe" in the Google search engine. > goal is not to be right here just for the sake of being right. As Eli > said, nobody has to prove anything. This is clearly not what he said. > >> 3. The `completion-filter-completions` API is the fastest possible API > > > > Again that's quite a statement that I cannot evaluate the veracity of > > without hard proof. > > As I said, I will ensure that my API does not introduce performance > regressions. Not only that, to produce veracity on that statement you would need some much more demanding proof, which is somehow be able to evaluate all possible APIs to compellingly demonstrate that yours triumphs. > I have a patch for Vertico which shows > this. I can provide patches for 'icomplete-mode' separately later on. Yes, please do. The earlier, the better. > No, we should not merge this problematic patch of yours. See the many > arguments against this proposal. I'm sorry to speak this child-like language, but a problem is a "bad thing"= . An undesirable thing that happens when presumably safe and good action(s) is taken by some user. Can you explain how, given my patch, a user would take a sequence of innocent actions that would lead to a "bad thing" that would _not_ happen if the same sequence of innocent actions were taken in a version of Emacs without the patch applied? That, to me, is what constitutes "a bug/problem in the patch". Let me give you an example: if I make a patch that deletes `/lisp` in the Emacs source tree, the innocent action "make" would probably not work. That would be the problem/"bad thing"/bug in that patch. We cannot proceed this discussion without these explanations. Mind you, I'm not stating, because it is impossible to prove, that my patch cannot possibly generate problems, subtle or obvious (that, by the way, is my interpretation of what Eli meant). But since you so confidently state that it does, it's quite reasonable that I ask you for examples that demonstrate it. Once you do demonstrate these bugs, it's reasonable I will go about fixing them. Exactly as you say you are going to do. I demonstrated with code and numbers a regression in _your_ patch, and you say are going to fix it. That's great, and that's the way it should be. But you possibly wouldn't go about fixing it if I hadn't demonstrated the regression compellingly, just as I can't go about fixing a "memory leak" or "debugging difficulties" if you don't explain what these things mean to you or how my patch causes them. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 11:48:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: mail@daniel-mendler.de, 47711@debbugs.gnu.org, joaotavora@gmail.com, 48841@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291144378272 (code B ref 48841); Mon, 16 Aug 2021 11:48:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 11:47:17 +0000 Received: from localhost ([127.0.0.1]:48670 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFb5I-00029M-It for submit@debbugs.gnu.org; Mon, 16 Aug 2021 07:47:16 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36658) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFb5D-00028o-G7; Mon, 16 Aug 2021 07:47:11 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44640) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFb57-00028Z-QC; Mon, 16 Aug 2021 07:47:05 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2095 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFb57-0003EM-Ac; Mon, 16 Aug 2021 07:47:05 -0400 Date: Mon, 16 Aug 2021 14:46:58 +0300 Message-Id: <83tujp8vd9.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> (message from Dmitry Gutov on Mon, 16 Aug 2021 06:17:32 +0300) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: mail@daniel-mendler.de, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, > 47711@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 16 Aug 2021 06:17:32 +0300 > > On 14.08.2021 14:29, Eli Zaretskii wrote: > > Text properties are stored separately from the string, so I don't > > think adding properties can in general be referred to as "change". > > Are you thinking of C strings? No, about the implementation of Lisp strings in Emacs. > Lisp strings carry text properties in addition to the array of > characters. It doesn't really matter where in the memory the properties > and the characters reside. Well, it does, at least in some situations. The string text is not affected, and so the code which processes the string will not notice that it has a property about which that code has no idea. Only properties that are known to the processing code can affect it; non-standard properties private to some other code will generally pass unnoticed. > > Whether in some particular situation that could count as a "change" > > depends on that situation and on the particular property, of course. > > I was talking in the general sense: modifying a value. > > One can talk about whether a certain modification matters in certain > situations, but that's not the way to discount a general principle. I didn't want to start a general philosophical discussion about string mutability. I hoped to provide input of specific practical use in the context of this discussion. If what I said is not useful, just disregard it. > > I'm not sure in the context of completion there's any reason to count > > as "change" adding properties that don't affect display. > > For the context in question, whether the properties affect display is > not particularly important. Properties affecting display just make it > easier to notice that something's wrong. Bug involving other properties > should be more difficult to investigate. Once again, if some code invents its private property, not used anywhere else and not documented anywhere else, then putting such a property on a string has very high chances of going unnoticed. I hope this consideration helps this discussion, because saying that properties change a string blurs the distinction between actually changing the string text or its properties that affect many parts in Emacs, and adding some obscure property that is not known to anyone. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 11:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: mail@daniel-mendler.de, joaotavora@gmail.com, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291145338450 (code B ref 48841); Mon, 16 Aug 2021 11:49:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 11:48:53 +0000 Received: from localhost ([127.0.0.1]:48675 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFb6r-0002CC-25 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 07:48:53 -0400 Received: from eggs.gnu.org ([209.51.188.92]:36928) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFb6p-0002Bt-IX; Mon, 16 Aug 2021 07:48:51 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44662) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFb6j-00032d-4E; Mon, 16 Aug 2021 07:48:45 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2200 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFb6i-0003Lq-Hr; Mon, 16 Aug 2021 07:48:44 -0400 Date: Mon, 16 Aug 2021 14:48:39 +0300 Message-Id: <83sfz98vag.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <42a56dff-197d-d223-a2d8-12db8577b505@yandex.ru> (message from Dmitry Gutov on Mon, 16 Aug 2021 06:26:58 +0300) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <83im08bjc3.fsf@gnu.org> <42a56dff-197d-d223-a2d8-12db8577b505@yandex.ru> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, joaotavora@gmail.com, > 48841@debbugs.gnu.org > From: Dmitry Gutov > Date: Mon, 16 Aug 2021 06:26:58 +0300 > > On 14.08.2021 10:01, Eli Zaretskii wrote: > > > Just to make sure we are on the same page: adding a text property to a > > string doesn't mutate a string. Lisp programs that process these > > strings will not necessarily see any difference, and displaying those > > strings will also not show any difference if the property is not > > related to display. So the assumption that seems to be made here, > > that adding a property is the same as mutating a string, is IMO > > inaccurate if not incorrect. > > This is nonsense. > > A program won't necessarily see a difference in *any* changed value, as > long as some part of it stays the same. > > I can zero out the tail of a string, and have a program that only looks > at its first few characters. It wouldn't mean that a string hasn't changed. You are not making any sense. Anyway, if what I wrote doesn't help, feel free to disregard it. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 11:58:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: 48841@debbugs.gnu.org, 47711@debbugs.gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291150379502 (code B ref 48841); Mon, 16 Aug 2021 11:58:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 11:57:17 +0000 Received: from localhost ([127.0.0.1]:48688 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbEy-0002T7-NK for submit@debbugs.gnu.org; Mon, 16 Aug 2021 07:57:17 -0400 Received: from eggs.gnu.org ([209.51.188.92]:38180) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbEw-0002Se-Kt; Mon, 16 Aug 2021 07:57:15 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:44788) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFbEq-0007if-P5; Mon, 16 Aug 2021 07:57:08 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2716 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFbEq-0004Nk-CS; Mon, 16 Aug 2021 07:57:08 -0400 Date: Mon, 16 Aug 2021 14:57:01 +0300 Message-Id: <83pmud8uwi.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <75ce4b68-240f-2f0e-3953-c1f74962c3cd@daniel-mendler.de> (message from Daniel Mendler on Mon, 16 Aug 2021 10:48:19 +0200) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <83h7fsbitl.fsf@gnu.org> <75ce4b68-240f-2f0e-3953-c1f74962c3cd@daniel-mendler.de> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: joaotavora@gmail.com, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, > 47711@debbugs.gnu.org > From: Daniel Mendler > Date: Mon, 16 Aug 2021 10:48:19 +0200 > > On 8/14/21 9:12 AM, Eli Zaretskii wrote: > >> Since up until now completion-pcm--hilit-commonality copied all strings > >> before modifying, completion tables such as described (with "shared" > >> strings) have all been "legal". Suddenly deciding to stop supporting > >> them would be a major API breakage with consequences that are hard to > >> predict. And while I perhaps agree that it's an inconvenience, I don't > >> think it's a choice we can simply make as this stage in c-a-p-f's > >> development. > > > > This sounds like an argument against Daniel's approach as well, no? > > Because if a completion API returns strings it "doesn't own", there > > will be restrictions on Lisp programs that use those strings, because > > those Lisp programs previously could do anything they liked with those > > strings, and now they cannot. Or am I missing something? > > No, in my patch the displayed candidate strings are still copied before > the text properties are attached. The strings are kept intact as they > are now. I was talking about the infrastructure that produces the completion candidates, not about the application that uses them. My point is that your approach requires the applications using the candidates to copy them, whereas previously they could use them without copying. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:03:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Daniel Mendler , 47711@debbugs.gnu.org, Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911534610288 (code B ref 48841); Mon, 16 Aug 2021 12:03:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:02:26 +0000 Received: from localhost ([127.0.0.1]:48713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbJx-0002fq-OP for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:02:25 -0400 Received: from mail-pj1-f47.google.com ([209.85.216.47]:37852) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbJv-0002fV-8N; Mon, 16 Aug 2021 08:02:24 -0400 Received: by mail-pj1-f47.google.com with SMTP id cp15-20020a17090afb8fb029017891959dcbso31975574pjb.2; Mon, 16 Aug 2021 05:02:23 -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=FgipmI8mrux/nK0E7ZMSHjfGrIdRCejKfhBwYRpSzms=; b=NL/i3b2zUrULUZHux5TA+MqbiNNWyPsLvWNIz288/2bHzqBhzF1PX1DAjP52KXueOq OqKJGwHo7W5uEcvkhTGqGNggg95bAF/5VDp8ElPqC608A6to5DwQfu9JwI1JGdhwOj3B iNi9JNWeoByf76QGKUOaunwbnyA7PdY7M/GjkwzJiX5tUHo/QmT/B2jYO9bu4EIicK+O 9ddkvdZeU/29pwC0TDqpzqjuUQHe9qaHiSjMkEklDUjaxBOWdZrUTJy23ifbe9l03tb8 KHBX/wPl9wHopXhQyM78V3pItqJ4ZCyU3xIQHlGWzHdAq+p9jNMFQYcoSHxXiN9ndvDk 9BvQ== 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=FgipmI8mrux/nK0E7ZMSHjfGrIdRCejKfhBwYRpSzms=; b=qh+YkK4baWh29gu+mmNPQZmWuy3GonuzFBhVvqEwKaGAWzlIzMChcx9/rcXchHMdVo eTmNfBulLU9D96a99RZGo74CgPRNR2o/8RTGxhZ2BbUBcs+VzpAo2z0Neb7FSfRu2WVq He5+Z4A07QTKtJLGbAHrB94tIc1H3ok3MXMIXMUIvFK+3eVDjn50UkHmGBKBdxEtAbyD lGmo31dGjk+uq3Ri8uUFZUsgEQSfwx8Ch4uKwRsOiaTowR5sibxC54DmvXDZf5vVw9rj QfUN/+3XevQwY8zbzIj5XepdIJYBKvAwqbf9A9Ckt93vllfKTKfWUGVYnmYkEn7Z+V4t AZww== X-Gm-Message-State: AOAM533OLx07BHDXGgeVlN1jsHlcr2KEp7DNf+TGazkhL47NP2gq1TaI Rh+3vWM7BVWJ99gQ0xn6YIoEgwtq9EnHBkr2G2Y= X-Google-Smtp-Source: ABdhPJzjM5Qis+eLF+MA/lhmfwPXQa7dKbrodyXqHMG9z4pIxWVkYHQWf/UHH6u+FZiAOiv4JLPdPwnMZ1rVYV2C/uc= X-Received: by 2002:a65:6653:: with SMTP id z19mr15605178pgv.394.1629115337363; Mon, 16 Aug 2021 05:02:17 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <83h7fsbitl.fsf@gnu.org> <75ce4b68-240f-2f0e-3953-c1f74962c3cd@daniel-mendler.de> <83pmud8uwi.fsf@gnu.org> In-Reply-To: <83pmud8uwi.fsf@gnu.org> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 13:02:04 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 12:57 PM Eli Zaretskii wrote: > I was talking about the infrastructure that produces the completion > candidates, not about the application that uses them. My point is > that your approach requires the applications using the candidates to > copy them, whereas previously they could use them without copying. If it helps, I think that that is true of all alternatives presented so far (though I haven't read the big patch fully yet). The difference is that the consumers who copy the candidate strings will only copy a much smaller number, typically only the ones that need to be displayed. Whereas currently, all candidate strings are copied, displayed or not. Jo=C3=A3o T=C3=A1vora From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:07:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov , Lars Ingebrigtsen , Eli Zaretskii , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911556610695 (code B ref 48841); Mon, 16 Aug 2021 12:07:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:06:06 +0000 Received: from localhost ([127.0.0.1]:48720 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbNV-0002mO-GU for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:06:05 -0400 Received: from server.qxqx.de ([178.63.65.180]:59331 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbNT-0002lo-8G; Mon, 16 Aug 2021 08:06:04 -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=Rqm3CwKvaY3irAWRkNIM3r7NyHLM9cGe9M3IfOA8XxM=; b=ktVOSLa8U2WRAXCOadinumlvJp FRn5yd3JtduX91ZpaoVdXSgrjRtx+cemkLkO/k7UphFRNq9cBPahXSsImb8uapcbODMEXeIhBRnGH oh+2hJ/SFUU7usXD9ubtxJrfKs4zQGlYeBC5I+w3mut2ZG26VRhpJIwkn95aORXMAX2s=; References: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> From: Daniel Mendler Message-ID: Date: Mon, 16 Aug 2021 14:05:54 +0200 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) João, the discussion is clearly not progressing. I propose that we both take a step back and let the Emacs maintainers, who participated in this discussion, decide on how to proceed. It seems to me that all arguments and data has been presented and there is no need for further reiterations in more and more colorful language. I would also like to point out that implying that I don't understand your language is borderline acceptable. I understand the discussion very well, but I don't understand why you are using these unfair and invalid means of discussion. For example there could be these decision outcomes: 1. The information presented up to now does not allow the maintainers to make a decision. For example the maintainers may ask for further clarification from you, João, or they may ask for benchmarks from me or a prove that my patch does not lead to performance regressions. 2. The maintainers decide that no patch should be merged. 2. The maintainers decide that your patch will be merged. I will accept this decision. 3. The maintainers decide that my patch will be merged. You will accept this decision. 4. The maintainers decide that both patches will be merged such that both approaches will be supported. We both will accept this decision. I want to summarize the situation in the following: The patches in question address a performance issue in the current completion machinery which is caused by over-eager copying of the completion candidate strings and over-eager application of the highlighting to all candidate strings. For incrementally updating UIs it would be sufficient to only copy and highlight the strings which are actually going to be displayed. My patch takes the approach to expose the existing two-step completion process, which consists of filtering and highlighting. By returning the filtered completion strings and a highlighting function this two-step process is decomposed and the caller of the API has the ability to call the highlighting function on only the displayed subset of completion candidates. I argue that exposing the filtering and highlighting procession steps is the logical and natural conclusion of the existing machinery. My patch is fully backward compatible and aims to not introduce any regressions (also no performance regressions) to the existing API. Furthermore my patch adheres to the current guarantees given by the existing 'completion-all-completions' API. The completion strings provided by the completion backend are not mutated in any way, no string properties are attached. Since the API 'completion-filter-completions' proposed in my patch does the minimal amount of work necessary (only filtering), if no highlighting is requested, I argue that the new API is the most efficient possible API, given the current constraints. Furthermore since I am introducing a new API, outstanding issues can be solved which could not be solved until now given the constraints of the existing 'completion-all-completions' API. In particular the new API 'completion-filter-completions' API returns additional data like the end position of the completion boundaries. Until now the end position was not made available and 'completion-base-position' just used the length of the input to guess the end position. In a strict sense this guess is incorrect and there is a FIXME in minibuffer.el, mentioning this issue. The downside of my patch is that it is a large patch. While it adds only 196 lines of code, which is not much and expected given that it only reshuffles the existing machinery, it is still a large patch in total. On the other side, João's patch avoids the complication of adhering to the existing guarantees of the APIs and takes the liberty of attaching "private" string properties to the completion strings of the completion table backend. I argue that attaching the string properties is a violation of the guarantees of the existing API and violates the expectations of the existing many completion tables. One very severe scenario is when obarray is used as completion table, since then each symbol name gets a private property attached. I argue that such global side effects like attaching string properties to all completion candidates should better be avoided. There is the issue that the attached string properties are a potential memory leak. When dumping the string representation of symbol names, the symbols will have additional properties which will complicate the debugging experience. Furthermore it will lead to confusion since the global side effect during completion will suddenly have an influence of symbols which don't have to do anything with completion. The big advantage of João's patch is that it is very limited in scope and very simple. However I argue that this simplicity is hard-won and we will regret this approach later due to the global side effects. Therefore I conclude that the two-step process proposed in my patch, which does not introduce problematic global side effects is the better approach forward. Furthermore a new API is needed such that more completion data can be returned, e.g., the completion end position. One could even return additional match data in the future given that the new API 'completion-filter-completions' is extensible thanks to its alist return value. João, please feel free to also present your closing arguments here. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:09:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: 48841@debbugs.gnu.org, 47711@debbugs.gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911572211058 (code B ref 48841); Mon, 16 Aug 2021 12:09:03 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:08:42 +0000 Received: from localhost ([127.0.0.1]:48739 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbQ2-0002sD-A7 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:08:42 -0400 Received: from server.qxqx.de ([178.63.65.180]:45343 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbQ0-0002rn-Ts; Mon, 16 Aug 2021 08:08:41 -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=R55hjCfJUe6SX5kZqUMWgP5U5R+Jn+Et7+fCwvgRegg=; b=xUpr01qQu0n2wvaRzOXBFioD6x WZOQKMXScwZKkhGaryKipNAaoHQY3Z34jY274hOKXT/Dg2nHk+3ngR56N0OHjYcFNE2TObaa+jnWo Fb5gH57N8WwLJjlZjMKWTuy9DJhSIxsAdn8YPaNZv0ICxhLSbprk+ZDPMKloA7Z7te/w=; References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <83h7fsbitl.fsf@gnu.org> <75ce4b68-240f-2f0e-3953-c1f74962c3cd@daniel-mendler.de> <83pmud8uwi.fsf@gnu.org> From: Daniel Mendler Message-ID: <003d6015-8594-7623-16d9-167991a1ac16@daniel-mendler.de> Date: Mon, 16 Aug 2021 14:08:33 +0200 MIME-Version: 1.0 In-Reply-To: <83pmud8uwi.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/16/21 1:57 PM, Eli Zaretskii wrote: > I was talking about the infrastructure that produces the completion > candidates, not about the application that uses them. My point is > that your approach requires the applications using the candidates to > copy them, whereas previously they could use them without copying. Okay, I understand. Yes, in my patch the strings returned by 'completion-filter-completions' must not be mutated by the API consumer directly. This should be documented clearly, but it is not unexpected. For example the API 'all-completions' which one can use to obtain the strings from a completion table also requires the caller to not mutate the returned strings. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:19:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov , Lars Ingebrigtsen , Eli Zaretskii , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911629720777 (code B ref 48841); Mon, 16 Aug 2021 12:19:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:18:17 +0000 Received: from localhost ([127.0.0.1]:48810 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbZI-0005Oy-QN for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:18:17 -0400 Received: from mail-pj1-f48.google.com ([209.85.216.48]:46021) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbZG-0005Oc-4H; Mon, 16 Aug 2021 08:18:15 -0400 Received: by mail-pj1-f48.google.com with SMTP id m24-20020a17090a7f98b0290178b1a81700so27283048pjl.4; Mon, 16 Aug 2021 05:18:14 -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=vG3PtNb8GFe1kTTcPbNe6NfvS5vc+wIhZ/FWyFFtPIA=; b=aSH3HPLhgEj06AokK9atlnXYm/oOd2CjowEF2KvMYq4OxnlLlxnOcYegTgcjSZrUir /Gnqd2IF3JkQsi/P7PDf9sWksjDdJqDcCCOlCJwSJz6tfBtT42fLgRGpo8Bie73KkyEY 3sMa17mBF5tUc4naAeibyvCC4I3vNffSI6++HNQ06W0LODRwswVIMbL/rNCRtMBs4QiP baMmFVNDsnxePgBeGwjgxaerbmFFBAMcb9rqwdLxml5NldIlSBq+0XMr7zorhL6OVPnM CwwKcY4cmbR5IHmKB0AVp2KVJ3ijYxFih/1F43g9ExDOg90vYdFXBYhMNmAr8mZZHUaz ZJBg== 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=vG3PtNb8GFe1kTTcPbNe6NfvS5vc+wIhZ/FWyFFtPIA=; b=Qom4B1JVd2ZKFouUGQ25Szzp34t2JSAqbsBlhonSin5uEhbqc1uyLEuaiu1uiyTGQk sN4Oa+ujRE6TlkJbeChFQEEcarV2LlcTHVkRQ8oIUgh3eH/Sc+a7l5UnBXcAHd3cbLqN hoM25UtCRLfVHM5Lpb8TC7kH9G0DMLh/fCZJf3YLaqUm77Wb+NQ7Ikd88zGsnOZHKnv0 tlcz2WZgiqa06Pbp4DHpPbXpk+lAdmYi64078Vt4JITHGNohBjLQHWJ+vMRwalfWVM7H Cwy8hCHbBsTnf7KKBq7NQAgDWAo6PdLI8rqP4I7BPQn0GvjtrQN+VOUNp7S8p2A77m4G ELJQ== X-Gm-Message-State: AOAM530uHOE8XO7G+R8t3gJtzl2uHZn12DE1K2XH0w6nt4F7tKoRPqi0 +O00AgqYEN4BLhgsPbqsZUPT5S+rqrlkfgWlrfw= X-Google-Smtp-Source: ABdhPJywkcSc4K1vtg2RIk7Im7oLva1pYFsW7yZevcSSbs8sdCdSVuP1J3zmP4M1vGwMvMjrDIjDcCGF+zSjKJ/4/lQ= X-Received: by 2002:a17:90a:3849:: with SMTP id l9mr6083033pjf.7.1629116288241; Mon, 16 Aug 2021 05:18:08 -0700 (PDT) MIME-Version: 1.0 References: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 13:17:56 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Jo=C3=A3o, please feel free to also present your closing arguments here. Sorry, I don't "close" arguments like this. I hope you can provide: * the fixes to the regression identified * the benchmarks you say you have * the patches to icomplete.el that show how it uses your new API * the demonstrations of the bugs you accuse my patch to suffer from Thanks. On Mon, Aug 16, 2021 at 1:05 PM Daniel Mendler wro= te: > > Jo=C3=A3o, the discussion is clearly not progressing. I propose that we b= oth > take a step back and let the Emacs maintainers, who participated in this > discussion, decide on how to proceed. It seems to me that all arguments > and data has been presented and there is no need for further > reiterations in more and more colorful language. I would also like to > point out that implying that I don't understand your language is > borderline acceptable. I understand the discussion very well, but I > don't understand why you are using these unfair and invalid means of > discussion. > > For example there could be these decision outcomes: > > 1. The information presented up to now does not allow the maintainers to > make a decision. For example the maintainers may ask for further > clarification from you, Jo=C3=A3o, or they may ask for benchmarks from me= or > a prove that my patch does not lead to performance regressions. > > 2. The maintainers decide that no patch should be merged. > > 2. The maintainers decide that your patch will be merged. I will accept > this decision. > > 3. The maintainers decide that my patch will be merged. You will accept > this decision. > > 4. The maintainers decide that both patches will be merged such that > both approaches will be supported. We both will accept this decision. > > I want to summarize the situation in the following: > > The patches in question address a performance issue in the current > completion machinery which is caused by over-eager copying of the > completion candidate strings and over-eager application of the > highlighting to all candidate strings. For incrementally updating UIs it > would be sufficient to only copy and highlight the strings which are > actually going to be displayed. > > My patch takes the approach to expose the existing two-step completion > process, which consists of filtering and highlighting. By returning the > filtered completion strings and a highlighting function this two-step > process is decomposed and the caller of the API has the ability to call > the highlighting function on only the displayed subset of completion > candidates. I argue that exposing the filtering and highlighting > procession steps is the logical and natural conclusion of the existing > machinery. > > My patch is fully backward compatible and aims to not introduce any > regressions (also no performance regressions) to the existing API. > Furthermore my patch adheres to the current guarantees given by the > existing 'completion-all-completions' API. The completion strings > provided by the completion backend are not mutated in any way, no string > properties are attached. Since the API 'completion-filter-completions' > proposed in my patch does the minimal amount of work necessary (only > filtering), if no highlighting is requested, I argue that the new API is > the most efficient possible API, given the current constraints. > > Furthermore since I am introducing a new API, outstanding issues can be > solved which could not be solved until now given the constraints of the > existing 'completion-all-completions' API. In particular the new API > 'completion-filter-completions' API returns additional data like the end > position of the completion boundaries. Until now the end position was > not made available and 'completion-base-position' just used the length > of the input to guess the end position. In a strict sense this guess is > incorrect and there is a FIXME in minibuffer.el, mentioning this issue. > > The downside of my patch is that it is a large patch. While it adds only > 196 lines of code, which is not much and expected given that it only > reshuffles the existing machinery, it is still a large patch in total. > > On the other side, Jo=C3=A3o's patch avoids the complication of adhering = to > the existing guarantees of the APIs and takes the liberty of attaching > "private" string properties to the completion strings of the completion > table backend. I argue that attaching the string properties is a > violation of the guarantees of the existing API and violates the > expectations of the existing many completion tables. One very severe > scenario is when obarray is used as completion table, since then each > symbol name gets a private property attached. I argue that such global > side effects like attaching string properties to all completion > candidates should better be avoided. There is the issue that the > attached string properties are a potential memory leak. When dumping the > string representation of symbol names, the symbols will have additional > properties which will complicate the debugging experience. Furthermore > it will lead to confusion since the global side effect during completion > will suddenly have an influence of symbols which don't have to do > anything with completion. The big advantage of Jo=C3=A3o's patch is that = it > is very limited in scope and very simple. However I argue that this > simplicity is hard-won and we will regret this approach later due to the > global side effects. > > Therefore I conclude that the two-step process proposed in my patch, > which does not introduce problematic global side effects is the better > approach forward. Furthermore a new API is needed such that more > completion data can be returned, e.g., the completion end position. One > could even return additional match data in the future given that the new > API 'completion-filter-completions' is extensible thanks to its alist > return value. > > Jo=C3=A3o, please feel free to also present your closing arguments here. > > Daniel --=20 Jo=C3=A3o T=C3=A1vora From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:20:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: mail@daniel-mendler.de, 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911637020929 (code B ref 48841); Mon, 16 Aug 2021 12:20:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:19:30 +0000 Received: from localhost ([127.0.0.1]:48817 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbaT-0005RQ-Lv for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:19:29 -0400 Received: from eggs.gnu.org ([209.51.188.92]:44826) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbaS-0005R8-MG; Mon, 16 Aug 2021 08:19:29 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46066) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFbaM-0002dP-36; Mon, 16 Aug 2021 08:19:22 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:4103 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFbaL-00074k-Mw; Mon, 16 Aug 2021 08:19:22 -0400 Date: Mon, 16 Aug 2021 15:19:17 +0300 Message-Id: <83mtph8tve.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Mon, 16 Aug 2021 13:02:04 +0100) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <83h7fsbitl.fsf@gnu.org> <75ce4b68-240f-2f0e-3953-c1f74962c3cd@daniel-mendler.de> <83pmud8uwi.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Mon, 16 Aug 2021 13:02:04 +0100 > Cc: Daniel Mendler , Dmitry Gutov , > Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org > > On Mon, Aug 16, 2021 at 12:57 PM Eli Zaretskii wrote: > > > I was talking about the infrastructure that produces the completion > > candidates, not about the application that uses them. My point is > > that your approach requires the applications using the candidates to > > copy them, whereas previously they could use them without copying. > > If it helps, I think that that is true of all alternatives presented > so far Yes, I know. I was comparing the proposed alternatives to what we have now, and specifically because Dmitry mentioned this aspect. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:40:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, dgutov@yandex.ru, joaotavora@gmail.com, larsi@gnus.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911759531581 (code B ref 48841); Mon, 16 Aug 2021 12:40:03 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:39:55 +0000 Received: from localhost ([127.0.0.1]:48869 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbuB-0008DE-DX for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:39:55 -0400 Received: from eggs.gnu.org ([209.51.188.92]:50686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbu8-0008Cs-5T; Mon, 16 Aug 2021 08:39:50 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46626) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFbu1-00014t-Dy; Mon, 16 Aug 2021 08:39:41 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1381 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFbu0-0000Ui-Sm; Mon, 16 Aug 2021 08:39:41 -0400 Date: Mon, 16 Aug 2021 15:39:33 +0300 Message-Id: <83k0kl8sxm.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Mendler on Mon, 16 Aug 2021 12:52:58 +0200) References: <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) > Cc: Dmitry Gutov , Lars Ingebrigtsen , > 47711@debbugs.gnu.org, 48841@debbugs.gnu.org, > Stefan Monnier , Eli Zaretskii > From: Daniel Mendler > Date: Mon, 16 Aug 2021 12:52:58 +0200 > > On 8/16/21 12:15 PM, João Távora wrote: > > On Mon, Aug 16, 2021 at 10:09 AM Daniel Mendler wrote: > > > >> There are serious drawbacks of attaching "private" string properties to > >> arbitrary strings. For once it complicates debugging seriously if there > >> are suddenly string properties attached to symbol names. It also leads > >> to a potential memory leak. > > > > Please, in the name of the sanity of this discussion, justify these two > > statements with examples or follow them with a clause like "because...". > > João, I am giving hard examples here. What is not an example about > "memory leak" or making debugging output verbose thanks to the attached > string properties? FWIW, I also don't understand how adding properties could cause a memory leak. When a string is GCed, its properties get GCed as well, all of them. Am I missing something? As to more difficult debugging, I think adding a couple of properties that have simple structure will not impair debugging too much. Strings with many properties are not uncommon in Emacs, so we already have to deal with that. > As I said, I will ensure that my API does not introduce performance > regressions. And since my new API performs strictly less work than your > proposal it will necessarily be faster if you consider only the > filtering, which is what matters for incrementally updating UIs. I would indeed suggest both to make sure there's no performance regressions, and would like to see some data similar to what João presented, which backs up your assessments about your proposal being faster. Since performance is the main motivation for these changes, I think it's important for us to be on the same page wrt facts related to performance, before we make the decision how to proceed. Thanks. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:45:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, dgutov@yandex.ru, joaotavora@gmail.com, larsi@gnus.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162911785932050 (code B ref 48841); Mon, 16 Aug 2021 12:45:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:44:19 +0000 Received: from localhost ([127.0.0.1]:48883 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbyR-0008Kk-Es for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:44:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:51464) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFbyL-0008KR-Sd; Mon, 16 Aug 2021 08:44:14 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:46722) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFbyG-0001uW-Ct; Mon, 16 Aug 2021 08:44:04 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:1648 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFbyG-0000ve-09; Mon, 16 Aug 2021 08:44:04 -0400 Date: Mon, 16 Aug 2021 15:43:59 +0300 Message-Id: <83im058sq8.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Mendler on Mon, 16 Aug 2021 14:05:54 +0200) References: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: Dmitry Gutov , Lars Ingebrigtsen , > 47711@debbugs.gnu.org, 48841@debbugs.gnu.org, > Stefan Monnier , Eli Zaretskii > From: Daniel Mendler > Date: Mon, 16 Aug 2021 14:05:54 +0200 > > João, the discussion is clearly not progressing. I propose that we both > take a step back and let the Emacs maintainers, who participated in this > discussion, decide on how to proceed. It seems to me that all arguments > and data has been presented and there is no need for further > reiterations in more and more colorful language. As I wrote elsewhere, I'd like to see the performance aspects of this to be presented from both sides, and agreed upon. I don't think we can make the decision before we have performance data we all agree about. The other pros and cons are all of qualitative nature, and involve intuition, personal experience, and personal preferences, so each one will have their own balance. But performance is both basic and qualitative, and we should have the facts and agree on them. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Daniel Mendler Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 12:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, dgutov@yandex.ru, joaotavora@gmail.com, larsi@gnus.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291181968379 (code B ref 48841); Mon, 16 Aug 2021 12:50:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:49:56 +0000 Received: from localhost ([127.0.0.1]:48899 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFc3w-0002B0-7m for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:49:56 -0400 Received: from server.qxqx.de ([178.63.65.180]:59823 helo=mail.qxqx.de) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFc3u-0002Af-FE; Mon, 16 Aug 2021 08:49:55 -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=kZrT7LuVRK9XGgsyWGpuxLP8FMvP7eeoAoRJa1adfP8=; b=BH6TKB+fVaN/xvMTztdySZbl+R ICbPRP+GFV1yS4R2oqMVSOGN5kRp6rCsBT2bq3J/+7c9HG0cOZoCV5nGxnAbDenMkZDpZhnpX36Vg axzIfoOp3ByTbm/Tw1zZrSyLjmDosJbk1jC0bANXga0bAhGgMq341ZOM0He1EeQvUBmc=; References: <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> From: Daniel Mendler Message-ID: Date: Mon, 16 Aug 2021 14:49:45 +0200 MIME-Version: 1.0 In-Reply-To: <83k0kl8sxm.fsf@gnu.org> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) On 8/16/21 2:39 PM, Eli Zaretskii wrote: >> João, I am giving hard examples here. What is not an example about >> "memory leak" or making debugging output verbose thanks to the attached >> string properties? > > FWIW, I also don't understand how adding properties could cause a > memory leak. When a string is GCed, its properties get GCed as well, > all of them. Am I missing something? If you add string properties to all symbol names this memory will stay alive for much longer than necessary. It is not a memory leak in the strongest sense. The memory is still reachable, but there is still no need to keep the string properties allocated. This is comparable to memory leaks in other GCed languages where memory is also kept alive for longer than necessary. > As to more difficult debugging, I think adding a couple of properties > that have simple structure will not impair debugging too much. > Strings with many properties are not uncommon in Emacs, so we already > have to deal with that. I disagree with that. We are talking about adding string properties to every symbol name. This is a global side effect and different from adding string properties to a set of isolated string in a controlled manner. I also don't understand why one would even want to take any chances here given that the feature can be implemented in a way which avoids this global side effect entirely as my patch shows. >> As I said, I will ensure that my API does not introduce performance >> regressions. And since my new API performs strictly less work than your >> proposal it will necessarily be faster if you consider only the >> filtering, which is what matters for incrementally updating UIs. > > I would indeed suggest both to make sure there's no performance > regressions, and would like to see some data similar to what João > presented, which backs up your assessments about your proposal being > faster. Since performance is the main motivation for these changes, I > think it's important for us to be on the same page wrt facts related > to performance, before we make the decision how to proceed. I will prepare some benchmarks. Daniel From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: [PATCH] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 13:00:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: 48841@debbugs.gnu.org, 47711@debbugs.gnu.org, joaotavora@gmail.com, monnier@iro.umontreal.ca, dgutov@yandex.ru Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291187549304 (code B ref 48841); Mon, 16 Aug 2021 13:00:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 12:59:14 +0000 Received: from localhost ([127.0.0.1]:48925 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcCs-0002Pr-3S for submit@debbugs.gnu.org; Mon, 16 Aug 2021 08:59:14 -0400 Received: from eggs.gnu.org ([209.51.188.92]:54842) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcCi-0002Ok-Hy; Mon, 16 Aug 2021 08:59:04 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47060) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFcCc-0004HU-LT; Mon, 16 Aug 2021 08:58:54 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2559 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFcCc-0006ac-7q; Mon, 16 Aug 2021 08:58:54 -0400 Date: Mon, 16 Aug 2021 15:58:47 +0300 Message-Id: <83h7fp8s1k.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Mendler on Mon, 16 Aug 2021 11:42:22 +0200) References: <837dgrdrec.fsf@gnu.org> <83mtpkbky3.fsf@gnu.org> X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: joaotavora@gmail.com, dgutov@yandex.ru, monnier@iro.umontreal.ca, > 48841@debbugs.gnu.org, 47711@debbugs.gnu.org > From: Daniel Mendler > Date: Mon, 16 Aug 2021 11:42:22 +0200 > > >> To address your technical comment - this variable is precisely what one > >> of the technical difficulties mentioned in my other mail is about. The > >> question is how we can retain backward compatibility of the completion > >> style 'all' functions, e.g., 'completion-basic-all-completions', while > >> still allowing the function to return the newly introduced alist format > >> with more data, which enables 'completion-filter-completions' to perform > >> the efficient deferred highlighting. > > > > I understand, but given that we provide this for other packages, it > > shouldn't be an internal variable. > > No, we explicitly don't provide this variable for other packages. It is > explicitly only meant to be used for the existing completion styles > emacs21, emacs22, basic, substring, partial-completion, initials and > flex to opt-in in a backward-compatible/calling convention preserving > way to the alist return format. The idea is to keep the existing APIs > fully backward compatible. > > Other packages should select the format returned from the completion > styles differently. They should return the alist format on Emacs 28 or > if the API 'completion-filter-completions' API is present. In the not so > near future external packages which support only Emacs 28 and upwards > will then only return the alist format and don't have to perform any > detection anymore. What if some package outside minibuffer.el will want to control the format of the returned value, for some reason, like support for old Emacs versions? are we going to disallow that? > >> The new API 'completion-filter-completions' will substitute the existing > >> API 'completion-all-completions'. > > > > That's your hope, and I understand. But we as a project didn't yet > > decide to deprecate the original APIs, so talking about superseding is > > premature. > > It is not the hope - it is the explicit goal. The API has been designed > to replace the existing API 'completion-all-completions'. A goal is not a fact. Until that goal is reached, we cannot in good faith tell people an API is superseded. > We can of > course tone this down. However I, as a package author, would appreciate > if Emacs tells me when a newer API aims to replace another API and when > the documentation is explicit about it. That's understood, and when we make that decision, we will of course announce it. But we didn't do so yet, and this discussion is not even about that decision. It could be, for example, that both APIs will live side by side until we decide whether to deprecate the old one. > Of course if you decide to have > the doc strings written in a different tone, I will adapt my patch > accordingly. Here I am just explaining why I chose the word "superseded" > instead of a more neutral word. I understand your motivation, I'm just saying that we cannot announce deprecation before we actually decide to deprecate. > > But the name says "filter completions". Which would mean you take a > > list of completions and filter out some of them. A completion table > > is much more general object than a list of strings. Thus, I think > > using "filter" here is sub-optimal. > > Okay, you are right about this. But I think even if the name > 'completion-filter-completions' is not 100% precise it still conveys > what the API is about. 'completion-completions-alist' or > 'completion-all-completions-as-alist' are valid names of course, but I > dislike them for their verbosity. Already 'completion-all-completions' > is quite verbose. A strong argument to use this long name is that the > completion style functions are still called > 'completion-basic-all-completions' etc. But if we accept that the new > API 'completion-filter-completions' will actually supersede the existing > API 'completion-all-completions' it makes sense to use a name which will > not hurt our eyes in the long run. However this is of course just a > personal preference of mine. I don't want to spent much time with name > bikeshedding discussions. If you decide on a name, I will adapt my patch > accordingly. Emacs is frequently accused in having names that are hard to discover. The only time where we can improve that is when a symbol is introduced, because later it's impossible for compatibility reasons. So I'd like to come up with a good name before we install the changes. That said, I'll let others chime in and agree or disagree with the name you've chosen. Thanks. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 13:22:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Daniel Mendler Cc: monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, dgutov@yandex.ru, joaotavora@gmail.com, larsi@gnus.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912009828273 (code B ref 48841); Mon, 16 Aug 2021 13:22:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 13:21:38 +0000 Received: from localhost ([127.0.0.1]:48987 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcYb-0007Lr-NL for submit@debbugs.gnu.org; Mon, 16 Aug 2021 09:21:38 -0400 Received: from eggs.gnu.org ([209.51.188.92]:59452) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcYS-0007LS-Lp; Mon, 16 Aug 2021 09:21:32 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:47768) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFcYM-00022e-Bl; Mon, 16 Aug 2021 09:21:22 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:3998 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFcYL-0004j1-Nk; Mon, 16 Aug 2021 09:21:22 -0400 Date: Mon, 16 Aug 2021 16:21:17 +0300 Message-Id: <83bl5x8r02.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: (message from Daniel Mendler on Mon, 16 Aug 2021 14:49:45 +0200) References: <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > Cc: joaotavora@gmail.com, 48841@debbugs.gnu.org, dgutov@yandex.ru, > larsi@gnus.org, monnier@iro.umontreal.ca, 47711@debbugs.gnu.org > From: Daniel Mendler > Date: Mon, 16 Aug 2021 14:49:45 +0200 > > On 8/16/21 2:39 PM, Eli Zaretskii wrote: > >> João, I am giving hard examples here. What is not an example about > >> "memory leak" or making debugging output verbose thanks to the attached > >> string properties? > > > > FWIW, I also don't understand how adding properties could cause a > > memory leak. When a string is GCed, its properties get GCed as well, > > all of them. Am I missing something? > > If you add string properties to all symbol names this memory will stay > alive for much longer than necessary. That's a very extreme example, something that I wouldn't expect a Lisp program to do, without removing the properties shortly thereafter. And even that isn't a leak. Note that we already put all kind of properties (although not text properties) on symbols. > > As to more difficult debugging, I think adding a couple of properties > > that have simple structure will not impair debugging too much. > > Strings with many properties are not uncommon in Emacs, so we already > > have to deal with that. > > I disagree with that. We are talking about adding string properties to > every symbol name. This is a global side effect and different from > adding string properties to a set of isolated string in a controlled > manner. I also don't understand why one would even want to take any > chances here given that the feature can be implemented in a way which > avoids this global side effect entirely as my patch shows. I understand your aversion from such global effects, but I was talking specifically about the debugging difficulties. > > I would indeed suggest both to make sure there's no performance > > regressions, and would like to see some data similar to what João > > presented, which backs up your assessments about your proposal being > > faster. Since performance is the main motivation for these changes, I > > think it's important for us to be on the same page wrt facts related > > to performance, before we make the decision how to proceed. > > I will prepare some benchmarks. Thank you. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 13:39:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: mail@daniel-mendler.de, 47711@debbugs.gnu.org, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, joaotavora@gmail.com Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291211145621 (code B ref 48841); Mon, 16 Aug 2021 13:39:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 13:38:34 +0000 Received: from localhost ([127.0.0.1]:49010 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcp0-0001Sb-HZ for submit@debbugs.gnu.org; Mon, 16 Aug 2021 09:38:34 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:33578) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcot-0001S9-SH; Mon, 16 Aug 2021 09:38:29 -0400 Received: by mail-wr1-f49.google.com with SMTP id r7so23782499wrs.0; Mon, 16 Aug 2021 06:38:27 -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=SqI0rHgABZha2WvRm9Y8w2oaSldHqcSN+3/YdatFStM=; b=P3asAjLAFMnMQalTG7bE/JtxvtRSVYQrO1SO8ibPC68FgWWLijkIgEzFGRkLUP2rWa tMbUCkJugsQ4qIarmfIjj1PWoLhlYNgvAYV9wNwTNdW6OVBRiSUycs4kUA0OFWlyPpXT sO0Pba0/zS2F9MfmmCRocbHU7XNfjnjMbkqC4ufJd330VYNR+u88qcW6LPHzjZh+5ENa 2IfCnRxfnk03f4x03x9BMqOEEQZvbt2AZr2Oca2waE45jvhQOFcYLzoCbRagZn673Oqh VDfv/grSzZxbQIh9SrLVtdegvQ868Ok/dwJ01iXR47wNaW+Ft6oLaSqqgaG61KgifutI +Peg== 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=SqI0rHgABZha2WvRm9Y8w2oaSldHqcSN+3/YdatFStM=; b=QB5A7bSEXh1zrowP8TpCIpUza44usXulBEwjSZxpOeybMnsKTY4i/b9TWfEhbMHpq/ G1bnDU/wTJcUFFNkFmMT3yd2gUORdRC6+u7fk/2rycZlBR9uw05aSrL5cGD4SWm4BqTr UZL7qJWMCzlnXTnmxZoj8siFD/lHfKgBNP1TJnbSCAEYJIhwK2fsl8rYE1ILnCuyibIg z5GIQ8FQyBztPNmJuCQWzyZJY66Ir522fy8gQuMsbxRyNB5U1u/LHVfU87VJHEO3dS6J yTOknHBmqxgK5mzakd7wj6kGYrxdHXIFUgH2QPCwSf1qGovjjKp5jezJs+4bSjOX5lrn 7a8A== X-Gm-Message-State: AOAM5315ZW6diOufYdM5GevSsitT+N4503MMIfsia+3GVa2/FAs0sa8/ YaeyMNmIJQY4+QusfTPoI3UU4DwA5tc= X-Google-Smtp-Source: ABdhPJzZKIM/o/bTUBPGReFn6m2jVcVa2wAgTqynCgT+U8mlc53Mkju/lc+p6FTVvnJZe0381ucgzA== X-Received: by 2002:a5d:534e:: with SMTP id t14mr18793923wrv.109.1629121101904; Mon, 16 Aug 2021 06:38:21 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v17sm13960685wro.45.2021.08.16.06.38.20 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 06:38:20 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> <83tujp8vd9.fsf@gnu.org> From: Dmitry Gutov Message-ID: <769c0ee0-6d6f-6177-7929-1ac4ada30951@yandex.ru> Date: Mon, 16 Aug 2021 16:38:19 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83tujp8vd9.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 14:46, Eli Zaretskii wrote: >>> Text properties are stored separately from the string, so I don't >>> think adding properties can in general be referred to as "change". >> >> Are you thinking of C strings? > > No, about the implementation of Lisp strings in Emacs. I was talking about their behavior. >> Lisp strings carry text properties in addition to the array of >> characters. It doesn't really matter where in the memory the properties >> and the characters reside. > > Well, it does, at least in some situations. The string text is not > affected, and so the code which processes the string will not notice > that it has a property about which that code has no idea. Only > properties that are known to the processing code can affect it; > non-standard properties private to some other code will generally pass > unnoticed. I don't think anybody was suggesting that changing text properties changes the character codes inside the "C string" part of the Lisp string. >>> I'm not sure in the context of completion there's any reason to count >>> as "change" adding properties that don't affect display. >> >> For the context in question, whether the properties affect display is >> not particularly important. Properties affecting display just make it >> easier to notice that something's wrong. Bug involving other properties >> should be more difficult to investigate. > > Once again, if some code invents its private property, not used > anywhere else and not documented anywhere else, then putting such a > property on a string has very high chances of going unnoticed. I hope > this consideration helps this discussion, because saying that > properties change a string blurs the distinction between actually > changing the string text or its properties that affect many parts in > Emacs, and adding some obscure property that is not known to anyone. What muddies the water is arguing against a solid engineering principle with statements like "those mutations are not mutations". Yes, when the properties are prefixed, the damage is reduced. Even then, that increases the possibility of introducing bugs in the very code that sets those properties (like having different code paths where one branch sets them and another does not; forgetting to clear them in the other branch; having subsequent code use the property values set by some previous invocation of the code in question where it took another branch; not to mention the potential troubles with parallel execution, which is not a real concern these days, but we're designing for years ahead, and someday it can be). Memory leaks, too. Our completion pipeline has multiple interchangeable/pluggable parts, so we have to be on the lookout even for problems which do not reproduce with stock Emacs, and that requires solid abstractions. And speaking of "only private properties", the completion-score property can be used by downstream code, with all the associated potential for trouble. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 13:43:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Eli Zaretskii , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291213266019 (code B ref 48841); Mon, 16 Aug 2021 13:43:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 13:42:06 +0000 Received: from localhost ([127.0.0.1]:49025 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcsP-0001Z0-G3 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 09:42:05 -0400 Received: from mail-pj1-f45.google.com ([209.85.216.45]:54162) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFcsL-0001Xp-Kg; Mon, 16 Aug 2021 09:42:03 -0400 Received: by mail-pj1-f45.google.com with SMTP id j1so26563685pjv.3; Mon, 16 Aug 2021 06:42:01 -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=JB2/qZP1S4rAp75M/+Afkq6jb97NXO4w7kLkGR+djWA=; b=Yu2KcewzKG/qJlN0SihwCY7y+vysP54IOuKDS1OtJoTmyJ5QbHu8KwmmqbcSLaBH0Y vIpZacV4rnocvYuWOwF2pKRd5iCSmpD03ZiqKxTsDHx1p6fU7aN451kt2gDmFPmwRr/Q w07ERlwnkDVHODlxIwGoiwmAjVmM//RwSf/l+zvy6uI00hFAohDdC5VVKSGx2oKyZU+s hW01rux4d+a3yO3x0iLOu7Fozq9QdHkPJYpdI485/2Gt7DbRrHnxaRuTNpIBcfvrXSvL L5mqdU+Jir5x1GIh7VF7RZmwCg/74esiRNUl6IhERyfW7I0wF9Mnne3+7dWmAPwkCDo+ zLqw== 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=JB2/qZP1S4rAp75M/+Afkq6jb97NXO4w7kLkGR+djWA=; b=DiRTqQ3LsdNDDqeCJkEjliIjHe+iliARb7CpltUjTVZ2kN4ZMrknQl6yhq8/WgmjRc ctpRAGEDhTYhxoyTn6mzD9R8l172xopveBjJQUEzleX+8mZZf8+3sT98gIK1ShZdv+0t c1e3kTOn2skcJ/Zxt8MqRRascJvVRo9RnUwD94qrdPI7ufpIp7ywAaE35JAGdKDtsXmY nCxOlEG9Mvqb+CAvPwFVFbT82Py8zgOgCvAM6fPCEamNRuGQ3eaywl86mRohKfsJ3ag+ lqi2bsVH6mnAD3t+rqFtF1a0y/ddLL9paCV+tMn27NQQWA3ac21Jt+L/Mt9/b5lbS3Bp y36w== X-Gm-Message-State: AOAM532XS5BhQp3s9lv+EinSmR3b2KHUuNXoR3o6aaSJ1ldhOQBwAAmF HlzUh3KZFmAT3r0jbZdis/tZBpU8iUHR3jaFu/0= X-Google-Smtp-Source: ABdhPJyePzhalqU929+kNUL5zmDJQwM7w+KfJDSztpA6kDzQ14RSTMdRFTJBW6cacsd8RedD0Smev4B6CV25zspzL34= X-Received: by 2002:a05:6a00:164d:b0:3e1:ab35:f3e4 with SMTP id m13-20020a056a00164d00b003e1ab35f3e4mr7474897pfc.42.1629121315603; Mon, 16 Aug 2021 06:41:55 -0700 (PDT) MIME-Version: 1.0 References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> <83tujp8vd9.fsf@gnu.org> <769c0ee0-6d6f-6177-7929-1ac4ada30951@yandex.ru> In-Reply-To: <769c0ee0-6d6f-6177-7929-1ac4ada30951@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 14:41:42 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 2:38 PM Dmitry Gutov wrote: > And speaking of "only private properties", the completion-score property > can be used by downstream code, with all the associated potential for > trouble. That's true. When I created it, I meant for it to be private, I think, but indeed did forget to mark it as such. It is not documented anywhere but that hasn't stopped anyone in the past it, indeed.Can you point to place(s) where it is indeed used other than the flex machinery of `minibuffer.el`? Thanks. Jo=C3=A3o T=C3=A1vora From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii , Daniel Mendler Cc: larsi@gnus.org, 47711@debbugs.gnu.org, joaotavora@gmail.com, 48841@debbugs.gnu.org, monnier@iro.umontreal.ca Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912242117608 (code B ref 48841); Mon, 16 Aug 2021 14:01:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:00:21 +0000 Received: from localhost ([127.0.0.1]:50652 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdA4-0004Zr-Mi for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:00:20 -0400 Received: from mail-wr1-f49.google.com ([209.85.221.49]:44878) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdA2-0004ZZ-9o; Mon, 16 Aug 2021 10:00:19 -0400 Received: by mail-wr1-f49.google.com with SMTP id x12so23770232wrr.11; Mon, 16 Aug 2021 07:00:18 -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=TRh/MX4EmZ66FHgFcppaqwOteymb1PkCFqcfL2chujM=; b=nc8WsBVrgLM7Wg59v/X/yVkCG2OfyyIRx/PpQksHaIid1Vq9sPXVm9PjXGiYRCYg1n xd21Ticr7+zaFBi3Ld7zN1osRzc9PQvAUCtyZtsUQf7ob+5YCwt7scHA9hi0Wu4pa+v1 18avkACqPKi1T1PU9zBgquM2nXDjDSHPhRqd499obNVYgujJVw3v7Ltkyn2iiqXdZJjI l1hsJrlLpN0KsEA9220uwl57J6w090jMy0/Pw4ZyIh27E6fd8090J+3ZbSa7nif0utAD uyAzY1eTH/eeQUri+8D3Kw1+XtyF8eGOsvOiefpt6bXROUFIpYhE2MBvpyX5agjhXGBO qgZA== 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=TRh/MX4EmZ66FHgFcppaqwOteymb1PkCFqcfL2chujM=; b=E0CWZgdro8+W8iExYu5VNRkV+6zhi7TIwWX2o3sKZHvnF8PYYDjxstQ6Ls3FOMWFRP 6sb1RCc5CmZsDnEzNjuBLr3PvZpO+6dQiHwedzZ5cnu7Bad8VvoIVd8SOlTrESeCqF7K hFBqf1pdnjx8qXd4JMmENqlkjIsYTbdI3jrtxWuvvsw1Zp/OGv4xeKZKe5cJZgWuEuRX bzxZ6A9RWwH1LqwMRZJuyqsVy7/PBW/Wt1RU9vNLIeMhtmtDGavkBsWQZ/FNpR7WxQUy 57+/iYv+iiRk01XCux7M2dXwm74dlCp19Nstf3uQFWFzJk8znFS83VfcD0c+7Fi2o5/T yh0Q== X-Gm-Message-State: AOAM532b05QFkVCvIDZ7mul2xvv2j0JjbSqlJaJcMP1fMGgFJdMnxcee ArAQup7hthN2SzlasL7T2SzK78M959g= X-Google-Smtp-Source: ABdhPJwkiy4M0IJtYn95Q8/m/tfWfaY59QCabBgr3N1AqLNUuCiXa+Kfi5NmDtUY+Q6aUSP7Ubx89Q== X-Received: by 2002:adf:e551:: with SMTP id z17mr19265734wrm.40.1629122412318; Mon, 16 Aug 2021 07:00:12 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id a11sm11840585wrw.67.2021.08.16.07.00.09 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:00:10 -0700 (PDT) References: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> From: Dmitry Gutov Message-ID: <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> Date: Mon, 16 Aug 2021 17:00:09 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <83bl5x8r02.fsf@gnu.org> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 16:21, Eli Zaretskii wrote: >>> FWIW, I also don't understand how adding properties could cause a >>> memory leak. When a string is GCed, its properties get GCed as well, >>> all of them. Am I missing something? >> >> If you add string properties to all symbol names this memory will stay >> alive for much longer than necessary. > > That's a very extreme example, something that I wouldn't expect a Lisp > program to do, without removing the properties shortly thereafter. And that *will* happen with Joao's approach, as soon as some package implements a Lisp completion backend in a certain (legal) fashion. Or using one of a few different fashions, actually. > And even that isn't a leak. > > Note that we already put all kind of properties (although not text > properties) on symbols. Those do not, generally, change over time. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:15:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912326719026 (code B ref 48841); Mon, 16 Aug 2021 14:15:03 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:14:27 +0000 Received: from localhost ([127.0.0.1]:50686 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdNi-0004wj-OU for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:14:26 -0400 Received: from mail-wr1-f41.google.com ([209.85.221.41]:44864) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdNe-0004wO-PC; Mon, 16 Aug 2021 10:14:24 -0400 Received: by mail-wr1-f41.google.com with SMTP id x12so23837150wrr.11; Mon, 16 Aug 2021 07:14:22 -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=QTEyYe7K0+Gh4xuATzEdO6A0e9+ClkEvPjO10gMLepE=; b=pkzpEeHI25hLjuuJLJ4Mk/ryWGYpIuM2XUWDH6CFOhexjCteO8vY/h7AWhmXUX9vyE st4KDl/j/BjNXMWJiFcJTxbGgoJmLkoP3+6icajMCWaXvJEmHf/L9tul7kd5dr/fn8hK 7sB+PgTre/qmDxAHOr5QGe4IbMg1EmZVOcI/VsDAUvzHHPvcsNEC/2aUVHkhGLShXXhO VAHoGJw7UOVQXvkibw8ZmNjI/maTXMK2rMW4xEMDdudS8vW17lsoF9EzsIIT1v8Zwx43 MB4d5yMf63BI5cb2vc+94w84lXeerZA5axKrZFh96CWkTMYJXTBRmhHBgPYvAFSdmkl4 3HCQ== 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=QTEyYe7K0+Gh4xuATzEdO6A0e9+ClkEvPjO10gMLepE=; b=YZGzH/yEG7l1rzdm/BZK5BIsm2WCFBQUk8akBRLAVEIIxGJ7fpcfo8KjNQ/sPH/i4X k/ML2mDdaW0+Tizv1Bc2aM2gz3C6sNkA4aUwWE9MyIhryBmebRZHrpEfpgaRGFhOtLLs B9Pjd4mnjdgin1++2skVxlZkZ1v7Yttyg3pg9JJz10SAqAWxWUNgYzMDJ7tm4kMr7f6E D/5Xh9aqiby16rJaq+IZoBhI4+2Zzdotm53lo2Q+YG8IxXyF59Xz30JD7ek7bU9+kUfj 0kDXHGum/Rhr123R+xnBxrMTyLJbyHU0Jx6vheTVCE1SiFBL49JulueJrZlmgSAmw+U4 tUSw== X-Gm-Message-State: AOAM532tnGB3vcPM0UUaH8sdgqUXiIcfkA43JiudjtjIWD3kYihm6W54 /W2f3Ed9ZLTl2NSQKRfQUyi2OpCKzCk= X-Google-Smtp-Source: ABdhPJyHIWnlJOPAlmmmuBrqk/1fXrEbXIf7CLGv3TGnr56xH3TKBFnAzn5F/LgUuR/cwHCpGjpF4Q== X-Received: by 2002:adf:db83:: with SMTP id u3mr19327638wri.363.1629123256841; Mon, 16 Aug 2021 07:14:16 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id h12sm10786701wmm.29.2021.08.16.07.14.15 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:14:16 -0700 (PDT) References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <31da8f43-02f7-e6dd-ab38-2160af138a4a@yandex.ru> <83tujp8vd9.fsf@gnu.org> <769c0ee0-6d6f-6177-7929-1ac4ada30951@yandex.ru> From: Dmitry Gutov Message-ID: Date: Mon, 16 Aug 2021 17:14:14 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 16:41, João Távora wrote: > It is not documented anywhere > but that hasn't stopped anyone in the past it, indeed.Can you point to > place(s) where it is indeed used other than the flex machinery of > `minibuffer.el`? Thanks. Try either of these: https://github.com/rustify-emacs/fuz.el/blob/master/helm-fuz.el#L228 https://github.com/emacs-helm/helm/blob/master/helm-utils.el And I'm considering using it in company-sort-by-occurrence, to make sure that flex sorting is at least semi-honored there (or create a variation of that transformer). For that to happen, the possible score values and their meanings will need to be documented, though. The main scenario (and source of the completion-score property) I have in mind is not related to fido-mode or flex, but the users can always put flex into completion-styles by default, which affects company-capf. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:21:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912365919641 (code B ref 48841); Mon, 16 Aug 2021 14:21:01 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:20:59 +0000 Received: from localhost ([127.0.0.1]:50698 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdTz-00056b-G8 for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:20:59 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:33449) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdTr-00056D-4m; Mon, 16 Aug 2021 10:20:51 -0400 Received: by mail-wm1-f43.google.com with SMTP id a201-20020a1c7fd2000000b002e6d33447f9so86640wmd.0; Mon, 16 Aug 2021 07:20:47 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=Q3zK+7/1DJLNkrgytux3CwuqtrXlG4P/nZ9MLv0C3rI=; b=q4ZJFDL5eGfX2CRUdiokAWiTFfpZX6sdfZG1Bmol2X32LXvsGO4PgHunFx9OOCHMHS hhubbq4S3qwKaRRg/VyUZt9Ne+B2SHSoye5ikVnpum0MYQ0tQ0Rh5/GKPyVnuupSOb6e N1o/xtqh48zuYcZ7mNcaSDJnIR1wXIKl73LW5XqUkITVc83o1qg9g8Pn+F1roNEriOjn NAaeQZGuTTRn/TkZWDUHWh2HWH+FFsIITfBezL9tR2HdvmDasEKjYPBZTUOtsE8cT2FQ inb/y1q0XRpIY++lQiMbWL/yfnKVLvzTX/jQzP4RTRU9lI59T7XJy2pnLa3G6EFFSzfK Cpfg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=Q3zK+7/1DJLNkrgytux3CwuqtrXlG4P/nZ9MLv0C3rI=; b=orBlOMDWSYSokVJeNicx1REH0HCxNGdkDIKwnjgCsAO80QkVLWDg+jzGQIGJduIhcP Wy2PXzj6DX3usChzpEIOfhic4SrAa5m0yD36s2RaPQFXnv1PQE43r5blMd0eTmthw3Z3 XTEQtcIeMoJ8aG9xoGY0a9iMY4kZiI5+CYBa0XnkL1cNOfABRLrfXgK0BfeeaHqdR8W/ W8FwJoXE9QZSVk7OmagF5BfetRBGA3hJvdHkHN3GSl8WYw0VHyTeI7aYwy61WH93MwA3 jCl8gSDKXP1rJDb4OGOjKKLhBvm3wSjA87cXlwhRx+XVmlheySzbZM1G3X7QYAtEh74F gGnw== X-Gm-Message-State: AOAM5326udjmBnS/FhmgIqVlf2bBHnFksidk0ipJAv/WMWJBkEqSyloS lJ0MJuGRwlQ5c6v0QgiZkLRpVrJ0VgA= X-Google-Smtp-Source: ABdhPJw5NZ8vcICaa27Insw1jRBGjjyzCTgnp2FYPaKhpFVm7go25OInr9NoQswLu0r8eb97wJ6smQ== X-Received: by 2002:a7b:c005:: with SMTP id c5mr15424096wmb.59.1629123640952; Mon, 16 Aug 2021 07:20:40 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id n3sm11414236wmi.0.2021.08.16.07.20.39 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Aug 2021 07:20:40 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> Date: Mon, 16 Aug 2021 15:20:36 +0100 In-Reply-To: <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> (Dmitry Gutov's message of "Mon, 16 Aug 2021 17:00:09 +0300") Message-ID: <8735r9ii8b.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 16.08.2021 16:21, Eli Zaretskii wrote: > >>>> FWIW, I also don't understand how adding properties could cause a >>>> memory leak. When a string is GCed, its properties get GCed as well, >>>> all of them. Am I missing something? >>> >>> If you add string properties to all symbol names this memory will stay >>> alive for much longer than necessary. >> That's a very extreme example, something that I wouldn't expect a >> Lisp >> program to do, without removing the properties shortly thereafter. > > And that *will* happen with Joao's approach, as soon as some package > implements a Lisp completion backend in a certain (legal) fashion. There is no leak, not in the strong or weak sense. There is a constant usage memory footprint proportional to the size of obarray, yes, but the factor isn't huge. From the top of my head, I think it's about two conses and a fp number for each sym. does anyone know how much that is or can teach me how to measure? Thanks. Anyway the current situation is constant copies of strings that put pressure on the GC, as the benchmarks show. Anyhoo, in the interest of placating this string property bogeyman, I've prepared a version of my patch that is based on weak-keyed hash tables. Slightly slower, but not much. Here are the usual benchmarks: (defmacro heyhey () `(progn ,@(cl-loop repeat 300000 collect `(defun ,(intern (symbol-name (gensym "heyhey")))= () 42)))) (setq completion-styles '(flex)) (heyhey) (when nil ;; Press C-u C-x C-e C-m quickly to produce a sample (benchmark-run (completing-read "" obarray)) =20=20=20=20 ;; my patch with private string properties (3.596972924 4 1.125298095999998) (3.584963294 4 1.1266740010000014) (3.4622216089999998 4 1.0924070069999985) (3.565632813 4 1.1066678320000012) (3.456130054 4 1.099950519) (3.49538751 4 1.1085273779999998) (3.4882531059999997 4 1.0928655200000001) (3.526581152 4 1.0909935229999999) (3.710919876 4 1.13883417) (3.576690379 4 1.09514685) =20=20=20=20 ;; my patch with an no string properties (global weak hts) ;; Probably the extra gc sweeps are paranoid cleaning up of the ;; hash tables. (3.981110008 7 1.6466288340000013) (3.819598429 7 1.5200578379999996) (3.823931386 7 1.5175787589999992) (3.9161236720000003 7 1.6184865899999998) (3.835148066 7 1.5686207249999988) (3.791906221 7 1.5481051090000015) (3.798378812 7 1.5164137029999996) (4.049880173 7 1.7670989089999996) (3.716469474 6 1.3442434509999996) (3.422806969 6 1.3272816180000002) =20=20=20=20 ;; current master (5.405534502 12 2.8778620629999994) (5.038353216999999 12 2.553688440000002) (4.94358915 12 2.4917956500000003) (4.950710861 12 2.4638737510000013) (5.0242796929999995 12 2.5226992029999984) (5.020964648 12 2.495171900999999) (4.914088866 12 2.4218276250000024) (5.003779622 12 2.502260272000001) (4.969347707 12 2.4814790469999988) (5.376038238 11 2.565757513000001) =20=20=20=20 ;; didn't bother with daniel's patch as I've already shown it to be ;; about 10% slower than current master. =20=20=20=20=20 ) The patch lives in the branch scratch/icomplete-lazy-highlight-no-string-props. It's a bit more complicated to follow, but not much if you understand hash tables. The interface to icomplete.el is completely unchanged. All in all, still a very good improvement over the current situation, and I think I can make it faster. (Though really do consider Eli's arguments the fastest approach) >> And even that isn't a leak. >> Note that we already put all kind of properties (although not text >> properties) on symbols. > > Those do not, generally, change over time. Neither does this one! At least in size, which is the thing that matters. So in terms of "negative" consequences it's exactly equivalent. Read the patch it will be obvious, I think. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:27:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= , Daniel Mendler Cc: Lars Ingebrigtsen , Eli Zaretskii , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912401520198 (code B ref 48841); Mon, 16 Aug 2021 14:27:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:26:55 +0000 Received: from localhost ([127.0.0.1]:50703 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdZm-0005Fh-Nl for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:26:54 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:55046) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdZl-0005FG-6d; Mon, 16 Aug 2021 10:26:53 -0400 Received: by mail-wm1-f49.google.com with SMTP id g138so11696540wmg.4; Mon, 16 Aug 2021 07:26:53 -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=sMEkiRq9ciWt+FPYy3cM0scH+z6bE93cpI/bIhDmE0g=; b=FQZoaZ1sThmU01FKL8HRaeGtyI5SfqcEUjPk8DJyLvT5TKy4hjXMhvY54tKaYqqC/w /Xwmqnrm7LBgLE4AXiarBQwQ5N17DoU8nFuTqQcMhMRi+hsr1lTcumaD79L4U2NEXsdG wxIRw7zqDKs5DwKnN7olruQJpTCkmMXYnVd+Tz8GptJLCbqx3pGBfoJdvmLoyn/M2exa Nyzb5OttWzu3xuvIqT8lr2Xwf5LUoktsFWMfKswhHIa14rdN4ulysdhTcww8DldHuMmz RLJW7aEDuSI/TGICXOSOVTAtfViH6vCAZe+lpv3ml+FAP4eRc8sCWDTe8ytqbOjBbS2c fhnA== 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=sMEkiRq9ciWt+FPYy3cM0scH+z6bE93cpI/bIhDmE0g=; b=JSp9XAmv9U182r3CCZ4JC6cAV5W1dQU9xGvL1rbKkVe7sran+bYbF+HkI3JfZ/Qt9U T0ywKkzstKNpNg2SidzuBn4KfEncscheNrVFa0NxLHajQS7VFNWDNjR13SJ3MPO9Ts/2 dcyt2aHLLsRGW1NeK36sDBpAzCOGdlF3sHHKc57DYCOtVi5nrrJ6Vk4xTDV4FLjkDTko I9GFh+A3KoMS2AjOErRz6B+fUorN+iD6qCk9YkIkUZ24gliya63/KE3xzo78SA2Mx6S3 G+9hPld5zgsn6A88JKwocDtYf3/O/zFulufGmqTyxhTJV6dZRy4ivwq97tJ2W7bwQz5X qh/g== X-Gm-Message-State: AOAM532hq7BncJFnR1Ghsv/1yU5pNxmoTB5Q9tulU5RF5t8w1BMN8lls hwk69QbzY9jL5zkOMkI/GqU= X-Google-Smtp-Source: ABdhPJw9HkNWrkTbtNMBDcH9FexTi5qO7xptULAMSRWYn4jvYzfyLXBU63JMwurKUL/n3EORgTmP6Q== X-Received: by 2002:a7b:c2fa:: with SMTP id e26mr15753217wmk.102.1629124007391; Mon, 16 Aug 2021 07:26:47 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id f2sm11880151wru.31.2021.08.16.07.26.45 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:26:46 -0700 (PDT) References: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> From: Dmitry Gutov Message-ID: <724345d2-a87b-064b-7ccf-b4ac2b66cc8d@yandex.ru> Date: Mon, 16 Aug 2021 17:26:44 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 14:37, João Távora wrote: > I am not a native English speaker, and maybe you don't understand > my language. Another way to explain what I am talking is to talk about > "bug reproduction". You say there's a bug in my patch, I am asking you > for a "bug reproduction recipe" as defined by most, if not all, the results > you get by searching "bug reproduction recipe" in the Google search engine. I hope you, or at least other here, can someday see and understand that asking to prove standard engineering practices from the first principles, time and time again in various discussions, is not a way to encourage good atmosphere or promote project participation. Are you really not imagine a buggy scenario coming from a combination of downstream uses of 'completion-score' property, different completion styles (some setting it, and some not), and a completion table that either uses global string values outright, or caches them for the duration of the current command? From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:31:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, Lars Ingebrigtsen , Eli Zaretskii , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912422020668 (code B ref 48841); Mon, 16 Aug 2021 14:31:01 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:30:20 +0000 Received: from localhost ([127.0.0.1]:50713 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdd5-0005ND-Ol for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:30:20 -0400 Received: from mail-pj1-f41.google.com ([209.85.216.41]:44010) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdd3-0005Ms-E0; Mon, 16 Aug 2021 10:30:18 -0400 Received: by mail-pj1-f41.google.com with SMTP id qe12-20020a17090b4f8c00b00179321cbae7so280594pjb.2; Mon, 16 Aug 2021 07:30:17 -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=6gCp2MWkyrOJTenj/gaPXra0uN7FZ0nNTmOza/+qVsI=; b=lzBx9LyacYo6GTONb6OG/EiRBXB6jmpUxfDbe+MQcEWX3oqdOZM3y1Mu+cS6IhxKHb LkKwYcRsKPEmFeKFFHvBwf/hSliFZmBvaHueNn6EEzgqwPa7QcHKPS0huJ8uTjUFUAYC 0UUpIi7GcQQBVzRCJiYBawRxXU9YdIEV/nIFDNTzsColOtyIY7PBowWfXgQG/dD1xPPT gL7jwrysclqNAl/ZkbVE4EZ/VzoaWkYSGYpwIR8fSMSXxhA1W8kxdi3VQJiAD/CPmw19 extC4cg10qBiwT0BeJEIkRXPTyfMx0kdISDEbKyqgIEvHNuWHyWf7YoXBp/TCXztw+HP 1Lsg== 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=6gCp2MWkyrOJTenj/gaPXra0uN7FZ0nNTmOza/+qVsI=; b=amFpRnBtz5fE97BWdGdcOpgjlAIAFNz9kavWl1uludqVKbHgLxDVHgWKeRyI13rJdr D90o3/aMuXR95fH54AfuRA99Wh1tqsSxBnCN8zszKvMK3h2RfuaBM9zk8lxPf+KYjpVu sCKVzlJslqEVX0XjYwy38/tx3LbZ0+rzb7WSlFo0x8esPQpZe1nZxfuoe2jPkGS/9QHk MszPgbl6wGjoMD1AZF28XfwUsoKtVQpRNAi7hmXf6iX9TP7l+itAe8u5f1SA2TchWyQM ZnStLL4DhR8Jj13E8mPtn4EXzoaOivt8JYIeVs65TME6m9X59oVaUn1+CKknEnXliOjK pC0g== X-Gm-Message-State: AOAM530OQqcNmLmKsePJv5NQ7Oq+NZH4z94K7DrRzZGDj25GvhLJiiQW dnmL9s74OCejTeVnCjB8cOfAlq2DprtJvM9SXe0= X-Google-Smtp-Source: ABdhPJwTdogs3r4e6mUHhd+5hHpBbqySsUMfev3EkDgq8pw5pqXZJECoHZXwISGxqEAy8hsfKh7nh2pyqNFtX6k4ohA= X-Received: by 2002:a17:902:d487:b0:12d:89d3:a6b with SMTP id c7-20020a170902d48700b0012d89d30a6bmr13674772plg.52.1629124211514; Mon, 16 Aug 2021 07:30:11 -0700 (PDT) MIME-Version: 1.0 References: <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <724345d2-a87b-064b-7ccf-b4ac2b66cc8d@yandex.ru> In-Reply-To: <724345d2-a87b-064b-7ccf-b4ac2b66cc8d@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 15:29:57 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 3:26 PM Dmitry Gutov wrote: > > On 16.08.2021 14:37, Jo=C3=A3o T=C3=A1vora wrote: > > I am not a native English speaker, and maybe you don't understand > > my language. Another way to explain what I am talking is to talk abou= t > > "bug reproduction". You say there's a bug in my patch, I am asking you > > for a "bug reproduction recipe" as defined by most, if not all, the re= sults > > you get by searching "bug reproduction recipe" in the Google search eng= ine. > > I hope you, or at least other here, can someday see and understand that > asking to prove standard engineering practices from the first > principles, time and time again in various discussions, is not a way to > encourage good atmosphere or promote project participation. > > Are you really not imagine a buggy scenario coming from a combination of > downstream uses of 'completion-score' property, different completion > styles (some setting it, and some not), and a completion table that > either uses global string values outright, or caches them for the > duration of the current command? I don't. Please prime my imagination with some illustration based on your fertile imagination of these things and the patches I have provided. Oh and spare me the lectures. Thanks. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:34:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912441220969 (code B ref 48841); Mon, 16 Aug 2021 14:34:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:33:32 +0000 Received: from localhost ([127.0.0.1]:50721 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdgB-0005S3-Jo for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:33:31 -0400 Received: from mail-wr1-f46.google.com ([209.85.221.46]:44708) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdg9-0005Rl-6Q; Mon, 16 Aug 2021 10:33:29 -0400 Received: by mail-wr1-f46.google.com with SMTP id x12so23930221wrr.11; Mon, 16 Aug 2021 07:33:29 -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=7yhkRd6f073YFMR5goDbFsS2fzyvIVrl94x/SsJzrBg=; b=DY50Iid1Sbj2GK1mneKSFMOsR+9XsulzGyPciOTRvzyaHaUnuYgT5vGlUWgZZmI1dy 4swb/1o5E76ywfkXBcHk2Nkqv3xUJIZioPA323JMbV6uox8gW32xN7aP5VNXC+1ED2wZ SIPrO14fbQ2xB7XHHOTBO8/3yLADLP+MfXtGGj2fOSu3O5/V4gaI1hM3PIZme1+LRSE+ Lpun3UAf8nLGSjofB0sy/+NayRhvlTxnxk+NCq0YftQ0Eydd8cfsh83xSgBnUEqwLTvO 3+0HJ31QLtknj/2c+FQUKnoXUrkxy4wYGh3TWrBKojD4vf/IA0msCsZoJGQuoeiobN/6 73qQ== 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=7yhkRd6f073YFMR5goDbFsS2fzyvIVrl94x/SsJzrBg=; b=bY54YElHTygTqe2u5xqJiMHv+r7MmlLLBnr/Jf2vXMh89A3XUMMW0JEtR5lbFMv0uV tsUPADEjOzIxQXfHsmJQqdV4TqfoKVTUJcq8Ep3Io+HCNF25i+6StAmr25SH0WlLgT7q SD6LnoPtHResdG5NzJbNcQlLY8bpSPeIu4J77Fj009VkfNnkDM7Wlq/m+PqWAFJR4by+ 6/6xnsylrhKW2uTArEgzceUq6sw85LiwlbRD/09dL91RE97x6wJ1w6/jWDqiCYhaqHtd pjEB+hRvqj9amkoiD4UKgeQfVXz8ewBdvQetPI47e7TEEYC6OfKOaUi0ryC6ibgfQLsy aSig== X-Gm-Message-State: AOAM533gFxpZ8XbhKk22ZelOUIBJLla54+MXCrilu7a6i9StmhTitPGI cn4KcJlCLb+mD06aEWPEQNS1ul54d24= X-Google-Smtp-Source: ABdhPJye/8ZNsPClneQzyydQRGpxAx4fmWBC0WlxNewFmwuGeLmb5UpSaleWrGePWNb8/hgkaGFOqw== X-Received: by 2002:a5d:6642:: with SMTP id f2mr11836658wrw.278.1629124403311; Mon, 16 Aug 2021 07:33:23 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id n16sm11867571wru.79.2021.08.16.07.33.21 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:33:22 -0700 (PDT) References: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> From: Dmitry Gutov Message-ID: Date: Mon, 16 Aug 2021 17:33:20 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <8735r9ii8b.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 17:20, João Távora wrote: >>>>> FWIW, I also don't understand how adding properties could cause a >>>>> memory leak. When a string is GCed, its properties get GCed as well, >>>>> all of them. Am I missing something? >>>> >>>> If you add string properties to all symbol names this memory will stay >>>> alive for much longer than necessary. >>> That's a very extreme example, something that I wouldn't expect a >>> Lisp >>> program to do, without removing the properties shortly thereafter. >> >> And that *will* happen with Joao's approach, as soon as some package >> implements a Lisp completion backend in a certain (legal) fashion. > > There is no leak, not in the strong or weak sense. Eli already said that, in a sentence that I also quoted. And still: "I wouldn't expect a Lisp program to do ". > There is a constant > usage memory footprint proportional to the size of obarray, yes, but the > factor isn't huge. From the top of my head, I think it's about two > conses and a fp number for each sym. does anyone know how much that is > or can teach me how to measure? Thanks. If we say that your approach is legal, those are only "two conses and a number" coming from minibuffer.el. But since other packages will also be allowed to do that, the factor will only be limited by the amount of installed packages. > Anyway the current situation is constant copies of strings that put > pressure on the GC, as the benchmarks show. > > Anyhoo, in the interest of placating this string property bogeyman, I've > prepared a version of my patch that is based on weak-keyed hash tables. > Slightly slower, but not much. Here are the usual benchmarks: Cool, I'll take a look, thanks. >>> And even that isn't a leak. >>> Note that we already put all kind of properties (although not text >>> properties) on symbols. >> >> Those do not, generally, change over time. > > Neither does this one! At least in size, which is the thing that > matters. So in terms of "negative" consequences it's exactly > equivalent. Read the patch it will be obvious, I think. I was talking about the values of the properties, not the size in memory. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:38:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, Eli Zaretskii , Lars Ingebrigtsen , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912463121313 (code B ref 48841); Mon, 16 Aug 2021 14:38:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:37:11 +0000 Received: from localhost ([127.0.0.1]:50726 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdjf-0005Xb-7K for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:37:11 -0400 Received: from mail-pj1-f46.google.com ([209.85.216.46]:37715) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFdjZ-0005Wz-Qu; Mon, 16 Aug 2021 10:37:05 -0400 Received: by mail-pj1-f46.google.com with SMTP id cp15-20020a17090afb8fb029017891959dcbso32760865pjb.2; Mon, 16 Aug 2021 07:37:01 -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=5PAeg9RsNGdHlZZkjv/EqP3UgGZjKj40G9my239+9iI=; b=I1M5PacNzqw2YsE+1EelLTLzWsDpFHSKMKBXh5YJoCOTS85fJrr8Hzmdzb6FUI+G1P b9il8CMoZuh8vE/Zv8BS2w9Q2QxxGsaXoixlB7+AXASnw93mq7+57aCHJpM3MDI/h1P5 XmNDOZE0xjYoexXKw54ahVihGbUSeXiRj6fVUFFBfAEhiiwChJTcunvS++2YKpqN642z mEUI+MUZFC3Qa2YREg1x3RkNQhJ5grGjqdW304SdO9TOPhmaDkBfkAb5Q/x2fNQzXVsZ bS/BJL6Dj7Kxo8VzhDUiSx+OTPMKCzqCpiuK/lVT1+xhtW0ctX1bhfuqiW9vVamRCfBo FNSA== 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=5PAeg9RsNGdHlZZkjv/EqP3UgGZjKj40G9my239+9iI=; b=Zb5v73tfxcPJPkAQplhRNi0jGlLvlJYDOrKhMliKVRg9b2nVSWTT9Kg78SZeLtnssc UaLT6FawEWFoNwdaTpc2FN6taGX87nq2dYh5ytUXcmKyITJBvNJF30hl5ImPIah6wcn5 WfPb9FVpmhx+8QS1Rmkr63brJLv1J5xtd6zVM3t9bhT/GefZYxj2EVef2T3HLx1m3dg5 5IKjxPGdZUS/U9bee3v4qNkfduI6+4ILzHsinis6cgM0k/SXsiwHjA1taEQQjFz6pThZ 9gZvZSEWxGCqZe18CmoghLU9xaIEEQkDA+kSrFg4/jrFwgQVZWeeLcOLKSd2jTs6C0Lu QkFA== X-Gm-Message-State: AOAM532yTF7agIy/Vw6xRJ09xlN1nKjFh0wZYaS3lpL63vzKeZbIPJHV m0HM+JFCP4FQ04SHMWnquyfScoJSXunCsfgLbyI= X-Google-Smtp-Source: ABdhPJybZKjkYF+cqnVxXra5q7YDqJ96+OX2Fgc2nCaRioja0ZeZ33DA5MU7nZlNU4R3ohdOwIrACLOsy5423NnafQw= X-Received: by 2002:a05:6a00:164d:b0:3e1:ab35:f3e4 with SMTP id m13-20020a056a00164d00b003e1ab35f3e4mr7708732pfc.42.1629124615984; Mon, 16 Aug 2021 07:36:55 -0700 (PDT) MIME-Version: 1.0 References: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> In-Reply-To: From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 15:36:42 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 3:33 PM Dmitry Gutov wrote: > I was talking about the values of the properties, not the size in memory. Then what's the problem if the value of a property that is an implementatio= n detail changes? What do you (meaning the user of Emacs) care, ultimately? Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 14:49:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , Lars Ingebrigtsen , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162912528922348 (code B ref 48841); Mon, 16 Aug 2021 14:49:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 14:48:09 +0000 Received: from localhost ([127.0.0.1]:50735 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFduK-0005oI-Vi for submit@debbugs.gnu.org; Mon, 16 Aug 2021 10:48:09 -0400 Received: from mail-wm1-f44.google.com ([209.85.128.44]:38573) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFduG-0005nc-6p; Mon, 16 Aug 2021 10:48:07 -0400 Received: by mail-wm1-f44.google.com with SMTP id i10-20020a05600c354ab029025a0f317abfso15241518wmq.3; Mon, 16 Aug 2021 07:48:04 -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=NhrkOvKUJICVjl5xDDw9F5RjRHGoP+9qoG17RMwuO/A=; b=RPFZcPJnmriAa8B/h8FyJhr3VSWCPPfeMWdULSQQ5PniNJq/6GPyhsqi4CZKKa+IJb EAB03TbgxV0guqGIUQvpKlC8kwvEj60TceBNSxUT+XPXOD8XDzSNmsgvFHk3cTl2UiSZ OGqM3IQcf0bD5CwPJuq4nTy9oxHm2LJUUgL8w+fibEnyA2G+OaH5D0+u6rxDQlQnpTRI /VGqrVPfzidCVOgv0dCJKCXb0VZLBZLfN4D8sRTkYFE5BDCAv7iw4towZBn7kFy7AGWw FJniXCw2M2APT4ty9cuFWRTenQIT17QdiRFiOkkSx4PnRnt+AEz/FXLFHDz4YpyJIiVo g4hw== 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=NhrkOvKUJICVjl5xDDw9F5RjRHGoP+9qoG17RMwuO/A=; b=Y4D+f9FCoWbQr673CHE37/eGFiVK0CoKEpzUJJp6eN2Kzdijesipsn/Q3AFAodIldl Hw5C0mhSLHsW6gioR2zBmf6iy4cIMJ0oRJWaFm9bA3S4kT0A4lz60sWp5a4jdF6oh7kX 8mUAitaYjyuZhcRITVXL2DpwbsVuhXlZ40r7kOpo/hAP1BSpuHNTmxwurLaIJTpV5aEU YszzKN1lHEDf2nVnqIrUDrNQx5nPZUgWoifzsFFbtiQU5OaKdTtspW5go05nUDXsHqRC ROiXGvyxndmbeNIJsN7AZr38GO+H6v0zizw7KOjt454jPVU937W8ozgufNg6cI4Nswyc FlSg== X-Gm-Message-State: AOAM531ZBCQacZUoUBWrZZ9P1GNKix8wYpkh7ud9K91pxYCwa3hjTDJw Bug85kcxr6LSJIl0H75ufETlW4SpLyI= X-Google-Smtp-Source: ABdhPJzA91feCktNb61n64WxgFD5Tv1PeB8zTHHL/1RfJMUKcrJ7h+BZiDLCy0YyCq9as/M+1ofC9w== X-Received: by 2002:a1c:f60c:: with SMTP id w12mr15582385wmc.3.1629125278336; Mon, 16 Aug 2021 07:47:58 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id b12sm14214564wrx.72.2021.08.16.07.47.57 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 07:47:57 -0700 (PDT) References: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> From: Dmitry Gutov Message-ID: <11bb7457-5b2d-e9bf-3f7d-b145a2df2d5b@yandex.ru> Date: Mon, 16 Aug 2021 17:47:56 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 17:36, João Távora wrote: > On Mon, Aug 16, 2021 at 3:33 PM Dmitry Gutov wrote: > >> I was talking about the values of the properties, not the size in memory. > Then what's the problem if the value of a property that is an implementation > detail changes? What do you (meaning the user of Emacs) care, ultimately? You said "we already have global symbol properties". I pointed out the differences. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 17:01:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , Lars Ingebrigtsen , Stefan Monnier , 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291332163272 (code B ref 48841); Mon, 16 Aug 2021 17:01:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 17:00:16 +0000 Received: from localhost ([127.0.0.1]:50858 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFfyB-0000qf-RJ for submit@debbugs.gnu.org; Mon, 16 Aug 2021 13:00:15 -0400 Received: from mail-pl1-f176.google.com ([209.85.214.176]:37564) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFfy8-0000qI-Vz; Mon, 16 Aug 2021 13:00:14 -0400 Received: by mail-pl1-f176.google.com with SMTP id n12so20738579plf.4; Mon, 16 Aug 2021 10:00:12 -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=qV2+/l5VR/pLQEvxmcp8xycIj/zsXEGyYP9xn5gGVe0=; b=GsAz05UoQg6/DplEU8NcUWhsWadwSKJcptzLN1jytc0gwfdIb0aVAfDpYNjVYY28G4 20aqCryTilZPdvGOg3Ha84LRnxDLzVktHJiYQrGDszWeVXi+lnv3fujLgJoAKX2tVv61 lCU7DAqhiajrTGVxFGSL7mM1ENhWI56bz7v/s3KpNg2+eDQxBeKjQqw/sN+GPwqNfK4z 9zdxhqPVjlOIqJUuh21ali4TfFsQKaJq5D6Gjd6lQDY1FBtWYauCs54+velwgYQz9EPb A65eLjfmiG6BYzzpHAwbRLIeKXVDgUakF9kuZS/TTHcKGw2tM79sIvHdz9t4J5s0WdNm v/+A== 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=qV2+/l5VR/pLQEvxmcp8xycIj/zsXEGyYP9xn5gGVe0=; b=ToPooqAPEKahoF83puli5fIycS+eA8km+WPN/zsWxGkHZSy+N+uhVsL4Q0bYKU1t5X xlHuidjBfpKLjBagf4JT+toFWVkrRL2j1xHUYkglOg2UxsKCYkAQuVJSY4gPWGaJDEJ9 yiBF5i6HidMhZ5d8SVTNqR36JLOALgoFKccPQUKXbC6qaA1Ub4qCACPE1KNCE6q+bTAH 4ulRzKbzsdK4UOYgSyjK/hpJceDG6pGL9hBrEJW6m2HYUainpXCQZfHlNQTR5OouCDnA utLwuFvIs7PGSzLRjNF1iKAlDotN3Ojn+UqCbgTaY4RFI1OPH0xVTc6buYzCGNjLg2G3 hMxA== X-Gm-Message-State: AOAM531LFXivk+lnNs0dETt75+pDQeCbYWuC/4WVFNMCDVWmTUnf/4ca TFFTByHZ/gTgflQaZh85VrXa2fOGYO0cjlJGMik= X-Google-Smtp-Source: ABdhPJzD08NqBBaeHKEjccg31U6XfOuxFKWgSurqoPsC5pMN1VIXBQ7BjByiY3xxe4timXWUTI9x0+Y7eF0NduqRrro= X-Received: by 2002:a17:90b:14b:: with SMTP id em11mr74388pjb.125.1629133206931; Mon, 16 Aug 2021 10:00:06 -0700 (PDT) MIME-Version: 1.0 References: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> <11bb7457-5b2d-e9bf-3f7d-b145a2df2d5b@yandex.ru> In-Reply-To: <11bb7457-5b2d-e9bf-3f7d-b145a2df2d5b@yandex.ru> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Mon, 16 Aug 2021 17:59:55 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Mon, Aug 16, 2021 at 3:47 PM Dmitry Gutov wrote: > > On 16.08.2021 17:36, Jo=C3=A3o T=C3=A1vora wrote: > > On Mon, Aug 16, 2021 at 3:33 PM Dmitry Gutov wrote: > > > >> I was talking about the values of the properties, not the size in memo= ry. > > Then what's the problem if the value of a property that is an implement= ation > > detail changes? What do you (meaning the user of Emacs) care, ultimatel= y? > > You said "we already have global symbol properties". I pointed out the > differences. Eli said that, I think. Anyway, it doesn't present any kind of problem whether their values of change or not, as long as the space they occupy doesn't. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Mon, 16 Aug 2021 18:26:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, Eli Zaretskii , larsi@gnus.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162913831412089 (code B ref 48841); Mon, 16 Aug 2021 18:26:02 +0000 Received: (at 48841) by debbugs.gnu.org; 16 Aug 2021 18:25:14 +0000 Received: from localhost ([127.0.0.1]:50954 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFhIQ-00038q-2Q for submit@debbugs.gnu.org; Mon, 16 Aug 2021 14:25:14 -0400 Received: from mail-wm1-f41.google.com ([209.85.128.41]:37427) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFhIM-00038Q-8B; Mon, 16 Aug 2021 14:25:12 -0400 Received: by mail-wm1-f41.google.com with SMTP id c8-20020a7bc008000000b002e6e462e95fso68660wmb.2; Mon, 16 Aug 2021 11:25:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=0BE4nTI0Dd3MVVLlpx1zJYGASsxUaJ4h6dDPWSlxDks=; b=IUmVH58Wlk5LXcC7cOXNmJmBG8dmNuqlPDZDNXrb+qTVGauEVYjXkZImXdgiJL4KWE WHaYKI2Z+vTXqNJxkfUWTtG6nnCvBJC357wpzaGEZ59xSx7BZymfQeA7++XLZWWlpeJg LbQLYABh53mNKF/tCToo9ge8uy1nySfm4wnBVu7ukyUKohwo4VW9iZC+KAWMUM9xpdEA vMAkUKO50+v5RKMzQdZ/EXbKyXjuloHyOuwYklBKyOacwG01+bad3Up6/i8Dgpw5aIh0 weD+G00ytsT+si218pf8/pLqhG6to9DpOI5BK3B7fa+1D74zTzgmkdlj2m+xvqjJsuZL mitA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=0BE4nTI0Dd3MVVLlpx1zJYGASsxUaJ4h6dDPWSlxDks=; b=LvNE67S4Pcz85buMgpdiTpsZBEThwMzWe/yu485N7UKBJzqTSUYpVNRpnSfBePwkWP pNWTEcgJ6MAh3376FFF2cIhLQ/jqYPCPj1Ks7eYyrH/B6QXZ+gPThiYFtlQ44dyzvJl9 Kn6s4JRpQKtAx9+ZewUv4+i02dSG+y1WedW1T6I5vkfQdt3OVxWmF/rGqC79ZrEcGR8m kJzx2kdqMIFDZ7kG8nheAgoV2kyoShp9HxMpelgXc2qZXhqvPA16mv7GYrTUF2D7qSal c1+HO3I8kjEaL35drnEg8sQCNVBspd44I3uK3gIp5Vua/gdK/pd+Uqo1SOtDbnWX2jOu LU1A== X-Gm-Message-State: AOAM530pJDiUpoVbdHDxTxieLeY2xHGUJ30cN5FKwG43xZVuGCEXxsp9 6t4X9LcvBdwFbL7YQmXUSYvZIKVJuNw= X-Google-Smtp-Source: ABdhPJyz1SX1npNmBM2hABJYxBnaAgGjAVWLvcpPufKvVmqnEmz12swhsQMV5sSQsQXecsNZq3YGkw== X-Received: by 2002:a05:600c:3b91:: with SMTP id n17mr413535wms.72.1629138303918; Mon, 16 Aug 2021 11:25:03 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id i3sm286343wmb.17.2021.08.16.11.25.02 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 16 Aug 2021 11:25:03 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> Date: Mon, 16 Aug 2021 19:25:00 +0100 In-Reply-To: (Dmitry Gutov's message of "Mon, 16 Aug 2021 17:33:20 +0300") Message-ID: <87tujpgscj.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: >> prepared a version of my patch that is based on weak-keyed hash tables. >> Slightly slower, but not much. Here are the usual benchmarks: > > Cool, I'll take a look, thanks. I've made it faster, now very close to the string-propertizing approach, itself very close to the theoretical best (which is no copy, no highlight). See the tip of the scratch/icomplete-lazy-highlight-no-string-props branch, which I had to rewrite (some Git flub-up). All benchmarks after sig. Jo=C3=A3o (require 'cl-lib) ;; Introduce 300 000 new symbols to slow things down. Probably more ;; than most non-Spacemancs people will have :-) ;; (setq ido-enable-flex-matching t) ;; (ido-mode) ;; (ignore-errors (ido-ubiquitous-mode)) ;; (fido-mode) ;; (fido-vertical-mode) ;; (vertico-mode) ;; (hash-table-keys completion--get-lazy-highlight-cache) (defmacro heyhey () `(progn ,@(cl-loop repeat 300000 collect `(defun ,(intern (symbol-name (gensym "heyhey"))) () 42)))) ;; (setq completion-styles '(substring)) (setq completion-styles '(flex)) (heyhey) (setq icomplete-show-matches-on-no-input t) (symbol-name 'mouse-kill) (when nil ;; Press C-u C-x C-e C-m quickly to produce a sample. Always discard ;; the first sample in the session, it tends to have an extra GC and be ;; slower. (benchmark-run (completing-read "" obarray)) ;; don't use string props (2.848873438 6 0.8307729419999994) (2.848416202 6 0.8370667889999996) (2.786944063 6 0.8230433460000004) (2.7815761840000004 6 0.819654023) (2.6929080819999998 5 0.7036257240000001) ;; string props (2.630354852 4 0.7071441910000011) (2.594761891 4 0.7082679669999994) (2.589480755 4 0.7112978109999997) (2.661196709 4 0.7130021060000011) (2.844372962 4 0.7378870879999999) ;; master (3.6339847759999997 12 1.601142523) (3.757091055 12 1.6231055449999996) (3.785980977 12 1.6333413839999995) (3.716144927 12 1.6100998260000008) (3.808275042 11 1.611891043) ;; these next two are not comparable to the above, because in ;; ab23fa4eb22f6557414724769958a63f1c59b49a I added sorting to flex ;; which changes results, and Daniel's patch no longer applies ;; cleanly. ;; daniel's patch (3.420418068 10 1.451012855) (3.603226896 10 1.672325507) (3.501318685 10 1.6150095739999992) (3.659821971 10 1.6580361760000004) (3.624743674 10 1.657498823) ;; master just before daniel's patch (254dc6ab4c) (2.611424665 10 1.5267066549999981) (2.48811409 10 1.486639387000002) (2.472587389 10 1.479865191) (2.543277273 10 1.510667634999999) (2.546243312 10 1.4986345790000009) =20=20 ) From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Aug 2021 02:09:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: Daniel Mendler , larsi@gnus.org, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.162916610923051 (code B ref 48841); Tue, 17 Aug 2021 02:09:01 +0000 Received: (at 48841) by debbugs.gnu.org; 17 Aug 2021 02:08:29 +0000 Received: from localhost ([127.0.0.1]:51221 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFoWi-0005zd-OI for submit@debbugs.gnu.org; Mon, 16 Aug 2021 22:08:29 -0400 Received: from mail-wm1-f43.google.com ([209.85.128.43]:35548) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFoWd-0005ym-SJ; Mon, 16 Aug 2021 22:08:27 -0400 Received: by mail-wm1-f43.google.com with SMTP id q11-20020a7bce8b0000b02902e6880d0accso787481wmj.0; Mon, 16 Aug 2021 19:08:23 -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=IAvF5+6geKHEsuSSEwhyDFNjtZUuki/x4PcgcWs5sg4=; b=qdRwou/tFgAeUiduNxNZKjaiARWFqmtU+7h2607k1U2n6u7+bgOQW7lkiVxje3r+sh /epnbO5D2MtkVFN8RwPoDYQfXMhD0hXZ9ZpOTXFlwk54NJF0G6Fxv06cGqm9YcuWCgMy ktz3cqASgTjxboOdO2Q3B4Th7oQyxvuRS43vO2Dm2FKfqX1dvA2/Gi94FaVLi5OaEkbN YBfRKeUuRCkZryyk5VbkNENy5clAUV+MxPnRzdm3BmsEuIy1HBBtlai7zVre7ggBU/8X ZgZmXLisKRZH9YOlVr5drZwZxUNKNMjjaOhg8ghK0fE8JqkyoVbrksUrkelI7H0R+vgz DRXQ== 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=IAvF5+6geKHEsuSSEwhyDFNjtZUuki/x4PcgcWs5sg4=; b=QdkFc+2IVRvrl2EPn9wCtkV1ARoyLeDiyMt0FaKcmPrciMl/ty3bmJ3zrF9rTJU8G2 lxRIto77yeYTYry6DEWKD/yuy9sWqcTJuT9w+ckQ+5QoLhDdCqpJYSFELkuEVk2JTK14 HbC/owtY+QsSBzQMvSCKy3vdGYNi8hL+S/matFgY0OWpgqX14d4GyReXclixWAYAmV4I Xnn512JJ7/titXeHTkKws2hNeoDmM92LCSahRG7dQ9JcQwNJ7rDcUgpf0YOwglmrpuby 0UdR7QwgymCJVHg+054KpqKxxpgTENo0bDpjsePyEgAuJyyEpiJB31n9Cs1qqWn7YArz ADqA== X-Gm-Message-State: AOAM531y9UvBZx2+09np3Y1uTM2zshz4Pvtg5uD14ekxFj/b2FmWkAcl V5FoFVzgvRjwMk0BS595J33dcIb2PUA= X-Google-Smtp-Source: ABdhPJxKoZa0etc1GMrF2vGIkqKsVfbehrU+3zPd5WmDAn41g2TPJBSXFDKEuQRKOxu+ERz7+nb7VQ== X-Received: by 2002:a1c:cc02:: with SMTP id h2mr814967wmb.39.1629166098047; Mon, 16 Aug 2021 19:08:18 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id y11sm671479wru.0.2021.08.16.19.08.16 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 16 Aug 2021 19:08:17 -0700 (PDT) References: <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> <87tujpgscj.fsf@gmail.com> From: Dmitry Gutov Message-ID: <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@yandex.ru> Date: Tue, 17 Aug 2021 05:08:15 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.11.0 MIME-Version: 1.0 In-Reply-To: <87tujpgscj.fsf@gmail.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-Spam-Score: 0.4 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -0.6 (/) On 16.08.2021 21:25, João Távora wrote: > I've made it faster, now very close to the string-propertizing approach, > itself very close to the theoretical best (which is no copy, no > highlight). See the tip of the > scratch/icomplete-lazy-highlight-no-string-props branch, which I had to > rewrite (some Git flub-up). All benchmarks after sig. Thanks. I've read it now. This implementation style (quick exfiltration via a dynamic var with some special-cased logic) reminds me of the recent changes to eldoc, really not my cup of tea. At the very least, though, you have done the work of proving that the no-string-propertization approach can be just as fast. Thank you for that. A hash table with :test 'eq is a good choice. I'd be happy to try to tweak it further, but it also seems that at this point we can transition to the discussion about what kind of implementation style we want, since the performance is proven to be more or less on par. Though of course that should start with an alternative patch which adds icomplete support as well (either Daniel does it, or I'll give it a try). From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Aug 2021 09:00:03 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Dmitry Gutov Cc: Daniel Mendler , larsi@gnus.org, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16291907787203 (code B ref 48841); Tue, 17 Aug 2021 09:00:03 +0000 Received: (at 48841) by debbugs.gnu.org; 17 Aug 2021 08:59:38 +0000 Received: from localhost ([127.0.0.1]:51658 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFuwb-0001rx-Ko for submit@debbugs.gnu.org; Tue, 17 Aug 2021 04:59:38 -0400 Received: from mail-wm1-f48.google.com ([209.85.128.48]:54956) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFuwZ-0001rc-Ak; Tue, 17 Aug 2021 04:59:36 -0400 Received: by mail-wm1-f48.google.com with SMTP id g138so13204806wmg.4; Tue, 17 Aug 2021 01:59:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=/dHRq1CLiHWhD7Jq2ZxdiJWP1UyGng3ccHVR6VjpgyM=; b=uRDRDoT/DLWGL+UByQK9yEGAK9aBW2hYBmdngJuA9OPx9uJZ+BeOXDRSm+VPC0KRgd la0DKIME4lGkwUhJcVm1dye40ZOHVv/Q5OkI1D3UNdZ5AK852x7Whr6HJyhP8QnB5o43 N7LFKV4URwZm70qHY1+kitqhil17pjpdmjTjzk+QQFcczyUfsqak8mzqIj/sDskvV6Sl cw/RxSXWRJQDpFTmV1PfkN85dTSjTPMi+OeHHtlygKRLb2wI1PaDK4KKLXtmGBHJV19E lCdat8KvBD+tTlx/eo0hIBjT3KZuswe+gj10JX+5YoBsRR8qaon29A9bJ4nXg2kAovI0 3diQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=/dHRq1CLiHWhD7Jq2ZxdiJWP1UyGng3ccHVR6VjpgyM=; b=CohTlTsyqLQUfTlfLd1teU+aXLps2dPwteDsMrmbks2fpOdpNEwvMZcWmlJn3nyQly ISi1LV8P/oCDzuxbYsaHiMLcQw+zCuJpahjsG6pkKpa0mrH6IEdnJuNxXQEW2Mkmh1NE AY9rLAzaIyduZsC11TUCId8d5qym2AE30uvzcM9MrXJEf76YTQzkKRi/wPmbYfa910G5 LEGl3IMSfV+ixEpLKyvZNhHDxU+tt/GlQnbiS1rexAoRmFAdNkW21YXvG81z0fgWWMzu TJn2TlvOLqlT0kS2OzMR+rGm6dBzZgUju43VTk06IiWHDWtTSDboKhFjoc6m6xVochl8 NCnw== X-Gm-Message-State: AOAM530FmEpHsjyLMmQpDdd8sp/vyJ7qfG07H3GO+E+9V+NKJ9g4dQJc Rw5IXJQ24uGJ9ajgmLjRHhOBcOIsfYc= X-Google-Smtp-Source: ABdhPJwsfqLedihw68Sh6MbVaQGXzHfs8AshozH8sIDGzQTLk6wiYmR8HdnRBL+YIyvvhE6u4fPRAw== X-Received: by 2002:a7b:c5d2:: with SMTP id n18mr2266047wmk.97.1629190768886; Tue, 17 Aug 2021 01:59:28 -0700 (PDT) Received: from krug (a94-133-27-132.cpe.netcabo.pt. [94.133.27.132]) by smtp.gmail.com with ESMTPSA id g21sm1449040wmk.8.2021.08.17.01.59.27 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Tue, 17 Aug 2021 01:59:28 -0700 (PDT) From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= References: <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> <87tujpgscj.fsf@gmail.com> <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@yandex.ru> Date: Tue, 17 Aug 2021 09:59:25 +0100 In-Reply-To: <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@yandex.ru> (Dmitry Gutov's message of "Tue, 17 Aug 2021 05:08:15 +0300") Message-ID: <87zgtgxx8y.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Dmitry Gutov writes: > On 16.08.2021 21:25, Jo=C3=A3o T=C3=A1vora wrote: >> I've made it faster, now very close to the string-propertizing approach, >> itself very close to the theoretical best (which is no copy, no >> highlight). See the tip of the >> scratch/icomplete-lazy-highlight-no-string-props branch, which I had to >> rewrite (some Git flub-up). All benchmarks after sig. > > Thanks. I've read it now. > > This implementation style (quick exfiltration via a dynamic var with > some special-cased logic) reminds me of the recent changes to eldoc, > really not my cup of tea. I'm sorry, but I'm not drinking from your herbarium. Googling for "exfiltration" brings up "malware" and data security. Why is mine "quick" at that? Is this some kind of metaphor? And what does "some special-cased logic" refer to exactly? I see as much similarity to Eldoc and I do to the Sistine chapel. The only thing I understand, I think, is "dynamic var". If you mean the variable 'completion-lazy-hilit', notice it is not necessarily used as dynamic var (in fact in icomplete.el it's just a buffer-local var). As I explained elsewhere, if the completion machinery had a realiable abstraction for "session" I would use that.=20=20 I don't think it does, does it? Currently, it's the frontend who holds that knowledge. It will either have an object representing it (maybe a fancy CLOS thing); or a stack frame with some kind of command loop; or, in the case of icomplete, a minibuffer session delineated by kill-all-local-variables. So, for icomplete.el, setting that variable buffer-locally is the appropriate thing. For the command-loopy frontend, dynamically binding it will be. The the objecty frontend, the object itself it proabably a good value for complation-lazy.hilit. For completion-capf, if you cared to optimize it with this stuff, it will likely be ... something something. Anyway, the "implementation style" I went for is speed, brevity and a decent docstring. And it'd be a bit shorter if it used string properties... > At the very least, though, you have done the work of proving that the > no-string-propertization approach can be just as fast. Thank you for > that. You're welcome. Not really just as fast, but in the big-O ballpark, of course. I had hoped to show also that the particular choice of global structure for string/symbol/whatever association is irrelevant. I'm still missing the imminent catastrophe (that is so clear to you) of the put-text-property approach. I'd like these slower and more complex techniques to appease more than superstition. > A hash table with :test 'eq is a good choice. I'd be happy to try to > tweak it further, but it also seems that at this point we can > transition to the discussion about what kind of implementation style > we want, since the performance is proven to be more or less on par. > > Though of course that should start with an alternative patch which > adds icomplete support as well (either Daniel does it, or I'll give it > a try). I'm curious to see those, yes. But Eli pointed out on, two different APIs will need to cohabitate since the new API won't kill off the old. To be very clear, I'm interested in the performance of Daniel's patch, not really in insufferable claims of its beauty and virginity. minibuffer.el is a great big mess, I'll leave it to the Great Designers of the Big Redesign, godspeed to them. Currently, I just want changes to not assassinate, in speed or form, icomplete.el or the flex completion style, two fundamental daily drivers to my work, and other's work. So if/when Daniel's patch doesn't do any of that (it seems that it currently does), I'll be all for it. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Aug 2021 11:50:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Cc: mail@daniel-mendler.de, monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, dgutov@yandex.ru, larsi@gnus.org, 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16292009598972 (code B ref 48841); Tue, 17 Aug 2021 11:50:02 +0000 Received: (at 48841) by debbugs.gnu.org; 17 Aug 2021 11:49:19 +0000 Received: from localhost ([127.0.0.1]:51978 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFxal-0002KT-IV for submit@debbugs.gnu.org; Tue, 17 Aug 2021 07:49:19 -0400 Received: from eggs.gnu.org ([209.51.188.92]:53000) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFxac-0002Jn-3o; Tue, 17 Aug 2021 07:49:10 -0400 Received: from fencepost.gnu.org ([2001:470:142:3::e]:53542) by eggs.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1mFxaW-0006Vj-51; Tue, 17 Aug 2021 07:49:00 -0400 Received: from 84.94.185.95.cable.012.net.il ([84.94.185.95]:2906 helo=home-c4e4a596f7) by fencepost.gnu.org with esmtpsa (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1mFxaV-0007lh-Nz; Tue, 17 Aug 2021 07:49:00 -0400 Date: Tue, 17 Aug 2021 14:48:55 +0300 Message-Id: <838s1070m0.fsf@gnu.org> From: Eli Zaretskii In-Reply-To: <87zgtgxx8y.fsf@gmail.com> (message from =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= on Tue, 17 Aug 2021 09:59:25 +0100) References: <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> <87tujpgscj.fsf@gmail.com> <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@yandex.ru> <87zgtgxx8y.fsf@gmail.com> MIME-version: 1.0 Content-type: text/plain; charset=utf-8 Content-Transfer-Encoding: 8bit X-Spam-Score: -2.3 (--) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -3.3 (---) > From: João Távora > Date: Tue, 17 Aug 2021 09:59:25 +0100 > Cc: Daniel Mendler , larsi@gnus.org, > monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org > > I'm sorry, but I'm not drinking from your herbarium. Once again, I'm asking everyone to please remove the emotional and sarcastic parts from the exchange. It is not helping to have constructive discussions. From unknown Sun Sep 07 23:15:53 2025 X-Loop: help-debbugs@gnu.org Subject: bug#48841: bug#47711: bug#48841: bug#47711: [PATCH VERSION 2] Add new `completion-filter-completions` API and deferred highlighting Resent-From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 17 Aug 2021 11:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 48841 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: To: Eli Zaretskii Cc: Daniel Mendler , Stefan Monnier , 48841@debbugs.gnu.org, Dmitry Gutov , Lars Ingebrigtsen , 47711@debbugs.gnu.org Received: via spool by 48841-submit@debbugs.gnu.org id=B48841.16292011779315 (code B ref 48841); Tue, 17 Aug 2021 11:53:02 +0000 Received: (at 48841) by debbugs.gnu.org; 17 Aug 2021 11:52:57 +0000 Received: from localhost ([127.0.0.1]:51983 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFxeL-0002QA-4v for submit@debbugs.gnu.org; Tue, 17 Aug 2021 07:52:57 -0400 Received: from mail-pj1-f43.google.com ([209.85.216.43]:42695) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mFxeH-0002Ps-2c; Tue, 17 Aug 2021 07:52:56 -0400 Received: by mail-pj1-f43.google.com with SMTP id mq2-20020a17090b3802b0290178911d298bso5935363pjb.1; Tue, 17 Aug 2021 04:52:52 -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=TEK86VaewgjdMLw/h7r4vTGKS6CguYWjFkZKWAtP/wU=; b=cvxqMtvPfvhOAL5+Gs+nqgraU2Mjxr9g+34iJwyehrv4JVySceLsUPHefX18Mo0qJD 5OdrZ+4zpuYZt07SOrJZTRF6UHpcQIcP+csxB+KLhJ0jnXwwoL4qpMB7hnUhQ6nE9+Kb mZhYytmod1wnep7WaousBq++37MjNAuSd9KMCA9UKVxDYJK3UR13JD67LfOUtW3scWZT A8mWCBFn6UAWDpMO4OmeSj3invgCu+1apMxBwG5qeKcX6EnH4DIQpEelTA46TRwBVo5y wxu+0MIP8FSr5dRX0hNWHmQdAHPA/KGOon4arWahUMYxy4BalOef4XKX003uWPg3JT1I oeoQ== 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=TEK86VaewgjdMLw/h7r4vTGKS6CguYWjFkZKWAtP/wU=; b=aV6L9YJAX9WI5ksenqXMm+6gosT57v1Ds7VPXqLo66uDKMJlsEz5SXYMDTYL9BYIm+ dEhr7fNRuCcT7BG/Mi5JLthwLqYPZM7fLSvBFDLWniy3jQd+Se/TcigvvsFfRKfOkPEF xIzUqKqPvlEzXGAlZmTDYx6TW7vMcUfihAMHgV7OneCFEdvP3v4wAvwJhLom3dQxz+q8 NbPdm2y4S+bRGA6i+Mj0wbQw/P2KVgK65Dy7s/KSxN7kTXCoCQCXxZJG+Ihn/2Np/U4X 4WF3i4R+M9CHZiZ++zRQlXMKAmYY6lS9YCNEJlSyX9cwhW6y9zlBy1NFHnPnWCDqfVx2 ixoA== X-Gm-Message-State: AOAM532wOnVUITeloOweJ3VOuOOfbTSm2w7Rzmo8I6qSXnWCtx1W7sWv FK3g79E4A+1/WNzhqOTpF/t2mk2PZCk+cNePfes= X-Google-Smtp-Source: ABdhPJylyc9Lo/7eud0V3p+zEOslveEBTHfAxiDHWf0kOUj0lZmVosUrDtmX/oZLqYeUT1fbHxfB3dF8CFjyRjQxIo8= X-Received: by 2002:a17:90a:a091:: with SMTP id r17mr3301716pjp.56.1629201167171; Tue, 17 Aug 2021 04:52:47 -0700 (PDT) MIME-Version: 1.0 References: <87y29471ov.fsf@gmail.com> <837dgob6yo.fsf@gnu.org> <87wnootec0.fsf@gnus.org> <5d70b0ad-3838-ddb8-d341-9a5531d9da73@yandex.ru> <0cbf224b-b382-8a02-3f06-9f6d7e5e9741@yandex.ru> <87a6lihv7b.fsf@gmail.com> <63e03b18-db81-3b11-c692-0af9df20c506@daniel-mendler.de> <83k0kl8sxm.fsf@gnu.org> <83bl5x8r02.fsf@gnu.org> <77e98cdf-427d-ec7a-7a49-04dcd65d6a94@yandex.ru> <8735r9ii8b.fsf@gmail.com> <87tujpgscj.fsf@gmail.com> <5118e88c-5b90-60f0-b5eb-ab4ce8bdc0dc@yandex.ru> <87zgtgxx8y.fsf@gmail.com> <838s1070m0.fsf@gnu.org> In-Reply-To: <838s1070m0.fsf@gnu.org> From: =?UTF-8?Q?Jo=C3=A3o_?= =?UTF-8?Q?T=C3=A1vora?= Date: Tue, 17 Aug 2021 12:52:35 +0100 Message-ID: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable X-Spam-Score: -0.0 (/) X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) On Tue, Aug 17, 2021 at 12:49 PM Eli Zaretskii wrote: > > > From: Jo=C3=A3o T=C3=A1vora > > Date: Tue, 17 Aug 2021 09:59:25 +0100 > > Cc: Daniel Mendler , larsi@gnus.org, > > monnier@iro.umontreal.ca, 48841@debbugs.gnu.org, 47711@debbugs.gnu.org > > > > I'm sorry, but I'm not drinking from your herbarium. > > Once again, I'm asking everyone to please remove the emotional and > sarcastic parts from the exchange. It is not helping to have > constructive discussions. I thought it was rather appropriate for the "my cup of tea" line :-) But I get the message, and I apologize. Jo=C3=A3o From unknown Sun Sep 07 23:15:53 2025 MIME-Version: 1.0 X-Mailer: MIME-tools 5.505 (Entity 5.505) X-Loop: help-debbugs@gnu.org From: help-debbugs@gnu.org (GNU bug Tracking System) To: Dmitry Gutov Subject: bug#48841: closed (Re: bug#48841: [PATCH] Make fido-mode about as fast as ido-mode even with many completions) Message-ID: References: <874kbda5tt.fsf@gmail.com> X-Gnu-PR-Message: they-closed 48841 X-Gnu-PR-Package: emacs Reply-To: 48841@debbugs.gnu.org Date: Wed, 25 Aug 2021 15:44:02 +0000 Content-Type: multipart/mixed; boundary="----------=_1629906242-4342-1" This is a multi-part message in MIME format... ------------=_1629906242-4342-1 Content-Disposition: inline Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" Your bug report #48841: fido-mode is slower than ido-mode with similar settings which was filed against the emacs package, has been closed. The explanation is attached below, along with your original report. If you require more details, please reply to 48841@debbugs.gnu.org. --=20 48841: http://debbugs.gnu.org/cgi/bugreport.cgi?bug=3D48841 GNU Bug Tracking System Contact help-debbugs@gnu.org with problems ------------=_1629906242-4342-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at 48841-done) by debbugs.gnu.org; 25 Aug 2021 15:43:07 +0000 Received: from localhost ([127.0.0.1]:47383 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIv3T-00016o-EJ for submit@debbugs.gnu.org; Wed, 25 Aug 2021 11:43:07 -0400 Received: from mail-wm1-f49.google.com ([209.85.128.49]:46053) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1mIv3P-00016F-Rr for 48841-done@debbugs.gnu.org; Wed, 25 Aug 2021 11:43:05 -0400 Received: by mail-wm1-f49.google.com with SMTP id j17-20020a05600c1c1100b002e754875260so71999wms.4 for <48841-done@debbugs.gnu.org>; Wed, 25 Aug 2021 08:43:03 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:references:date:in-reply-to:message-id :user-agent:mime-version:content-transfer-encoding; bh=yD7B/XLdbwNkEeJkA7mN+GGToapeQO8Y0dGhHrB6Fko=; b=is8Puqlg3DJMBCsqPd5qtC+1GdGcTboFkrwKYo1fuFOn1nKrxh83zuTHu70o+picrF +Ejftp7TiS+HocNqlLGnxTZqR80saQBO/+ps+OIbjiraGE9UbzIte/MX5JBx8DufW47e qtb5yRJwKcmCcMMZIYF1cs/u06Zg57ZXQwzFfdZ+xgogUn/M3i7n5Yo3vcyA9++/AOv7 piffiPbpGu9jbop2tg8FljvNhtPaSQ3+suHG8nMiHnc53/GkiRHwxPd+nFqDxST4NdPg 8pQybEZvv3SnbH0W4DGFXRoyOf0SkWvhTEH6pPGbosmVQbcmXqpH6A81A8CIiRsBVnkr U6Ng== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:references:date:in-reply-to :message-id:user-agent:mime-version:content-transfer-encoding; bh=yD7B/XLdbwNkEeJkA7mN+GGToapeQO8Y0dGhHrB6Fko=; b=czr+88y0WbKd4VaHKhPpocwln6ySo22q36JxMZ9beX3RTiq5mhFGDlpZ1a+0aZcklP iNqmmIzszqm52TpHQ0n8PzXiF/ZlxonTEQbnQpma4dxpp6qlJ4HDOcNmDdALRjkcNFCd onja5uZv/MUeJYemFrkYI1eL+kGhLjuhifaJ1UU+OKVhJthqLb3J2nAw7JZxaq4mQT77 LkpMSHepDSh2DlBQeI7CRw7hv/FeiydvUnicB/OQTMDSWvVVoteIivklVyHl4mVVFoX4 hvhFJo3lZGd1nRHHu0TY33DvesIN6DeqzvWq+XkEdzJsTaOrSKttqDGCZmQsnH+mAIDP U+bg== X-Gm-Message-State: AOAM531dDpOFBVJ2TiH5jK3pjEtraclfc6tPAwCKtutIxs8srxCkTwwO 9boCgjE3chqKh9AXaBtZ5rs= X-Google-Smtp-Source: ABdhPJw0lq4PVNV/rczK25KIbQ2vPpVe6yH8VHIsgR0B9YViEB29TLQFOSjz54A/kZcX5X3iFgJfuQ== X-Received: by 2002:a1c:7402:: with SMTP id p2mr9994769wmc.111.1629906177862; Wed, 25 Aug 2021 08:42:57 -0700 (PDT) Received: from krug (a83-132-128-184.cpe.netcabo.pt. [83.132.128.184]) by smtp.gmail.com with ESMTPSA id b15sm311647wru.1.2021.08.25.08.42.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Wed, 25 Aug 2021 08:42:57 -0700 (PDT) From: =?utf-8?B?Sm/Do28gVMOhdm9yYQ==?= To: Dmitry Gutov Subject: Re: bug#48841: [PATCH] Make fido-mode about as fast as ido-mode even with many completions References: <3d3f894f-a6fa-53ae-5d50-c3aa9bffc73e@daniel-mendler.de> <56ab18b1-4348-9b2c-85bb-af9b76cd429a@daniel-mendler.de> <38a06f3c-4a7a-755c-c99b-708f91afabfa@daniel-mendler.de> <9f59f87c-2489-aaa0-5b3f-0e911b7ffa6c@daniel-mendler.de> <8a36e61a-1c5b-bf3b-a454-077348589c4f@yandex.ru> <87y29471ov.fsf@gmail.com> <87sfzaimng.fsf_-_@gmail.com> Date: Wed, 25 Aug 2021 16:42:54 +0100 In-Reply-To: <87sfzaimng.fsf_-_@gmail.com> (=?utf-8?Q?=22Jo=C3=A3o_T=C3=A1?= =?utf-8?Q?vora=22's?= message of "Sun, 15 Aug 2021 19:32:51 +0100") Message-ID: <874kbda5tt.fsf@gmail.com> User-Agent: Gnus/5.13 (Gnus v5.13) Emacs/28.0.50 (gnu/linux) MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable X-Spam-Score: 0.0 (/) X-Debbugs-Envelope-To: 48841-done Cc: Daniel Mendler , eliz@gnu.org, Stefan Monnier , 48841-done@debbugs.gnu.org X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.0 (-) Jo=C3=A3o T=C3=A1vora writes: > [I've removed bug#47711 from the list, since I haven't read the bug. > This is only directly concerned with this report bug#48841 about speed > differences between fido-mode and ido-mode.] > > Jo=C3=A3o T=C3=A1vora writes: > >> scratch/icomplete-lazy-highlight-attempt-2, although still incomplete, >> is one such approach, though it still sets `completion-score` on the >> "shared" string, used later for sorting. But also that could be >> prevented (again, only if it turns out to be actually problematic >> IMO). > > I have tested the patch more thoroughly now, and have not found any > problems. As I wait for genuine reports or explanations of the much dramatized problems in the above patch, I've pushed a much simpler patch that has a dramatic beneficial effect: simply don't do any copying, highlighting or scoring if the pcm-style pattern (used by the styles 'flex', 'substring' and others) is empty. This more than halves the waiting time for the candidate display when the pattern is empty. As far as i can tell, `fido-mode` is now faster than `ido-mode` and so I'm marking this bug closed. Of course, when there is a pattern of a single character or more, the icomplete waiting times using my earlier 'completion-lazy-highlight' patch are still around 70% of the current master. But those times are always quite shorter than the empty-pattern case. I'll wait a bit for the alternatives presumably being worked on before pushing that or something based on it. Jo=C3=A3o ------------=_1629906242-4342-1 Content-Type: message/rfc822 Content-Disposition: inline Content-Transfer-Encoding: 7bit Received: (at submit) by debbugs.gnu.org; 5 Jun 2021 01:39:58 +0000 Received: from localhost ([127.0.0.1]:48094 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpLI6-0007c6-7W for submit@debbugs.gnu.org; Fri, 04 Jun 2021 21:39:58 -0400 Received: from lists.gnu.org ([209.51.188.17]:47576) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1lpLI3-0007bx-K8 for submit@debbugs.gnu.org; Fri, 04 Jun 2021 21:39:57 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:51402) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lpLI3-0002Ak-Cb for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 21:39:55 -0400 Received: from mail-wr1-x435.google.com ([2a00:1450:4864:20::435]:41812) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1lpLI1-0000Ay-Gw for bug-gnu-emacs@gnu.org; Fri, 04 Jun 2021 21:39:55 -0400 Received: by mail-wr1-x435.google.com with SMTP id h8so10956018wrz.8 for ; Fri, 04 Jun 2021 18:39:53 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:to:from:subject:message-id:date:user-agent:mime-version :content-language:content-transfer-encoding; bh=w+Vi8Fpo1tJdAAFVOptzaAe9XHfZKDU/nqNQTPxTR6M=; b=i1crFa30B8GbHmqBOb8TCrma99l4X3pCSu8mm2DpDqZAmATZPVnIoWKcKkXWxui3uP Y9yUsQGvIBtbWEKAzO2+ymC9lh3ix/x88kvjzWOZ87ffOUggEnV3Ue2w/2XvQt1M7C96 JAiJcr2ottLrpRq0TngXylxhpVWJowpc1yjP5s8E+XavGA3ypZL+YOtl7p4IuW5yGYxy LzFjwx6R0q5Kfhjem5Whvx6GkcFvx+lgL6p7z8i9tagXcGSyEFu4ixCxZVmko1RDsOZX /BZDE+7btFdKwh2xMr7UG8+TyoZc0FVEPX7TJ/+VJyyJw7lPUF7TVeY3EnPNvUhheBP0 j/Iw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:to:from:subject:message-id:date :user-agent:mime-version:content-language:content-transfer-encoding; bh=w+Vi8Fpo1tJdAAFVOptzaAe9XHfZKDU/nqNQTPxTR6M=; b=bJzkqYalNQ5ijdZqUKaUglFwLMaZUy8yBaWmKAMVLU/e04eTy2qcz6hoT/ChfOvait revbsKaIcnv4OEFmkGhjypCKNmSkvFhOxq3rwOWpbKpYQgvN/gnIP5D5fH0YyB+sx0HK TKKWcZF1K6oP50xLxMGb+VuujI7q5AGcUkLlXQ8zh+Ld+7pYQxAOg6XpRUsCxO3O2KqV 4kjlyG/pRmxuTTK+xQBz5VnQQivSghoZKOkJRwbm8bFKqftxQ3nTzCUmx2WJcEJdkjTe 2SUjdLuX6IUTyAIqtBdqTZyRbMn0XV7Z1Ek+JpEbIHIMvSrfUtY9ijBQXUQk3GpLs7q0 ZqpQ== X-Gm-Message-State: AOAM533itREXD0GDI8RhX1y9EN9bKsDDcPJ18hm6c84FoZ/1EVDJj8FE 1QVCjkzUZdmsHJafyed4uSAf8LSCPrw= X-Google-Smtp-Source: ABdhPJxbX4wtdl7i73Z5mS/SwhBb5vA7FPw2IDcoYR5voDsdcL+48ylHkJhr83sLsLyrfYPaFNm+9Q== X-Received: by 2002:adf:fa0f:: with SMTP id m15mr6275716wrr.379.1622857191261; Fri, 04 Jun 2021 18:39:51 -0700 (PDT) Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id u7sm2846858wrt.18.2021.06.04.18.39.50 for (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Fri, 04 Jun 2021 18:39:50 -0700 (PDT) To: bug-gnu-emacs@gnu.org From: Dmitry Gutov Subject: fido-mode is slower than ido-mode with similar settings Message-ID: Date: Sat, 5 Jun 2021 04:39:49 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit Received-SPF: pass client-ip=2a00:1450:4864:20::435; envelope-from=raaahh@gmail.com; helo=mail-wr1-x435.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.249, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, 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-Spam-Score: -0.8 (/) X-Debbugs-Envelope-To: submit X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: debbugs-submit-bounces@debbugs.gnu.org Sender: "Debbugs-submit" X-Spam-Score: -1.8 (-) I'm comparing ido-mode with ido-ubiquitous-mode (for support for arbitrary completion tables), available at https://github.com/DarwinAwardWinner/ido-completing-read-plus with (setq ido-enable-flex-matching t), of course versus fido-mode with (setq icomplete-compute-delay 0) (setq icomplete-show-matches-on-no-input t) (setq icomplete-max-delay-chars 0) The values chosen for behavior maximally close to ido. Try something like: - Start a session with personal config and a number of loaded packages (so that there are a lot of functions defined in obarray) - Type 'C-h f' - Type 'a', then type 'b'. - Delete 'b', type it again, see how quickly you can make the completions update. With ido, the updates seem instant (probably due to some magic in ido-completing-read-plus); with fido, there is some lag. Not huge, but easy enough to notice. ------------=_1629906242-4342-1--