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: Automatic (e)tags generation and incremental updates Date: Tue, 12 Jan 2021 03:33:10 +0200 Message-ID: <106abdbb-ce7a-4911-0831-149da3dccfb3@yandex.ru> References: <779a6328-9ca5-202a-25a2-b270c66fe6dd@yandex.ru> <8fc5e96c-ebb8-c668-9b2a-c7c4ee54c0b9@yandex.ru> <83r1mwltob.fsf@gnu.org> <0bee9ab4-46bc-b6fd-97b6-e26cc80f1610@yandex.ru> <875z45dbm7.fsf@tromey.com> <1e9c9572-52ee-339b-78a2-731b9eb5f3de@yandex.ru> <871resd93f.fsf@tromey.com> <83mtxffrou.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="20012"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: philipk@posteo.net, tom@tromey.com, emacs-devel@gnu.org, john@yates-sheets.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane-mx.org@gnu.org Tue Jan 12 02:34:15 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 1kz8Zb-00056K-IM for ged-emacs-devel@m.gmane-mx.org; Tue, 12 Jan 2021 02:34:15 +0100 Original-Received: from localhost ([::1]:42136 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kz8Za-0000s4-GR for ged-emacs-devel@m.gmane-mx.org; Mon, 11 Jan 2021 20:34:14 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:49394) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kz8Yj-0000PT-Ro for emacs-devel@gnu.org; Mon, 11 Jan 2021 20:33:21 -0500 Original-Received: from mail-ed1-x536.google.com ([2a00:1450:4864:20::536]:39064) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kz8Yg-0005MF-7r; Mon, 11 Jan 2021 20:33:19 -0500 Original-Received: by mail-ed1-x536.google.com with SMTP id c7so515519edv.6; Mon, 11 Jan 2021 17:33:16 -0800 (PST) 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=9hgeBDvx0Mzg3i7fr5naaeK9Y/g5dEfGysqv6MBwfmY=; b=aEJ3qk+y6AUIno80hk/IyuVn3nHXjeVNysaRdYAYvKMyjuuGyMHezmAXdHF8d4ysUb MZlcaRg0BikITRGV0a0uxXLukD+lslodFizcBvUZCUcHuD+r1GCrq0kAivg6zqXTN/aa fWpX6femfIJR/virJi+p6FVviJs0YQSrgAWi4AHEUxDkAxFRihJINMTgHHOViLTWm5UE s3EdkpmCKcjDnDGvYxW9zk3ryFttUWgqJlu8InGo9XEjZvwWuWD6RmBrrI6xytgaL+KV rIXkUPb617W6SMBu+eEiOuwailKI6PA/FNirykvZ/UoZP+EW65nIiCpATpGMYTI8lG+W S6QQ== 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=9hgeBDvx0Mzg3i7fr5naaeK9Y/g5dEfGysqv6MBwfmY=; b=cCg6gPP9/nNjm0F4z32+UFEmJFK76miBMBWI4xICHA+0paP5RPGFY6U2E5WPZy2Exm vKvoKuIV6k4HeIUcCC6H8YCto4AOaStzcs93g2EVbuILKd7pzTdJmAvNSb9HZpvahHTA TsxCfmCjMUp7ejwpdQokUYcOq13xLOZ8pFWolYmLwdT22dHiYZX1GYjtE434QcwmnPsz LyyBS9KXPwYNPCxndBzJo9OvR7jlpFZyYGDtztDCYVyVUIAZ6LmskglsByb/yLbbWYQ/ 9Xb1wx1gHi2vhMfuKFfekNRiyjnp61WpqnRWsDw67GyhIJWZxUxJPD6qDCL+V0iI+i+H NHNQ== X-Gm-Message-State: AOAM532vGxdZf+/Cqc/SF1r4rzTuu/apk9ACJ7SDPteJLDaaA4d8LT00 dCBPwE1veWO6v8tyy6r/T0q2xGJVoIuHwA== X-Google-Smtp-Source: ABdhPJxz0d1wHqTyZ003xMAlrdP1USr4AosAd5YmVlYqTRfZjEXb80bvaVHgRUrrFa7r/MIvc2YDGA== X-Received: by 2002:a50:b905:: with SMTP id m5mr1470603ede.292.1610415194513; Mon, 11 Jan 2021 17:33:14 -0800 (PST) Original-Received: from [192.168.0.6] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id i13sm703772edu.22.2021.01.11.17.33.12 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 11 Jan 2021 17:33:13 -0800 (PST) In-Reply-To: <83mtxffrou.fsf@gnu.org> Content-Language: en-US Received-SPF: pass client-ip=2a00:1450:4864:20::536; envelope-from=raaahh@gmail.com; helo=mail-ed1-x536.google.com X-Spam_score_int: -14 X-Spam_score: -1.5 X-Spam_bar: - X-Spam_report: (-1.5 / 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.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=no 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:262954 Archived-At: On 11.01.2021 16:56, Eli Zaretskii wrote: >> Correction: it's actually writing the updated file to disk which takes >> half a second. This call: >> >> (write-region (point-min) (point-max) buffer-file-name nil 'silent) >> >> I wonder if *that* could be done asynchronously. > > What kind of asynchronicity did you have in mind? One where the Lisp code doesn't have to wait for the disk write to complete. Could use being able to set up a callback for the end, though. > And I'm probbaly missing something, because I don't understand how > Emacs is involved in updating the tags table. It's part of the secret sauce for the quick incremental updates: if etags writes to disk, even just to update one file's index, we'll have to revert-buffer, and the bigger the tags file is, the longer the revert will take. Basically, N(project-size). To go around that, when updating a file, we delete its existing entry inside the buffer visiting the tags file, and then call etags directing its output to the end of the same buffer. This way we avoid reverting the buffer, although the completion table still needs to be regenerated. To synchronize the buffer contents with disk, though, we need that write-region. *If* we want to synchronize it, of course, e.g. to be able to open the file in some future Emacs session. Or I guess we could write to that file only once later, in kill-emacs-hook. BTW, writing it to disk becomes 10x faster if the tags file is visited literally. I wonder if that mode could work well for most users. Some quick testing showed that it's functional, though I'm guessing it won't work for identifiers containing unicode characters.