From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: dalanicolai Newsgroups: gmane.emacs.bugs Subject: bug#66542: Fix: locate-dominating-file predicate should receive dir not file Date: Sat, 21 Oct 2023 17:39:17 +0200 Message-ID: References: <83mswlqka5.fsf@gnu.org> Mime-Version: 1.0 Content-Type: multipart/mixed; boundary="00000000000068348806083bcbad" Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="5761"; mail-complaints-to="usenet@ciao.gmane.io" Cc: 66542@debbugs.gnu.org To: Eli Zaretskii Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Sat Oct 21 17:41:05 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 1quE65-0001JQ-LN for geb-bug-gnu-emacs@m.gmane-mx.org; Sat, 21 Oct 2023 17:41:05 +0200 Original-Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1quE5c-0006Dv-RE; Sat, 21 Oct 2023 11:40:36 -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 1quE5a-0006DW-K6 for bug-gnu-emacs@gnu.org; Sat, 21 Oct 2023 11:40:34 -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 1quE5a-0005eM-Bg for bug-gnu-emacs@gnu.org; Sat, 21 Oct 2023 11:40:34 -0400 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1quE61-00028x-TG for bug-gnu-emacs@gnu.org; Sat, 21 Oct 2023 11:41:01 -0400 X-Loop: help-debbugs@gnu.org Resent-From: dalanicolai Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Sat, 21 Oct 2023 15:41:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 66542 X-GNU-PR-Package: emacs X-GNU-PR-Keywords: patch Original-Received: via spool by 66542-submit@debbugs.gnu.org id=B66542.16979028078060 (code B ref 66542); Sat, 21 Oct 2023 15:41:01 +0000 Original-Received: (at 66542) by debbugs.gnu.org; 21 Oct 2023 15:40:07 +0000 Original-Received: from localhost ([127.0.0.1]:44913 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1quE59-00025w-5h for submit@debbugs.gnu.org; Sat, 21 Oct 2023 11:40:07 -0400 Original-Received: from mail-wm1-x333.google.com ([2a00:1450:4864:20::333]:60467) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1quE54-00022v-Vu for 66542@debbugs.gnu.org; Sat, 21 Oct 2023 11:40:05 -0400 Original-Received: by mail-wm1-x333.google.com with SMTP id 5b1f17b1804b1-40859dee28cso3646745e9.0 for <66542@debbugs.gnu.org>; Sat, 21 Oct 2023 08:39:35 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20230601; t=1697902769; x=1698507569; 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=ucx3wlulNcxBZprXgBIu4UNiKkwJjcyFbMsRxClwQBY=; b=FvsyPao6ponnaVOVIEOSkDfczIk+DivoyabKcZckD087yU0AU7RXnxxsALkBG6mywO lXjycaIwKlQdhiuPMpqBOFQvEFVQSjEx1gziMXm3vx6VoedkB/IC/9RZkZpBRMNJdWFN fVetAU9/SzsU5u5bdtAmjwa6W4HUvwJeVAsdEHwWLA0R9bZE8689LNQMIDVAiETc4kjL pVmZ5PfgHCJijUProWQnPpjqd7ou0uyB+r2kTqCVUvrbosy0bV01H2W8c3UW8+3x+q7S tksZHOjmto6z22DklRT5ZEPl4rM4nt4ndB18kBW1F7JIHUECGHPMuv5en4JtnMKYZ7WL t5Og== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1697902769; x=1698507569; 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=ucx3wlulNcxBZprXgBIu4UNiKkwJjcyFbMsRxClwQBY=; b=MtteuPiyGQv/EXG4x+XeVxpMQOuT7r1SdUbMQwE8/C33N6ICl6sH0clKezuiuwYf8I KBUm431/ESlTYotYXgo7TAV44xd1BQPzf/ExxhRQoXrHwglU+zQ6HnAIa83lBmN6H15y 8W9ElDbff5IbLcqxy1Z3AvACBz/ppEnhm6x7rKZk6cqhJNNpVzWLSncXBSN37yANomcr sb9MbZwBosnQy2B+13Fv+oit9j5WH5lFYCF6l9GCM4eI7ykiP6Eo7/RhllcuLti35Jfi H4Vp87+aGkbA7cj/jwKdnJwukZgLxppXMfevVtz00gBzwTNDkcavfmUpsDFGCJnUdy+r auAQ== X-Gm-Message-State: AOJu0Yxmf10OOW55CKWEKiGoVhJ08c0CSeOxFVOIEKYWh8mMiHuXu1tn eNQbMaBAvan+NsmgwOI0ffF7/QUWoSIHVkU0j0Q= X-Google-Smtp-Source: AGHT+IEsWOpWwB+POalkXoI2KNfAHsenV8Gtfyt+r1Nh32XW4p4OqOrF3uvfEo1XOhySQBskxjfDzil1of0bIfOZ+QM= X-Received: by 2002:a05:600c:a05:b0:405:82c0:d9f3 with SMTP id z5-20020a05600c0a0500b0040582c0d9f3mr3874064wmp.30.1697902768927; Sat, 21 Oct 2023 08:39:28 -0700 (PDT) In-Reply-To: <83mswlqka5.fsf@gnu.org> 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:272918 Archived-At: --00000000000068348806083bcbad Content-Type: multipart/alternative; boundary="00000000000068348706083bcbab" --00000000000068348706083bcbab Content-Type: text/plain; charset="UTF-8" You are right (of course :) So I have attached another patch which only strips the file name (applies file-name-directory) if the file is not a directory. If the file is not a directory, then that stripped name should also be returned by the function, i.e. in the 'cond`, root should be set to the stripped file name. Therefore, the patched version simply 'checks and sets' the file name first inside the setq. Also, now we can remove the check in the first clause of the 'if' (of 'setq try'), because 'file' is guaranteed to be a directory name, and the existence of the directory name is already checked by the 'file-exists-p'. This change does not affect other parts of the function (except that it speeds it up a little, because it excludes the cycles, that only strip the file names in case file is a 'real' file. Indeed, the function should only check for 'parent directories' (not files). I hope I did not miss anything. On Sat, 14 Oct 2023 at 17:46, Eli Zaretskii wrote: > > From: dalanicolai > > Date: Sat, 14 Oct 2023 17:11:18 +0200 > > > > The docstring of 'locate-dominating-file' mentions that its NAME argument > > should be a dir, but currently it simply receives the FILE > > argument. Therefore, using the function e.g. with the following > predicate for NAME > > > > (lambda (dir) > > (seq-filter (apply-partially #'string-match-p "paint") > > (directory-files > > dir))) > > > > to check if a directory contains a file regexp-matching 'paint', throws > > an error: > > > > (file-error "Opening directory" "Not a directory" "/home/...") > > > > This patch simply wraps the FILE argument in the (funcall NAME FILE) with > > a 'file-name-directory' thereby fixing the function. > > Sorry, I don't understand: the return value of file-name-directory is > not identical to its argument when the argument is a directory, so > this patch might change the behavior. Or what am I missing? > > In addition, I don't think I understand the problem you are trying to > solve. Could you please describe the problem more completely, by > telling when and how was locate-dominating-file called with the name > of a file that is not a directory? > --00000000000068348706083bcbab Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
You are right (of course :)
So I have attac= hed another patch which only strips the file name (applies file-name-direct= ory) if the file is not a directory.

