[simon.marshall@misys.com: Lingering input pending with motif menu bar]

[simon.marshall@misys.com: Lingering input pending with motif menu bar]

[Richard Stallman]

Would someone please DTRT and ack?

------- Start of forwarded message -------
From: "Marshall, Simon" <simon.marshall@misys.com>
To: "'Emacs Pretest Bug (emacs-pretest-bug@gnu.org)'"
	<emacs-pretest-bug@gnu.org>
Date: Fri, 30 Jun 2006 15:03:37 +0100
MIME-Version: 1.0
Content-Type: text/plain
Subject: Lingering input pending with motif menu bar
X-Spam-Status: No, score=0.0 required=5.0 tests=none autolearn=failed 
	version=3.0.4

I can reproduce this with --with-x-toolkit=MOTIF, but not LUCID.  Note that
Motif is provided by Solaris.  I don't have GNU/Lesstif (sp?) to try it
with.  Fingers crossed that this is also the cause of some other oddities
I've seen with the menu bar that I've not been able to document enough to
report...

src/emacs -Q
Options > Enter Debugger on Quit/C-g
Tools > Games > Towers of Hanoi

I get split windows, with the top of the *Hanoi* buffer in the upper window
and the *Backtrace* buffer in the lower window, containing:

Debugger entered--Lisp error: (quit "I can tell you've had enough")
  signal(quit ("I can tell you've had enough"))
  hanoi-sit-for(0)
  hanoi-n(nil nil (217 . 61) (503 . 113) (477 . 87) 1151672642.537304)
  hanoi-n((0) ((217 . 3)) (217 . 61) (477 . 87) (503 . 113)
1151672642.537304)
  hanoi-n((0 0) ((295 . 5) (217 . 3)) (217 . 61) (503 . 113) (477 . 87)
1151672642.537304)
  hanoi-n((0 0 0) ((373 . 7) (295 . 5) (217 . 3)) (217 . 61) (477 . 87) (503
. 113) 1151672642.537304)
  hanoi-internal(3 (0 0 0) 1151672642.537304)
  hanoi(3)
  call-interactively(hanoi)

Tools > Games > Life also stops immediately, though Snake and Tetris do not.

M-x hanoi and M-x life work normally.

Debugging it, I see:

(dbx) where
=>[1] readable_events(flags = 3), line 3551 in "keyboard.c"
  [2] get_input_pending(addr = 0x4bfd20, flags = 3), line 6599 in
"keyboard.c"
  [3] Finput_pending_p(), line 10006 in "keyboard.c"
  ...

Which is the return at this statement:

	      if (!(
#ifdef USE_TOOLKIT_SCROLL_BARS
		    (flags & READABLE_EVENTS_FILTER_EVENTS) &&
#endif
		    event->kind == FOCUS_IN_EVENT)
#ifdef USE_TOOLKIT_SCROLL_BARS
		  && !((flags & READABLE_EVENTS_IGNORE_SQUEEZABLES)
		       && event->kind == SCROLL_BAR_CLICK_EVENT
		       && event->part == scroll_bar_handle
		       && event->modifiers == 0)
#endif
		  )
		return 1;

Which it hits the first time through the outer do-while loop.  The event is:

(dbx) print *event
*event = {
    kind            = HELP_EVENT
    code            = 0
    part            = scroll_bar_move_ratio
    modifiers       = 1
    x               = 541935616
    y               = 541935616
    timestamp       = 4280257056U
    padding         = (0x200030, 0x1)
    frame_or_window = -2138585600
    arg             = 541935616
}

I'm not sure what a HELP_EVENT is, but it doesn't look right.  How can I
help?

In GNU Emacs 22.0.50.3 (sparc-sun-solaris2.8, Motif Version 2.1.0)
 of 2006-06-26 on perth
X server distributor `Hummingbird Ltd.', version 11.0.100015
configured using `configure
'--prefix=/rvcarma/marshals/software/slash/usr/local'
'--with-x-toolkit=motif' 'CFLAGS=-g''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: en_GB.ISO8859-1
  value of $LC_CTYPE: en_GB.ISO8859-1
  value of $LC_MESSAGES: C
  value of $LC_MONETARY: en_GB.ISO8859-1
  value of $LC_NUMERIC: en_GB.ISO8859-1
  value of $LC_TIME: en_GB.ISO8859-1
  value of $LANG: en_GB.ISO8859-1
  locale-coding-system: iso-8859-1
  default-enable-multibyte-characters: t

Major mode: Emacs-Lisp

Minor modes in effect:
  tooltip-mode: t
  tool-bar-mode: t
  mouse-wheel-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  unify-8859-on-encoding-mode: t
  utf-translate-cjk-mode: t
  auto-compression-mode: t


_______________________________________________
emacs-pretest-bug mailing list
emacs-pretest-bug@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-pretest-bug
------- End of forwarded message -------

