From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: David Fussner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" Newsgroups: gmane.emacs.bugs Subject: bug#53749: 29.0.50; [PATCH] Xref backend for TeX buffers Date: Tue, 23 Apr 2024 14:21:52 +0100 Message-ID: References: <1de34060-e93b-0a42-fff5-20e283abe0dc@yandex.ru> <87o7vq0zir.fsf@gnus.org> <8735d20yvd.fsf@gnus.org> <2c5c8afa-b57e-3156-d21c-5523cacb4d87@yandex.ru> <831qf1mgjl.fsf@gnu.org> <87cyyj9rpp.fsf@gnu.org> <65793.1694843596@localhost> Reply-To: David Fussner Mime-Version: 1.0 Content-Type: text/plain; charset="UTF-8" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="3393"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 53749@debbugs.gnu.org, Ikumi Keita , Dmitry Gutov , Stefan Monnier , Tassilo Horn , Eli Zaretskii , stefankangas@gmail.com To: Arash Esbati Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Apr 23 15:23:31 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 1rzG7P-0000i9-2n for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 23 Apr 2024 15:23:31 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1rzG72-0002W0-0c; Tue, 23 Apr 2024 09:23:08 -0400 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 1rzG6q-0002VB-Ll for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2024 09:22:58 -0400 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 1rzG6q-0002uv-3v for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2024 09:22:56 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1rzG76-0000Wb-03 for bug-gnu-emacs@gnu.org; Tue, 23 Apr 2024 09:23:12 -0400 X-Loop: help-debbugs@gnu.org Resent-From: David Fussner Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 23 Apr 2024 13:23:11 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 53749 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: pending patch Original-Received: via spool by 53749-submit@debbugs.gnu.org id=B53749.17138785541183 (code B ref 53749); Tue, 23 Apr 2024 13:23:11 +0000 Original-Received: (at 53749) by debbugs.gnu.org; 23 Apr 2024 13:22:34 +0000 Original-Received: from localhost ([127.0.0.1]:52150 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzG6M-0000Gs-Hg for submit@debbugs.gnu.org; Tue, 23 Apr 2024 09:22:33 -0400 Original-Received: from mail-pl1-x629.google.com ([2607:f8b0:4864:20::629]:57533) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1rzG66-0000A6-N8 for 53749@debbugs.gnu.org; Tue, 23 Apr 2024 09:22:21 -0400 Original-Received: by mail-pl1-x629.google.com with SMTP id d9443c01a7336-1e3f17c6491so44761495ad.2 for <53749@debbugs.gnu.org>; Tue, 23 Apr 2024 06:21:54 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=googlemail.com; s=20230601; t=1713878508; x=1714483308; darn=debbugs.gnu.org; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:from:to:cc:subject:date:message-id:reply-to; bh=rCjX6uk1DuX1uS2qa/XC12uCoY3pARo2nIHg3Nn1W30=; b=NdWpivMPhFM47/ZETyEwB2Kn0JTbsFnNd/VfmOSniBbtl83tAVZX6nHarAulhIhO+f /aCO4Mc9Ch0MfhpkuEs5neK4SgOwivXXa5WIlU4F0OY7TDW1KGPkdx5j0hYif3a6rLvM nn6ErPZDR90vUFoOhtDp7N6aML1mf5Wn7mzAIH2G3vp1ZecwJX4TDp6XIdpaCuUIeEKB ML/f4CDQPEWA90Mc4bOps8p10+vpD7bUg9JgK3thAMGIyi8ttwre2KM6OP7uehouXc8L FYv0NvmAION9MHaCRH5Jk677x1zR+zGpaM59GHs7MR65Gk0UKGqPpRMPjXimhn10suY4 6Mkw== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1713878508; x=1714483308; h=cc:to:subject:message-id:date:from:in-reply-to:references :mime-version:x-gm-message-state:from:to:cc:subject:date:message-id :reply-to; bh=rCjX6uk1DuX1uS2qa/XC12uCoY3pARo2nIHg3Nn1W30=; b=lEheCCdrc5tvI2IKdgLKIPEHSRpLrH8tghWdg60JykCrWTdVu3i15DcuHZMnQ0EoSF 7bjONHYWm3pZQn2vt9Hcq5Jh7+QlqB3dOHl+GulDqC5r9hkWAjP818eS/WcCm/oh37dD 7irPBW1H+9V8+lO7OC+csuJuXzrQubRKlGJjV23GYf+5527Og69IwJtGGSaeA04B/Xyh wxest9Yg4SvX9ulwyKFrKQY8gDLI6KpLvEea+yL//kZdUNX6XeDEYIoduSRaLsMa7PGV UMnV8TKiG8nIMgrdQIFmFWMX+CwCcqR3uOyMO4cYkcs88YyXL1w07ApplxGTe37U4ecM P+Bg== X-Forwarded-Encrypted: i=1; AJvYcCVmx3t3GYCMBfShldk6vwI9ve+s81Rzk0EjlyWFFS6tx9ce19s1q1bnH5X4HgmyvFeqq1FYpZgpMd6vg0cHkGlDQN20Gn0= X-Gm-Message-State: AOJu0YyZYlS2J+kmtG5ATPf+c714AmL4ZBWbKqDhtmzmCTXhJLgB+N/R 802Sleg3DWxwd0FR/k+lS8CVSwCjzG5K9k88WGryDA1wYcEwAyeAJECSmt75uJm12SwCmnIz2ft tVvnJLlcLtKs7awiLxJiqatgSxd0= X-Google-Smtp-Source: AGHT+IGCEiFEagmAWn69b6NCyF0aARFWihoKGqf7CPc/FNuTjpsjNH04vRG/j/kpNeIIEB52hfRvzz4DxJ1O6vNxjPk= X-Received: by 2002:a17:902:dac7:b0:1e8:2c8d:b74a with SMTP id q7-20020a170902dac700b001e82c8db74amr15066997plx.10.1713878507913; Tue, 23 Apr 2024 06:21:47 -0700 (PDT) In-Reply-To: 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:283883 Archived-At: Thanks for the reply, Arash. > I'm not familiar with the way xref works, but reading the above, xref > doesn't care about modes set per file variables, is this correct? As far as I know, the default xref-find-references deals strictly in file extensions. > I think this is almost impossible. Besides the effort, take for example > the .cnf extension which is used by other programs as well, so > associating it with LaTeX-mode wouldn't make sense, IMO. Agreed -- this may be an argument against my current approach. I hope, however, that the way xref-find-references searches by directory or by project should limit spurious searching when a more common extension appears on a TeX file. > This is possibly the next mess since .tex can be plain-TeX, ConTeXt, > LaTeX ... I guess currently I'm thinking that this is sort of a feature, as searching for symbols in files/buffers from many closely-related modes may produce useful matches. The code I'm finishing up tends to search more files rather than fewer, but it should be possible to prune this if it's deemed too messy. > So in general, I second what Stefan M. wrote in his other > message, but respecting/using file local variables could help here. Currently, the code takes into account file-local variables only by including in the search list extensions of TeX-related buffers, which may well only have become TeX-related due to such variables. I'll post a patch as soon as I solve an outstanding issue or two, and we'll see where we are. Thank you indeed for your help, David. On Tue, 23 Apr 2024 at 13:04, Arash Esbati wrote: > > David Fussner writes: > > > Thanks for the nudge. I am in fact in the final stages of preparing a > > new patch to get xref working in TeX buffers. > > Thanks for the update. > > > The semantic/symref backend used by xref-find-references greps in > > files matching the major-mode of the buffer where the user calls the > > command. It looks in semantic-symref-filepattern-alist for > > file-extensions matching the major-mode, and if that fails it looks in > > auto-mode-alist. When both fail to produce any file extensions it > > tells the user to customize semantic-symref-filepattern-alist. Also, > > if it finds things in s-s-f-a, it doesn't go on to auto-mode-alist, so > > s-s-f-a has to be complete in order to be useful. In effect, we need > > s-s-f-a to hold all the extensions for all the modes that can appear > > as values of major-mode, and I notice that AUCTeX has started to > > populate that alist, though incompletely. > > I'm not familiar with the way xref works, but reading the above, xref > doesn't care about modes set per file variables, is this correct? > > > I'm also aware that many packages add their own extensions to files > > which are basically TeX or LaTeX files, and I wonder whether we can > > really keep up with the whole of CTAN in terms of providing complete > > lists of extensions for s-s-f-a. > > I think this is almost impossible. Besides the effort, take for example > the .cnf extension which is used by other programs as well, so > associating it with LaTeX-mode wouldn't make sense, IMO. Finally, I > think many packages are written in .dtx format and the ones with many > files with different extensions (.def, .enc, .fd, ...) usually extract > them from the .dtx via an .ins file, so the edited source is inside the > .dtx, and we don't need to care about these extensions. > > > As an example of where we are, if you open a plain-tex-mode (or > > plain-TeX-mode) file and M-? with point on some standard word you'll > > currently get the message to customize s-s-f-a, because > > auto-mode-alist has only tex-mode and s-s-f-a doesn't cover them, > > either. > > This is possibly the next mess since .tex can be plain-TeX, ConTeXt, > LaTeX ... So in general, I second what Stefan M. wrote in his other > message, but respecting/using file local variables could help here (if > it doesn't work ATM, see above), e.g.: > > --8<---------------cut here---------------start------------->8--- > \beginsection 1. Introduction. > This is the start of the introduction. > \bye > > %%% Local Variables: > %%% mode: plain-TeX > %%% TeX-master: t > %%% End: > --8<---------------cut here---------------end--------------->8--- > > HTH. Best, Arash