unofficial mirror of bug-gnu-emacs@gnu.org 
 help / color / mirror / code / Atom feed
From: Joseph Turner via "Bug reports for GNU Emacs, the Swiss army knife of text editors" <bug-gnu-emacs@gnu.org>
To: Eli Zaretskii <eliz@gnu.org>
Cc: michael_heerdegen@web.de, philipk@posteo.net, 66187@debbugs.gnu.org
Subject: bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function
Date: Tue, 03 Oct 2023 23:25:18 -0700	[thread overview]
Message-ID: <8734yq52em.fsf@breatheoutbreathe.in> (raw)
In-Reply-To: <83ttr66hxy.fsf@gnu.org>

[-- Attachment #1: Type: text/plain, Size: 1014 bytes --]


Eli Zaretskii <eliz@gnu.org> writes:

>> From: Joseph Turner <joseph@breatheoutbreathe.in>
>> Cc: michael_heerdegen@web.de, philipk@posteo.net, 66187@debbugs.gnu.org
>> Date: Tue, 03 Oct 2023 13:43:56 -0700
>>
>>
>> Eli Zaretskii <eliz@gnu.org> writes:
>>
>> > This is okay, except that we do document the other arguments.  So why
>> > not just copy/paste the description of MUSTMATCH from read-file-name
>> > to read-directory-name instead?
>>
>> The read-file-name docstring for MUSTMATCH is lengthy, and duplicating
>> it will mean that if read-file-name changes, we'll need to remember to
>> change the docstring of read-directory-name.
>
> That's true, but it doesn't sound like a grave problem to me.  We have
> the same duplication elsewhere, so this isn't a precedent.  Moreover,
> when a doc string is long and complicated, asking the reader to read
> part of it elsewhere is also quite a hassle.
>
> So I still think duplication is the lesser evil here.

Thanks for the explanation! See patch.

Joseph


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: 0001-Fix-MUSTMATCH-description-in-read-directory-name-doc.patch --]
[-- Type: text/x-diff, Size: 2014 bytes --]

From 3a653d681083d8d14d2d2437cb3f405dd7f07f04 Mon Sep 17 00:00:00 2001
From: Joseph Turner <joseph@breatheoutbreathe.in>
Date: Tue, 26 Sep 2023 18:01:27 -0700
Subject: [PATCH] Fix MUSTMATCH description in read-directory-name docstring

* lisp/files.el (read-directory-name): Copy from read-file-name
description, replacing "file" with "directory".
---
 lisp/files.el | 19 +++++++++++++++++--
 1 file changed, 17 insertions(+), 2 deletions(-)

diff --git a/lisp/files.el b/lisp/files.el
index b72f141c0ee..c31cb13653e 100644
--- a/lisp/files.el
+++ b/lisp/files.el
@@ -817,8 +817,23 @@ non-empty string that was inserted by this function.
 If the user exits with an empty minibuffer, this function returns
 an empty string.  (This can happen only if the user erased the
 pre-inserted contents or if `insert-default-directory' is nil.)
-Fourth arg MUSTMATCH non-nil means require existing directory's name.
- Non-nil and non-t means also require confirmation after completion.
+
+Fourth arg MUSTMATCH can take the following values:
+- nil means that the user can exit with any input.
+- t means that the user is not allowed to exit unless
+  the input is (or completes to) an existing directory.
+- `confirm' means that the user can exit with any input, but she needs
+  to confirm her choice if the input is not an existing directory.
+- `confirm-after-completion' means that the user can exit with any
+  input, but she needs to confirm her choice if she called
+  `minibuffer-complete' right before `minibuffer-complete-and-exit'
+  and the input is not an existing directory.
+- a function, which will be called with the input as the
+  argument.  If the function returns a non-nil value, the
+  minibuffer is exited with that argument as the value.
+- anything else behaves like t except that typing RET does not exit if it
+  does non-null completion.
+
 Fifth arg INITIAL specifies text to start with.
 DIR should be an absolute directory name.  It defaults to
 the value of `default-directory'."
-- 
2.41.0


      reply	other threads:[~2023-10-04  6:25 UTC|newest]

Thread overview: 40+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-09-24 21:31 bug#66187: read-file-name unexpected behavior when MUSTMATCH is a function Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-25  3:58 ` Michael Heerdegen
2023-09-25  5:12   ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-25 21:33     ` Michael Heerdegen
2023-09-26  8:37       ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-27  0:26         ` Michael Heerdegen
2023-09-27  0:55           ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-27  1:43             ` Michael Heerdegen
2023-10-03 21:18               ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-03 23:00                 ` Drew Adams
2023-10-04  3:35                 ` Michael Heerdegen
2023-10-04  5:22                   ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-05  1:12                     ` Michael Heerdegen
2023-10-04  7:03                 ` Eli Zaretskii
2023-10-05 19:34                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-05 20:20                     ` Drew Adams
2023-10-06  4:47                       ` Eli Zaretskii
2023-10-06 13:05                         ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 14:08                           ` Drew Adams
2023-10-06  4:45                     ` Eli Zaretskii
2023-10-06 13:01                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06 13:46                         ` Eli Zaretskii
2023-10-06 16:43                           ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07  5:23                             ` Eli Zaretskii
2023-10-07 14:25                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-07 15:09                                 ` Eli Zaretskii
2023-10-07 15:12                                   ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-12 21:26                                     ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-11-26  6:49                                       ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-18  0:24                                       ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-12-19  2:52                                         ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-09  8:06                                           ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-25 20:53                                             ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-28 19:20                                               ` Stefan Monnier via Bug reports for GNU Emacs, the Swiss army knife of text editors
2024-01-28 19:28                                                 ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-06  5:55                     ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-09-29 12:00             ` Eli Zaretskii
2023-10-03 20:43               ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors
2023-10-04  6:05                 ` Eli Zaretskii
2023-10-04  6:25                   ` Joseph Turner via Bug reports for GNU Emacs, the Swiss army knife of text editors [this message]

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=8734yq52em.fsf@breatheoutbreathe.in \
    --to=bug-gnu-emacs@gnu.org \
    --cc=66187@debbugs.gnu.org \
    --cc=eliz@gnu.org \
    --cc=joseph@breatheoutbreathe.in \
    --cc=michael_heerdegen@web.de \
    --cc=philipk@posteo.net \
    /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).