From: Drew Adams <drew.adams@oracle.com>
To: 17779@debbugs.gnu.org
Subject: bug#17779: 24.4.50; (elisp) `Using Interactive'
Date: Sat, 14 Jun 2014 08:50:37 -0700 (PDT) [thread overview]
Message-ID: <79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default> (raw)
I wonder about the bullet "It may be a Lisp expression that is not a
string...".
1. The text for this does two things, which should perhaps be separated:
(a) it describes the general nature and use of such an expression, and
(b) it goes down a rabbit hole to talk about one particular gotcha.
Combining these in the same bullet, which is supposed to present the non-string Lisp sexp case, just confuses things - that's my guess.
2. Wrt that gotcha: Really? I'm probably missing something here, since
this text has been in the manual for a long time. But here's my take on
this gotcha. What am I missing?
> Providing point or the mark as an argument value is also common,
> but if you do this and read input (whether using the minibuffer
> or not), be sure to get the integer values of point or the mark
> after reading.
Why? Why is after reading always (or typically) the appropriate time?
> The current buffer may be receiving subprocess output; if
> subprocess output arrives while the command is waiting for input,
> it could relocate point and the mark.
And? Why is the location after reading more appropriate than before?
What does the input reading have to do, necessarily, with the timing of
the external process and its possible effect on the buffer text?
> Here's an example of what not to do:
> (interactive
> (list (region-beginning) (region-end)
> (read-string "Foo: " nil 'my-history)))
>
> Here's how to avoid the problem, by examining point and the mark
> after reading the keyboard input:
> (interactive
> (let ((string (read-string "Foo: " nil 'my-history)))
> (list (region-beginning) (region-end) string)))
That does not make sense to me as a general guideline. The appropriate
time for the interactive spec to record the region limits depends on
just what behavior one wants for the particular command. I see no
reason to assume that one always (or typically) wants the limits to be
recorded after reading input instead of before.
If text modifications because of some external process are a concern,
then it is likely that the exact interaction between that process and
user input action needs to be taken into account for the particular
command definition.
IOW, I don't see why such a generalization is appropriate here. What am
I missing?
[I would think it would be more typical (if any generalization is
appropriate here) for the command to make sure that such a process
finishes before checking the region limits, if the process can
change them.]
In GNU Emacs 24.4.50.1 (i686-pc-mingw32)
of 2014-06-08 on ODIEONE
Bzr revision: 117291 rgm@gnu.org-20140608234143-lxs3ijcc3exkcomq
Windowing system distributor `Microsoft Corp.', version 6.1.7601
Configured using:
`configure --prefix=/c/Devel/emacs/snapshot/trunk
--enable-checking=yes,glyphs 'CFLAGS=-O0 -g3'
LDFLAGS=-Lc:/Devel/emacs/lib 'CPPFLAGS=-DGC_MCHECK=1
-Ic:/Devel/emacs/include''
next reply other threads:[~2014-06-14 15:50 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-06-14 15:50 Drew Adams [this message]
2019-08-04 12:41 ` bug#17779: 24.4.50; (elisp) `Using Interactive' Lars Ingebrigtsen
2019-08-04 17:13 ` Eli Zaretskii
2019-08-05 9:29 ` Lars Ingebrigtsen
2019-08-05 16:25 ` Eli Zaretskii
2019-08-05 2:05 ` Drew Adams
2019-08-06 3:20 ` Richard Stallman
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
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=79a25ee9-e53e-494f-b7e3-ebd2e2eebafa@default \
--to=drew.adams@oracle.com \
--cc=17779@debbugs.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 external index
https://git.savannah.gnu.org/cgit/emacs.git
https://git.savannah.gnu.org/cgit/emacs/org-mode.git
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.