If the file i= s not a directory, then that stripped name should also be returned by the f= unction, i.e. in the 'cond`, root should be set to the stripped file na= me. Therefore, the patched version simply 'checks and sets' the fil= e name first inside the setq.

Also, now we can rem= ove the check in the first clause of the 'if' (of 'setq try'= ;), because 'file' is guaranteed to be a directory name, and the ex= istence of the directory name is already checked by the 'file-exists-p&= #39;.

This change does not affect other parts of t= he function (except that it speeds it up a little, because it excludes the = cycles, that only strip the file names in case file is a 'real' fil= e.
Indeed, the function should only check for 'parent directo= ries' (not files).

I hope I did not miss a= nything.


On Sat, 14 Oct 2023 at 17:46, Eli Zaretski= i <eliz@gnu.org> wrote:
=
> From: dalanicolai &l= t;dalanicolai@gm= ail.com>
> Date: Sat, 14 Oct 2023 17:11:18 +0200
>
> The docstring of 'locate-dominating-file' mentions that its NA= ME argument
> should be a dir, but currently it simply receives the FILE
> argument. Therefore, using the function e.g. with the following predic= ate for NAME
>
> (lambda (dir)
> (seq-filter (apply-partially #'string-match-p "paint") > (directory-files
> dir)))
>
> to check if a directory contains a file regexp-matching 'paint'= ;, throws
> an error:
>
> (file-error "Opening directory" "Not a directory" = "/home/...")
>
> This patch simply wraps the FILE argument in the (funcall NAME FILE) w= ith
> a 'file-name-directory' thereby fixing the function.

Sorry, I don't understand: the return value of file-name-directory is not identical to its argument when the argument is a directory, so
this patch might change the behavior.=C2=A0 Or what am I missing?

In addition, I don't think I understand the problem you are trying to solve.=C2=A0 Could you please describe the problem more completely, by
telling when and how was locate-dominating-file called with the name
of a file that is not a directory?
--00000000000068348706083bcbab-- --00000000000068348806083bcbad Content-Type: application/octet-stream; name=locate-dominating-file-patch Content-Disposition: attachment; filename=locate-dominating-file-patch Content-Transfer-Encoding: base64 Content-ID: X-Attachment-Id: f_lo079hah0 ZGlmZiAtLWdpdCBhL2xpc3AvZmlsZXMuZWwgYi9saXNwL2ZpbGVzLmVsCmluZGV4IGUxNDIxYjQw M2JmLi40ZTNjOTY5OTg1MiAxMDA2NDQKLS0tIGEvbGlzcC9maWxlcy5lbAorKysgYi9saXNwL2Zp bGVzLmVsCkBAIC0xMTM1LDkgKzExMzUsMTEgQEAgbG9jYXRlLWRvbWluYXRpbmctZmlsZQogICAg ICh3aGlsZSAobm90IChvciByb290CiAgICAgICAgICAgICAgICAgICAgIChudWxsIGZpbGUpCiAg ICAgICAgICAgICAgICAgICAgIChzdHJpbmctbWF0Y2ggbG9jYXRlLWRvbWluYXRpbmctc3RvcC1k aXItcmVnZXhwIGZpbGUpKSkKLSAgICAgIChzZXRxIHRyeSAoaWYgKHN0cmluZ3AgbmFtZSkKLSAg ICAgICAgICAgICAgICAgICAgKGFuZCAoZmlsZS1kaXJlY3RvcnktcCBmaWxlKQotICAgICAgICAg ICAgICAgICAgICAgICAgIChmaWxlLWV4aXN0cy1wIChleHBhbmQtZmlsZS1uYW1lIG5hbWUgZmls ZSkpKQorICAgICAgKHNldHEgZmlsZSAoaWYgKGZpbGUtZGlyZWN0b3J5LXAgZmlsZSkKKyAgICAg ICAgICAgICAgICAgICAgIGZpbGUKKyAgICAgICAgICAgICAgICAgICAoZmlsZS1uYW1lLWRpcmVj dG9yeSBmaWxlKSkKKyAgICAgICAgICAgIHRyeSAoaWYgKHN0cmluZ3AgbmFtZSkKKyAgICAgICAg ICAgICAgICAgICAgKGZpbGUtZXhpc3RzLXAgKGV4cGFuZC1maWxlLW5hbWUgbmFtZSBmaWxlKSkK ICAgICAgICAgICAgICAgICAgIChmdW5jYWxsIG5hbWUgZmlsZSkpKQogICAgICAgKGNvbmQgKHRy eSAoc2V0cSByb290IGZpbGUpKQogICAgICAgICAgICAgKChlcXVhbCBmaWxlIChzZXRxIGZpbGUg KGZpbGUtbmFtZS1kaXJlY3RvcnkK --00000000000068348806083bcbad--