Re: "... the window start at a meaningless point within a line."

[Alan Mackenzie <acm@muc.de>]

Hello, Eli,

Thanks for this.

On Sat, Oct 31, 2015 at 03:21:02PM +0200, Eli Zaretskii wrote:
> > Date: Wed, 28 Oct 2015 13:15:05 +0000
> > Cc: emacs-devel@gnu.org
> > From: Alan Mackenzie <acm@muc.de>

[ .... ]

> The patch below should go a long way towards solving these problems.
> The only issue I left unsolved is exposed when typing C-p on the
> second screen line of the right-side window: you will see that it
> doesn't succeed in keeping the visual column.  Solving this is left as
> an exercise ;-)

> I hope the changes I made and the comments to those changes will speak
> for themselves, and show how to solve such problems.

> Please note that there's a very serious underlying problem here: the
> move_it_* functions and all their callers assume that moving beyond
> above or below the window keeps the same window dimensions, in
> particularly its width.  Follow mode violates this assumption, because
> moving from the left-side to the right-side window or vice versa can
> change the width.  Accounting for this would need very deep changes in
> the above mentioned functions.  For now, I avoided that, and the patch
> below is just a band-aid.  If it works well enough in practice, maybe
> we can avoid the surgery.  But in general, I must say that fixing what
> you are trying to fix is an ambitious undertaking; perhaps it would be
> better to make sure the two windows are always the same width, using
> pixel-wise resizing where necessary.

I'm aware that it's a difficult thing to achieve.  But pixel-wise
resizing isn't a good idea on ttys.  The only "equivalent" there would
be to thicken borders between windows to make them equal width.  I can't
see that being a popular move.

Anyhow, I played around with the new indent.c a bit, got a seg fault,
rebuilt it with debugging, and reproduced the said seg fault.

At the time, I had Follow Mode active on a buffer in three side by side
windows in the initial frame.  Point was in the left window, and I
attempted to scroll the window by either a single line, or six lines
(the latter, I think).  The segfault happened here:
 
> +      /* If we moved up in the right-side window under follow-mode,
> +	 and found ourselves beyond the window's start, we must move
> +	 back from window start to PT, see how many lines is that,
> +	 then switch to the left-side window, and move back the rest
> +	 of NLINES starting from that window's last line.  That's
> +	 because move_it_* functions use the window dimensions, which
> +	 might be different in the other window.  */
> +      if (w->exact_start && IT_CHARPOS (it) < w_start)
> +	{
> +	  int vpos = it.vpos, nlines_prev_window;
> +	  Lisp_Object prev_window = w->prev;
> +	  struct window *pw;
> +	  ptrdiff_t prev_window_endpos;
> +	  struct text_pos pw_top;
> +
> +	  eassert (WINDOW_LIVE_P (prev_window));
> +	  reseat_at_window_start (&it);
> +	  it.current_x = it.hpos = it.vpos = 0;
> +	  move_it_to (&it, goal_pt, -1, -1, -1, MOVE_TO_POS);
> +	  nlines_prev_window = nlines + it.vpos + 1;
> +	  pw = XWINDOW (prev_window);
> +	  SET_TEXT_POS_FROM_MARKER (pw_top, pw->start);   <=================================
> +	  start_display (&it, pw, pw_top);
> +	  move_it_to (&it, -1, -1, it.last_visible_y - 1, -1, MOVE_TO_Y);
> +	  move_it_by_lines (&it, nlines_prev_window);
> +	  /* Pretend the original move worked as intended.  */
> +	  it.vpos = vpos;
> +	}
> +
>        /* Move to the goal column, if one was specified.  If the window
>  	 was originally hscrolled, the goal column is interpreted as
>  	 an addition to the hscroll amount.  */

, and it happened because prev_window is 0.  Presumably the left hand
window on the first frame has no previous.  I can't see how the
WINDOW_LIVE_P check failed to catch this.

I haven't spent enough time studying the patch yet to be able to
understand it.

Anyhow, just in case the cause is obvious, here's the relevant section
from my gdb session:

