From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Sean Whitton Newsgroups: gmane.emacs.bugs Subject: bug#74243: [PATCH] Speed up vc-hg-state by treating ignored files as unregistered Date: Tue, 26 Nov 2024 15:52:29 +0800 Message-ID: <87r06ytosi.fsf@melete.silentflame.com> References: <87mshy7jtp.fsf@melete.silentflame.com> Mime-Version: 1.0 Content-Type: text/plain Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="25429"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Gnus/5.13 (Gnus v5.13) Cc: 74243@debbugs.gnu.org To: Spencer Baugh Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Nov 26 08:53:26 2024 Return-path: Envelope-to: geb-bug-gnu-emacs@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 1tFqNw-0006SM-0Y for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 26 Nov 2024 08:53:24 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1tFqNc-0002qp-8S; Tue, 26 Nov 2024 02:53:04 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1tFqNa-0002qQ-KB for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 02:53:02 -0500 Original-Received: from debbugs.gnu.org ([2001:470:142:5::43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1tFqNa-0001lk-BD for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 02:53:02 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=debbugs.gnu.org; s=debbugs-gnu-org; h=MIME-Version:Date:References:In-Reply-To:From:To:Subject; bh=pa1XbxGH9Yk2ivNIFynbeA3oO5B3PzMhIvLdh7mPieM=; b=kCicUfXtjReM+4Pbsu8GlzMuCB3pNETziauBtxL7yiP309Fo/bpzRKNPEF+9egsVJUNOzt/qvQX0eyx5hBSDfbuzRZxGbDb7QkEH1n3NpfBKxmT2ebU0IKmltvVjPRedPq+PTqeo3MkUOIx8Lpmh9F6KxpY2tmhOh6ur+J+FsAjQPhuKmCHQtlAGMgct5hC5qj8Tl7WxGC5EtsWSM2crxEOacxC8QWzKhJm0n7adkyvotqYU+1n9HoCT4YusQkCqLpbZBdv9BEr4B70vt3P5Nd5K79wMG4ZhhwjKzmCOvGB7R+7LEAnUtujp52TapLAiMjYoZEBATO/dx3WPEyZVVQ==; Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1tFqNa-0003Sb-4M for bug-gnu-emacs@gnu.org; Tue, 26 Nov 2024 02:53:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Sean Whitton Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 26 Nov 2024 07:53:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 74243 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 74243-submit@debbugs.gnu.org id=B74243.173260756313269 (code B ref 74243); Tue, 26 Nov 2024 07:53:02 +0000 Original-Received: (at 74243) by debbugs.gnu.org; 26 Nov 2024 07:52:43 +0000 Original-Received: from localhost ([127.0.0.1]:45531 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFqNG-0003Rx-Th for submit@debbugs.gnu.org; Tue, 26 Nov 2024 02:52:43 -0500 Original-Received: from sendmail.purelymail.com ([34.202.193.197]:50550) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1tFqNE-0003Rf-Vs for 74243@debbugs.gnu.org; Tue, 26 Nov 2024 02:52:41 -0500 DKIM-Signature: a=rsa-sha256; b=FIqeMc882Q/0RIVQKUgs6dbaso70rJH5kaoOcDKKl8pw92IfRCdCMllx3MIVdeVSJ20u5wJ6WfNfeBYK4/0dyt18NP5ptPSpDDTeCJdOU8jrLC48b5ka9Xg9Xhah5hG70GOAo4LrKeBgz1n6NWqIphUn/oXG/MI3k+UyFL/pWgRgqqA12cMi9PlV2dyCwngi85ndfv68noYROwn9/vcWLoOTUexdUWAkcVGtbm4J/1V0/e3UrATcnWnj1h7tMm647blh8ziYdTCl8xKzrfobO7xPs7jDkIqMFl3zTQOyM75sOJOPVpUSyeTqn0PwkSeU9gcdR3Teg0NsLnYUfMW9XQ==; s=purelymail1; d=spwhitton.name; v=1; bh=qVwD/nhhfCpQ0hrFTlJwssj1yj0OPvp8boSbeRuN8f8=; h=Received:Received:From:To:Subject:Date; DKIM-Signature: a=rsa-sha256; b=N7gvmCHZFS4RPqwEaCbUiBLtLpQWXAqvPTCKV90Yx3Tn83EKJZ7OGmEJ0BqOX1sqt+6pCUsyDSueBAfdEVHbiAITDWyXShRI9yEZ/z9ImKsQZUnzhg1jYxkzLWinORpkZ/Ou8Zr5izy/q2gVaLasEtZ/XIxSBICDrXVlTIblr0HBvBJ43K7GTytmRPR4d8grSqfdhHL8TVloJYjRHrOcj7fuf4BIDXApqs6kgeVGU7zlRUKaf0oYPg0H6G0JcDF4EQLo77NgRlZhwcBx5I9mk7Rshq0R0aiMlB8WK2xFfiVzAXuM77C5l18oG1yFMnzduG6Vvw8IdK6GNMY9CIEaLA==; s=purelymail1; d=purelymail.com; v=1; bh=qVwD/nhhfCpQ0hrFTlJwssj1yj0OPvp8boSbeRuN8f8=; h=Feedback-ID:Received:Received:From:To:Subject:Date; Feedback-ID: 20115:3760:null:purelymail X-Pm-Original-To: 74243@debbugs.gnu.org Original-Received: by smtp.purelymail.com (Purelymail SMTP) with ESMTPSA id -1795065679; (version=TLSv1.3 cipher=TLS_AES_256_GCM_SHA384); Tue, 26 Nov 2024 07:52:33 +0000 (UTC) Original-Received: by melete.silentflame.com (Postfix, from userid 1000) id 4CFDE7ED990; Tue, 26 Nov 2024 15:52:29 +0800 (CST) In-Reply-To: (Spencer Baugh's message of "Tue, 19 Nov 2024 08:28:59 -0500") X-BeenThere: debbugs-submit@debbugs.gnu.org X-Mailman-Version: 2.1.18 Precedence: list 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-mx.org@gnu.org Original-Sender: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Xref: news.gmane.io gmane.emacs.bugs:295976 Archived-At: Hello, On Tue 19 Nov 2024 at 08:28am -05, Spencer Baugh wrote: > The original motivation of optimizing 'state is to speed up > vc-refresh-state and vc-after-save, since they call vc-hg-state in > find-file-hook and after-save-buffer, which adds very noticeable > latency. (I care less about the speed of vc-dir, which uses > 'dir-status-files not 'state) > > So those functions would need to pass this argument. But they (through > vc-state-refresh) then store the returned state in 'vc-state in the VC > per-file properties, so anyone accessing that will also see the effect > of this argument. I see what you mean. Quoting vc-state, | A return of nil from this function means we have no information on the | status of this file. | [...] | `ignored' The file showed up in a dir-status listing with a flag | indicating the version-control system is ignoring it, | Note: This property is not set reliably (some VCSes | don't have useful directory-status commands) so assume | that any file with vc-state nil might be ignorable | without VC knowing it. | | `unregistered' The file is not under version control." | | ;; Note: we usually return nil here for unregistered files anyway | ;; when called with only one argument. This doesn't seem to cause | ;; any problems. But if we wanted to change that, we should | ;; probably opt for redefining the `registered' command to return | ;; non-nil even for unregistered files (maybe also rename it), and | ;; then make sure that all `state' implementations handle | ;; unregistered file appropriately. (I think there's a mistake here: an ignored file is not a file "under version control", so `unregistered' should say "not under version control and not ignored". Would you agree?) Thanks for pointing out the involvement of find-file-hook and after-save-hook. The problem you describe is not at all Hg-specific: vc-state gets called in a context where speed matters, but it's also the primary entry point for any code that wants to know the state of a file, some of which might care more about accuracy than speed. To put it another way, the code assumes throughout that finding out the file state will always be fast. But it also assumes the information is accurate if present. This makes me queasy about your original patch. It does not seem wise to return something we don't know to be true only on the basis that it all works out fine for now. The 'nil' return value might provide us with a way out, however. Could we add an optional argument to vc-state that means "just return nil if finding out the state properly might be slow"? Could we make vc-after-save and the relevant find-file-hook entry pass that option through, and do something sensible with a nil return value? If they get nil, they would clear out the saved property, and possibly update the mode line display to "????" or something. Maybe we'd want a user option (that could go in your large repo's .dir-locals.el, so it's set-and-forget) to opt-in to not knowing the file state as often. -- Sean Whitton