all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
From: Eli Zaretskii <eliz@gnu.org>
To: Stefan Monnier <monnier@iro.umontreal.ca>
Cc: esq@lawlist.com, 17678@debbugs.gnu.org
Subject: bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before	visual redisplay
Date: Fri, 13 Jun 2014 23:59:33 +0300	[thread overview]
Message-ID: <838up0wmoa.fsf@gnu.org> (raw)
In-Reply-To: <jwvvbs4ac20.fsf-monnier+emacsbugs@gnu.org>

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: esq@lawlist.com,  17678@debbugs.gnu.org
> Date: Fri, 13 Jun 2014 14:47:05 -0400
> 
> >> > Not necessarily: there are the w->optional_new_start and
> >> > w-> force_start flags, which determine what redisplay does with
> >> > window-start in these cases.
> >> > Also, the window-start could be set to a value that leaves point out
> >> > of the displayed area, in which case it won't be in effect.
> >> Right, but these fall back into the case where redisplay performs
> >> a second pass trough the window/buffer, so it's similar to the scrolling
> >> case, right?
> > Not necessarily, AFAIR.  Sometimes these situations are detected and
> > handled on the fly.
> 
> Aha!  Could you add comment somewhere in xdisp.c discussing the above
> issues about how/when is window-start obeyed and when it's not and
> when that causes a second pass and when that's handled on the fly?

I will see what I can do.

> Could be.  But I already find it hard to know what can be done with
> window-scroll-functions because it's not clear exactly when it's called,
> in 2 sense:
> - it's not clear exactly when it is called and when it is not.
> - it's not clear exactly at which stage of redisplay it is called
>   (e.g. what has already been processed, what hasn't; will any and all
>   modifications caused by window-scroll-functions be reflected on screen
>   at the end of the current redisplay, or will some of it only be
>   handled by the next redisplay?  If so, which do and which don't?)

I'm not sure I follow.  Redisplay, at the level we are talking, has no
stages.  It goes through all the windows on every frame, and does for
each window what it thinks has to be done in that window.  A process
of redisplaying a window is done in one go, there are no stages or
phases in it.  The window-scroll-functions are called when redisplay
thinks it will scroll the window in order to redisplay it.

Which modifications in window-scroll-functions did you have in mind?





  parent reply	other threads:[~2014-06-13 20:59 UTC|newest]

Thread overview: 22+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-06-03 17:48 bug#17678: 24.4.50; Feature Request -- calculate new `window-start` & `window-end` before visual redisplay Keith David Bershatsky
2014-06-11 18:00 ` Stefan Monnier
2014-06-11 18:45   ` Eli Zaretskii
2014-06-11 21:58     ` Stefan Monnier
2014-06-12 17:54       ` Eli Zaretskii
2014-06-13  2:11         ` Stefan Monnier
2014-06-13  6:22           ` Eli Zaretskii
2014-06-13 12:34             ` Stefan Monnier
2014-06-13 13:27               ` Eli Zaretskii
2014-06-13 14:14                 ` Stefan Monnier
2014-06-13 14:47                   ` Eli Zaretskii
2014-06-13 18:47                     ` Stefan Monnier
2014-06-13 20:21                       ` Keith David Bershatsky
2014-06-13 20:59                       ` Eli Zaretskii [this message]
2014-06-14  9:45                         ` Eli Zaretskii
2014-06-14 17:10                           ` Keith David Bershatsky
2014-06-15  2:24                         ` Stefan Monnier
2014-06-13 16:22 ` Keith David Bershatsky
2014-06-13 17:55   ` Eli Zaretskii
2014-06-13 18:24     ` Keith David Bershatsky
2014-06-13 20:54       ` Eli Zaretskii
2014-06-13 21:19         ` Keith David Bershatsky

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=838up0wmoa.fsf@gnu.org \
    --to=eliz@gnu.org \
    --cc=17678@debbugs.gnu.org \
    --cc=esq@lawlist.com \
    --cc=monnier@iro.umontreal.ca \
    /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.