Re: [simon.marshall@misys.com: Lingering input pending with motif menu bar]

[Chong Yidong]

> Would someone please DTRT and ack?
>
> I can reproduce this with --with-x-toolkit=MOTIF, but not LUCID.  Note that
> Motif is provided by Solaris.  I don't have GNU/Lesstif (sp?) to try it
> with.  Fingers crossed that this is also the cause of some other oddities
> I've seen with the menu bar that I've not been able to document enough to
> report...
>
> src/emacs -Q
> Options > Enter Debugger on Quit/C-g
> Tools > Games > Towers of Hanoi
>
> I get split windows, with the top of the *Hanoi* buffer in the upper window
> and the *Backtrace* buffer in the lower window, containing:

As the Hanoi program runs, it checks (input-pending-p), and quits if
input is detected.  The trouble is that when you invoke hanoi with the
menubar, on some toolkits, (input-pending-p) gets triggered even when
there is no input arriving.

The Elisp manual entry for input-pending-p says

  On rare occasions it may return `t' when no input is available.

so this is not necessarily the fault of input-pending-p, but it is
still annoying and problematic.  I have checked that sit-for also
suffers from the same problem (i.e., if Hanoi is recoded to run while
(sit-for foo) is t, the sit-for gets interrupted spuriously.)

I can see this happening reliably when Emacs is compiled with no X
toolkit; it doesn't happen with GTK.

Maybe someone who's worked on sit-for and/or the no-toolkit menu code
can enlighten us.  Why does the input-pending-p get triggered, and is
there any way to distinguish between a real input event and a fake
one?  (Checking unread-command-chars or last-input-event doesn't
work).

Re: [simon.marshall@misys.com: Lingering input pending with motif menu bar]

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> As the Hanoi program runs, it checks (input-pending-p), and quits if
> input is detected.  The trouble is that when you invoke hanoi with the
> menubar, on some toolkits, (input-pending-p) gets triggered even when
> there is no input arriving.
>
> The Elisp manual entry for input-pending-p says
>
>   On rare occasions it may return `t' when no input is available.

This is inaccurate!  It happens all the time.

For example, try this:

GNU Emacs 22.0.50.67 (i686-pc-linux-gnu, X toolkit, Xaw3d scroll bars)

emacs -Q
M-x hanoi

Move the mouse to a tool-bar button or outside the emacs frame.

Hanoi quits.


Problem is that input-pending-p simply indicates that there is
some unprocessed event in the queue -- not necessarily something
the user entered by pressing a key or clicking a mouse button.

I haven't looked to see what specific events are in the queue
in the above cases, but maybe it is a help-echo and "leave" event.

> Maybe someone who's worked on sit-for and/or the no-toolkit menu code
> can enlighten us.  Why does the input-pending-p get triggered, and is
> there any way to distinguish between a real input event and a fake
> one?  (Checking unread-command-chars or last-input-event doesn't
> work).

There is code to ignore FOCUS_IN events in readable_events.
Maybe we can extend the list to include more events.
But we may want to actually process some of those events.

--
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [simon.marshall@misys.com: Lingering input pending with motif menu bar]

[Chong Yidong]

> Problem is that input-pending-p simply indicates that there is
> some unprocessed event in the queue -- not necessarily something
> the user entered by pressing a key or clicking a mouse button.
>
> I haven't looked to see what specific events are in the queue
> in the above cases, but maybe it is a help-echo and "leave" event.
>
>> Maybe someone who's worked on sit-for and/or the no-toolkit menu code
>> can enlighten us.  Why does the input-pending-p get triggered, and is
>> there any way to distinguish between a real input event and a fake
>> one?  (Checking unread-command-chars or last-input-event doesn't
>> work).
>
> There is code to ignore FOCUS_IN events in readable_events.
> Maybe we can extend the list to include more events.
> But we may want to actually process some of those events.

