[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: "... the window start at a meaningless point within a line."
From: |
Alan Mackenzie |
Subject: |
Re: "... the window start at a meaningless point within a line." |
Date: |
Sat, 31 Oct 2015 21:17:40 +0000 |
User-agent: |
Mutt/1.5.23 (2014-03-12) |
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: address@hidden
> > From: Alan Mackenzie <address@hidden>
[ .... ]
> 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).
- Re: "... the window start at a meaningless point within a line.", (continued)
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/18
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/18
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/19
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/27
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/27
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/27
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/27
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/28
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/28
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/31
- Re: "... the window start at a meaningless point within a line.",
Alan Mackenzie <=
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/31
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/18
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/18
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/19
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/19
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/19
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/19
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/19
- Re: "... the window start at a meaningless point within a line.", Eli Zaretskii, 2015/10/19
- Re: "... the window start at a meaningless point within a line.", Alan Mackenzie, 2015/10/19