From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dave Abrahams Newsgroups: gmane.emacs.bugs Subject: bug#64198: Feature request: compile.el's "Find this in" prompt should be hookable. Date: Thu, 22 Jun 2023 14:49:56 -0700 Message-ID: <1601C730-4525-4130-8746-FF57FD743DD5@boostpro.com> References: <837crx5a8x.fsf@gnu.org> <03EC2FC3-A297-4CD1-91FB-2262A319A6F3@boostpro.com> <83ilbf2zx6.fsf@gnu.org> <3D7A63CD-5B7B-412A-8C55-90EFFA294F09@boostpro.com> Mime-Version: 1.0 (Mac OS X Mail 16.0 \(3731.600.7\)) Content-Type: multipart/alternative; boundary="Apple-Mail=_0A6A6292-7228-4684-95F6-F6702F17C0AB" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5129"; mail-complaints-to="usenet@ciao.gmane.io" Cc: Eli Zaretskii , 64198@debbugs.gnu.org To: Daniel =?UTF-8?Q?Mart=C3=ADn?= Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Thu Jun 22 23:51:51 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 1qCSDW-00017F-6h for geb-bug-gnu-emacs@m.gmane-mx.org; Thu, 22 Jun 2023 23:51:50 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1qCSD0-0006Pn-01; Thu, 22 Jun 2023 17:51:18 -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 1qCSCk-000659-SV for bug-gnu-emacs@gnu.org; Thu, 22 Jun 2023 17:51:02 -0400 Original-Received: from debbugs.gnu.org ([209.51.188.43]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1qCSCk-0008Om-DC for bug-gnu-emacs@gnu.org; Thu, 22 Jun 2023 17:51:02 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1qCSCk-0001Ju-0o for bug-gnu-emacs@gnu.org; Thu, 22 Jun 2023 17:51:02 -0400 X-Loop: help-debbugs@gnu.org Resent-From: Dave Abrahams Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Thu, 22 Jun 2023 21:51:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 64198 X-GNU-PR-Package: emacs Original-Received: via spool by 64198-submit@debbugs.gnu.org id=B64198.16874706175022 (code B ref 64198); Thu, 22 Jun 2023 21:51:01 +0000 Original-Received: (at 64198) by debbugs.gnu.org; 22 Jun 2023 21:50:17 +0000 Original-Received: from localhost ([127.0.0.1]:36891 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qCSC0-0001Iw-V8 for submit@debbugs.gnu.org; Thu, 22 Jun 2023 17:50:17 -0400 Original-Received: from mail-yw1-f178.google.com ([209.85.128.178]:53373) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1qCSBx-0001Ih-PZ for 64198@debbugs.gnu.org; Thu, 22 Jun 2023 17:50:14 -0400 Original-Received: by mail-yw1-f178.google.com with SMTP id 00721157ae682-57026f4bccaso80458777b3.2 for <64198@debbugs.gnu.org>; Thu, 22 Jun 2023 14:50:13 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=boostpro-com.20221208.gappssmtp.com; s=20221208; t=1687470608; x=1690062608; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:from:to:cc:subject:date:message-id:reply-to; bh=FEGp6MYpjQluEug0CbglZRW50KLQ1UV1weV/GBhGBdc=; b=wsQkK/3q1UkwGHSVkMoT44cjaj5bZUmpcqwOEvYbXEST+UQdJ1A7L5qPJbVet8CDZC RCYSg4C5j0N1jinJDxv49tNnwX4etehdwPqjQsk/s7thXfgBw6soE/EcvB6RRFXJq6T+ v8ZHCRbNEK0JnLFCEdlHhqhr+/4ubYLFXtVx3S75ZxNf0m48bN28Sif7eCnGD+0LvMEI 9UJq4wgnxToSuVt7wehywX37EYSRqIuwZHiZbrsX0zXogti4Fu412I4ZeXrMrWT8SX3S P8/Wg2VXIem9uayzmh8jsgD2tTeJiQ+Fw5Ita3ZQQnJgyM6l4ME3yaoyV3/fZFMGtGfs wCew== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1687470608; x=1690062608; h=references:to:cc:in-reply-to:date:subject:mime-version:message-id :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=FEGp6MYpjQluEug0CbglZRW50KLQ1UV1weV/GBhGBdc=; b=YqMJrfw4tq/o5ay2w69+RgNG7qGXTpOVMqbHpw+bggX6rGb8u0ZEpbEb26anbSGIig rfSrRCnZQWBy00N+3U8ct299WsFNmrudXxRieso14GCjuAmwHGwsZdKkD+ARcctl4j4D A/kxqv/q+9PDdqpa1peJLQWP+ydG5TmaUIUmukfcEbSq7S+cJIRnbbOATQ9ZhcEwjlsu 0WO1MNwCcwoEYTyv+jXMK6kuWdGOLuUcuwOxD5LvFwKL3Nw9JV9vjVGGCWTOczTNM8YX 3D5hyXBi5g+ihsJgXb4Kj1HCzTpjbwbEPyfbmWp5uGDmzfDW49w4VbR4nAuyk1PiRHKc 0IIg== X-Gm-Message-State: AC+VfDwgnrhvvhUJRlmAHs6xHGHPb3gwOc5r74QcGwOHLwc+lGurjFBt fRnJTbwjDVxLTt22oBwmrjUliA== X-Google-Smtp-Source: ACHHUZ5LFRCK4BiNa3SNg+GuFN55O/4ykD7BwYkz4RKzNehwJjGgPHpWumFbIdz0Id8tz2oRhccirA== X-Received: by 2002:a81:7109:0:b0:572:2759:c099 with SMTP id m9-20020a817109000000b005722759c099mr13075190ywc.52.1687470608100; Thu, 22 Jun 2023 14:50:08 -0700 (PDT) Original-Received: from smtpclient.apple (69-209-31-205.lightspeed.sntcca.sbcglobal.net. [69.209.31.205]) by smtp.gmail.com with ESMTPSA id x124-20020a81a082000000b0054c0f3fd3ddsm2105150ywg.30.2023.06.22.14.50.06 (version=TLS1_2 cipher=ECDHE-ECDSA-AES128-GCM-SHA256 bits=128/128); Thu, 22 Jun 2023 14:50:07 -0700 (PDT) In-Reply-To: X-Mailer: Apple Mail (2.3731.600.7) 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:263922 Archived-At: --Apple-Mail=_0A6A6292-7228-4684-95F6-F6702F17C0AB Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset=utf-8 > On Jun 22, 2023, at 10:58 AM, Daniel Mart=C3=ADn = wrote: >=20 > Dave Abrahams > writes: >>=20 >> Swift is a programming language. When its assertions (like C's >> assert() macro) fail, a diagnostic is output with a file ID and >> line. The file ID looks like a path, but it's really not. If it's a >> path in the filesystem, that's coincidental but it's likely to point >> to the right file. I don't want to manually hunt down the file every >> time an assertion fails; I'd rather emacs made an educated guess = based >> on the current project. It's obviously not the right answer for >> everyone, but I'd like to have the hooks needed to implement that >> without too much hackery. >=20 > This is the Elisp code you posted on GitHub, based on customizing > compilation-parse-errors-filename-function: >=20 > (defun dwa/path-tails-matching (path paths) > "Returns the elements of PATHS with PATH as their suffix, matching by = path component." > (let ((tail (file-name-concat "/" path))) > (seq-filter (lambda (full-path) (string-suffix-p tail full-path)) = paths))) >=20 > (defun dwa/compilation-parse-errors-filename-in-project = (path-in-error) > "If PATH-IN-ERROR is found in the filesystem, returns it > unchanged; otherwise tries to return a unique file in the current > project likely to be identified by PATH-IN-ERROR. Returns > PATH-IN-ERROR unchanged if no such file can be found." > (if (file-exists-p path-in-error) path-in-error > ;; First look for relative path suffixes. > (let* ((candidates (project-files (project-current t))) > (full-matches (dwa/path-tails-matching path-in-error = candidates))) >=20 > ;; If not found, try just the filename component of > ;; path-in-error; Swift assertions are weird and include a > ;; module name that doesn't necessarily correspond to anything in = the > ;; filesystem. > (cond ((null full-matches) > (let ((filename-matches > (dwa/path-tails-matching (file-name-nondirectory = path-in-error) candidates))) > (cond ((null filename-matches) path-in-error) > ;; unique match; return it > ((null (cadr filename-matches)) (car = filename-matches)) > ;; multiple matches; consider prompting for the = user to select one. > (t path-in-error)))) > ;; unique match; return it > ((null (cadr matches)) (car matches)) > ; multiple matches; consider prompting for the user to = select one. > (t path-in-error))))) >=20 > (setq compilation-parse-errors-filename-function = 'dwa/compilation-parse-errors-filename-in-project) >=20 > I've tried it and it seems to work well, although I agree that the = code > is a bit hacky and prone to error. How would the new hooks you = propose > simplify this customization code? It would not. The problem with this code is that it runs too early. = That means two things: 1. if you get 1000 errors in different files, this code will try to = resolve each one, accessing the filesystem during parsing, before the = compilation buffer even font locks, which is really inefficient = especially if you only care about the first of these errors. 2. There's no good way to prompt the user for a match when there are = multiple matches. =20 I want a hook that will be run at the time compile.el currently prompts = me to locate the file in the filesystem: the first time I visit an error = at a given path and no file is found there by emacs. > Similar use cases have been discussed in the mailing list in the past. > Someone proposed to make compilation-find-file customizable, which may > not be a bad idea. See > https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00910.html Yes, I think I could probably get where I need to by advising = compilation-find-file.= --Apple-Mail=_0A6A6292-7228-4684-95F6-F6702F17C0AB Content-Transfer-Encoding: quoted-printable Content-Type: text/html; charset=utf-8

