From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!.POSTED!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#26710: Fwd: 25.2; project-find-regexp makes emacs use 100% cpu Date: Sun, 30 Apr 2017 13:35:53 +0300 Message-ID: <3d76a3ac-32ad-412d-349d-5904fc964a2b@yandex.ru> References: <87a86zu3gf.fsf@hari-laptop.i-did-not-set--mail-host-address--so-tickle-me> <83vapnktcn.fsf@gnu.org> NNTP-Posting-Host: blaine.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Trace: blaine.gmane.org 1493548639 22939 195.159.176.226 (30 Apr 2017 10:37:19 GMT) X-Complaints-To: usenet@blaine.gmane.org NNTP-Posting-Date: Sun, 30 Apr 2017 10:37:19 +0000 (UTC) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:53.0) Gecko/20100101 Thunderbird/53.0 Cc: control@debbugs.gnu.org, 26710@debbugs.gnu.org To: Hariharan Rangasamy , Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Sun Apr 30 12:37:15 2017 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by blaine.gmane.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d4mE7-0005uF-A3 for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Apr 2017 12:37:15 +0200 Original-Received: from localhost ([::1]:44090 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d4mEC-0008R3-Ry for geb-bug-gnu-emacs@m.gmane.org; Sun, 30 Apr 2017 06:37:20 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:47152) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1d4mDy-0008Pz-SX for bug-gnu-emacs@gnu.org; Sun, 30 Apr 2017 06:37:09 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1d4mDu-0003fx-Ur for bug-gnu-emacs@gnu.org; Sun, 30 Apr 2017 06:37:06 -0400 Original-Received: from debbugs.gnu.org ([208.118.235.43]:48750) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1d4mDu-0003fp-Qw for bug-gnu-emacs@gnu.org; Sun, 30 Apr 2017 06:37:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1d4mDu-0008UE-3M for bug-gnu-emacs@gnu.org; Sun, 30 Apr 2017 06:37:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sun, 30 Apr 2017 10:37:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 26710 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 26710-submit@debbugs.gnu.org id=B26710.149354856432555 (code B ref 26710); Sun, 30 Apr 2017 10:37:02 +0000 Original-Received: (at 26710) by debbugs.gnu.org; 30 Apr 2017 10:36:04 +0000 Original-Received: from localhost ([127.0.0.1]:46949 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d4mCy-0008Sv-D0 for submit@debbugs.gnu.org; Sun, 30 Apr 2017 06:36:04 -0400 Original-Received: from mail-wm0-f49.google.com ([74.125.82.49]:35702) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1d4mCw-0008SM-0B; Sun, 30 Apr 2017 06:36:02 -0400 Original-Received: by mail-wm0-f49.google.com with SMTP id w64so71913800wma.0; Sun, 30 Apr 2017 03:36: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=zvOdF25UmChNkWstCyIVectyghwR5uVoFlTExjLCmyU=; b=BMDkWFnD1nCCfq5eiwjy0TFKRSKKSzR4PII04hYfeGF/PI+XLWSrXr7chCUVZPlyBY eNPeI63UWCXGxktgkvrCXg3R6h09AiXmpx4JzKNNxXr5zK2GbcVdurebS4Dyx02uQ1KS csx4SznBAMIEiZDiMnLiDUObzWariadeQ+OSov3I7EbMDHXmwC5M2SRIWTIqAQI8asGQ CVF1YY2WjHdU/GFaTC/bfvAo+Pd5sypB/vnFLE68EEXaueXiTbY1w3G/RN2LWLr3Y61S TLlYYjEicz8hnMDB526mBcCBFnV+kLojcqfwusx3FyhyEvHKabPGbfLfVNkTvHX+7a7r 8Ntw== 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=zvOdF25UmChNkWstCyIVectyghwR5uVoFlTExjLCmyU=; b=RrhXoGcQ75aSeqE9DYHGPxIcuEtS3BeDsSYq++WHKqMym7xc/C6q0B5m03s+seCAMN TMUeDuteLWfZy+CsV5MdyFIfxu2Z7x81fcjp4SEpXgqfUQVbQav6sT2xBiq7m4qUkh1I ZKZJDR+SWIrWG05IWHuJaL8LoEoQ72oEmlAp/9zTScgWlkD0g34enINIfzGZTM2TWb9Z IAvdf5UZTBGupj5MfSKeyoP2//QMYs2a/GNNEizh5bJb7cCxBVky73wDwN5b9+YadzN/ ZmBocJryP37gjXQIJ+yXDa+ySfiRulKwKzkKaTBKs3wPCbVPlKTUyvQ0sW+P4rDSwGIG uX/A== X-Gm-Message-State: AN3rC/7MpRnzwVCQtiE28EGJtQT1H1rKo7rXbnY7cVfC4tfrcNwjCRyV ZG7kdlLAR1RaqA== X-Received: by 10.28.12.78 with SMTP id 75mr3715721wmm.13.1493548556295; Sun, 30 Apr 2017 03:35:56 -0700 (PDT) Original-Received: from [192.168.1.3] ([185.105.173.156]) by smtp.googlemail.com with ESMTPSA id l81sm6534605wmi.22.2017.04.30.03.35.54 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 30 Apr 2017 03:35:55 -0700 (PDT) In-Reply-To: Content-Language: en-US X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 2.2.x-3.x [generic] X-Received-From: 208.118.235.43 X-BeenThere: bug-gnu-emacs@gnu.org List-Id: "Bug reports for GNU Emacs, the Swiss army knife of text editors" List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Original-Sender: "bug-gnu-emacs" Xref: news.gmane.org gmane.emacs.bugs:132125 Archived-At: retitle 26710 project-find-regexp blocks the UI stop On 30.04.2017 7:13, Hariharan Rangasamy wrote: > When the search is in progress, I'm unable to use emacs. > Emacs doesn't respond to any action until the search is over. OK, that's a reasonable complaint, especially when the search term is a rarely occurring one (so most of the time is spent in the external process). It is non-trivial to fix, however, while keeping the xref backend API and associated code sane. I'm hoping that the newly-added concurrency support can help us in that. I have not looked into actually using it, though. If someone (Eli?) would like to try their hand at it, or to even outline the basic direction such solution would use, that would be welcome. It seems we need two parts: - Generating some sort of lazy sequence from the external process' output, so that the return value of an xref backend call is still a sequence. - Being able to hook up in an asynchronous fashion to that sequence in a (second?) background thread, to render the search results in the xref buffer as soon as they appear.