From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: [PATCH] (icomplete-vertical-mode): Add support for affixations and, annotations Date: Wed, 2 Jun 2021 14:28:24 +0300 Message-ID: <8e0cfb49-4ce3-c9aa-21fd-f0063b7c8107@yandex.ru> References: <23510125-37b9-e87e-3590-5322f44772ce@daniel-mendler.de> <87y2c5nhsr.fsf@mail.linkov.net> <87h7irss50.fsf@mail.linkov.net> <43d1599e-2ba9-2efb-45c3-76c67d29a69d@daniel-mendler.de> <87tumrgqrb.fsf@gmail.com> <87tumq92pe.fsf@mail.linkov.net> <87lf82g10g.fsf@gmail.com> <87y2c24lww.fsf@mail.linkov.net> <871r9t2lsy.fsf@mail.linkov.net> <22880197-6d05-c821-2c58-328ed3cfc02e@daniel-mendler.de> <87eedruui3.fsf@gmail.com> <8dd915fe-fe67-2a45-67ff-8aaa3e9b9aca@daniel-mendler.de> <878s3zuq47.fsf@gmail.com> <09f2a253-84ba-5cfd-552e-0b89109864a5@daniel-mendler.de> <875yyxaoxp.fsf@gmail.com> <871r9laj6a.fsf@gmail.com> <1a183c3b.2f2f.179cb27f64c.Coremail.tumashu@163.com> <87lf7s7lli.fsf@gmail.com> <2dd59f1c-1d4d-a7d7-fae5-d9ca9b5c90c2@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 8bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="31610"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.8.1 Cc: tumashu , Juri Linkov , "emacs-devel@gnu.org" , Stefan Monnier , Daniel Mendler To: =?UTF-8?B?Sm/Do28gVMOhdm9yYQ==?= Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 02 13:29:10 2021 Return-path: Envelope-to: ged-emacs-devel@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1loP3e-000864-Rp for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 13:29:10 +0200 Original-Received: from localhost ([::1]:48182 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loP3d-0000iJ-UM for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 07:29:09 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:37048) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loP30-0008Rl-Ve for emacs-devel@gnu.org; Wed, 02 Jun 2021 07:28:30 -0400 Original-Received: from mail-wm1-x334.google.com ([2a00:1450:4864:20::334]:45749) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loP2z-0005xR-2W for emacs-devel@gnu.org; Wed, 02 Jun 2021 07:28:30 -0400 Original-Received: by mail-wm1-x334.google.com with SMTP id s5-20020a7bc0c50000b0290147d0c21c51so1452705wmh.4 for ; Wed, 02 Jun 2021 04:28: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=J9bS3xvanX9umJNNdVlgdniiem8OBSaDrkfrbs4fLl4=; b=JQdPUoW1DDShhczoYSs4S+ba0izYUrv89zzcKtXWnjKv0lzZAmcUYiKVEeo9k5Ezgk uX4WmTlW85KYh3rzXtEfeBN3UISwccjNd/t9EK5dJoY3FIBewk+qwPJ3XnUv+c97YoYz bNTqVHO8j307LZE69DPlVaytyIN9zB+6xTMbZOiiB13WiA5RR09wKtQXeq+lHm7UT3j9 udQzOxFNIZYigby6+W4CdLFy2fQMq36sIRTBXGWI5ZFFxFwFOuGkQSIPCg/hozMrvncu h2UYyK9da7UyN0GpmV13t77ngcQhZTgEr43GcNCio8NczLUv4VZyJYKsC3MxCj+DG2ux FTiA== 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=J9bS3xvanX9umJNNdVlgdniiem8OBSaDrkfrbs4fLl4=; b=igaLTUUZdTCtsMwrxSjGyq010idJnaJZ8uxUuRWY/tI7GIiu9Kq2maVtJQFqrExFNx 4pwTQzOxdb5YfL7Y14amNyiR//61zkhM4ZtQoVFkHNJKDiD5NbZCWDQWbrg8oktLfWh0 KFtsfhXiZwZEYCzkpDAOXc/2TREremm4tOSHf3W27XynfQwI2q1fYo+I0KoqnYLmig86 mIqYO2zetBn+B6TCr318zX1lqdHrj4sljP0YiPN60+h2d26UKHAuj14DYgRsckVRlVSX wFFBF2gb11XJQbW4fVbq7A1iGLIj51p8nZYXMCjtUARAMM7VKHkFo5+hn+V30MM138wY CcYw== X-Gm-Message-State: AOAM533ZRPaUGoWwvXEWcRv6kDp8XvU6VZ6csiYttsZwWWlxQlcdFSbe yiw+d1iaVQ0Q2q9ZlOwVTpQ= X-Google-Smtp-Source: ABdhPJwkcL9u8RU9woYYyEtta8sv0IcVEA872n+VpeMRLNg1tRHb08aIECrefCkYa3zCmd1ILlnhPQ== X-Received: by 2002:a7b:c8ce:: with SMTP id f14mr1794880wml.88.1622633307519; Wed, 02 Jun 2021 04:28:27 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id v8sm7172468wrc.29.2021.06.02.04.28.25 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Jun 2021 04:28:26 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::334; envelope-from=raaahh@gmail.com; helo=mail-wm1-x334.google.com X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FORGED_FROMDOMAIN=0.248, FREEMAIL_FROM=0.001, HEADER_FROM_DIFFERENT_DOMAINS=0.249, NICE_REPLY_A=-0.613, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Original-Sender: "Emacs-devel" Xref: news.gmane.io gmane.emacs.devel:270278 Archived-At: On 02.06.2021 14:04, João Távora wrote: >> (defun icomplete-post-command-hook () >> (let ((non-essential t)) ;E.g. don't prompt for password! >> >> >> I would also suggest lowering the default of icomplete-compute-delay to >> 0.1 or even 0.05. >> >> With 300ms delay, the new behavior does look a little weird. > > Can you remind us what that delay is doing there again? It waits before fetching completions if input it too short. To save on CPU usage or whatever. > Anyway, it should probably consult a customization knob. Or > maybe the new behaviour could decide based on > icomplete-compute-delay If someone is customizing that to a > low value, turn on the anti-flicker and suffer some little latency. > If the normal value, keep the current flickering and 0-ish latency. The proposed change doesn't add any latency. And it would be helpful to have it working OOTB. But maybe disable if the user customizes the delay to be higher.