navigation broken - occur, org-babel-goto-named-src-block, etc fail

navigation broken - occur, org-babel-goto-named-src-block, etc fail

[Charles Berry]

Start with emacs -q, then load today's org-mode.

Execute the source block in this file:

=== start of file

#+NAME: AAA
#+BEGIN_SRC x

#+END_SRC


#+BEGIN_SRC emacs-lisp :results raw output
  (let ((i ?a))
        (while (< i ?z)
          (princ (format "* %s\n\n\n#+NAME: %s\n\n" 
                         (char-to-string i) 
                         (char-to-string i)))
          (setq i (1+ i))))

#+END_SRC


#+NAME: BBB
#+BEGIN_SRC x

#+END_SRC

=== end of file

Now try 

C-c C-v g AAA RET
C-c C-v g BBB RET
C-c C-v n

or 

M-x occur RET \+name RET

then try to click on each of the matches in the *Occur* buffer.
The first few work, then failure set in. Seems like local moves of
a few lines work, but longer jumps fail.

I've tried using edebug on org-reveal. When I step through by pressing
'n', occur works fine. When I skip stepping by pressing 'c', it often fails.


What gives?

Chuck

p.s.

Org-mode version 8.2.7 (release_8.2.7-1096-g23496c [...]
GNU Emacs 24.3.1 [...]

Re: navigation broken - occur, org-babel-goto-named-src-block, etc fail

[Nicolas Richard]

Charles Berry <ccberry@ucsd.edu> 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 ?

> Org-mode version 8.2.7 (release_8.2.7-1096-g23496c [...]
> GNU Emacs 24.3.1 [...]

I don't have a commit g23496c in my repo, so I can't tell if it is
affected by the problem.

-- 
Nico.

Re: navigation broken - occur, org-babel-goto-named-src-block, etc fail

[Nicolas Richard]

Nicolas Richard <theonewiththeevillook@yahoo.fr> writes:
> A glitch in 30220ff was quickly fixed in feca87b (three hours ago).

I meant "three hours later".

-- 
Nico.

Re: navigation broken - occur, org-babel-goto-named-src-block, etc fail

[Charles C. Berry]

On Sun, 15 Jun 2014, Nicolas Richard wrote:

> Charles Berry <ccberry@ucsd.edu> 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?

FWIW, this has been around for a few days at least.

Chuck

Re: navigation broken - occur, org-babel-goto-named-src-block, etc fail

[Nicolas Richard]

Hello Charles,

"Charles C. Berry" <ccberry@ucsd.edu> writes:
> On Sun, 15 Jun 2014, Nicolas Richard wrote:
>
>> Charles Berry <ccberry@ucsd.edu> 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.