From: Jean Louis <bugs@gnu.support>
To: Richard Stallman <rms@gnu.org>
Cc: michael_heerdegen@web.de, emacs-devel@gnu.org
Subject: Re: Doc of deprecated INITIAL-INPUT arg of completing-read
Date: Fri, 1 Jul 2022 08:54:53 +0300 [thread overview]
Message-ID: <Yr6MLSxCHHevDw/4@protected.localdomain> (raw)
In-Reply-To: <E1o6kXU-0003lD-4F@fencepost.gnu.org>
* Richard Stallman <rms@gnu.org> [2022-06-30 06:08]:
> [[[ To any NSA and FBI agents reading my email: please consider ]]]
> [[[ whether defending the US Constitution against all enemies, ]]]
> [[[ foreign or domestic, requires you to follow Snowden's example. ]]]
>
> > I have many use cases for initial-input, when making calls I need to
> > make a note, and I like entering new date and time automatically as
> > initial input, so that I do not need to invoke keys in minibuffer.
>
> Is there a reason not to handle this the way most commands do? That
> is to use the current or last-used date-time as the default, if the
> argument is empty.
There are good reasons. I am using read-from-minibuffer and
completing-read many times per day as that is one of the way how I
enter new notes about assigned tasks.
In general INITIAL-INPUT is helpful to easier enter some value, and
DEFAULT is what is chosen if no value is entered.
Those are two different meanings not related to each other.
If some people choose to make them same, it does not make their
underlying functionality same. That is matter of docstring to explain
it well for users.
The DEFAULT I use for those cases where there is nothing written in
the prompt in minibuffer, so just by pressing RET I would get the
default.
DEFAULT may be inserted also with M-n however, when there are many
entries in completing that is rather for me "unsafe" way to choose the
default as I may not have assurance that I have pressed M-n once or
more times, and more often I use M-p to go back in history to choose
some previous value.
INITIAL-INPUT I use to help myself to enter some information quickly
in the minibuffer. It is often, in my case more than often, different
then the default.
Practical examples:
===================
Task has been assigned, and report is written on the task. DEFAULT is
"2022-07-01 Customer informed." but INITIAL-INPUT may be exact date
and time with space waiting for me as user to enter the actual note
about it, like this: "2022-07-01 14:22 ". If I however, delete it, and
press RET, I would get default "2022-07-01 Customer informed."
Further, I do not use those functions directly, they are wrapped in my
functions and what is DEFAULT is usually database backed entry, while
what is INITIAL-INPUT is usually dynamically generated string to help
me as user spare writing.
This may not mean much to people who rarely use completing-read or
read-from-minibuffer -- it means to me and team members who use it way
too often and where INITIAL-INPUT becomes helpful string placed in
mini buffer to help the with editing. It does not represent the
DEFAULT.
Also note that in database backed editing there may be different
users, and one user could turn off INITIAL-INPUT, while other could
have it, while third one could customize it.
In general INITIAL-INPUT shall not be considered neither similar nor
equivalent to any DEFAULT, it should be considered as helpful way to
put initial string in minibuffer, whatever it may be such, and initial
input is on my side rather editable, while DEFAULT is not necessarily
considered editable.
Jean
Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns
In support of Richard M. Stallman
https://stallmansupport.org/
prev parent reply other threads:[~2022-07-01 5:54 UTC|newest]
Thread overview: 30+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-06-27 15:22 Doc of deprecated INITIAL-INPUT arg of completing-read Michael Heerdegen
2022-06-27 16:33 ` [External] : " Drew Adams
2022-06-27 17:22 ` Christopher Dimech
2022-06-28 16:19 ` Michael Heerdegen
2022-06-28 16:40 ` Drew Adams
2022-06-29 13:42 ` Michael Heerdegen
2022-06-29 14:24 ` Drew Adams
2022-06-28 21:46 ` Christopher Dimech
2022-06-29 9:15 ` Arash Esbati
2022-06-29 13:46 ` Michael Heerdegen
2022-06-30 9:10 ` Arash Esbati
2022-07-04 12:25 ` Michael Heerdegen
2022-06-28 19:17 ` [External] : " Jean Louis
2022-06-28 19:15 ` Jean Louis
2022-06-28 21:10 ` Stefan Monnier
2022-06-28 22:00 ` Jean Louis
2022-06-29 2:58 ` Stefan Monnier
2022-06-30 3:08 ` Richard Stallman
2022-06-30 14:28 ` Stefan Monnier
2024-02-13 14:43 ` Tim Landscheidt
2024-02-13 14:59 ` Stefan Monnier
2024-02-13 17:07 ` Tim Landscheidt
2024-02-13 20:09 ` Stefan Monnier
2024-02-15 8:21 ` Tim Landscheidt
2024-02-15 16:09 ` [External] : " Drew Adams
2024-02-15 18:39 ` Stefan Monnier
2024-02-17 17:12 ` Tim Landscheidt
2024-02-17 17:41 ` Stefan Monnier
2022-06-30 3:08 ` Richard Stallman
2022-07-01 5:54 ` Jean Louis [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=Yr6MLSxCHHevDw/4@protected.localdomain \
--to=bugs@gnu.support \
--cc=emacs-devel@gnu.org \
--cc=michael_heerdegen@web.de \
--cc=rms@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).