On Jun = 22, 2023, at 10:58 AM, Daniel Mart=C3=ADn <mardani29@yahoo.es> = wrote:

Dave = Abrahams <dave@boostpro.com> writes:

Swift is a programming language.  When = its assertions (like C's
assert() macro) fail, a diagnostic is output = with a file ID and
line. The file ID looks like a path, but it's = really not. If it's a
path in the filesystem, that's coincidental but = it's likely to point
to the right file.  I don't want to = manually hunt down the file every
time an assertion fails; I'd rather = emacs made an educated guess based
on the current project.  It's = obviously not the right answer for
everyone, but I'd like to have the = hooks needed to implement that
without too much = hackery.

This is = the Elisp code you posted on GitHub, based on customizing
compilation-parse-errors-filename-function:

(defun = dwa/path-tails-matching (path paths)
 "Returns the = elements of PATHS with PATH as their suffix, matching by path = component."
 (let ((tail (file-name-concat "/" path)))
   (seq-filter (lambda (full-path) = (string-suffix-p tail full-path)) paths)))

(defun = dwa/compilation-parse-errors-filename-in-project = (path-in-error)
 "If PATH-IN-ERROR is found in the filesystem, returns = it
unchanged; otherwise tries to return a unique file in the = current
project = likely to be identified by PATH-IN-ERROR.  Returns
PATH-IN-ERROR unchanged if no such file can be = found."
 (if (file-exists-p path-in-error) = path-in-error
   ;; First look for relative path = suffixes.
   (let* ((candidates (project-files = (project-current t)))
=    (full-matches = (dwa/path-tails-matching path-in-error candidates)))

     ;; If not found, try just the = filename component of
     ;; path-in-error; Swift = assertions are weird and include a
     ;; module name that doesn't = necessarily correspond to anything in the
     ;; filesystem.
     (cond ((null = full-matches)
=      (let = ((filename-matches
=    (dwa/path-tails-m= atching (file-name-nondirectory path-in-error) candidates)))
      = ; (cond ((null filename-matches) path-in-error)
=      ;; = unique match; return it
=      ((nul= l (cadr filename-matches)) (car filename-matches))
=      ;; = multiple matches; consider prompting for the user to select = one.
=      (t = path-in-error))))
=     ;; unique = match; return it
=     ((null = (cadr matches)) (car matches))
=      ; = multiple matches; consider prompting for the user to select = one.
=     (t = path-in-error)))))

(setq = compilation-parse-errors-filename-function = 'dwa/compilation-parse-errors-filename-in-project)

I've = tried it and it seems to work well, although I agree that the = code
is a = bit hacky and prone to error.  How would the new hooks you = propose
simplify this customization code?

It would not.  The problem = with this code is that it runs too early.  That means two = things:

1. if you get 1000 errors in different = files, this code will try to resolve each one, accessing the filesystem = during parsing, before the compilation buffer even font locks, which is = really inefficient especially if you only care about the first of these = errors.
2. There's no good way to prompt the user for a match = when there are multiple matches.
 
I want a = hook that will be run at the time compile.el currently prompts me to = locate the file in the filesystem: the first time I visit an error at a = given path and no file is found there by = emacs.

Similar use cases have = been discussed in the mailing list in the past.
Someone = proposed to make compilation-find-file customizable, which may
not be = a bad idea.  See
https://lists.gnu.org/archive/html/emacs-devel/2021-04/msg00910.html=

Yes, I think I could probably get = where I need to by advising compilation-find-file.
= --Apple-Mail=_0A6A6292-7228-4684-95F6-F6702F17C0AB--