From: lompik@voila.fr
To: Eli Zaretskii <eliz@gnu.org>
Cc: 18545@debbugs.gnu.org
Subject: bug#18545: 24.4.50: Bug - forward-line inside with-selected-window
Date: Mon, 29 Sep 2014 16:21:40 +0200 (CEST) [thread overview]
Message-ID: <156699050.231851412000500133.JavaMail.www@wwinf7125> (raw)
In-Reply-To: <83a95imtcc.fsf@gnu.org>
Works great ! Thank you !
>
> It's a god-awful mess. In this use case, we enter that code not
> because of the force_start flag, but because of the frame's
> frozen_window_starts flag. That flag is set when we resize the
> minibuffer window, and it currently acts almost like the force_start
> flag. (There's a function window_frozen_p, which attempts to exempt
> some special windows from this "frozen-start" state, but it cannot
> handle this complicated case, because by the time redisplay kicks in,
> the fact that *Completions* was at some point displayed by the
> selected window is long forgotten, and its window is now just like any
> other one.)
>
> The best solution I can propose is in the patch below, which is a
> cumulative patch against the emacs-24 branch, and is supposed to fix
> all of these problems. It fixes this last problem by treating the
> frozen_window_starts flag as advisory, i.e. like we treat the
> optional_new_start flag of a window.
>
> Please test it. I will commit it later today (to get it into the next
> pretest).
>
> === modified file 'src/window.c'
> --- src/window.c 2014-09-11 08:47:34 +0000
> +++ src/window.c 2014-09-29 06:03:36 +0000
> @@ -5897,6 +5897,8 @@ and redisplay normally--don't erase and
> w->start_at_line_beg = (bytepos == BEGV_BYTE ||
> FETCH_BYTE (bytepos - 1) == '\n');
>
> + wset_redisplay (w);
> +
> set_buffer_internal (obuf);
> return Qnil;
> }
>
> === modified file 'src/xdisp.c'
> --- src/xdisp.c 2014-09-18 15:10:33 +0000
> +++ src/xdisp.c 2014-09-29 13:13:42 +0000
> @@ -15027,6 +15027,10 @@ run_window_scroll_functions (Lisp_Object
> If FORCE_P is non-zero, return 0 even if partial visible cursor row
> is higher than window.
>
> + If CURRENT_MATRIX_P is non-zero, use the information from the
> + window's current glyph matrix; otherwise uze the desired glyph
> + matrix.
> +
> A value of 0 means the caller should do scrolling
> as if point had gone off the screen. */
>
> @@ -16136,26 +16140,47 @@ redisplay_window (Lisp_Object window, bo
>
> /* If someone specified a new starting point but did not insist,
> check whether it can be used. */
> - if (w->optional_new_start
> + if ((w->optional_new_start || window_frozen_p (w))
> && CHARPOS (startp) >= BEGV
> && CHARPOS (startp) <= ZV)
> {
> + ptrdiff_t it_charpos;
> +
> w->optional_new_start = 0;
> start_display (&it, w, startp);
> move_it_to (&it, PT, 0, it.last_visible_y, -1,
> MOVE_TO_POS | MOVE_TO_X | MOVE_TO_Y);
> - if (IT_CHARPOS (it) == PT)
> - w->force_start = 1;
> - /* IT may overshoot PT if text at PT is invisible. */
> - else if (IT_CHARPOS (it) > PT && CHARPOS (startp) <= PT)
> - w->force_start = 1;
> + /* Record IT's position now, since line_bottom_y might change
> + that. */
> + it_charpos = IT_CHARPOS (it);
> + /* Make sure we set the force_start flag only if the cursor row
> + will be fully visible. Otherwise, the code under force_start
> + label below will try to move point back into view, which is
> + not what the code which sets optional_new_start wants. */
> + if (line_bottom_y (&it) < it.last_visible_y && !w->force_start)
> + {
> + if (it_charpos == PT)
> + w->force_start = 1;
> + /* IT may overshoot PT if text at PT is invisible. */
> + else if (it_charpos > PT && CHARPOS (startp) <= PT)
> + w->force_start = 1;
> +#ifdef GLYPH_DEBUG
> + if (w->force_start)
> + {
> + if (window_frozen_p (w))
> + debug_method_add (w, "set force_start from frozen window start");
> + else
> + debug_method_add (w, "set force_start from optional_new_start");
> + }
> +#endif
> + }
> }
>
> force_start:
>
> /* Handle case where place to start displaying has been specified,
> unless the specified location is outside the accessible range. */
> - if (w->force_start || window_frozen_p (w))
> + if (w->force_start)
> {
> /* We set this later on if we have to adjust point. */
> int new_vpos = -1;
> @@ -16200,7 +16225,7 @@ redisplay_window (Lisp_Object window, bo
> goto need_larger_matrices;
> }
>
> - if (w->cursor.vpos < 0 && !window_frozen_p (w))
> + if (w->cursor.vpos < 0)
> {
> /* If point does not appear, try to move point so it does
> appear. The desired matrix has been built above, so we
> @@ -16293,6 +16318,11 @@ redisplay_window (Lisp_Object window, bo
> }
> */
> }
> + if (w->cursor.vpos < 0 || !cursor_row_fully_visible_p (w, 0, 0))
> + {
> + clear_glyph_matrix (w->desired_matrix);
> + goto try_to_scroll;
> + }
>
> #ifdef GLYPH_DEBUG
> debug_method_add (w, "forced window start");
> @@ -16357,7 +16387,8 @@ redisplay_window (Lisp_Object window, bo
> || CHARPOS (startp) == BEGV
> || !window_outdated (w)))
> {
> - int d1, d2, d3, d4, d5, d6;
> + int d1, d2, d5, d6;
> + int rtop, rbot;
>
> /* If first window line is a continuation line, and window start
> is inside the modified region, but the first change is before
> @@ -16386,10 +16417,14 @@ redisplay_window (Lisp_Object window, bo
> doing so will move point from its correct position
> instead of scrolling the window to bring point into view.
> See bug#9324. */
> - && pos_visible_p (w, PT, &d1, &d2, &d3, &d4, &d5, &d6))
> + && pos_visible_p (w, PT, &d1, &d2, &rtop, &rbot, &d5, &d6)
> + && rtop == 0 && rbot == 0)
> {
> w->force_start = 1;
> SET_TEXT_POS_FROM_MARKER (startp, w->start);
> +#ifdef GLYPH_DEBUG
> + debug_method_add (w, "recomputed window start in continuation line");
> +#endif
> goto force_start;
> }
>
>
>
___________________________________________________________
Mode, hifi, maison,… J'achète malin. Je compare les prix avec Voila.fr http://shopping.voila.fr/
next prev parent reply other threads:[~2014-09-29 14:21 UTC|newest]
Thread overview: 55+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-09-24 13:34 bug#18545: 24.4.50: Bug - forward-line inside with-selected-window lompik
2014-09-24 15:14 ` Stefan Monnier
2014-09-24 15:50 ` lompik
2014-09-25 13:55 ` Eli Zaretskii
2014-09-25 13:59 ` Eli Zaretskii
2014-09-25 15:20 ` Eli Zaretskii
2014-09-25 17:41 ` lompik
2014-09-25 17:51 ` Eli Zaretskii
2014-09-25 18:14 ` lompik
2014-09-25 18:31 ` Eli Zaretskii
2014-09-25 19:06 ` lompik
2014-09-25 19:18 ` Eli Zaretskii
2014-09-25 20:05 ` lompik
2014-09-26 7:31 ` Eli Zaretskii
2014-09-26 12:48 ` Stefan Monnier
2014-09-26 13:29 ` Eli Zaretskii
2014-09-26 14:13 ` Stefan Monnier
2014-09-26 15:20 ` Eli Zaretskii
2014-09-26 19:32 ` Stefan Monnier
2014-09-27 7:05 ` Eli Zaretskii
2014-09-27 14:45 ` lompik
2014-09-27 15:45 ` Eli Zaretskii
2014-09-27 7:35 ` martin rudalics
2014-09-27 8:53 ` Eli Zaretskii
2014-09-27 10:01 ` martin rudalics
2014-09-27 11:22 ` Eli Zaretskii
2014-09-27 13:36 ` martin rudalics
2014-09-27 16:06 ` Eli Zaretskii
2014-09-27 17:25 ` Stefan Monnier
2014-09-27 17:35 ` Eli Zaretskii
2014-09-27 17:53 ` Stefan Monnier
2014-09-27 19:03 ` martin rudalics
2014-09-27 19:38 ` Eli Zaretskii
2014-09-27 19:55 ` Eli Zaretskii
2014-09-28 9:34 ` martin rudalics
2014-09-28 16:29 ` Eli Zaretskii
2014-09-28 17:51 ` Eli Zaretskii
2014-09-28 19:03 ` martin rudalics
2014-09-28 19:25 ` Eli Zaretskii
2014-09-28 20:25 ` martin rudalics
2014-09-29 0:31 ` lompik
2014-09-29 6:16 ` Eli Zaretskii
2014-09-29 13:47 ` Eli Zaretskii
2014-09-29 14:21 ` lompik [this message]
2014-09-29 16:49 ` Eli Zaretskii
2014-09-29 22:56 ` lompik
2014-09-30 2:38 ` Eli Zaretskii
2014-09-27 19:01 ` martin rudalics
2014-09-27 19:27 ` Eli Zaretskii
2014-09-27 19:01 ` martin rudalics
2014-09-27 19:25 ` Eli Zaretskii
2014-09-28 9:33 ` martin rudalics
2014-09-28 16:33 ` Eli Zaretskii
2014-09-28 19:04 ` martin rudalics
2014-09-28 19:24 ` Eli Zaretskii
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
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=156699050.231851412000500133.JavaMail.www@wwinf7125 \
--to=lompik@voila.fr \
--cc=18545@debbugs.gnu.org \
--cc=eliz@gnu.org \
/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 public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).