From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Mackenzie Newsgroups: gmane.emacs.devel Subject: Re: "... the window start at a meaningless point within a line." Date: Sat, 31 Oct 2015 21:17:40 +0000 Message-ID: <20151031211739.GA1853@acm.fritz.box> References: <83oafx4qsb.fsf@gnu.org> <83lhb14o6e.fsf@gnu.org> <83k2ql4lsy.fsf@gnu.org> <20151018150052.GD1639@acm.fritz.box> <83lhb0hy0h.fsf@gnu.org> <20151019102755.GB2438@acm.fritz.box> <20151027134025.GA2401@acm.fritz.box> <83fv0w41dg.fsf@gnu.org> <20151028131505.GB2538@acm.fritz.box> <8337wryy0x.fsf@gnu.org> NNTP-Posting-Host: plane.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=us-ascii X-Trace: ger.gmane.org 1446326186 15690 80.91.229.3 (31 Oct 2015 21:16:26 GMT) X-Complaints-To: usenet@ger.gmane.org NNTP-Posting-Date: Sat, 31 Oct 2015 21:16:26 +0000 (UTC) Cc: emacs-devel@gnu.org To: Eli Zaretskii Original-X-From: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Sat Oct 31 22:16:17 2015 Return-path: Envelope-to: ged-emacs-devel@m.gmane.org Original-Received: from lists.gnu.org ([208.118.235.17]) by plane.gmane.org with esmtp (Exim 4.69) (envelope-from ) id 1ZsdVX-0004JY-6U for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2015 22:16:15 +0100 Original-Received: from localhost ([::1]:57036 helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsdVW-0003lT-FK for ged-emacs-devel@m.gmane.org; Sat, 31 Oct 2015 17:16:14 -0400 Original-Received: from eggs.gnu.org ([2001:4830:134:3::10]:37160) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsdVH-0003lB-SQ for emacs-devel@gnu.org; Sat, 31 Oct 2015 17:16:01 -0400 Original-Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1ZsdVC-0004aD-RS for emacs-devel@gnu.org; Sat, 31 Oct 2015 17:15:59 -0400 Original-Received: from mail.muc.de ([193.149.48.3]:61019) by eggs.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1ZsdVC-0004ZO-Fs for emacs-devel@gnu.org; Sat, 31 Oct 2015 17:15:54 -0400 Original-Received: (qmail 66211 invoked by uid 3782); 31 Oct 2015 21:15:53 -0000 Original-Received: from acm.muc.de (p579E9C22.dip0.t-ipconnect.de [87.158.156.34]) by colin.muc.de (tmda-ofmipd) with ESMTP; Sat, 31 Oct 2015 22:15:52 +0100 Original-Received: (qmail 25471 invoked by uid 1000); 31 Oct 2015 21:17:40 -0000 Content-Disposition: inline In-Reply-To: <8337wryy0x.fsf@gnu.org> User-Agent: Mutt/1.5.23 (2014-03-12) X-Delivery-Agent: TMDA/1.1.12 (Macallan) X-Primary-Address: acm@muc.de X-detected-operating-system: by eggs.gnu.org: FreeBSD 9.x X-Received-From: 193.149.48.3 X-BeenThere: emacs-devel@gnu.org X-Mailman-Version: 2.1.14 Precedence: list List-Id: "Emacs development discussions." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Original-Sender: emacs-devel-bounces+ged-emacs-devel=m.gmane.org@gnu.org Xref: news.gmane.org gmane.emacs.devel:193035 Archived-At: 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 [ .... ] > 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 , handlers=18912, hfun=0x558d60 ) 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 , 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).