Program received signal SIGSEGV, Segmentation fault.
0x00000000005b150f in Fvertical_motion (lines=-2, window=13422013, cur_col=0) at indent.c:2254
2254              SET_TEXT_POS_FROM_MARKER (pw_top, pw->start);
(gdb) p pw->start
Cannot access memory at address 0x53
(gdb) p pw
$1 = (struct window *) 0xfffffffffffffffb
(gdb) p window->prev
Attempt to extract a component of a value that is not a structure pointer.
(gdb) p w->prev
$2 = 0
(gdb) p prev_window
$3 = 0
(gdb) p w->prev
$4 = 0
(gdb) p WINDOW_LIVE_P (prev_window)
$5 = 0
(gdb) bt
#0  0x00000000005b150f in Fvertical_motion (lines=-2, window=13422013, cur_col=0) at indent.c:2254
#1  0x00000000004a7016 in window_scroll_line_based (window=13422013, n=-1, whole=false, noerror=false) at window.c:5206
#2  0x00000000004a56df in window_scroll (window=13422013, n=-1, whole=false, noerror=false) at window.c:4726
#3  0x00000000004a7654 in scroll_command (n=6, direction=-1) at window.c:5341
#4  0x00000000004a76b8 in Fscroll_down (arg=6) at window.c:5369
#5  0x00000000005f856b in Ffuncall (nargs=2, args=0x7ffca6e8f8b8) at eval.c:2650
#6  0x000000000063da3b in exec_byte_code (bytestr=45853268, vector=16338405, maxdepth=10, args_template=0, nargs=0, args=0x0) at bytecode.c:880
#7  0x00000000005f90df in funcall_lambda (fun=16338501, nargs=1, arg_vector=0xf94de5) at eval.c:2876
#8  0x00000000005f8b7d in apply_lambda (fun=16338501, args=17625955, count=9) at eval.c:2751
#9  0x00000000005f72fb in eval_sub (form=17940163) at eval.c:2168
#10 0x00000000005f3542 in Fprogn (body=21580531) at eval.c:427
#11 0x00000000005f904e in funcall_lambda (fun=21580291, nargs=1, arg_vector=0x7ffca6e90160) at eval.c:2869
#12 0x00000000005f88f4 in Ffuncall (nargs=2, args=0x7ffca6e90158) at eval.c:2711
#13 0x00000000005f041c in Ffuncall_interactively (nargs=2, args=0x7ffca6e90158) at callint.c:248
#14 0x00000000005f845a in Ffuncall (nargs=3, args=0x7ffca6e90150) at eval.c:2630
#15 0x00000000005f2aba in Fcall_interactively (function=3125504, record_flag=0, keys=13390261) at callint.c:836
#16 0x00000000005f85e5 in Ffuncall (nargs=4, args=0x7ffca6e90488) at eval.c:2657
#17 0x000000000063da3b in exec_byte_code (bytestr=10398516, vector=10398549, maxdepth=54, args_template=4102, nargs=1, args=0x7ffca6e909f0) at bytecode.c:880
#18 0x00000000005f8daf in funcall_lambda (fun=10398469, nargs=1, arg_vector=0x7ffca6e909e8) at eval.c:2810
#19 0x00000000005f881d in Ffuncall (nargs=2, args=0x7ffca6e909e0) at eval.c:2699
#20 0x00000000005f7f5e in call1 (fn=14736, arg1=3125504) at eval.c:2509
#21 0x0000000000559da8 in command_loop_1 () at keyboard.c:1458
#22 0x00000000005f5279 in internal_condition_case (bfun=0x55959c <command_loop_1>, handlers=18912, hfun=0x558d60 <cmd_error>) at eval.c:1309
#23 0x00000000005592a4 in command_loop_2 (ignore=0) at keyboard.c:1086
#24 0x00000000005f4a6e in internal_catch (tag=45552, func=0x55927b <command_loop_2>, arg=0) at eval.c:1073
#25 0x0000000000559244 in command_loop () at keyboard.c:1065
#26 0x0000000000558935 in recursive_edit_1 () at keyboard.c:671
#27 0x0000000000558ac2 in Frecursive_edit () at keyboard.c:742
#28 0x00000000005568b2 in main (argc=2, argv=0x7ffca6e90e88) at emacs.c:1644
(gdb)


-- 
Alan Mackenzie (Nuremberg, Germany).