From: Lars Ingebrigtsen <larsi@gnus.org>
To: Dmitry Gutov <dgutov@yandex.ru>
Cc: Guillaume Salagnac <guillaume.salagnac@gmail.com>, 28513@debbugs.gnu.org
Subject: bug#28513: 25.1; ido insists on guessing the wrong directory
Date: Tue, 15 Dec 2020 07:42:10 +0100 [thread overview]
Message-ID: <875z531sfx.fsf@gnus.org> (raw)
In-Reply-To: <baa28697-9c41-c0de-f8eb-f71e96b27d4a@yandex.ru> (Dmitry Gutov's message of "Tue, 15 Dec 2020 04:23:29 +0200")
Dmitry Gutov <dgutov@yandex.ru> writes:
>> So this isn't an ido problem at all -- it's a bug in `write-file'?
>> Or
>> rather...
>> (let ((default-directory "/tmp/")) (read-file-name "Foo: "))
>> If you just hit RET there, it'll return `buffer-file-name'.
>
> But there is a difference between having default-directory set to
> /tmp/ and typing /tmp/ yourself.
There is. However, I don't think the way
(let ((default-directory "/tmp/")) (read-file-name "Foo: "))
works is logical. We're clearly presenting the user with an interface
that seems like we're doing something in /tmp/, but RET returns
buffer-file-name.
The following would be more logical, in my opinion. But it's a very
low-level change, so it's... ticklish. It should give the same results
99% of the time (because binding default-directory and then calling
read-file-name isn't the usual pattern, I think?), but would fix this
issue.
Opinions?
diff --git a/lisp/minibuffer.el b/lisp/minibuffer.el
index 456193d52e..d1f1bf3758 100644
--- a/lisp/minibuffer.el
+++ b/lisp/minibuffer.el
@@ -2814,7 +2814,9 @@ read-file-name-default
(unless default-filename
(setq default-filename
(cond
- ((null initial) buffer-file-name)
+ ((null initial)
+ (expand-file-name (file-name-nondirectory buffer-file-name)
+ default-directory))
;; Special-case "" because (expand-file-name "" "/tmp/") returns
;; "/tmp" rather than "/tmp/" (bug#39057).
((equal "" initial) dir)
--
(domestic pets only, the antidote for overdose, milk.)
bloggy blog: http://lars.ingebrigtsen.no
next prev parent reply other threads:[~2020-12-15 6:42 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-09-19 15:03 bug#28513: 25.1; ido insists on guessing the wrong directory Guillaume Salagnac
2020-12-12 12:10 ` Lars Ingebrigtsen
2020-12-13 1:11 ` Dmitry Gutov
2020-12-13 13:12 ` Lars Ingebrigtsen
2020-12-14 2:24 ` Dmitry Gutov
2020-12-14 16:42 ` Lars Ingebrigtsen
2020-12-15 2:23 ` Dmitry Gutov
2020-12-15 6:42 ` Lars Ingebrigtsen [this message]
2020-12-17 11:33 ` Lars Ingebrigtsen
2020-12-17 11:54 ` Dmitry Gutov
2021-01-01 21:51 ` bug#28513: Ryan C. Thompson
2021-01-10 23:07 ` bug#19412: bug#28513 Ryan C. Thompson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=875z531sfx.fsf@gnus.org \
--to=larsi@gnus.org \
--cc=28513@debbugs.gnu.org \
--cc=dgutov@yandex.ru \
--cc=guillaume.salagnac@gmail.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).