I've found a Lisp-level workaround --- by using `read-event' and
`with-timeout', it's possible to catch just the events we are
interested in (i.e., mouse clicks and keystrokes).  It took quite a
long time to find something that works, though.

If this is an acceptable solution, the Elisp manual node on "Waiting"
could be updated to mention this hack.

*** emacs/lisp/play/hanoi.el.~1.19.~	2006-05-09 10:08:04.000000000 -0400
--- emacs/lisp/play/hanoi.el	2006-07-04 09:44:24.000000000 -0400
***************
*** 399,407 ****
  ;; update display and pause, quitting with a pithy comment if the user
  ;; hits a key.
  (defun hanoi-sit-for (seconds)
!   (sit-for seconds)
!   (if (input-pending-p)
!       (signal 'quit '("I can tell you've had enough"))))
  
  ;; move ring to a given buffer position and update ring's car.
  (defun hanoi-ring-to-pos (ring pos)
--- 399,409 ----
  ;; update display and pause, quitting with a pithy comment if the user
  ;; hits a key.
  (defun hanoi-sit-for (seconds)
!   (if (= 0 seconds)
!       (sit-for 0)
!     (if (with-timeout (seconds nil)
! 	  (read-event))
! 	(signal 'quit '("I can tell you've had enough")))))
  
  ;; move ring to a given buffer position and update ring's car.
  (defun hanoi-ring-to-pos (ring pos)

RE: [simon.marshall@misys.com: Lingering input pending with motifmenu bar]

[Drew Adams]

    > The Elisp manual entry for input-pending-p says
    >   On rare occasions it may return `t' when no input is available.

    This is inaccurate!  It happens all the time.

    Problem is that input-pending-p simply indicates that there is
    some unprocessed event in the queue -- not necessarily something
    the user entered by pressing a key or clicking a mouse button.

    I haven't looked to see what specific events are in the queue
    in the above cases, but maybe it is a help-echo and "leave" event.

Is this perhaps related? `handle-switch-frame' shows up as a user command. I
use a separate frame for each buffer, and I have a standalone minibuffer. As
a result of this virtual user "command", I end up doing things like this in
my code:

 (if (memq last-command (list this-command 'handle-switch-frame))...

Logically, I just want to check if the current user command is the same as
the previous one. But because of automatically inserted
`handle-switch-frame' entries, I need to pollute the test to deal with those
also. Note that the `handle-switch-frame' can arise without the user doing
anything (that I can see) - without, for instance, using the mouse or
keyboard to switch frames. I get the impression that even if the program
itself changes frame focus for some reason, a `handle-switch-frame'
"command" is inserted in the command history.

