From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#20629: 25.0.50; Regression: TAGS broken, can't find anything in C++ files. Date: Fri, 29 May 2015 20:12:34 +0300 Message-ID: <55689E02.5040605@yandex.ru> References: <555EC552.5010600@swipnet.se> <83fv6kysjf.fsf@gnu.org> <556447EF.3050103@yandex.ru> <83bnh7z8c5.fsf@gnu.org> <5564C2C7.5050909@yandex.ru> <837frvywfn.fsf@gnu.org> <55650812.60909@yandex.ru> <831ti2yu1a.fsf@gnu.org> <5565E28A.5040507@yandex.ru> <83wpzuxbtd.fsf@gnu.org> <5565E8AB.5020107@yandex.ru> <83r3q2xa3q.fsf@gnu.org> <5566583F.7020503@yandex.ru> <83h9qxxvo4.fsf@gnu.org> <5566EC49.8010907@yandex.ru> <837frsycly.fsf@gnu.org> <5567351E.7020006@yandex.ru> <83zj4owthp.fsf@gnu.org> <5567AE52.1000600@yandex.ru> <83fv6fx0nk.fsf@gnu.org> <55687241.5030200@yandex.ru> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=windows-1252; format=flowed Content-Transfer-Encoding: 7bit X-Trace: ger.gmane.org 1432919607 21569 80.91.229.3 (29 May 2015 17:13:27 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Fri, 29 May 2015 17:13:27 +0000 (UTC) Cc: 20629@debbugs.gnu.org To: Stefan Monnier Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Fri May 29 19:13:17 2015 Return-path: Envelope-to: geb-bug-gnu-emacs@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1YyNqL-0006rk-VG for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 May 2015 19:13:14 +0200 Original-Received: from localhost ([::1]:37140 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyNqL-0007qG-8w for geb-bug-gnu-emacs@m.gmane.org; Fri, 29 May 2015 13:13:13 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:60059) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyNqE-0007nW-Mx for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 13:13:10 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1YyNqB-0005vA-8u for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 13:13:06 -0400 Original-Received: from debbugs.gnu.org ([140.186.70.43]:50845) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1YyNqB-0005v4-5F for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 13:13:03 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.80) (envelope-from ) id 1YyNqA-0005Ff-Mz for bug-gnu-emacs@gnu.org; Fri, 29 May 2015 13:13: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: Fri, 29 May 2015 17:13:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 20629 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: Original-Received: via spool by 20629-submit@debbugs.gnu.org id=B20629.143291956520161 (code B ref 20629); Fri, 29 May 2015 17:13:02 +0000 Original-Received: (at 20629) by debbugs.gnu.org; 29 May 2015 17:12:45 +0000 Original-Received: from localhost ([127.0.0.1]:60820 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YyNps-0005F7-A6 for submit@debbugs.gnu.org; Fri, 29 May 2015 13:12:44 -0400 Original-Received: from mail-wg0-f43.google.com ([74.125.82.43]:33400) by debbugs.gnu.org with esmtp (Exim 4.80) (envelope-from ) id 1YyNpp-0005Eu-On for 20629@debbugs.gnu.org; Fri, 29 May 2015 13:12:42 -0400 Original-Received: by wgez8 with SMTP id z8so68116219wge.0 for <20629@debbugs.gnu.org>; Fri, 29 May 2015 10:12:36 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=sender:subject:to:references:cc:from:message-id:date:user-agent :mime-version:in-reply-to:content-type:content-transfer-encoding; bh=XxTtsF4P7cQHUyOfs3MkGfdgWAq/vOq7E3l4mkQi7cw=; b=B5z3zUgox+/e0Eei+OMArl+d8aF4nsMYOQc5sQISeNGCeladEFo1piI0HiERBUU8jj g2W5wNyvx7GltJIKYWMq3s9Kr4c+ArxSlg9ZgW60k1yFBjLijZ/eXIwl1ewVO6vvAXd2 rHCLvvCKqe/+/wc47q3Z8wSqgKwyfcP6pj+AVG+R+oduhyBiulpcUoY+JDnV4qaKB25r Sek/FT4dj8tT1CVghU6b3NPMfo5+xCG+Ct4E9VmQqnCE6FoCpltYlyFLfSB/Fm2ar2+8 c8LbltvugVJ72KQSU1OMfQjo1JkRszlODF6kCS1AZYaA09UV7XiqHKHUhzyh7x8/GINS 2Csw== X-Received: by 10.180.90.202 with SMTP id by10mr8301735wib.62.1432919556158; Fri, 29 May 2015 10:12:36 -0700 (PDT) Original-Received: from [192.168.0.185] (static-nbl2-118.cytanet.com.cy. [212.31.107.118]) by mx.google.com with ESMTPSA id nb9sm3981648wic.10.2015.05.29.10.12.35 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Fri, 29 May 2015 10:12:35 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:38.0) Gecko/20100101 Thunderbird/38.0 In-Reply-To: X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.15 Precedence: list X-detected-operating-system: by eggs.gnu.org: GNU/Linux 3.x X-Received-From: 140.186.70.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-bounces+geb-bug-gnu-emacs=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.bugs:103318 Archived-At: On 05/29/2015 07:51 PM, Stefan Monnier wrote: > FWIW, doubling the size of the TAGS file will also double the size of > the obarray and hence increase the completion time similarly regardless > of whether we keep using an obarray or if we switch to searching the > TAGS buffers. Completion using obarray is currently an order of magnitude (or two) faster than the proposed patch that just uses search. Doubling that won't be a problem. And the size of obarray may grow more than twice as big, or only a little, depending on what we're comparing to. The latter - if we're dealing with a C++ codebase with a lot of methods with the same name (and comparing against the same codebase where all names are qualified). In any case, we can choose which entries to include in the obarray, in Lisp. If we don't want the unqualified names in completions (or the qualified ones, for some reason), we won't put them in the obarray, but we'll still be able to find them if asked by the user. > Yet another alternative is to build a trie, which would speed up > prefix (and partial) completion (but not substring completion). It doesn't seem warranted thus far. Displaying the completions currently takes considerably longer than finding them in the obarray.