GNU bug report logs - #63337
[PATCH] package-vc--build-documentation: Fix relative @include statements

Previous Next

Full log

Message #38 received at submit <at> debbugs.gnu.org (full text, mbox):

From: Joseph Turner <joseph <at> breatheoutbreathe.in>
To: Ruijie Yu <ruijie <at> netyu.xyz>
Cc: 63337 <at> debbugs.gnu.org, Philip Kaludercic <philipk <at> posteo.net>,
 bug-gnu-emacs <at> gnu.org, Eli Zaretskii <eliz <at> gnu.org>
Subject: Re: bug#63337: [PATCH] package-vc--build-documentation: Fix
 relative @include statements
Date: Mon, 08 May 2023 19:48:30 -0700

Ruijie Yu <ruijie <at> netyu.xyz> writes:

> Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs <at> gnu.org> writes:
>
>> + (file-path (expand-file-name file (package-desc-dir pkg-desc)))
>> + (default-directory (expand-file-name (file-name-directory file-path)))
>>
>> (package-desc-dir pkg-desc) may return a relative path with or without a
>> directory, e.g. "doc/manual.org" or "manual.org". In the latter case,
>> (file-name-directory "manual.org") would return `nil' and
>> (expand-file-name nil) would signal an error.
>
> In this case, can't you do this instead:
>
>     (expand-file-name (or (file-name-directory ...) "."))

Yes, we could do this, but we make use of FILE-PATH anyway. We can't use
FILE after DEFAULT-DIRECTORY has been set the file containing FILE.

The choice is between

(file-name-directory file-path)

and

(or (file-name-directory file) ".")

I think the intent comes across more clearly in the former.

Joseph

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.