I haven't traced this in detail, to try to understand it, but it is annoying
and it makes the code less readable. I don't know if this is by design or a
bug. I imagine that there are good reasons why `handle-switch-frame' shows
up in the command history. I'm just pointing out that it makes my code more
cumbersome.

Please don't ask for a test case or scenario - I don't have time to do that
now. If this rings a bell, and you can enlighten me about this, fine; I'd
like to understand it better. If not, please ignore.

Re: [simon.marshall@misys.com: Lingering input pending with motif menu bar]

[Richard Stallman]

    I've found a Lisp-level workaround --- by using `read-event' and
    `with-timeout', it's possible to catch just the events we are
    interested in (i.e., mouse clicks and keystrokes).  It took quite a
    long time to find something that works, though.

    If this is an acceptable solution, the Elisp manual node on "Waiting"
    could be updated to mention this hack.

If this is the right way to wait N seconds, we should make sit-for do
this, so that user programs don't have to use a complex work-around.

If this indeed works right, then I think putting this into sit-for
is a clear bug-fix.  Would you like to do it?

RE: [simon.marshall@misys.com: Lingering input pending with motifmenu bar]

[Drew Adams]

        I've found a Lisp-level workaround --- by using `read-event' and
        `with-timeout', it's possible to catch just the events we are
        interested in (i.e., mouse clicks and keystrokes).  It took quite a
        long time to find something that works, though.

    If this is the right way to wait N seconds, we should make sit-for do
    this, so that user programs don't have to use a complex work-around.

    If this indeed works right, then I think putting this into sit-for
    is a clear bug-fix.  Would you like to do it?

Please make sure that all possible user events are treated. I don't know if
Chong meant to include mouse wheel in "mouse clicks", but wheel movement
should be included as a user event that ends `sit-for'. Likewise, drag
events (which aren't clicks either). Also, at least some of the special
events (`special-event-map') are user events (e.g. iconify-frame,
delete-frame).

Even though the doc of `sit-for' speaks of input events, I wonder if there
isn't perhaps some existing code that expects `sit-for' to also stop waiting
for other, non-user events. We shall see...

Also, if we fix `sit-for' this way, would something similar need to be done
for code that sets variables such as `last-input-event'? I'm guessing that
here and there current code already tries to distinguish user events, and it
might need updating to use the correct approach. IOW, maybe the same
approach should be used elsewhere.

Because the exact list of events that are user-initiated might change (e.g.
over releases), I wonder if it would be worth defining `user-event' as a
type (category) of events and `user-event-p' as its test. Then, any code
that deals with this would use that, and the exact set of user events would
only be updated in one place.

Is the `sit-for' bug fix to be made before the release?

Re: [simon.marshall@misys.com: Lingering input pending with motif menu bar]

[Chong Yidong]

Richard Stallman <rms@gnu.org> writes:

>     I've found a Lisp-level workaround --- by using `read-event' and
>     `with-timeout', it's possible to catch just the events we are
>     interested in (i.e., mouse clicks and keystrokes).  It took quite a
>     long time to find something that works, though.
>
>     If this is an acceptable solution, the Elisp manual node on "Waiting"
>     could be updated to mention this hack.
>
> If this is the right way to wait N seconds, we should make sit-for do
> this, so that user programs don't have to use a complex work-around.
>
> If this indeed works right, then I think putting this into sit-for
> is a clear bug-fix.  Would you like to do it?

The trouble is that sit-for is widely-used in the Emacs sources,
particularly (sit-for 0) for forcing redisplay.  There is apparently a
need for a routine that waits for a set time, and stops if and only if
there is an Emacs Lisp input event available, which is not an exact
match for what `sit-for' does.  So how about putting this macro into
timer.el?  We can change individual existing `sit-for' calls to use
this if necessary (e.g. in Hanoi), and avoid destabilizing the tree at
this stage of the release.

Another point is that it relies on the timer.el code, and is thus more
heavyweight than sit-for, which is a built-in.  So it can't replace
sit-for generally.

Yes, I've checked that this gets interrupted by input events like
mouse wheel turns, etc: basically, anything that read-event would
grab.  It does not get interrupted by moving the mouse over a toolbar
button, unlike sit-for.


(defmacro wait-for-input (seconds)
  "Wait for SECONDS seconds or until an input event is available.
Value is t if the full time elapsed with no input arriving, and
nil otherwise.

SECONDS may be a floating-point value, meaning that you can wait
for a fraction of a second.  (Not all operating systems support
waiting for a fraction of a second.)

If an input event arrives, it is put in `unread-command-events'.

Unlike `sit-for', this returns nil if and only if an input event
is available.  It does not perform redisplay."
  `(let ((tag (cons nil nil))
	 (with-timeout-timers with-timeout-timers)
	 event timer)
     (if (catch tag
	   (progn
	     (setq timer (run-with-timer ,seconds nil
					 'with-timeout-handler
					 tag))
	     (push timer with-timeout-timers)
	     (setq event (read-event))
	     nil))
	 t
       (cancel-timer timer)
       (push event unread-command-events)
       nil)))

Re: [simon.marshall@misys.com: Lingering input pending with motif menu bar]

[Kim F. Storm]

Chong Yidong <cyd@stupidchicken.com> writes:

> The trouble is that sit-for is widely-used in the Emacs sources,
> particularly (sit-for 0) for forcing redisplay.  There is apparently a
> need for a routine that waits for a set time, and stops if and only if
> there is an Emacs Lisp input event available, which is not an exact
> match for what `sit-for' does.  So how about putting this macro into
> timer.el?  We can change individual existing `sit-for' calls to use
> this if necessary (e.g. in Hanoi), and avoid destabilizing the tree at
> this stage of the release.

I agree this change is too risky to put into sit-for now.


> It does not get interrupted by moving the mouse over a toolbar
> button, unlike sit-for.

Excellent!

>
> (defmacro wait-for-input (seconds)

Why is it a macro?

IMO, it should be a defun and placed in subr.el.


Also, why not add a NODISP arg (similar to sit-for) and change the
code to call (sit-for -1) on entry if NODISP is nil.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: [simon.marshall@misys.com: Lingering input pending with motifmenu bar]

[Richard Stallman]

    Also, if we fix `sit-for' this way, would something similar need to be done
    for code that sets variables such as `last-input-event'?

If an event is handled at a level that users don't see, we should
probably prevent it from remaining in `last-input-event' after that is
done with.

    Because the exact list of events that are user-initiated might change (e.g.
    over releases), I wonder if it would be worth defining `user-event' as a
    type (category) of events and `user-event-p' as its test. Then, any code
    that deals with this would use that, and the exact set of user events would
    only be updated in one place.

I don't understand how this would be used or what problem it is meant
to solve.

Re: [simon.marshall@misys.com: Lingering input pending with motifmenu bar]

[Richard Stallman]

    Is the `sit-for' bug fix to be made before the release?

I think it should be.  It should not be so disruptive that we
need to put it off.

It is true that there are many calls to sit-for.  That doesn't mean
these callers want the current behavior.  They use sit-for because it
is the way to let input pre-empt the delay.  I think that most of the
callers will be better off if the bug is fixed.  Perhaps all of them.

I think it is likely that NO caller really wants this bug.
But someone needs to check.

RE: [simon.marshall@misys.com: Lingering input pending withmotifmenu bar]

[Drew Adams]

        Because the exact list of events that are user-initiated
        might change (e.g. over releases), I wonder if it would be
        worth defining `user-event' as a type (category) of events
        and `user-event-p' as its test. Then, any code that deals
        with this would use that, and the exact set of user events
        would only be updated in one place.

    I don't understand how this would be used or what problem it is meant
    to solve.

It was just a thought - half-baked, no, hardly baked at all.

If user events are not easily distinguished from other, system-generated (?)
events, then code that wants to handle only user events needs to do the
filtering, event type by event type, to get only the events it wants to
handle. I'm guessing that much (most?) library code that handles events
wants to ignore all events not initiated by users.

The idea would be to have a simple test that code could use to tell whether
an event or an event type was user-initiated or not. Then, instead of
testing for multiple user event types, it could test an event with just
`user-event-p'. More generally, perhaps organize event types into sets
(categories) or, to put it another way, have a hierarchy of event types - at
least `user-event', from which all user event types would "inherit" (in some
way).

People who know more about events can speak to whether something like this
might actually be useful or not - I don't know.

Re: [simon.marshall@misys.com: Lingering input pending withmotifmenu bar]

[Richard Stallman]

    The idea would be to have a simple test that code could use to tell whether
    an event or an event type was user-initiated or not.

That is starting to make some sense.  Such a distinction may be
useful.  But maybe it is only needed inside sit-for, as part of fixing
the bug that we're now talking about.  If we find it is useful
elsewhere, then we can define a way for user code to check it.

Revamping sit-for [Was: Lingering input pending with motif menu bar]

[Chong Yidong]

In the thread

  [simon.marshall@misys.com: Lingering input pending with motif menu bar]

Richard has said he wanted to replace sit-for so that only actual
Emacs Lisp events will interrupt input.  I still think this is a
little dangerous so close to the release, but if we gotta do what we
gotta do, I have written the necessary code for it.  It involves the
following changes:

1. Delete the built-in function Fsit_for, and change the four places
   in the C source code that call Fsit_for to call sit_for instead.

2. Insert a new built-in function `redisplay':

DEFUN ("redisplay", Fredisplay, Sredisplay, 0, 0, 0,
       doc: /* Perform redisplay.
If input is available before this starts, redisplay is preempted
unless `redisplay-dont-pause' is non-nil.  */)
     ()
{
  swallow_events (Qt);
  redisplay_preserve_echo_area (2);
  return Qt;
}

3. Put a new function `sit-for' in subr.el:

(defun sit-for (seconds &optional nodisp obsolete)
  "Perform redisplay, then wait for SECONDS seconds or until input is available.
SECONDS may be a floating-point value, meaning that you can wait for a
fraction of a second.
\(Not all operating systems support waiting for a fraction of a second.)
Optional arg NODISP non-nil means don't redisplay, just wait for input.
Redisplay is preempted as always if input arrives, and does not happen
if input is available before it starts.
Value is t if waited the full time with no input arriving, and nil otherwise.

Redisplay will occur even when input is available if SECONDS is negative.

An obsolete but still supported form is
\(sit-for SECONDS &optional MILLISECONDS NODISP)
Where the optional arg MILLISECONDS specifies an additional wait period,
in milliseconds; this was useful when Emacs was built without
floating point support.
usage: (sit-for SECONDS &optional NODISP OLD-NODISP)"
  (when obsolete
    (setq seconds (+ seconds (* 1e-3 nodisp)))
    (setq nodisp obsolete))
  (unless nodisp
    (let ((redisplay-dont-pause (or (< seconds 0) redisplay-dont-pause)))
      (redisplay)))
  (or (<= seconds 0)
      (let ((tag (cons nil nil))
	    event timer)
	(if (catch tag
	      (setq timer (run-with-timer seconds nil 'with-timeout-handler tag))
	      (setq event (read-event))
	      nil)
	    t
	  (cancel-timer timer)
	  (push event unread-command-events)
	  nil))))

I have tested out these changes, and observed that Emacs does not
explode.  Richard, if you really want to do this, I can check the
changes in so that they can get as much testing as possible before the
pretest.

Re: Revamping sit-for

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

> In the thread
>
>   [simon.marshall@misys.com: Lingering input pending with motif menu bar]
>
> Richard has said he wanted to replace sit-for so that only actual
> Emacs Lisp events will interrupt input.  I still think this is a
> little dangerous so close to the release, but if we gotta do what we
> gotta do, I have written the necessary code for it.  It involves the
> following changes:
>
> 1. Delete the built-in function Fsit_for, and change the four places
>    in the C source code that call Fsit_for to call sit_for instead.
>
> 2. Insert a new built-in function `redisplay':

[...]

> 3. Put a new function `sit-for' in subr.el:
>
> (defun sit-for (seconds &optional nodisp obsolete)

[uses timers]

> I have tested out these changes, and observed that Emacs does not
> explode.  Richard, if you really want to do this, I can check the
> changes in so that they can get as much testing as possible before
> the pretest.

Personally, I find the changes too far-reaching to feel comfortable
about them now.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

RE: Revamping sit-for [Was: Lingering input pending with motif menu bar]

[Drew Adams]

    3. Put a new function `sit-for' in subr.el:

Excuse me if I'm misunderstanding, but how can you change the signature of
sit-for in a way that breaks existing code? IIUC, it is changing from

  (sit-for seconds)
  (sit-for seconds milliseconds)
  (sit-for seconds milliseconds nodisp)

to

  (sit-for seconds)
  (sit-for seconds nodisp)
  (sit-for seconds nodisp obsolete)

That means that existing calls that use the milliseconds arg will be newly
interpreted to consider that arg as a no-display arg, no?

What happens to an existing call such as (sit-for 3 200)? Is that now
interpreted as "sit for 3 seconds with no redisplay"? What about (sit-for 3
200 t) - is that too interpreted only as "sit for 3 seconds with no
redisplay"?

I didn't check the code; I just read the doc string.

    (defun sit-for (seconds &optional nodisp obsolete)
...
    An obsolete but still supported form is
    \(sit-for SECONDS &optional MILLISECONDS NODISP)
    Where the optional arg MILLISECONDS specifies an additional wait period,
    in milliseconds; this was useful when Emacs was built without
    floating point support.
    usage: (sit-for SECONDS &optional NODISP OLD-NODISP)"

Re: Revamping sit-for

[Chong Yidong]

"Drew Adams" <drew.adams@oracle.com> writes:

> Excuse me if I'm misunderstanding, but how can you change the signature of
> sit-for in a way that breaks existing code? IIUC, it is changing from
>
>   (sit-for seconds)
>   (sit-for seconds milliseconds)
>   (sit-for seconds milliseconds nodisp)
>
> to
>
>   (sit-for seconds)
>   (sit-for seconds nodisp)
>   (sit-for seconds nodisp obsolete)
>
> That means that existing calls that use the milliseconds arg will be newly
> interpreted to consider that arg as a no-display arg, no?

No.  If the third argument is non-nil, it uses the old behavior.  But
this is considered an obsolete behavior, so it is only briefly
explained in the docstring; all this is identical to the current
behavior.

RE: Revamping sit-for

[Drew Adams]

    > Excuse me if I'm misunderstanding, but how can you change the
    > signature of
    > sit-for in a way that breaks existing code? IIUC, it is changing from
    >
    >   (sit-for seconds)
    >   (sit-for seconds milliseconds)
    >   (sit-for seconds milliseconds nodisp)
    >
    > to
    >
    >   (sit-for seconds)
    >   (sit-for seconds nodisp)
    >   (sit-for seconds nodisp obsolete)
    >
    > That means that existing calls that use the milliseconds arg
    > will be newly interpreted to consider that arg as a
    > no-display arg, no?

    No.  If the third argument is non-nil, it uses the old behavior.  But
    this is considered an obsolete behavior, so it is only briefly
    explained in the docstring; all this is identical to the current
    behavior.

If everything is identical to the current behavior, then the doc string
seems very wrong.

The doc string says, to me, that an existing call of (sit-for 3 200), which
previously simply waited 3.2 sec, with no inhibition of display, will now be
interpreted as a wait of 3.0 sec, with inhibition of display. That's a
serious change in behavior.

I don't see how else to read the doc string: (sit-for 3 200) fits the
pattern (sit-for seconds nodisp), and it says that nodisp non-nil means no
redisplay.

You mention the third arg being non-nil, saying that in that case it uses
the old behavior. Even it that is the case (and it should be so stated, if
so), what about when the third arg is nil?

Sorry, but I just don't get this. What's the magic or the missing
ingredient?

Re: Revamping sit-for

[Chong Yidong]

> The doc string says, to me, that an existing call of (sit-for 3 200), which
> previously simply waited 3.2 sec, with no inhibition of display, will now be
> interpreted as a wait of 3.0 sec, with inhibition of display. That's a
> serious change in behavior.

  if (NILP (nodisp) && !NUMBERP (milliseconds))
    { /* New style.  */
      nodisp = milliseconds;
      milliseconds = Qnil;
    }

However, since the old form has been obsolete for a long time, and can
cause confusion (as demonstrated), it might be good to simply drop it.

Re: Revamping sit-for

[David Kastrup]

Chong Yidong <cyd@stupidchicken.com> writes:

>> The doc string says, to me, that an existing call of (sit-for 3 200), which
>> previously simply waited 3.2 sec, with no inhibition of display, will now be
>> interpreted as a wait of 3.0 sec, with inhibition of display. That's a
>> serious change in behavior.
>
>   if (NILP (nodisp) && !NUMBERP (milliseconds))
>     { /* New style.  */
>       nodisp = milliseconds;
>       milliseconds = Qnil;
>     }
>
> However, since the old form has been obsolete for a long time, and can
> cause confusion (as demonstrated), it might be good to simply drop it.

This is not a time for such a step.  We should do this after some
release, if at all.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: Revamping sit-for

[Stefan Monnier]

>> The doc string says, to me, that an existing call of (sit-for 3 200), which
>> previously simply waited 3.2 sec, with no inhibition of display, will now be
>> interpreted as a wait of 3.0 sec, with inhibition of display. That's a
>> serious change in behavior.

>   if (NILP (nodisp) && !NUMBERP (milliseconds))
>     { /* New style.  */
>       nodisp = milliseconds;
>       milliseconds = Qnil;
>     }

> However, since the old form has been obsolete for a long time, and can
> cause confusion (as demonstrated), it might be good to simply drop it.

Huh?  "Obsolete for a long time"?
We don't know yet when was the first time it's been officially obsoleted
because Emacs-22 will be the first version to obsolete the "old" form.
I.e. the new form (introduced partly for XEmacs compatibility) is new in
Emacs-22.


        Stefan

Re: Revamping sit-for

[Romain Francoise]

David Kastrup <dak@gnu.org> writes:

> This is not a time for such a step.  We should do this after some
> release, if at all.

<aol />

-- 
Romain Francoise <romain@orebokech.com> | The sea! the sea! the open
it's a miracle -- http://orebokech.com/ | sea! The blue, the fresh, the
                                        | ever free! --Bryan W. Procter

Re: Revamping sit-for [Was: Lingering input pending with motif menu bar]

[Richard Stallman]

    Richard has said he wanted to replace sit-for so that only actual
    Emacs Lisp events will interrupt input.

I would like to do this, but first we need to check whether there are
any callers that really want the current behavior of sit-for.  It's
unlikely that any caller does want it, but not impossible, and we
should check.

Could people please check?

RE: Revamping sit-for

[Drew Adams]

    > The doc string says, to me, that an existing call of (sit-for
    > 3 200), which previously simply waited 3.2 sec, with no
    > inhibition of display, will now be interpreted as a wait of
    > 3.0 sec, with inhibition of display. That's a
    > serious change in behavior.

      if (NILP (nodisp) && !NUMBERP (milliseconds))
        { /* New style.  */ nodisp = milliseconds;
          milliseconds = Qnil;}

    However, since the old form has been obsolete for a long time, and can
    cause confusion (as demonstrated), it might be good to simply drop it.

My argument, from the beginning, has been based on what "the doc string
says". You've already stated previously that the code does what you indicate
above. Your doc string, however, says something entirely different - it
suggests that existing code will not work, for the reasons I indicated.

There appear to be three possible issues at stake here:
1. Whether your change is a good one.
2. Whether it should be made now.
3. Whether the doc string accurately describes the change.

Others have spoken mainly to #2 (no). My point was that either the doc
string is inaccurate (#3) or the change is a bad one (#1). Your argument
supports #3: your doc string is inaccurate.

Re: Revamping sit-for

[Richard Stallman]

    However, since the old form has been obsolete for a long time, and can
    cause confusion (as demonstrated), it might be good to simply drop it.

No, that would be too drastic.  A change like this should be done
in multiple steps.

The first step might be to arrange to display a warning with a
backtrace the first time the old form is used in any session.  That
way we could arrange to notify programmers to fix old calls, without
breaking the packages that contain them.

However, if 22.0 is the first release in which that interface
is considered obsolete, we should not take any further steps
until Emacs 23.

Re: Revamping sit-for [Was: Lingering input pending with motif menu bar]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Richard has said he wanted to replace sit-for so that only actual
>     Emacs Lisp events will interrupt input.
>
> I would like to do this, but first we need to check whether there are
> any callers that really want the current behavior of sit-for.  It's
> unlikely that any caller does want it, but not impossible, and we
> should check.
>
> Could people please check?

Can you give a _precise_ description of what behaviour of the old sit-for
is "lost" in the new sit-for.

I think we should put that into NEWS, in case someone has external code
which relies on the old behaviour.


I would also like to have an optional arg FORCE to the new "redisplay"
function which does an immediate update.

Then we can get rid of the ugly hacky (sit-for -1) added recently.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Revamping sit-for [Was: Lingering input pending with motif menu bar]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Richard has said he wanted to replace sit-for so that only actual
>     Emacs Lisp events will interrupt input.
>
> I would like to do this, but first we need to check whether there are
> any callers that really want the current behavior of sit-for.  It's
> unlikely that any caller does want it, but not impossible, and we
> should check.
>
> Could people please check?

FYI, there are 534 calls to sit-for in *.el files.

It seems hard to try to understand for each of these calls whether
non-Lisp event are _intended_ to interrupt it or not.

BTW, 134 of those calls are (sit-for 0), which most likely are intended
to do a redisplay, so for clarity, they could be replaced by (redisplay).

Maybe some calls to sit-for may actually wait for process output; in which
case they should really be calls to accept-process-output.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Revamping sit-for [Was: Lingering input pending with motif menu bar]

[Richard Stallman]

    Can you give a _precise_ description of what behaviour of the old sit-for
    is "lost" in the new sit-for.

I don't have one, because that behavior was never designed.  It was a
bug.  It arose in the 90s as an unintended consequence of the
existence of events (I think even X events) that the user would never
see.

I think the behavior is that internal events can appear in the queue
and cause sit-for to return, but then no input is really available.

Chances are that this behavior causes nothing but bugs, and that all
callers will benefit from the correction of it.  However, I think we
ought to check the callers, so as to make sure we don't introduce any
new bugs by this change.

Re: Revamping sit-for [Was: Lingering input pending with motif menu bar]

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     Can you give a _precise_ description of what behaviour of the old sit-for
>     is "lost" in the new sit-for.
>
> I don't have one, because that behavior was never designed.  It was a
> bug.  It arose in the 90s as an unintended consequence of the
> existence of events (I think even X events) that the user would never
> see.
>
> I think the behavior is that internal events can appear in the queue
> and cause sit-for to return, but then no input is really available.
>
> Chances are that this behavior causes nothing but bugs, and that all
> callers will benefit from the correction of it.  However, I think we
> ought to check the callers, so as to make sure we don't introduce any
> new bugs by this change.


It would be useful to know exactly what events will no longer make
sit-for return -- then we could grep for those events and see if any
lisp code uses sit-for to wait for one of those events.

That would be a much more directed effort than trying to understand
each of the 534 calls to sit-for.

BTW, will "help-echo" events still make the new sit-for return?

Chong, could you post a genuine patch with your changes.
Thanks.


-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Revamping sit-for

[Chong Yidong]

For better or worse, I've checked in the new sit-for that's written in
Emacs Lisp.  Probably a "make bootstrap" will be necessary.

Once the dust settles, I'll go through the Lisp tree replacing
(sit-for 0) calls with (redisplay).

At least Hanoi works now (yay).

Re: Revamping sit-for

[Chong Yidong]

Chong Yidong <cyd@stupidchicken.com> writes:

> For better or worse, I've checked in the new sit-for that's written in
> Emacs Lisp.  Probably a "make bootstrap" will be necessary.
>
> Once the dust settles, I'll go through the Lisp tree replacing
> (sit-for 0) calls with (redisplay).

As part of this change, there is a new built-in function `redisplay'
that is equivalent to the old (sit-for 0).  Also, (thanks Kim!)
calling `redisplay' with the optional argument FORCE forces redisplay.

It seems to me that the following hack, which would have been new to
Emacs 22:

  *** `sit-for' called with a negative SECONDS value now forces an
  immediate redisplay even if input is pending.

is now unnecessary; (sit-for -1) will do exactly the same thing as
(redisplay t) and the latter is much clearer

If there are no objections, I'll remove the negative-sit-for behavior,
and add a note about `redisplay' to NEWS.

Re: Revamping sit-for [Was: Lingering input pending with motif menu bar]

[Richard Stallman]

    It would be useful to know exactly what events will no longer make
    sit-for return -- then we could grep for those events and see if any
    lisp code uses sit-for to wait for one of those events.

Some of them, such as help-echo events, could be grepped for.  But
some kinds may not even show up at the Lisp level.  And other code
might not refer to them by name.  Therefore, I don't think such
grepping would be at all reliable.

Re: Revamping sit-for

[Richard Stallman]

      *** `sit-for' called with a negative SECONDS value now forces an
      immediate redisplay even if input is pending.

    is now unnecessary; (sit-for -1) will do exactly the same thing as
    (redisplay t) and the latter is much clearer

    If there are no objections, I'll remove the negative-sit-for behavior,
    and add a note about `redisplay' to NEWS.

Please do.

Would you please also update the Lisp Manual?  Please search for
sit-for in the manual to make sure you find all the places that need
to be changed.

Re: Revamping sit-for

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>       *** `sit-for' called with a negative SECONDS value now forces an
>       immediate redisplay even if input is pending.
>
>     is now unnecessary; (sit-for -1) will do exactly the same thing as
>     (redisplay t) and the latter is much clearer
>
>     If there are no objections, I'll remove the negative-sit-for behavior,
>     and add a note about `redisplay' to NEWS.
>
> Please do.
>
> Would you please also update the Lisp Manual?  Please search for
> sit-for in the manual to make sure you find all the places that need
> to be changed.

I already made those changes yesterday, including updating the manual.

-- 
Kim F. Storm <storm@cua.dk> http://www.cua.dk

Re: Revamping sit-for

[Richard Stallman]

    > Would you please also update the Lisp Manual?  Please search for
    > sit-for in the manual to make sure you find all the places that need
    > to be changed.

    I already made those changes yesterday, including updating the manual.

Thanks.  (I had not seen, when I sent this message, that you had done
them.  I am always a day behind.  Please forgive any confusion this
causes.)