bug#17779: 24.4.50; (elisp) `Using Interactive'

[Drew Adams]

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''