From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.devel Subject: Re: xref and leaving "temporary" buffers open Date: Mon, 3 Aug 2015 05:12:32 +0300 Message-ID: <55BECE10.90800@yandex.ru> References: <55B2DC8F.3050305@yandex.ru> <55B3489C.2070009@gmx.at> <55B390CE.6020104@yandex.ru> <55B3994A.5010709@gmx.at> <55B3A0B6.6080101@yandex.ru> <55B3B0FC.3080004@gmx.at> <55B3EDBD.8050409@yandex.ru> <55B4C439.1040909@gmx.at> <55B4E5B3.3000108@yandex.ru> <55B65610.7070308@gmx.at> <55B77C57.6010306@yandex.ru> <55B82F77.3090204@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 1438567990 9455 80.91.229.3 (3 Aug 2015 02:13:10 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Mon, 3 Aug 2015 02:13:10 +0000 (UTC) Cc: martin rudalics , emacs-devel To: Stefan Monnier Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Mon Aug 03 04:12:59 2015 Return-path: Envelope-to: ged-emacs-devel@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 1ZM5FK-00087c-5i for ged-emacs-devel@m.gmane.org; Mon, 03 Aug 2015 04:12:58 +0200 Original-Received: from localhost ([::1]:57261 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZM5FJ-0005fT-4l for ged-emacs-devel@m.gmane.org; Sun, 02 Aug 2015 22:12:57 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:55294) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZM5F4-0005fN-Lp for emacs-devel@gnu.org; Sun, 02 Aug 2015 22:12:43 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZM5F1-0006Lq-Ev for emacs-devel@gnu.org; Sun, 02 Aug 2015 22:12:42 -0400 Original-Received: from mail-wi0-x22b.google.com ([2a00:1450:400c:c05::22b]:36305) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZM5F1-0006La-7j for emacs-devel@gnu.org; Sun, 02 Aug 2015 22:12:39 -0400 Original-Received: by wicgj17 with SMTP id gj17so84915574wic.1 for ; Sun, 02 Aug 2015 19:12:38 -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=o2ezlDNO04R8725XkZ7YxZAZn93x0pAK9QzBctTVFTw=; b=I9t9fSxMM3YjVUqEBvmWD7rOT7Eza4wiXOPZnwkzWgmC3/+/qpCvCvWEIxSnjLJuUS jQuwqYcdx1Pd0Aaajh4ejcraViJHfb8XuAFfOnKX7fuWgpeeZhqJ0EgQG8Kg+MInlnzx qVQ6F7XrM+0QLzupFvbQMC7HQHnRJiIDPsuA7RdQC8nO10xnqGnfBZdXKR9t1jDfWMno Kizpn/zlO3ovYyHSVLwbsrsB9EsCxzPZhKhrFCSWUMwqasgUUeepxAssYcnlEvUY9lrQ p0h7EPrF057Qgq1N1egOekaiUoYYk66mD84L6ehZ6PLodIebYwEuLqxNycx9U3bv8+pP W2SQ== X-Received: by 10.194.77.5 with SMTP id o5mr32233712wjw.102.1438567958146; Sun, 02 Aug 2015 19:12:38 -0700 (PDT) Original-Received: from [192.168.1.2] ([185.105.175.24]) by smtp.googlemail.com with ESMTPSA id lm5sm10968226wic.22.2015.08.02.19.12.36 (version=TLSv1.2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Sun, 02 Aug 2015 19:12:37 -0700 (PDT) User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:40.0) Gecko/20100101 Thunderbird/40.0 In-Reply-To: X-detected-operating-system: by eggs.gnu.org: Error: Malformed IPv6 address (bad octet value). X-Received-From: 2a00:1450:400c:c05::22b X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 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.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:188317 Archived-At: On 07/31/2015 12:41 AM, Stefan Monnier wrote: >> So, you'd limit the changes to the higher level, like read-buffer-to-switch >> and internal-complete-buffer-except? > > Yes. We'll need to also catch the moment, somehow, when an "incomplete" buffer become displayed as a result of user's action. And "complete" its initialization at that point. Would you use window-configuration-change-hook for that? > AFAIK they (should) all skip the "hidden buffers" (those starting with > a space), so we'd just have to make those incomplete buffers use a name > with a leading space. Indeed. Thinking about it initially, I was under impression that most of those tools have a view that shows all buffers including ephemeral (which could then be overwhelmed by the full list of "incomplete" buffers), but apparently not. The exceptions can adapt later. By the way, I'm considering naming them "delayed buffers" (like in delay-mode-hooks), and the respective function would be find-file-delayed. >> And depending on the file size, the overhead from vc-find-file-hook may >> become noticeable, too. In (find-file-noselect ".gitignore"), it takes more >> than half of the time (15 out of 25 ms), here. > > But for xdisp.c, that's probably negligible compared to the > syntax-propertize call ;-) Well, at least the slowdown will be proportional to the file size, and less impacted by the quantity only (that will improve the case of many small files). And we don't always need to propertize until the end of the file (the match could be in the beginning). Opening xdisp.c, even without calling syntax-propertize, takes a lot of time now, but that should be optimizable. Anyway, simply being allowed to open any files and not worry about cleaning up their buffers will simplify things for xref considerably.