From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Eli Zaretskii Newsgroups: gmane.emacs.bugs Subject: bug#67687: Feature request: automatic tags management Date: Thu, 28 Dec 2023 11:30:20 +0200 Message-ID: <83y1de7jyr.fsf@gnu.org> References: <2f86b882-9ec1-f63f-d90b-5f8f7ae114f2@gutov.dev> <58D84A29-9A63-45BA-AD8B-B476CDC931A1@gmail.com> <812729c8-726f-d60e-2603-2d8e588929fd@gutov.dev> <835y0sgg12.fsf@gnu.org> <661f4951-cb0a-5257-63b0-efe71a0d217e@gutov.dev> Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5796"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 67687@debbugs.gnu.org, eskinjp@gmail.com, stefankangas@gmail.com To: Dmitry Gutov Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Dec 28 10:32:30 2023 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 1rImkg-0001J1-KH for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 28 Dec 2023 10:32:30 +0100 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rImkH-0005zg-Fm; Thu, 28 Dec 2023 04:32:05 -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 1rImkF-0005zD-Ma for bug-gnu-emacs@gnu.org; Thu, 28 Dec 2023 04:32:03 -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 1rImkF-0004Cl-Cq for bug-gnu-emacs@gnu.org; Thu, 28 Dec 2023 04:32:03 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rImkE-0005Ut-7J for bug-gnu-emacs@gnu.org; Thu, 28 Dec 2023 04:32:02 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Eli Zaretskii Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 28 Dec 2023 09:32:02 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 67687 X-GNU-PR-Package: emacs Original-Received: via spool by 67687-submit@debbugs.gnu.org id=B67687.170375586919813 (code B ref 67687); Thu, 28 Dec 2023 09:32:02 +0000 Original-Received: (at 67687) by debbugs.gnu.org; 28 Dec 2023 09:31:09 +0000 Original-Received: from localhost ([127.0.0.1]:38486 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rImjM-00058V-De for submit@debbugs.gnu.org; Thu, 28 Dec 2023 04:31:09 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:42286) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rImjJ-0004xv-U9 for 67687@debbugs.gnu.org; Thu, 28 Dec 2023 04:31:06 -0500 Original-Received: from fencepost.gnu.org ([2001:470:142:3::e]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1rImjE-00041A-UF; Thu, 28 Dec 2023 04:31:00 -0500 DKIM-Signature: v=1; a=rsa-sha256; q=dns/txt; c=relaxed/relaxed; d=gnu.org; s=fencepost-gnu-org; h=References:Subject:In-Reply-To:To:From:Date: mime-version; bh=2xQ6BNnl3eEPEHYsetxcZzrcPecDueKYCCU68MGYm7k=; b=AoFQj8x+ZuQU nZJKUjrpiGnbWu/dEB+R0Knr3Hu3HVwLVoXzojiX10UzXTUcA+bRgRv86KsLtGfRZfC5OBUvH8xIY ZBtagUMXgR9gZ2hUJmW0c0EwoMfJSaa1w/6+Gs9ZQdaalaYY+JLZ3GA9X19JcloYVWpbup5i/2lYJ 8xC/1TWe0WGhXW/Txoy/5nQpyez34vrEtzlcg/RU4iypp/H1g5MbWihrMYjp9QOnaRwi0NekIJCv1 0UicTtoNGXDw3yZNPh6dLyU4lGbC3JIfUanwCxjHLnzqucrMyN+Zq2dPA2iaAqFZhOm5lOkbeRoh+ 1jQnn4iPxkiWAF3vj8dPDQ==; In-Reply-To: (message from Dmitry Gutov on Sun, 24 Dec 2023 03:43:25 +0200) 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:276966 Archived-At: > Date: Sun, 24 Dec 2023 03:43:25 +0200 > From: Dmitry Gutov > Cc: 67687@debbugs.gnu.org, eskinjp@gmail.com, stefankangas@gmail.com > > On 22/12/2023 01:37, Dmitry Gutov wrote: > > On 21/12/2023 18:46, Dmitry Gutov wrote: > >> See instead the patch attached to this bug report. > > > > Here's an update, incorporating the feedback from here and there. > > Fixed a typo in dir-locals and implemented better support for > etags-regen-ignores (though with one omission). > > To me it looks good to check in now. Thanks, I have a few minor comments. > +(defcustom etags-regen-program (executable-find "etags") > + "Name of the etags program. > + > +If you only have `ctags' installed, you can also set this to > +\"ctags -e\". Some features might not be supported this way." > + ;; Always having our 'etags' here would be easier, but we can't > + ;; always rely on it being installed. So it might be ctags's etags. > + :type 'file) Please add :version tags to all the defcustoms you add. > +(defcustom etags-regen-tags-file "TAGS" > + "Name of the tags file to create inside the project. This and the other defcustom's here should say in the first line of the doc string that they are for etags-regen-mode. This will help discoverability and also produce a more helpful display with the various apropos commands. > +This value should either be a simple file name (no directory ^^^^^^^^^^ "The value" or just "Value". > +specified), or a function that accepts a project root directory > +and returns a distinct file name for the tags file for it. That function should also return only a file name without leading directories, right? If so, the text should be more explicit about that. For example: Value should be either a string specifying a file name without leading directories, or or a function that accepts a project's root directory and returns such a file name, to be used as the tags file for that project. > The > +latter option is most useful when you prefer to store the tag ^^^^^^ Using "option" in a doc string of a user option might be ambiguous. I suggest to use "alternative" or "possibility" instead. > +files somewhere outside -- e.g. in `temporary-file-directory'." So the function could return a file name _with_ leading directories? > +;;;###autoload > +(put 'etags-regen-file-extensions 'safe-local-variable > + (lambda (value) (and (listp value) (seq-every-p #'stringp value)))) Why not use list-of-strings-p here? > +;;;###autoload > +(put 'etags-regen-ignores 'safe-local-variable > + (lambda (value) (and (listp value) (seq-every-p #'stringp value)))) And here. > + (if (> (+ (length added-files) > + (length changed-files) > + (length removed-files)) > + 100) > + (progn > + (message "etags-regen: Too many changes, falling back to full rescan") Should the magic 100 value be a defvar, not a hard-coded constant? > +(defun etags-regen--maybe-generate () > + (let ((proj)) Would (let (proj) do here? IOW, why the extra pair of parens? > + (lambda (f) (or (not (string-match-p match-re f)) > + (string-match-p "/\\.#" f) Is that '/' there to detect regexps for absolute file names? If so, that won't work for Windows. > +(defun etags-regen--ignore-regexp (ignore) > + (require 'dired) > + ;; It's somewhat brittle to rely on Dired. > + (let ((re (dired-glob-regexp ignore))) > + ;; We could implement root anchoring here, but \\= doesn't work in > + ;; string-match :-(. > + (concat (unless (eq ?/ (aref re 3)) "/") > + ;; Cutting off the anchors. > + (substring re 2 (- (length re) 2)) > + (unless (eq ?/ (aref re (- (length re) 3))) > + ;; Either match a full name segment, or eos. > + "\\(?:/\\|\\'\\)")))) Same here: what is the purpose of comparisons with a slash? I think we need some more comments there explaining the logic of the code. > +(defun etags-regen--append-tags (&rest file-names) > + (goto-char (point-max)) > + (let ((options (etags-regen--build-program-options (etags-regen--ctags-p))) > + (inhibit-read-only t)) > + ;; XXX: call-process is significantly faster, though. > + ;; Like 10ms vs 20ms here. > + (shell-command > + (format "%s %s %s -o -" > + etags-regen-program (mapconcat #'identity options " ") > + (mapconcat #'identity file-names " ")) > + t etags-regen--errors-buffer-name)) Should we indeed use call-process?