From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.ciao.gmane.io!not-for-mail From: Konstantin Kharlamov Newsgroups: gmane.emacs.devel Subject: Re: What is the most useful potential feature which Emacs lacks? A: Autocompletion Date: Wed, 03 Jun 2020 17:40:30 +0300 Message-ID: References: <380db8f0-0e18-744f-d72a-a6e12c3b6e1d@yandex.ru> <8919f9382c738573f20d97e22f293d61866f99b8.camel@yandex.ru> <5f3891ac-29f5-f544-360c-384ff9608bd1@yandex.ru> <701b151d-2133-7916-3169-5d0f29cf3bb8@yandex.ru> Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="ciao.gmane.io:159.69.161.202"; logging-data="10819"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Evolution 3.36.3 To: Dmitry Gutov , ndame , Emacs developers Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Wed Jun 03 16:42:02 2020 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 1jgUag-0002iX-40 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Jun 2020 16:42:02 +0200 Original-Received: from localhost ([::1]:54070 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jgUae-0007GB-L4 for ged-emacs-devel@m.gmane-mx.org; Wed, 03 Jun 2020 10:42:00 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:34212) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgUZK-0005aN-CB for emacs-devel@gnu.org; Wed, 03 Jun 2020 10:40:38 -0400 Original-Received: from forward105j.mail.yandex.net ([2a02:6b8:0:801:2::108]:58972) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1jgUZH-0006QC-Mk for emacs-devel@gnu.org; Wed, 03 Jun 2020 10:40:37 -0400 Original-Received: from mxback12g.mail.yandex.net (mxback12g.mail.yandex.net [IPv6:2a02:6b8:0:1472:2741:0:8b7:91]) by forward105j.mail.yandex.net (Yandex) with ESMTP id 0374EB20C92; Wed, 3 Jun 2020 17:40:31 +0300 (MSK) Original-Received: from sas1-e00c2743cdb8.qloud-c.yandex.net (sas1-e00c2743cdb8.qloud-c.yandex.net [2a02:6b8:c14:3a22:0:640:e00c:2743]) by mxback12g.mail.yandex.net (mxback/Yandex) with ESMTP id 2c2qmfr5VV-eUjikAvC; Wed, 03 Jun 2020 17:40:30 +0300 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=yandex.ru; s=mail; t=1591195230; bh=qbVE43y+Wux+GVI/9Iv65QXEcARG7JizL814A+D4JnU=; h=In-Reply-To:To:From:Subject:Message-ID:References:Date; b=keVmxDcrSkFqejFVydGToNf1icPhwJvi8b9n7dj2EO0h7lxD2li1BFf2ogEi6Ylam CbZ51QuvWpJ0dbF8qGRCRt0FQtHb++pPhCgy0xXPJOAfEjrn+sPpIl6FAzViJqD3fe HccixrP7NNONMKXgQZRYrTkxSPRZL93bEZBOvDQM= Authentication-Results: mxback12g.mail.yandex.net; dkim=pass header.i=@yandex.ru Original-Received: by sas1-e00c2743cdb8.qloud-c.yandex.net (smtp/Yandex) with ESMTPSA id L9zM2c5iIZ-eUaeNTXQ; Wed, 03 Jun 2020 17:40:30 +0300 (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) (Client certificate not present) In-Reply-To: <701b151d-2133-7916-3169-5d0f29cf3bb8@yandex.ru> Received-SPF: pass client-ip=2a02:6b8:0:801:2::108; envelope-from=hi-angel@yandex.ru; helo=forward105j.mail.yandex.net X-detected-operating-system: by eggs.gnu.org: No matching host in p0f cache. That's all we know. X-Spam_score_int: -20 X-Spam_score: -2.1 X-Spam_bar: -- X-Spam_report: (-2.1 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_PASS=-0.001, URIBL_BLOCKED=0.001 autolearn=_AUTOLEARN 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:251811 Archived-At: On Wed, 2020-06-03 at 17:21 +0300, Dmitry Gutov wrote: > On 03.06.2020 16:59, Konstantin Kharlamov wrote: > > > I am not sure why you say it seems wasteful. Do you mean perhaps, > > as > > opposed to setting, say, 100ms? > > Or 50ms, maybe. > > Wasteful of CPU cycles and laptop battery, I'd say. Of course, the > exact > impact depends on the size of your project. > > > 100ms I think is the top limit this > > timeout should be set. > > The defaults are not set in stone, we can discuss changing them on > the > company issue tracker. But it's a balancing act. Set the value too > small > -- and the result is more likely to annoy people who don't rely on > the > popup as much. > > > I just tested how quickly I can type a string > > "prog". I fired up `libinput debug-events` and tried to type > > "prog". The letter "g" says "+0.256s", i.e. it took 256ms. This > > means > > even if I set to 100ms, there's high chance I won't get any > > autocompletion. > > Should I take this to mean the completion request itself took 156ms > to > finish? I mean, I was typing outside Emacs, in the same terminal where `libinput debug-events` was running. I was just testing how fast I can type, to figure out how small the timeout should be set if I want a completion to pop up. > > > To be 100% sure, you should try it yourself (I don't do C/C++). > > > Maybe > > > someone else here can testify, though. > > > > Thank you! Indeed, I confirm this does seem to work with an async > > backend. I tested it as follows: > > > > 1. Opened a test.cpp file, enabled company-irony, checked that > > completion works. > > 2. I set `(setq company-idle-delay 0)` > > 3. I paused the irony-server process with `kill -SIGSTOP $(pidof > > irony-server)` > > 4. I tried typing a gibberish to see if I get any delay in > > rendering a > > text. > > > > I don't see any lags, so I assume using an async backend with the > > timeout set to 0 should work fine. > > Indeed, that's what asynchronous means. But the quality of the user > experience also depends on how quickly the backing server can handle > those requests. Well, I paused the backing server in the steps above, so server couldn't answer. This was emulating a behaviour where a user works with a project too big for backend to return a completion immediately. Expected behaviour was that I should not get any lags while typing, and there were no lags. > > This is great news! I wonder if > > company mode should default to zero or so timeout, and print a > > warning > > if somebody tries to connect a non-async backend? > > The majority of backends are synchronous. And the "standard" > completion > API for Emacs (which we want to integrate with) still only supports > the > synchronous convention. I am a bit confused by the last sentence. What's the relation between the Emacs API and already working company-mode? Did you mean, company- mode is trying to be compatible with backends for some standard Emacs API, and those can't be async?