From mboxrd@z Thu Jan 1 00:00:00 1970 From: Nicolas Richard Subject: Re: navigation broken - occur, org-babel-goto-named-src-block, etc fail Date: Sun, 15 Jun 2014 21:49:29 +0200 Message-ID: <871tuqymuu.fsf@yahoo.fr> References: <8761k25nrf.fsf@geodiff-mac3.ulb.ac.be> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:4830:134:3::10]:48628) by lists.gnu.org with esmtp (Exim 4.71) (envelope-from ) id 1WwGQz-0003Ts-03 for emacs-orgmode@gnu.org; Sun, 15 Jun 2014 15:49:51 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1WwGQs-0000fp-UK for emacs-orgmode@gnu.org; Sun, 15 Jun 2014 15:49:44 -0400 In-Reply-To: (Charles C. Berry's message of "Sun, 15 Jun 2014 08:07:19 -0700") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org Sender: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane.org@gnu.org To: "Charles C. Berry" Cc: bzg@gnu.org, Nicolas Richard , emacs-orgmode@gnu.org Hello Charles, "Charles C. Berry" writes: > On Sun, 15 Jun 2014, Nicolas Richard wrote: > >> Charles Berry writes: >> >>> Start with emacs -q, then load today's org-mode. >> >> A glitch in 30220ff was quickly fixed in feca87b (three hours ago). >> Maybe that's what you see ? >> > > The ECM still fails. > > Did it work for you? Unfortunately I didn't have the time to test, but it seemed very similar to what I had experienced between these two commits, hence my suggestion to look into them. I'll try later (and a few hours later...) M-a M-k Let me try that now. TL;DR: see near the end. Ok, so here's what I think I have understood of the problem: In org-fix-ellipsis-at-bol, we now do (set-window-start (selected-window) (window-start)) which I thought would be a noop. But it is not, and to understand why here's a simpler way of reproducing the funny result: In some buffer with a few screenful of lines, when I do : M-: (progn (forward-line 55) (set-window-start (selected-window) (window-start))) (assuming point was at beginning of the buffer) I end up at line 22 (instead of 1+55 = 56) on my current frame/window configurations. (The number 55 is chosen so that it is beyond the last line of the buffer.) Now if I try this: (progn (forward-line 55) (redisplay) (set-window-start (selected-window) (window-start))) then it works perfectly fine. So my conclusion is that in the first version, the command loop of emacs doesn't redraw/recompute the window start position before the end of the command, i.e. we have the following actions : (progn ;; let's assume point is a position 1. (forward-line 55) ;; now point is at line 56, but (window-start) is still at 1. ;; if we used (redisplay) now, then (window-start) would be recomputed. (set-window-start (selected-window) (window-start))) ;; at this point, the command loop was instructed to make the window start at ;; position 1. But point is at line 56, which is out of the window, ;; hence emacs moves point to put it back in the window (namely, in its ;; center). See (info "(elisp) Window Start and End") for more info on how set-window-start works when point ends up out of the window. TL;DR begins here: Hence we could either use the optional arg "NOFORCE" or force (redisplay) before set-window-start. Both would probably the bug you're seeing, but I'm not sure any of those is TRT in org-fix-ellipsis-at-bol. (BTW if you try to fix org-fix-ellipsis-at-bol in a running emacs, be sure to re-eval the definition of its callers because it's a defsubst and IIUC that gets inlined automatically.) -- Nico.