GNU bug report logs - #50142
27.1; Meaning of interactive specifier "f" unexpectedly depends on visited file

Previous Next

Package: emacs;

Reported by: Markus Triska <triska <at> metalevel.at>

Date: Sat, 21 Aug 2021 08:49:02 UTC

Severity: normal

Tags: notabug

Found in version 27.1

Done: Lars Ingebrigtsen <larsi <at> gnus.org>

Bug is archived. No further changes may be made.

To add a comment to this bug, you must first unarchive it, by sending
a message to control AT debbugs.gnu.org, with unarchive 50142 in the body.
You can then email your comments to 50142 AT debbugs.gnu.org in the normal way.

Toggle the display of automated, internal messages from the tracker.

View this report as an mbox folder, status mbox, maintainer mbox


Report forwarded to bug-gnu-emacs <at> gnu.org:
bug#50142; Package emacs. (Sat, 21 Aug 2021 08:49:02 GMT) Full text and rfc822 format available.

Acknowledgement sent to Markus Triska <triska <at> metalevel.at>:
New bug report received and forwarded. Copy sent to bug-gnu-emacs <at> gnu.org. (Sat, 21 Aug 2021 08:49:02 GMT) Full text and rfc822 format available.

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

From: Markus Triska <triska <at> metalevel.at>
To: bug-gnu-emacs <at> gnu.org
Subject: 27.1; Meaning of interactive specifier "f" unexpectedly depends on
 visited file
Date: Sat, 21 Aug 2021 10:40:18 +0200
Let ~/f.el consist of:

    (defun f (file)
      (interactive "fFile:")
      (message "The file is: %s" file))

When I start Emacs with:

    $ cd
    $ emacs -Q -l f.el

And then, in Emacs, do:

    M-x f RET RET

Then the echo area shows, as expected:

    The file is: ~/

In contrast, when I start Emacs with:

    $ emacs -Q -l f.el f.el

And then perform the same steps as above, i.e.,

    M-x f RET RET

then the echo area unexpectedly shows:

    The file is: ~/f.el

This is unexpected, since the minibuffer prompt when doing M-x f RET
shows: "File:~/" (as before), indicating that pressing RET would yield
"~/", also as before, not "~/f.el".

The key difference between the two cases is that in the second
invocation, f.el is visited, and in the first case it is not visited.

I noticed this difference when testing cdvdmacs, visiting cdvdmacs.el
and then trying to add the directory in which cdvdmacs.el resides to the
list of files and directories I want to archive, and unexpectedly adding
only the file itself (cdvdmacs.el) instead of the entire directory:

    https://www.metalevel.at/cdvdmacs/

Thank you and all the best,
Markus

In GNU Emacs 27.1 (build 1, x86_64-apple-darwin15.3.0, X toolkit, Xaw scroll bars)
 of 2020-12-12 built on mt-macbook
Windowing system distributor 'The X.Org Foundation', version 11.0.11502000
System Description:  Mac OS X 10.11.3





Information forwarded to bug-gnu-emacs <at> gnu.org:
bug#50142; Package emacs. (Mon, 22 Aug 2022 13:53:01 GMT) Full text and rfc822 format available.

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

From: Lars Ingebrigtsen <larsi <at> gnus.org>
To: Markus Triska <triska <at> metalevel.at>
Cc: 50142 <at> debbugs.gnu.org
Subject: Re: bug#50142: 27.1; Meaning of interactive specifier "f"
 unexpectedly depends on visited file
Date: Mon, 22 Aug 2022 15:52:33 +0200
Markus Triska <triska <at> metalevel.at> writes:

> then the echo area unexpectedly shows:
>
>     The file is: ~/f.el
>
> This is unexpected, since the minibuffer prompt when doing M-x f RET
> shows: "File:~/" (as before), indicating that pressing RET would yield
> "~/", also as before, not "~/f.el".

The "f" interactive spec is basically `read-file-name'.  As the doc
string says:

---
  If DEFAULT-FILENAME is omitted or
nil, then if INITIAL is non-nil, the default is DIR combined with
INITIAL; otherwise, if the current buffer is visiting a file,
that file serves as the default; otherwise, the default is simply
the string inserted into the minibuffer.
---

Which is what you're seeing.

So this is working as intended (and in any case, we can't change this
long standing behaviour), and I'm therefore closing this bug report.




Added tag(s) notabug. Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 22 Aug 2022 13:53:02 GMT) Full text and rfc822 format available.

bug closed, send any further explanations to 50142 <at> debbugs.gnu.org and Markus Triska <triska <at> metalevel.at> Request was from Lars Ingebrigtsen <larsi <at> gnus.org> to control <at> debbugs.gnu.org. (Mon, 22 Aug 2022 13:53:02 GMT) Full text and rfc822 format available.

bug archived. Request was from Debbugs Internal Request <help-debbugs <at> gnu.org> to internal_control <at> debbugs.gnu.org. (Tue, 20 Sep 2022 11:24:10 GMT) Full text and rfc822 format available.

This bug report was last modified 1 year and 190 days ago.

Previous Next


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