bug#15042: 24.3.50; while-no-input and input-pending-p

bug#15042: 24.3.50; while-no-input and input-pending-p

[Michael Heerdegen]

Hello,

I want to discuss if the current implementation of `while-no-input':

--8<---------------cut here---------------start------------->8---
(defmacro while-no-input (&rest body)
  "Execute BODY only as long as there's no pending input.
If input arrives, that ends the execution of BODY,
and `while-no-input' returns t.  Quitting makes it return nil.
If BODY finishes, `while-no-input' returns whatever value BODY produced."
  (declare (debug t) (indent 0))
  (let ((catch-sym (make-symbol "input")))
    `(with-local-quit
       (catch ',catch-sym
	 (let ((throw-on-input ',catch-sym))
	   (or (input-pending-p)
	       (progn ,@body)))))))
--8<---------------cut here---------------end--------------->8---

that uses a preliminary `input-pending-p' test is useful.  My reasons:


1.  `input-pending-p' can (and does) return t in cases were no input is
pending (see the doc).  In such cases, `while-no-input' just returns t,
although no input was given.  This contradicts the doc, is not useful
and the behavior is unforeseeable.

2.  Even if `input-pending-p' would not give false alarm sometimes - why
needs `while-no-input' to use it?

If the programmer really wants to check for input _before_ starting the
calculation, he can do so explicitly.

With the current implementation, I have to `discard-input' if I don't
want this.


2 is probably arguable, but 1 is really bad.  I experienced that
 
 (while-no-input code ...)

is sometimes semantically equivalent to

 t

without any input.


Regards,

Michael.




In GNU Emacs 24.3.50.1 (x86_64-pc-linux-gnu, GTK+ Version 3.8.2)
 of 2013-08-04 on dex, modified by Debian
 (emacs-snapshot package, version 2:20130804-1)
Windowing system distributor `The X.Org Foundation', version 11.0.11204000
System Description:	Debian GNU/Linux testing (jessie)

Configured using:
 `configure --build x86_64-linux-gnu --host x86_64-linux-gnu
 --prefix=/usr --sharedstatedir=/var/lib --libexecdir=/usr/lib
 --localstatedir=/var --infodir=/usr/share/info --mandir=/usr/share/man
 --with-pop=yes
 --enable-locallisppath=/etc/emacs-snapshot:/etc/emacs:/usr/local/share/emacs/24.3.50/site-lisp:/usr/local/share/emacs/site-lisp:/usr/share/emacs/24.3.50/site-lisp:/usr/share/emacs/site-lisp
 --without-compress-info --with-crt-dir=/usr/lib/x86_64-linux-gnu/
 --with-x=yes --with-x-toolkit=gtk3 --with-imagemagick=yes
 CFLAGS='-DDEBIAN -DSITELOAD_PURESIZE_EXTRA=5000 -g -O2'
 CPPFLAGS='-D_FORTIFY_SOURCE=2' LDFLAGS='-g -Wl,--as-needed
 -znocombreloc''

Important settings:
  value of $LC_ALL: de_DE.utf8
  value of $LANG: de_DE.utf8
  locale-coding-system: utf-8-unix
  default enable-multibyte-characters: t

bug#15042: 24.3.50; while-no-input and input-pending-p

[Stefan Monnier]

> 1.  `input-pending-p' can (and does) return t in cases were no input is
> pending (see the doc).  In such cases, `while-no-input' just returns t,
> although no input was given.  This contradicts the doc, is not useful
> and the behavior is unforeseeable.

Those cases where it immediately returns t should hopefully be very
similar to those cases where it stops in the middle even tho the event
that interrupted it is "ignorable".

> 2.  Even if `input-pending-p' would not give false alarm sometimes - why
> needs `while-no-input' to use it?

while-no-input is for code which should runs "transparently" without
preventing the user from running his commands.  So if the user has
already typed the next key before we even get to while-no-input, we
definitely should not enter the while-no-input, since while-no-input
is implemented such that it is only interrupted by *new* input.

> With the current implementation, I have to `discard-input' if I don't
> want this.

Can you give an example where you'd want to do that?

I experienced that
 
 (while-no-input code ...)

is sometimes semantically equivalent to

 t

without any input.

        Stefan

bug#15042: 24.3.50; while-no-input and input-pending-p

[Michael Heerdegen]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

> > 1.  `input-pending-p' can (and does) return t in cases were no input is
> > pending (see the doc).  In such cases, `while-no-input' just returns t,
> > although no input was given.  This contradicts the doc, is not useful
> > and the behavior is unforeseeable.
>
> Those cases where it immediately returns t should hopefully be very
> similar to those cases where it stops in the middle even tho the event
> that interrupted it is "ignorable".

Sure? (What are such "ignorable" events?)  That would mean that binding
`throw-on-input' also "fires" in cases where no input arrived.

Is there an alternative to cancel a calculation on input without "false
positives"?

> > With the current implementation, I have to `discard-input' if I don't
> > want this.
>
> Can you give an example where you'd want to do that?

Actually, no.  This was hypothetical, maybe unfounded.


Regards,

Michael.

bug#15042: 24.3.50; while-no-input and input-pending-p

[Stefan Monnier]

>> > 1.  `input-pending-p' can (and does) return t in cases were no input is
>> > pending (see the doc).  In such cases, `while-no-input' just returns t,
>> > although no input was given.  This contradicts the doc, is not useful
>> > and the behavior is unforeseeable.
>> Those cases where it immediately returns t should hopefully be very
>> similar to those cases where it stops in the middle even tho the event
>> that interrupted it is "ignorable".
> Sure? (What are such "ignorable" events?)  That would mean that binding
> `throw-on-input' also "fires" in cases where no input arrived.

Same as for input-pending-p, I think, yes.  The issue is not really "no
input" but that what you consider as input is not necessarily the same
as what Emacs considers as input.

E.g. Moving the mouse might send mouse-movement events.  Would you consider
that as "input"?  Emacs sometimes does (e.g. when you select text with
the mouse), but in most cases it should be ignored.  Emacs tries to get
it right, but...

> Is there an alternative to cancel a calculation on input without "false
> positives"?

I don't think so.  But we can refine the definition of "input" to ebtter
match the user's expectation.

>> > With the current implementation, I have to `discard-input' if I don't
>> > want this.
>> Can you give an example where you'd want to do that?
> Actually, no.  This was hypothetical, maybe unfounded.

If/when you do, please report it, so we can try and fix it.


        Stefan

bug#15042: 24.3.50; while-no-input and input-pending-p

[Lars Ingebrigtsen]

Michael Heerdegen <michael_heerdegen@web.de> writes:

>> > With the current implementation, I have to `discard-input' if I don't
>> > want this.
>>
>> Can you give an example where you'd want to do that?
>
> Actually, no.  This was hypothetical, maybe unfounded.

The definition of while-no-input has changed a lot since this issue was
opened, but it looks like it's basically functionally equivalent still.

Like Stefan, I think the definition looks correct -- we don't want to
do BODY even if the keystrokes arrive before `while-no-input' has
arrived, and (as you point out) if you don't want that, you can put a
`discard-input' before the loop.

So I think this is working as designed, and I'm closing this bug
report.  If there's something to be worked on here, please respond to
the debbugs address and we'll reopen.

-- 
(domestic pets only, the antidote for overdose, milk.)
   bloggy blog: http://lars.ingebrigtsen.no