From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Dmitry Gutov Newsgroups: gmane.emacs.bugs Subject: bug#28513: 25.1; ido insists on guessing the wrong directory Date: Tue, 15 Dec 2020 04:23:29 +0200 Message-ID: References: <3526ABC6-2389-492A-83D7-A26195A6FC37@gmail.com> <875z575iog.fsf@gnus.org> <88f8e8d4-581b-85f8-92e6-8607d533cd77@yandex.ru> <87o8ix4zq6.fsf@gnus.org> <871rfs1gqt.fsf@gnus.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="607"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:68.0) Gecko/20100101 Thunderbird/68.10.0 Cc: Guillaume Salagnac , 28513@debbugs.gnu.org To: Lars Ingebrigtsen Original-X-From: bug-gnu-emacs-bounces+geb-bug-gnu-emacs=m.gmane-mx.org@gnu.org Tue Dec 15 03:24:13 2020 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 1kp00a-000Abf-O1 for geb-bug-gnu-emacs@m.gmane-mx.org; Tue, 15 Dec 2020 03:24:12 +0100 Original-Received: from localhost ([::1]:40196 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kp00Z-0008PH-Pq for geb-bug-gnu-emacs@m.gmane-mx.org; Mon, 14 Dec 2020 21:24:11 -0500 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:40486) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kp00Q-0008Od-VC for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 21:24:02 -0500 Original-Received: from debbugs.gnu.org ([209.51.188.43]:43421) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kp00P-0000TC-No for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 21:24:01 -0500 Original-Received: from Debian-debbugs by debbugs.gnu.org with local (Exim 4.84_2) (envelope-from ) id 1kp00P-0007Al-Ix for bug-gnu-emacs@gnu.org; Mon, 14 Dec 2020 21:24:01 -0500 X-Loop: help-debbugs@gnu.org Resent-From: Dmitry Gutov Original-Sender: "Debbugs-submit" Resent-CC: bug-gnu-emacs@gnu.org Resent-Date: Tue, 15 Dec 2020 02:24:01 +0000 Resent-Message-ID: Resent-Sender: help-debbugs@gnu.org X-GNU-PR-Message: followup 28513 X-GNU-PR-Package: emacs Original-Received: via spool by 28513-submit@debbugs.gnu.org id=B28513.160799902027538 (code B ref 28513); Tue, 15 Dec 2020 02:24:01 +0000 Original-Received: (at 28513) by debbugs.gnu.org; 15 Dec 2020 02:23:40 +0000 Original-Received: from localhost ([127.0.0.1]:54967 helo=debbugs.gnu.org) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kp004-0007A6-6Y for submit@debbugs.gnu.org; Mon, 14 Dec 2020 21:23:40 -0500 Original-Received: from mail-wr1-f52.google.com ([209.85.221.52]:44686) by debbugs.gnu.org with esmtp (Exim 4.84_2) (envelope-from ) id 1kp002-00079s-Ib for 28513@debbugs.gnu.org; Mon, 14 Dec 2020 21:23:38 -0500 Original-Received: by mail-wr1-f52.google.com with SMTP id w5so14572531wrm.11 for <28513@debbugs.gnu.org>; Mon, 14 Dec 2020 18:23:38 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=sender:subject:to:cc:references:from:message-id:date:user-agent :mime-version:in-reply-to:content-language:content-transfer-encoding; bh=rRXmIScUMZrTHiodg8LIc7Fj9oLe8HJUOnIeKx15x/A=; b=FFmUcRzdzsS1afiaqZ7OwULswycuMrR98bgV0b2qIqEAUdnIskUOYjT0Pu5fKj/sOj 1MdwV7h7s1Pgo0eX8NQ6kaAXccQ1Ic8HxFvEZFRmH0giEN4T1vznDeRQ8Ah4fq+PdryG aYiPC9kUi3SLI1lOOT9dU75gMC677tkF0Rk+XB8G92lAwNqGgD6COcKA5FHycrft4+CS UId1L3Vb6Rie2l4+q10BLGkeAZG3dL62GXQlGLABQyaHzUiyENVwMJ2yrnf7+NGO4qY6 TFnZb2kr6zxXjSQuPTfdDrDQDEOi3c9/a59XkEOHpS041P1zu68X3p3wqCvI0r31zGLH 9L9A== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:sender:subject:to:cc:references:from:message-id :date:user-agent:mime-version:in-reply-to:content-language :content-transfer-encoding; bh=rRXmIScUMZrTHiodg8LIc7Fj9oLe8HJUOnIeKx15x/A=; b=GDuD6UA9lwUwKnQJeqrFuGnnKxIJgcOWCxqp7XkSYCt/W9OzB9ZHEIJc88HUoua0rm AOti/oV4BXHwZoFPizf22UF+IfSrEwKieTZ1Fowi1jJlCYC13x/3yGKeKfjmtHIamx2N Ki5NMUVX8RutuaS8hvQRPBI+Drftwy2MHbgD9AEsccEVzNZUiSD79C5fLy2KEEiBvjOT vN556Kf6Aaw6fy6NF84Y4ubJiREXJIL6o4ityOFLB+bE6BvDreDO/CJ7l98uRtti4Hgn yCEgAw/LwJDw4zYdLtJPexXl0+bhZwYAA6uDPMjl3j3VI90wFU+E1iguV5RzIq/N/6Ey 5emw== X-Gm-Message-State: AOAM532YOcbJP+I9Z8DekBuB0e76pqGjuxqEBkpp5QSFQL8eUi8dXhtr Aj0CqBFc1GeXfxsrBQOjpi7nm4aozUeGTQ== X-Google-Smtp-Source: ABdhPJxUEZlRqm4q3QidL32Z0W3TQv7XRBvDepZmHMLXE6lPCMWs+Cx3bS+0rLrII/8SjPxW08eZKQ== X-Received: by 2002:adf:eecc:: with SMTP id a12mr31489275wrp.312.1607999012336; Mon, 14 Dec 2020 18:23:32 -0800 (PST) Original-Received: from [192.168.0.5] ([46.251.119.176]) by smtp.googlemail.com with ESMTPSA id q15sm34145539wrw.75.2020.12.14.18.23.30 (version=TLS1_3 cipher=TLS_AES_128_GCM_SHA256 bits=128/128); Mon, 14 Dec 2020 18:23:31 -0800 (PST) In-Reply-To: <871rfs1gqt.fsf@gnus.org> Content-Language: en-US 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" Xref: news.gmane.io gmane.emacs.bugs:196122 Archived-At: On 14.12.2020 18:42, Lars Ingebrigtsen wrote: >> Okay, but why does the fallback command end up trying to overwrite the >> original file, even though, in your scenario, input ends with /vc/? > > In essence, it's doing this (if we say we've navigated to "/tmp/" before > `C-f'): > > (let ((default-directory "/tmp/")) > (call-interactively 'write-file)) > > This gives you a prompt of > > Write file: /tmp/ > > If you then hit RET, then: > > > > That is, hitting RET in the `write-file' dialogue gives you > buffer-file-name, and ignores whatever is in the prompt. This seems > contrary to what the doc string says: > > --- > Interactively, prompt for FILENAME. > If you specify just a directory name as FILENAME, that means to write > to a file in that directory. In this case, the base name of the file > is the same as that of the file visited in the buffer, or the buffer > name sans leading directories, if any, if the buffer is not already > visiting a file. > --- > > 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. I think when the user calls the escape hatch command, they don't expect their current input to translate to the new default-directory value. Rather, it should be the input in the new prompt. Might not be easy to fix, however, given that the current code in Ido tries to do that in the most generic way: (let ((default-directory ido-current-directory) (read-file-name-function nil)) (setq this-command (or ido-fallback fallback 'find-file)) ... (call-interactively this-command)) And since that this feature is an escape hatch and, say, fido-mode (which everyone will migrate to any year now) shouldn't need anything like it, maybe it's not worth the effort fixing.