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 15:31:34 +0300 Message-ID: References: <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> <8e0cfb49-4ce3-c9aa-21fd-f0063b7c8107@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="34365"; 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 14:33:16 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 1loQ3f-0008nB-S9 for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 14:33:15 +0200 Original-Received: from localhost ([::1]:59146 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1loQ3e-0006Y1-Qh for ged-emacs-devel@m.gmane-mx.org; Wed, 02 Jun 2021 08:33:14 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:52202) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1loQ2C-0004yg-S0 for emacs-devel@gnu.org; Wed, 02 Jun 2021 08:31:44 -0400 Original-Received: from mail-wr1-x431.google.com ([2a00:1450:4864:20::431]:43794) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1loQ27-0004Mg-6I for emacs-devel@gnu.org; Wed, 02 Jun 2021 08:31:42 -0400 Original-Received: by mail-wr1-x431.google.com with SMTP id v23so2108647wrd.10 for ; Wed, 02 Jun 2021 05:31: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=TnW1aUSWm6cKjiYf1ZPhv7Eq79apRGiJ4647LGL/LYQ=; b=VnbtgUfWPtBSMqY6bHWD7QNKis1dz460fIQovywF/z+i7ra++qXydKB4brLAHqnXw9 RUaLQsIbbqLY6XDA6EPAR+PiS4sWll+EP1yVs1ABqoapmeRfl1x16xhqasMUbazz4/ql m0zicpTxkYE5C1syx2gV870ai3x8aU15eaPhwrufJ2c1BanUihdBN1sMh/4zQT9wnkNm KUZHvoWULP0Nv/hDSv0yhnmzbPxo1iBC5CsTgk7T/47UsuSJR3HTn8+O1jrV/2V1s019 wBFNJUpBw/jxOsdoNm8xom9JFOr7XTuBwEQZS1uIRrO4PwWVUpMuls2rDy1YRd4XHeg6 Lp9A== 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=TnW1aUSWm6cKjiYf1ZPhv7Eq79apRGiJ4647LGL/LYQ=; b=aY+Be99bAqBNycuL7LR+1uMFBi+X96Wz4/TrKrhDKJP/qOAQJaQ1NYCG86s1Vxg8MR 9TfqHapbHo3gK/8b0WLDJe8xjeRgbsBJBfg4OhRtiKOk95nb5GOpU1ERgZ8iXl9FDINy QqjbvxAxnOMoOpg+JPfyDgdYP95suuqUqtVU3arydO3tcAxRQ2O+Q6NFIyi+qm2OH/Y9 pd1DawvVYEJA9J7mUavuNn8mrWCx/FBxh2glsFPeFekBsmO8dxFpkLd/Jf8LdjSrQA5Q mwfp3tjCKqSj3Kdb9Gv0Iz498SyOqduil4FnyHAa/MGeM5ZmHTGVh4sEvVLk1yVirQyq BjmQ== X-Gm-Message-State: AOAM533qRd0lLe/f7s6k2dpXHcIq+DhmrpgImr/F67ECoql7rPKSzzX+ WOaInVxEvCOghDQ3Tzmyal0= X-Google-Smtp-Source: ABdhPJyMbfhFtStyFfqZVVwCyRT37CKAwCIXcMLjOhXP1QjW67FsVCijw6DPitc1XHzqpXHFp5UnaQ== X-Received: by 2002:a5d:5549:: with SMTP id g9mr26916277wrw.204.1622637096624; Wed, 02 Jun 2021 05:31:36 -0700 (PDT) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q3sm6604464wrz.71.2021.06.02.05.31.35 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Wed, 02 Jun 2021 05:31:35 -0700 (PDT) In-Reply-To: Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::431; envelope-from=raaahh@gmail.com; helo=mail-wr1-x431.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:270286 Archived-At: On 02.06.2021 14:33, João Távora wrote: > On Wed, Jun 2, 2021 at 12:28 PM Dmitry Gutov wrote: > >> It waits before fetching completions if input it too short. To save on >> CPU usage or whatever. > > Makes sense. Even though it can be interrupted, doesn't mean we > should start spinning up fans. OTOH, ido-mode has lived with the "spinning up fans" behavior for ages, and we don't hear much complaints about that. Or fan noise, really. >> 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. > > Indeed it doesn't, just tried it. So I have even less objection to doing it. > Do you have a take on the reasons for this `icomplete-tidy` call in > pre-command-hook? All the justifications for the current behavior you have come up with already, I suppose. Here and in the related Company discussion. Simpler mental model, a guarantee of no "inconsistent" display, I suppose. But the flicking is real annoying, it's one of the things that has stopped my from migrating to fido-mode (somewhat lower performance is the other). > Anyway, the weirdness (and less flickering) could be solved by > replacing xx/xx with of the same length ??/?? instead of deleting the > overlay outright. But I'm fine with the weirdness too, to be honest. > My main concern was typing latency, and it doesn't happen. It might make sense to keep them at the previous values, to emphasize that the output simply hasn't been updated yet. And to keep the prompt from moving around twice. As long as the delay is not too high (meaning, we do make it lower than 100ms), that behavior looks natural enough. The user just gets used to "asynchronous" updates. Here's one edge case that might warrant some looking into: - fido-mode on (but not -vertical-mode). - Have, like, only 2 buffers open. - C-x b Start typing an existing buffer's name, in the way that would create a unique prefix match. icomplete will render it with cutoff prefix, like ico[mplete.el] where "ico" is input. If I backspace and type "o" again, there will be an interval of time when two "o" will be shown. That looks kinda weird, but probably still better than having it blink. Hopefully, this behavior could still be improved, though.