redisplay-dont-pause does not work

redisplay-dont-pause does not work

[David Kastrup]

I am checking for factual correctness of display.texi at the moment.
It says:


      You can request a display update, but only if no input is pending,
    with @code{(sit-for 0)}.  To force a display update even when input is
    pending, do this:

    @example
    (let ((redisplay-dont-pause t))
      (sit-for 0))
    @end example

However, if I do

M-: (progn (redraw-display) (let ((redisplay-dont-pause t)) (sleep-for
1) (sit-for 0) (sleep-for 5))) RET

and press C-n within 1 second, then no redisplay occurs for the whole
duration of 6 seconds.  This is on

GNU Emacs 22.0.50.36 (i686-pc-linux-gnu, GTK+ Version 2.8.17) of 2006-05-24 on lola

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Richard Stallman]

    I am checking for factual correctness of display.texi at the moment.

Thank you for checking it!

    However, if I do

    M-: (progn (redraw-display) (let ((redisplay-dont-pause t)) (sleep-for
    1) (sit-for 0) (sleep-for 5))) RET

    and press C-n within 1 second, then no redisplay occurs for the whole
    duration of 6 seconds.

That seems correct to me.  sit-for sees there is input, so it does
not redisplay.

Do you perceive a contradiction between any part of the documentation
and this observed behavior?

Re: redisplay-dont-pause does not work

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

>     I am checking for factual correctness of display.texi at the moment.
>
> Thank you for checking it!
>
>     However, if I do
>
>     M-: (progn (redraw-display) (let ((redisplay-dont-pause t)) (sleep-for
>     1) (sit-for 0) (sleep-for 5))) RET
>
>     and press C-n within 1 second, then no redisplay occurs for the whole
>     duration of 6 seconds.
>
> That seems correct to me.  sit-for sees there is input, so it does
> not redisplay.
>
> Do you perceive a contradiction between any part of the documentation
> and this observed behavior?

Richard, I quoted it immediately above and you snipped it in your
reply:

      You can request a display update, but only if no input is pending,
    with @code{(sit-for 0)}.  To force a display update even when input is
    pending, do this:

    @example
    (let ((redisplay-dont-pause t))
      (sit-for 0))
    @end example

Yes, I see a contradiction here.  Setting `redisplay-dont-pause' does
not have the declared effect, to wit "to force a display update even
when input is pending".

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Richard Stallman]

	  You can request a display update, but only if no input is pending,
	with @code{(sit-for 0)}.  To force a display update even when input is
	pending, do this:

	@example
	(let ((redisplay-dont-pause t))
	  (sit-for 0))
	@end example

    Yes, I see a contradiction here.  Setting `redisplay-dont-pause' does
    not have the declared effect, to wit "to force a display update even
    when input is pending".

