From: "Drew Adams" <drew.adams@oracle.com>
To: "'Eli Zaretskii'" <eliz@gnu.org>
Cc: bug-gnu-emacs@gnu.org
Subject: RE: doc string of insert-default-directory is unclear
Date: Sat, 9 Feb 2008 07:59:15 -0800 [thread overview]
Message-ID: <001301c86b34$b882f240$a350908d@us.oracle.com> (raw)
In-Reply-To: <usl02qn3j.fsf@gnu.org>
> > In previous releases, the doc string said only what its first line
> > says. The rest was presumably added in Emacs 22 to clarify
> > the meaning and use.
>
> Not just clarify, to document its different semantics.
That semantic difference is not clear to me from the new doc string you
propose. Sorry. Could you point out the difference?
> > Please consider rephrasing the entire doc string. A good starting
> > point could be to explain the significance of the initial contents
> > being non-empty.
>
> I took a shot at this.
Thanks.
> The new doc string is this:
>
> *Non-nil means when reading a filename start with default
> dir in minibuffer.
>
> When the initial minibuffer contents show a name of a
> file or a directory, typing RETURN without editing the
> initial contents is equivalent to typing
> the default file name.
>
> If this variable is non-nil, the minibuffer contents are always
> initially non-empty, and typing RETURN without editing
> will fetch the default name, if one is provided. Note however
> that this default name is not necessarily the same as initial
> contents inserted in the minibuffer,
> if the initial contents is just the default directory.
>
> If this variable is nil, the minibuffer often starts out
> empty. In that case you may have to explicitly fetch the next
> history element to request the default name; typing RETURN
> without editing will leave the minibuffer empty.
>
> For some commands, exiting with an empty minibuffer has a
> special meaning, such as making the current buffer visit no
> file in the case of `set-visited-file-name'.
Here's some additional feedback. If it makes sense to you, fine; if not,
ignore.
The variable controls the behavior of one or more functions, but it is not
clear which. It's not necessarily the case that every time a file name is
read in Emacs the behavior is controlled by this variable. And even if that
is true of vanilla Emacs, it might not be true in general. Isn't this only
about `read-file-name'? If so, then it should say "when a file name is read
with `read-file-name'".
If it is mainly about `read-file-name' but there are some other cases, it
still might be better to mention "when read by functions such as
`read-file-name'."
Some of the statements are too general: "If this variable is non-nil, the
minibuffer contents are always initially non-empty". That's certainly not
true of the minibuffer in general (e.g. `M-x'). This would be cleared up by
saying that we are talking only of the context of `read-file-name' (or
whatever).
Readers can be confused by the concept of "default file name", which can
depend on the particular command. I think that should be clarified. And
references to the default directory should refer to `default-directory', so
users can look up what that means.
More generally, for information about different behaviors and special cases,
the doc string should refer to the functions and variables whose doc strings
explain those cases in context.
"Typing RETURN without editing will leave the minibuffer empty." No, it will
exit the minibuffer, returning the empty string. RETURN doesn't empty the
minibuffer or just leave it empty (no-op).
I hate to say it, but I think that, in general, the added text just adds
confusion. So far, I think it is clearest to say simply that non-nil means
that `default-directory' is inserted initially in the minibuffer when a name
is read by `read-file-name'. It is the doc of `read-file-name' etc. that
should explain what happens if you empty the minibuffer or if you hit RETURN
without typing anything.
What is the problem that adding this text is intended to solve? If you tell
me what the problem we are solving is, perhaps I can help some more with the
wording.
next prev parent reply other threads:[~2008-02-09 15:59 UTC|newest]
Thread overview: 5+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-02-03 1:31 doc string of insert-default-directory is unclear Drew Adams
2008-02-09 13:24 ` Eli Zaretskii
2008-02-09 15:59 ` Drew Adams [this message]
2008-02-09 16:35 ` Eli Zaretskii
2008-02-09 19:17 ` Drew Adams
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='001301c86b34$b882f240$a350908d@us.oracle.com' \
--to=drew.adams@oracle.com \
--cc=bug-gnu-emacs@gnu.org \
--cc=eliz@gnu.org \
/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).