I think that text in the manual is mistaken.  `redisplay-dont-pause'
only affects redisplay itself.  It has no effect on sit-for, which
isn't (strictly speaking) redisplay.

We could change the code, or change the manual.
I am not sure which is better.

Re: redisplay-dont-pause does not work

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> 	  You can request a display update, but only if no input is pending,
> 	with @code{(sit-for 0)}.  To force a display update even when input is
> 	pending, do this:
>
> 	@example
> 	(let ((redisplay-dont-pause t))
> 	  (sit-for 0))
> 	@end example
>
>     Yes, I see a contradiction here.  Setting `redisplay-dont-pause' does
>     not have the declared effect, to wit "to force a display update even
>     when input is pending".
>
> I think that text in the manual is mistaken.  `redisplay-dont-pause'
> only affects redisplay itself.  It has no effect on sit-for, which
> isn't (strictly speaking) redisplay.
>
> We could change the code, or change the manual.
> I am not sure which is better.

Given that there is no other way to force redisplay, I think it would
be sensible to change the code.  The manual would not talk about this
possibility if there was not a perceived need for it.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Lars Hansen]

Richard Stallman wrote:

>We could change the code, or change the manual.
>I am not sure which is better.
>  
>
IMO changing the code is best. Otherwise, IIUC, there is no way one can
force redisplay from a lisp program.

Here is an example of the need of a way to force redisplay:
I have an Emacs lisp program that I use to copy files from one box to
another. It shows in a buffer the list of files to copy and marks each
file as it is processed. If I switch away from the Emacs frame and back
again, the display is no longer updated (except for minibuffer
messages). Until now I did not know why, but now I see that some window
manager event stops (sit-for 0) forcing redisplay.

Re: redisplay-dont-pause does not work

[Eli Zaretskii]

> Date: Sat, 27 May 2006 10:24:39 +0200
> From: Lars Hansen <lists@soem.dk>
> Cc: emacs-devel@gnu.org
> 
> Richard Stallman wrote:
> 
> >We could change the code, or change the manual.
> >I am not sure which is better.
> >  
> >
> IMO changing the code is best. Otherwise, IIUC, there is no way one can
> force redisplay from a lisp program.

I think we should define what does ``force redisplay'' mean, before we
decide how to provide such a feature.  Does it mean redisplay
everything (i.e. every window on every frame)?  Or just the current
frame, or maybe just the current window?  (The latter should be
available with "C-l", I think.)  Do we want to let Lisp programs
specify what they want redisplayed, perhaps?

I think after we decide what possible uses could this functionality
have, we should design a suitable Lisp interface to supersede the
sit-for kludge.  (It is a kludge, IMHO, because it doesn't really
force a redisplay, it just enters the Emacs idle loop, which triggers
a redisplay as one of its side effects--_provided_, that is, that
there's no input pending, which is the reason for the need to toggle
redisplay-dont-pause in the first place.)

> Here is an example of the need of a way to force redisplay:
> I have an Emacs lisp program that I use to copy files from one box to
> another. It shows in a buffer the list of files to copy and marks each
> file as it is processed. If I switch away from the Emacs frame and back
> again, the display is no longer updated (except for minibuffer
> messages). Until now I did not know why, but now I see that some window
> manager event stops (sit-for 0) forcing redisplay.

But sit-for was designed precisely for such situations, I think: wait
for some event with a time-out.  The fact that it does a redisplay is
a side effect, not its purpose.  What we need is redisplay-now or some
such, which will explicitly enter the display engine, without any
delays and conditions.

Re: redisplay-dont-pause does not work

[Stefan Monnier]

>> IMO changing the code is best. Otherwise, IIUC, there is no way one can
>> force redisplay from a lisp program.

> I think we should define what does ``force redisplay'' mean, before we
> decide how to provide such a feature.  Does it mean redisplay
> everything (i.e. every window on every frame)?  Or just the current
> frame, or maybe just the current window?  (The latter should be
> available with "C-l", I think.)  Do we want to let Lisp programs
> specify what they want redisplayed, perhaps?

I think we have to distinguish between a redisplay that does a "redraw" and
one that does what the toplevel loop normally.  The "redraw" does call for
a specification of what to redraw, but the normal toplevel redisplay doesn't
(it just looks for things that have changed since the last "redisplay").
For redraw, we already have redraw-display and redraw-frame and
redraw-modeline, so I think we're set.  For forcing the display to be
updated OTOH only sit-for is available and it's not reliable.


        Stefan

Re: redisplay-dont-pause does not work

[David Kastrup]

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

>>> IMO changing the code is best. Otherwise, IIUC, there is no way one can
>>> force redisplay from a lisp program.
>
>> I think we should define what does ``force redisplay'' mean, before we
>> decide how to provide such a feature.  Does it mean redisplay
>> everything (i.e. every window on every frame)?  Or just the current
>> frame, or maybe just the current window?  (The latter should be
>> available with "C-l", I think.)  Do we want to let Lisp programs
>> specify what they want redisplayed, perhaps?
>
> I think we have to distinguish between a redisplay that does a "redraw" and
> one that does what the toplevel loop normally.  The "redraw" does call for
> a specification of what to redraw, but the normal toplevel redisplay doesn't
> (it just looks for things that have changed since the last "redisplay").
> For redraw, we already have redraw-display and redraw-frame and
> redraw-modeline, so I think we're set.

Disagree.  Those _clear_ the respective frame and mark it as to be
redrawn, but don't actually do the redraw.  Even if one _could_ use
them for forcing a redraw immediately, it would cause unnecessary
flicker.

> For forcing the display to be updated OTOH only sit-for is available
> and it's not reliable.

Well, then maybe one should try making it do what the docs claim?

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> 	  You can request a display update, but only if no input is pending,
> 	with @code{(sit-for 0)}.  To force a display update even when input is
> 	pending, do this:
>
> 	@example
> 	(let ((redisplay-dont-pause t))
> 	  (sit-for 0))
> 	@end example
>
>     Yes, I see a contradiction here.  Setting `redisplay-dont-pause' does
>     not have the declared effect, to wit "to force a display update even
>     when input is pending".
>
> I think that text in the manual is mistaken.  `redisplay-dont-pause'
> only affects redisplay itself.  It has no effect on sit-for, which
> isn't (strictly speaking) redisplay.
>
> We could change the code, or change the manual.
> I am not sure which is better.

Here is a fix for the code.

*** dispnew.c	01 May 2006 10:07:42 +0200	1.363
--- dispnew.c	27 May 2006 22:53:42 +0200	
***************
*** 6406,6412 ****
    swallow_events (display);
  
    if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
!     return Qnil;
  
    if (initial_display)
      redisplay_preserve_echo_area (2);
--- 6406,6415 ----
    swallow_events (display);
  
    if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
!     {
!       if (!redisplay_dont_pause || sec || usec)
! 	return Qnil;
!     }
  
    if (initial_display)
      redisplay_preserve_echo_area (2);


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

Re: redisplay-dont-pause does not work

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> 	  You can request a display update, but only if no input is pending,
>> 	with @code{(sit-for 0)}.  To force a display update even when input is
>> 	pending, do this:
>>
>> 	@example
>> 	(let ((redisplay-dont-pause t))
>> 	  (sit-for 0))
>> 	@end example
>>
>>     Yes, I see a contradiction here.  Setting `redisplay-dont-pause' does
>>     not have the declared effect, to wit "to force a display update even
>>     when input is pending".
>>
>> I think that text in the manual is mistaken.  `redisplay-dont-pause'
>> only affects redisplay itself.  It has no effect on sit-for, which
>> isn't (strictly speaking) redisplay.
>>
>> We could change the code, or change the manual.
>> I am not sure which is better.
>
> Here is a fix for the code.
>
> *** dispnew.c	01 May 2006 10:07:42 +0200	1.363
> --- dispnew.c	27 May 2006 22:53:42 +0200	
> ***************
> *** 6406,6412 ****
>     swallow_events (display);
>   
>     if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
> !     return Qnil;
>   
>     if (initial_display)
>       redisplay_preserve_echo_area (2);
> --- 6406,6415 ----
>     swallow_events (display);
>   
>     if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
> !     {
> !       if (!redisplay_dont_pause || sec || usec)
> ! 	return Qnil;
> !     }
>   
>     if (initial_display)
>       redisplay_preserve_echo_area (2);

Is there a particular reason that you used " || sec || usec" here?  It
makes (sit-for 0) a special case, and I am not sure why.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>>> 	@example
>>> 	(let ((redisplay-dont-pause t))
>>> 	  (sit-for 0))
>>> 	@end example

> Is there a particular reason that you used " || sec || usec" here?  It
> makes (sit-for 0) a special case, and I am not sure why.

To match the example...  And to make the change as non-intrusive
as possible at this stage.


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

Re: redisplay-dont-pause does not work

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>>>> 	@example
>>>> 	(let ((redisplay-dont-pause t))
>>>> 	  (sit-for 0))
>>>> 	@end example
>
>> Is there a particular reason that you used " || sec || usec" here?  It
>> makes (sit-for 0) a special case, and I am not sure why.
>
> To match the example...  And to make the change as non-intrusive as
> possible at this stage.

Is redisplay-dont-pause set by anybody but the user?  If not, the
change is not intrusive.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Richard Stallman]

Does this fix it?

*** dispnew.c	01 May 2006 16:16:58 -0400	1.363
--- dispnew.c	27 May 2006 20:01:39 -0400	
***************
*** 6405,6411 ****
  {
    swallow_events (display);
  
!   if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
      return Qnil;
  
    if (initial_display)
--- 6405,6414 ----
  {
    swallow_events (display);
  
!   if ((detect_input_pending_run_timers (display)
!        && NILP (Vredisplay_dont_pause))
!       || !NILP (Vexecuting_kbd_macro))
!       
      return Qnil;
  
    if (initial_display)

Re: redisplay-dont-pause does not work

[David Kastrup]

Richard Stallman <rms@gnu.org> writes:

> Does this fix it?
>
> *** dispnew.c	01 May 2006 16:16:58 -0400	1.363
> --- dispnew.c	27 May 2006 20:01:39 -0400	
> ***************
> *** 6405,6411 ****
>   {
>     swallow_events (display);
>   
> !   if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
>       return Qnil;
>   
>     if (initial_display)
> --- 6405,6414 ----
>   {
>     swallow_events (display);
>   
> !   if ((detect_input_pending_run_timers (display)
> !        && NILP (Vredisplay_dont_pause))
> !       || !NILP (Vexecuting_kbd_macro))
> !       
>       return Qnil;
>   
>     if (initial_display)


/home/tmp/emacs/src/dispnew.c: In function ‘sit_for’:
/home/tmp/emacs/src/dispnew.c:6409: error: ‘Vredisplay_dont_pause’ undeclared (first use in this function)
/home/tmp/emacs/src/dispnew.c:6409: error: (Each undeclared identifier is reported only once
/home/tmp/emacs/src/dispnew.c:6409: error: for each function it appears in.)
make[1]: *** [dispnew.o] Error 1
make[1]: Leaving directory `/usr/local/tmp/emacs-build/src'
make: *** [src] Error 2


-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Richard Stallman]

Thanks.  Does this do it?

*** dispnew.c	01 May 2006 16:16:58 -0400	1.363
--- dispnew.c	28 May 2006 19:07:02 -0400	
***************
*** 356,362 ****
  static void add_frame_display_history P_ ((struct frame *, int));
  static void add_window_display_history P_ ((struct window *, char *, int));
  
! 
  /* Add to the redisplay history how window W has been displayed.
     MSG is a trace containing the information how W's glyph matrix
     has been constructed.  PAUSED_P non-zero means that the update
--- 356,363 ----
  static void add_frame_display_history P_ ((struct frame *, int));
  static void add_window_display_history P_ ((struct window *, char *, int));
  
! extern Lisp_Object Vredisplay_dont_pause;
! \f
  /* Add to the redisplay history how window W has been displayed.
     MSG is a trace containing the information how W's glyph matrix
     has been constructed.  PAUSED_P non-zero means that the update
***************
*** 6405,6411 ****
  {
    swallow_events (display);
  
!   if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
      return Qnil;
  
    if (initial_display)
--- 6406,6415 ----
  {
    swallow_events (display);
  
!   if ((detect_input_pending_run_timers (display)
!        && NILP (Vredisplay_dont_pause))
!       || !NILP (Vexecuting_kbd_macro))
!       
      return Qnil;
  
    if (initial_display)

Re: redisplay-dont-pause does not work

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

> Thanks.  Does this do it?

Obviously not, as the variable is named redisplay_dont_pause.

Try this:

*** dispnew.c	01 May 2006 16:16:58 -0400	1.363
--- dispnew.c	28 May 2006 19:07:02 -0400	
***************
*** 6405,6411 ****
  {
    swallow_events (display);
  
!   if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
      return Qnil;
  
    if (initial_display)
--- 6406,6415 ----
  {
    swallow_events (display);
  
!   if ((detect_input_pending_run_timers (display)
!	 && !redisplay_dont_pause)
!	|| !NILP (Vexecuting_kbd_macro))
!	
      return Qnil;
  
    if (initial_display)

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

Re: redisplay-dont-pause does not work

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Richard Stallman <rms@gnu.org> writes:
>
>> Thanks.  Does this do it?
>
> Obviously not, as the variable is named redisplay_dont_pause.
>
> Try this:
>
> *** dispnew.c	01 May 2006 16:16:58 -0400	1.363
> --- dispnew.c	28 May 2006 19:07:02 -0400	
> ***************
> *** 6405,6411 ****
>   {
>     swallow_events (display);
>   
> !   if (detect_input_pending_run_timers (display) || !NILP (Vexecuting_kbd_macro))
>       return Qnil;
>   
>     if (initial_display)
> --- 6406,6415 ----
>   {
>     swallow_events (display);
>   
> !   if ((detect_input_pending_run_timers (display)
> !	 && !redisplay_dont_pause)
> !	|| !NILP (Vexecuting_kbd_macro))
> !	
>       return Qnil;
>   
>     if (initial_display)

This works as documented in the manual.  The effect with a non-zero
argument to sit-for is that redisplay happens immediately, then the
wait is commenced until (or unless) input is available.  Which appears
natural enough.  I propose checking this change in.  It might be worth
mentioning redisplay-dont-pause in the DOC string of sit-for.  If
people agree, I could write something for there.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Eli Zaretskii]

> From: David Kastrup <dak@gnu.org>
> Date: Thu, 01 Jun 2006 11:44:27 +0200
> Cc: rms@gnu.org, emacs-devel@gnu.org
> 
> The effect with a non-zero argument to sit-for is that redisplay
> happens immediately, then the wait is commenced until (or unless)
> input is available.  Which appears natural enough.

Not only is it natural, I think it would be a bug if it worked any
other way: one of sit-for's purposes is to let the user to read a
message that is displayed for a short duration of time.  If sit-for
would wait first and redisplay after that, it would defeat this
purpose.

Re: redisplay-dont-pause does not work

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

>  I propose checking this change in.

Done.

>  It might be worth
> mentioning redisplay-dont-pause in the DOC string of sit-for.  If
> people agree, I could write something for there.

Please do.

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

Re: redisplay-dont-pause does not work

[David Kastrup]

[-- Attachment #1: Type: text/plain, Size: 303 bytes --]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>>  I propose checking this change in.
>
> Done.
>
>>  It might be worth
>> mentioning redisplay-dont-pause in the DOC string of sit-for.  If
>> people agree, I could write something for there.
>
> Please do.

I came up with


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: Type: text/x-patch, Size: 710 bytes --]

Index: dispnew.c
===================================================================
RCS file: /sources/emacs/emacs/src/dispnew.c,v
retrieving revision 1.364
diff -u -r1.364 dispnew.c
*** dispnew.c	1 Jun 2006 13:53:19 -0000	1.364
--- dispnew.c	1 Jun 2006 20:18:09 -0000
***************
*** 6438,6443 ****
--- 6438,6446 ----
  if input is available before it starts.
  Value is t if waited the full time with no input arriving.
  
+ Redisplay will occur even when input is available if you bind
+ `redisplay-dont-pause' to a non-nil value.
+ 
  An obsolete but still supported form is
  \(sit-for SECONDS &optional MILLISECONDS NODISP)
  Where the optional arg MILLISECONDS specifies an additional wait period,

[-- Attachment #3: Type: text/plain, Size: 91 bytes --]


If nobody complains, I'll check it in.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: redisplay-dont-pause does not work

[Lars Hansen]

[-- Attachment #1: Type: text/plain, Size: 171 bytes --]

Kim F. Storm wrote:

>David Kastrup <dak@gnu.org> writes:
>
>  
>
>> I propose checking this change in.
>>    
>>
>
>Done.
>  
>
Thanks!

What about something like this:


[-- Attachment #2: subr.el.diff --]
[-- Type: text/x-patch, Size: 409 bytes --]

*** /home/lh/cvsroot/emacs/lisp/subr.el	2006-06-01 22:55:47.000000000 +0200
--- subr.el	2006-06-05 09:04:22.868010017 +0200
***************
*** 1869,1874 ****
--- 1869,1879 ----
        (setq buffer-file-name name)
        (set-buffer-modified-p modified))))
  
+ (defun redisplay-now ()
+   "Force display update."
+   (let ((redisplay-dont-pause t))
+     (sit-for 0)))
+ 
  \f
  ;;;; Overlay operations
  


[-- Attachment #3: display.text.diff --]
[-- Type: text/x-patch, Size: 708 bytes --]

*** /home/lh/cvsroot/emacs/lispref/display.texi	2006-06-01 22:55:58.000000000 +0200
--- display.texi	2006-06-05 10:30:36.432000900 +0200
***************
*** 103,114 ****
  
    You can request a display update, but only if no input is pending,
  with @code{(sit-for 0)}.  To force a display update even when input is
! pending, do this:
! 
! @example
! (let ((redisplay-dont-pause t))
!   (sit-for 0))
! @end example
  
  @node Truncation
  @section Truncation
--- 103,109 ----
  
    You can request a display update, but only if no input is pending,
  with @code{(sit-for 0)}.  To force a display update even when input is
! pending, call @code{redisplay-now}.
  
  @node Truncation
  @section Truncation


[-- Attachment #4: Type: text/plain, Size: 142 bytes --]

_______________________________________________
Emacs-devel mailing list
Emacs-devel@gnu.org
http://lists.gnu.org/mailman/listinfo/emacs-devel

Re: redisplay-dont-pause does not work

[David Kastrup]

Lars Hansen <lists@soem.dk> writes:

> Kim F. Storm wrote:
>
>>David Kastrup <dak@gnu.org> writes:
>>
>>  
>>
>>> I propose checking this change in.
>>>    
>>>
>>
>>Done.
>>  
>>
> Thanks!
>
> What about something like this:
>
> *** /home/lh/cvsroot/emacs/lisp/subr.el	2006-06-01 22:55:47.000000000 +0200
> --- subr.el	2006-06-05 09:04:22.868010017 +0200
> ***************
> *** 1869,1874 ****
> --- 1869,1879 ----
>         (setq buffer-file-name name)
>         (set-buffer-modified-p modified))))
>   
> + (defun redisplay-now ()
> +   "Force display update."
> +   (let ((redisplay-dont-pause t))
> +     (sit-for 0)))
> + 
>   \f

In my opinion it is too much of a hack to warrant a function of its
own.  A proper `redisplay-now' function should have the ability to
redisplay just a particular window and/or frame.

If we invent such a function, it should do something more thorough.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Lars Hansen]

David Kastrup wrote:

>In my opinion it is too much of a hack to warrant a function of its
>own.  A proper `redisplay-now' function should have the ability to
>redisplay just a particular window and/or frame.
>  
>
Optional parameters could be added to the function if a better
implementation is envented later.

Re: redisplay-dont-pause does not work

[Slawomir Nowaczyk]

On Mon, 05 Jun 2006 11:05:08 +0200
David Kastrup <dak@gnu.org> wrote:

#> Lars Hansen <lists@soem.dk> writes:
#> 
#> > + (defun redisplay-now ()
#> > +   "Force display update."
#> > +   (let ((redisplay-dont-pause t))
#> > +     (sit-for 0)))
#> > + 
#> 
#> In my opinion it is too much of a hack to warrant a function of its
#> own. A proper `redisplay-now' function should have the ability to
#> redisplay just a particular window and/or frame.

FWIW, I think it is important to have a functions *exactly* because it
is a hack... this way, when people use the function, we can later
reimplement it in a better way. Otherwise, the hacks will have to be
hunted down and replaced one by one.

-- 
 Best wishes,
   Slawomir Nowaczyk
     ( slawomir.nowaczyk.847@student.lu.se )

Avoid metaphors like the plague.

Re: redisplay-dont-pause does not work

[David Kastrup]

Slawomir Nowaczyk <slawomir.nowaczyk.847@student.lu.se> writes:

> On Mon, 05 Jun 2006 11:05:08 +0200
> David Kastrup <dak@gnu.org> wrote:
>
> #> Lars Hansen <lists@soem.dk> writes:
> #> 
> #> > + (defun redisplay-now ()
> #> > +   "Force display update."
> #> > +   (let ((redisplay-dont-pause t))
> #> > +     (sit-for 0)))
> #> > + 
> #> 
> #> In my opinion it is too much of a hack to warrant a function of its
> #> own. A proper `redisplay-now' function should have the ability to
> #> redisplay just a particular window and/or frame.
>
> FWIW, I think it is important to have a functions *exactly* because it
> is a hack... this way, when people use the function, we can later
> reimplement it in a better way. Otherwise, the hacks will have to be
> hunted down and replaced one by one.

But the hacks will have to be hunted down and replaced one by one,
anyway, since the stuff indiscriminately refreshes everything instead
of just the required parts of the display.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Lars Hansen]

Slawomir Nowaczyk wrote:

>FWIW, I think it is important to have a functions *exactly* because it
>is a hack... this way, when people use the function, we can later
>reimplement it in a better way. Otherwise, the hacks will have to be
>hunted down and replaced one by one.
>  
>
Thanks for expressing my thoughts :-)

Re: redisplay-dont-pause does not work

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> But the hacks will have to be hunted down and replaced one by one,
> anyway, since the stuff indiscriminately refreshes everything instead
> of just the required parts of the display.

Not so -- if we allow (but ignore) the object to update, code can
be written as if it DTRT.

(defun redisplay-now (&optional object)
  "Force immediate display update of all windows.
If optional arg object is a frame, update display of that frame only.
If optional arg object is a window, update display of that window only.
If object is a buffer or buffer name, update display of all windows
displaying that buffer."
  ;; There is currently no way to update individual windows, so
  ;; update everything.
  (let ((redisplay-dont-pause t))
    (sit-for 0)))

Of course, in this form, it redisplays way too much if you specify a
window or frame object, but in most cases, nobody will be able to notice!


See also force-window-update.


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

Re: redisplay-dont-pause does not work

[Richard Stallman]

    + (defun redisplay-now ()
    +   "Force display update."
    +   (let ((redisplay-dont-pause t))
    +     (sit-for 0)))

I don't want dinky little Lisp extensions now.  Let's focus on what we
need to do to make the release.

Re: redisplay-dont-pause does not work

[Lars Hansen]

Kim F. Storm wrote:

>(defun redisplay-now (&optional object)
>  "Force immediate display update of all windows.
>If optional arg object is a frame, update display of that frame only.
>If optional arg object is a window, update display of that window only.
>If object is a buffer or buffer name, update display of all windows
>displaying that buffer."
>  ;; There is currently no way to update individual windows, so
>  ;; update everything.
>  (let ((redisplay-dont-pause t))
>    (sit-for 0)))
>  
>
This would be great IMO.

Re: redisplay-dont-pause does not work

[Kim F. Storm]

Richard Stallman <rms@gnu.org> writes:

>     + (defun redisplay-now ()
>     +   "Force display update."
>     +   (let ((redisplay-dont-pause t))
>     +     (sit-for 0)))
>
> I don't want dinky little Lisp extensions now.  Let's focus on what we
> need to do to make the release.

There is a discussion on whether redisplay-dont-pause is a user option
or not, and what other choices we have for separating the implications
on sit-for vs. users who don't want the preemptive redisplay jumpiness
on slow computers.

We do have a problem/bug here ...  the question is how to solve it.


The above implementation of redisplay-now does not solve this problem,
but some form of redisplay-now function detached from
redisplay-dont-pause could be a solution.


For emacs 22, what about just making (sit-for t) force an immediate
display update, and in general let sit-for _not_ pay attention to
redisplay-dont-pause?  And update the docs/NEWS accordingly.


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

Re: redisplay-dont-pause does not work

[Kim F. Storm]

Lars Hansen <lists@soem.dk> writes:

> Kim F. Storm wrote:
>
>>(defun redisplay-now (&optional object)
>>  "Force immediate display update of all windows.
>>If optional arg object is a frame, update display of that frame only.
>>If optional arg object is a window, update display of that window only.
>>If object is a buffer or buffer name, update display of all windows
>>displaying that buffer."
>>  ;; There is currently no way to update individual windows, so
>>  ;; update everything.
>>  (let ((redisplay-dont-pause t))
>>    (sit-for 0)))
>>  
>>
> This would be great IMO.


Thinking some more about this, I'm a bit puzzled about what specific
purpose anyone would have from doing this ...   

In most cases, if there are no changes to other parts of the frame,
redisplay will not spend time on updating them...  So if the concern
is that updating all windows/frames is performance related, I think
that's a non-issue.

And even if it _does_ redisplay all windows/frames, only the actual
changes to the display are actually propagated to the screen.


So I'm back to supporting the original proposal of having an explicit
"redisplay now" functionality ... but I propose to implement it as a
special call to sit-for: (sit-for t) or perhaps as
(sit-for 0 'redisplay-dont-pause).

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

Re: redisplay-dont-pause does not work

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> Lars Hansen <lists@soem.dk> writes:
>
>> Kim F. Storm wrote:
>>
>>>(defun redisplay-now (&optional object)
>>>  "Force immediate display update of all windows.
>>>If optional arg object is a frame, update display of that frame only.
>>>If optional arg object is a window, update display of that window only.
>>>If object is a buffer or buffer name, update display of all windows
>>>displaying that buffer."
>>>  ;; There is currently no way to update individual windows, so
>>>  ;; update everything.
>>>  (let ((redisplay-dont-pause t))
>>>    (sit-for 0)))
>
> Thinking some more about this, I'm a bit puzzled about what specific
> purpose anyone would have from doing this ...   
>
> In most cases, if there are no changes to other parts of the frame,
> redisplay will not spend time on updating them...  So if the concern
> is that updating all windows/frames is performance related, I think
> that's a non-issue.
>
> And even if it _does_ redisplay all windows/frames, only the actual
> changes to the display are actually propagated to the screen.
>
>
> So I'm back to supporting the original proposal of having an explicit
> "redisplay now" functionality ... but I propose to implement it as a
> special call to sit-for: (sit-for t) or perhaps as
> (sit-for 0 'redisplay-dont-pause).

If we are going to be mess around with sit-for's argument, we might as
well use

(sit-for -1)

This is perfectly logical, since then no input has been seen during
the time interval [0, limit].

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Kim F. Storm]

David Kastrup <dak@gnu.org> writes:

> If we are going to be mess around with sit-for's argument, we might as
> well use
>
> (sit-for -1)
>
> This is perfectly logical, since then no input has been seen during
> the time interval [0, limit].

Excellent idea.

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

Re: redisplay-dont-pause does not work

[Lars Hansen]

David Kastrup wrote:

>If we are going to be mess around with sit-for's argument, we might as
>well use
>
>(sit-for -1)
>
>This is perfectly logical, since then no input has been seen during
>the time interval [0, limit].
>  
>
I like this idea.

Re: redisplay-dont-pause does not work

[David Kastrup]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> If we are going to be mess around with sit-for's argument, we might as
>> well use
>>
>> (sit-for -1)
>>
>> This is perfectly logical, since then no input has been seen during
>> the time interval [0, limit].
>
> Excellent idea.

Given that `redisplay-dont-pause' did not work previously in
connection with sit-for (has there been some released Emacs version
where it did something useful?), I think changing the call interface
for sit-for to make negative arguments ignore pending input would be a
logical idea.

However, `redisplay-dont-pause' seems intended to be a user option,
and it is heeded at some points in the code.

In dispnew.c I find:

    /* Update display of window W.  FORCE_P non-zero means that we should
       not stop when detecting pending input.  */

    static int
    update_window (w, force_p)
         struct window *w;
         int force_p;
    {
      struct glyph_matrix *desired_matrix = w->desired_matrix;
      int paused_p;
      int preempt_count = baud_rate / 2400 + 1;
      extern int input_pending;
      extern Lisp_Object do_mouse_tracking;
    #if GLYPH_DEBUG
      /* Check that W's frame doesn't have glyph matrices.  */
      xassert (FRAME_WINDOW_P (XFRAME (WINDOW_FRAME (w))));
      xassert (updating_frame != NULL);
    #endif

      /* Check pending input the first time so that we can quickly return.  */
      if (redisplay_dont_pause)
        force_p = 1;
      else
        detect_input_pending_ignore_squeezables ();

      /* If forced to complete the update, or if no input is pending, do
         the update.  */

What is strange here is that if the function is entered with "force_p"
set, but not redisplay_dont_pause, then it will still do the input
detection thingy.  I don't know whether this is intended: I have no
clue about redisplay.

Other functions checking `redisplay_dont_pause' are update_frame_1,
and of course recently sit_for.  All of the functions appear to have a
"force_p" argument as well, which might suffice for passing the
information down the call chain from sit_for, but I am not too certain
about it.

And the way it reads in ChangeLog.21, `redisplay_dont_pause' might be
intended for use as a global variable representing a user preference.

It might probably make sense to retain that functionality (though I
have my doubts that it corresponds to consistent behavior), but still
make sit-for use its own argument for doing an unconditional refresh:
those functions seem not really too related.

-- 
David Kastrup, Kriemhildstr. 15, 44793 Bochum

Re: redisplay-dont-pause does not work

[Kim F. Storm]

storm@cua.dk (Kim F. Storm) writes:

> David Kastrup <dak@gnu.org> writes:
>
>> If we are going to be mess around with sit-for's argument, we might as
>> well use
>>
>> (sit-for -1)
>>
>> This is perfectly logical, since then no input has been seen during
>> the time interval [0, limit].
>
> Excellent idea.

.. which has now been implemented.  Thanks.

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