bug#5652: 23.1.92; Info-index puts cursor at wrong position

bug#5652: 23.1.92; Info-index puts cursor at wrong position

[enami tsugutomo]

Info-index puts cursor at wrong position.  The key sequence in `Recent
input' below is the example when `save-excursion' is searched on emacs
lisp refernec manual.  Ideally (and acutually at least emacs 20.7 does)
it puts cursor at the line here:

 -- Special Form: save-excursion body...

.. but instead it puts 2 lines below.

I guess Info-index-next should be changed as follows:

=== modified file 'lisp/info.el'
*** lisp/info.el	2010-02-10 20:04:51 +0000
--- lisp/info.el	2010-02-26 00:46:14 +0000
***************
*** 3062,3068 ****
  	  num (1- num)))
    (Info-goto-node (nth 1 (car Info-index-alternatives)))
    (if (> (nth 3 (car Info-index-alternatives)) 0)
!       (forward-line (1- (nth 3 (car Info-index-alternatives))))
      (forward-line 3)			; don't search in headers
      (let ((name (car (car Info-index-alternatives))))
        (Info-find-index-name name)))
--- 3062,3069 ----
  	  num (1- num)))
    (Info-goto-node (nth 1 (car Info-index-alternatives)))
    (if (> (nth 3 (car Info-index-alternatives)) 0)
!       (forward-line (- (nth 3 (car Info-index-alternatives))
! 		       (line-number-at-pos)))
      (forward-line 3)			; don't search in headers
      (let ((name (car (car Info-index-alternatives))))
        (Info-find-index-name name)))

... when following change was done.

------------------------------------------------------------
revno: 91515
committer: Juri Linkov <juri@jurta.org>
timestamp: Sat 2008-10-18 23:04:38 +0000
message:
  (Info-find-node-2): Put initial point below the header line and breadcrumbs line.
------------------------------------------------------------

enami.


In GNU Emacs 23.1.92.1 (x86_64--netbsd)
 of 2010-02-24 on rplaca.sm.sony.co.jp
configured using `configure  'x86_64--netbsd' '--with-x=no' 'build_alias=x86_64--netbsd' 'host_alias=x86_64--netbsd' 'target_alias=x86_64--netbsd''

Important settings:
  value of $LC_ALL: nil
  value of $LC_COLLATE: nil
  value of $LC_CTYPE: nil
  value of $LC_MESSAGES: nil
  value of $LC_MONETARY: nil
  value of $LC_NUMERIC: nil
  value of $LC_TIME: nil
  value of $LANG: nil
  value of $XMODIFIERS: nil
  locale-coding-system: nil
  default enable-multibyte-characters: t

Major mode: Info

Minor modes in effect:
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  line-number-mode: t
  transient-mark-mode: t

Recent input:
ESC x i n f o RET C-s e l i s p C-a m RET i s a v e 
- e x c u r s i o n RET ESC x r e p o r TAB RET

Recent messages:
("emacs")
For information about GNU Emacs and the GNU system, type C-h C-a.
Source file `/home/enami/src/emacs/lisp/info.el' newer than byte-compiled file
Composing main Info directory...done
Mark saved where search started
Found `save-excursion' in Index.  (Only match)

Load-path shadows:
None found.

Features:
(shadow sort mail-extr message sendmail regexp-opt ecomplete rfc822 mml
mml-sec password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums mailabbrev nnheader gnus-util
netrc time-date mm-util mail-prsvr gmm-utils wid-edit mailheader canlock
sha1 hex-util hashcash mail-utils emacsbug multi-isearch info tool-bar
easymenu ediff-hook vc-hooks lisp-float-type lisp-mode register page
menu-bar rfn-eshadow timer jit-lock font-lock syntax facemenu font-core
frame cham georgian utf-8-lang misc-lang vietnamese tibetan thai
tai-viet lao korean japanese hebrew greek romanian slovak czech european
ethiopic indian cyrillic chinese case-table epa-hook jka-cmpr-hook help
simple abbrev loaddefs button minibuffer faces cus-face files
text-properties overlay md5 base64 format env code-pages mule custom
widget hashtable-print-readable backquote make-network-process multi-tty
emacs)

bug#5652: 23.1.92; Info-index puts cursor at wrong position

[Juri Linkov]

> Info-index puts cursor at wrong position.  The key sequence in `Recent
> input' below is the example when `save-excursion' is searched on emacs
> lisp refernec manual.  Ideally (and acutually at least emacs 20.7 does)
> it puts cursor at the line here:
>
>  -- Special Form: save-excursion body...
>
> .. but instead it puts 2 lines below.
>
> I guess Info-index-next should be changed as follows:

Thanks for the bug report.  I think your patch is not right.

When you look at the raw Info file in info/elisp-11, you can see:

  * save-excursion:         Excursions.          (line  20)
                                                  ========

When you turn breadcrumbs off e.g. by (setq Info-breadcrumbs-depth 0),
visit (info "(elisp) Excursions") and go to the line 20, you can see
that it is the following line:

     The `save-excursion' special form saves the identity of the current

So currently the incorrect offset is not 2 lines, but only 1 line.

When you see that the line 20 is "-- Special Form: save-excursion body..."
it is only when breadcrumbs insert a line directly to the Info buffer
and thus breaks line numbers.  We have more troubles with breadcrumbs
and hope to fix them by displaying breadcrumbs in the header window.

Now it seems the right fix is to just decrement this offset by 1:

=== modified file 'lisp/info.el'
--- lisp/info.el	2010-02-11 20:57:10 +0000
+++ lisp/info.el	2010-02-26 09:07:27 +0000
@@ -3090,7 +3090,7 @@ (defun Info-index-next (num)
 	  num (1- num)))
   (Info-goto-node (nth 1 (car Info-index-alternatives)))
   (if (> (nth 3 (car Info-index-alternatives)) 0)
-      (forward-line (1- (nth 3 (car Info-index-alternatives))))
+      (forward-line (- (nth 3 (car Info-index-alternatives)) 2))
     (forward-line 3)			; don't search in headers
     (let ((name (car (car Info-index-alternatives))))
       (Info-find-index-name name)))

BTW, the brz history seems corrupted.

Trying to see the reason why this line in `Info-index-next'
was changed last time:

      (forward-line (1- (nth 3 (car Info-index-alternatives))))

I typed `C-x v g' (vc-annotate) in info.el, and it displays:

  49780.1.32 henrik. | (forward-line (1- (nth 3 (car Info-index-alternatives))))

Typing `l' on this line displays the *vc-change-log* buffer:

  ------------------------------------------------------------
  revno: 49780.1.32
  committer: Henrik Enberg <henrik.enberg@telia.com>
  timestamp: Mon 2006-01-16 00:03:54 +0000
  message:
    sync with trunk

Does anyone know is it possible to see the original log
instead of this merge commit?

-- 
Juri Linkov
http://www.jurta.org/emacs/

bug#5652: 23.1.92; Info-index puts cursor at wrong position

[Andreas Schwab]

Juri Linkov <juri@jurta.org> writes:

> Trying to see the reason why this line in `Info-index-next'
> was changed last time:
>
>       (forward-line (1- (nth 3 (car Info-index-alternatives))))
>
> I typed `C-x v g' (vc-annotate) in info.el, and it displays:
>
>   49780.1.32 henrik. | (forward-line (1- (nth 3 (car Info-index-alternatives))))

Looks like a bug in bzr.  With git blame it points to f4ed1f85:

commit f4ed1f852b3fb7650178446ac53db773d9fd25d6
Author: Juri Linkov <juri@jurta.org>
Date:   Tue Apr 27 06:39:46 2004 +0000

    Add *info*<[0-9]+> to same-window-regexps instead of
    same-window-buffer-names.

Andreas.

-- 
Andreas Schwab, schwab@linux-m68k.org
GPG Key fingerprint = 58CA 54C7 6D53 942B 1756  01D3 44D5 214B 8276 4ED5
"And now for something completely different."

bug#5652: broken bzr history

[Juri Linkov]

>> Trying to see the reason why this line in `Info-index-next'
>> was changed last time:
>>
>>       (forward-line (1- (nth 3 (car Info-index-alternatives))))
>>
>> I typed `C-x v g' (vc-annotate) in info.el, and it displays:
>>
>>   49780.1.32 henrik. | (forward-line (1- (nth 3 (car Info-index-alternatives))))
>
> Looks like a bug in bzr.  With git blame it points to f4ed1f85:
>
> commit f4ed1f852b3fb7650178446ac53db773d9fd25d6
> Author: Juri Linkov <juri@jurta.org>
> Date:   Tue Apr 27 06:39:46 2004 +0000

Yes, I can confirm this is the correct commit.  In read-only CVS I see:

revision 1.393
date: 2004-04-27 09:39:46 +0300;  author: jurta;  state: Exp;  lines: +80 -42;
[...]
(Info-index-next): Decrement line number.

-- 
Juri Linkov
http://www.jurta.org/emacs/

broken bzr history?

[Glenn Morris]

The following is from http://debbugs.gnu.org/5652#8 and onwards.
It sounds potentially serious. Is it?

Juri Linkov wrote:

>>> I typed `C-x v g' (vc-annotate) in info.el, and it displays:
>>>
>>>   49780.1.32 henrik. | (forward-line (1- (nth 3 (car Info-index-alternatives))))
>>
>> Looks like a bug in bzr.  With git blame it points to f4ed1f85:
>>
>> commit f4ed1f852b3fb7650178446ac53db773d9fd25d6
>> Author: Juri Linkov <juri@jurta.org>
>> Date:   Tue Apr 27 06:39:46 2004 +0000
>
> Yes, I can confirm this is the correct commit.  In read-only CVS I see:
>
> revision 1.393
> date: 2004-04-27 09:39:46 +0300;  author: jurta;  state: Exp;  lines: +80 -42;
> [...]
> (Info-index-next): Decrement line number.

Re: broken bzr history?

[Óscar Fuentes]

Glenn Morris <rgm@gnu.org> writes:

> The following is from http://debbugs.gnu.org/5652#8 and onwards.
> It sounds potentially serious. Is it?
>
> Juri Linkov wrote:
>
>>>> I typed `C-x v g' (vc-annotate) in info.el, and it displays:
>>>>
>>>>   49780.1.32 henrik. | (forward-line (1- (nth 3 (car Info-index-alternatives))))
>>>
>>> Looks like a bug in bzr.  With git blame it points to f4ed1f85:
>>>
>>> commit f4ed1f852b3fb7650178446ac53db773d9fd25d6
>>> Author: Juri Linkov <juri@jurta.org>
>>> Date:   Tue Apr 27 06:39:46 2004 +0000
>>
>> Yes, I can confirm this is the correct commit.  In read-only CVS I see:
>>
>> revision 1.393
>> date: 2004-04-27 09:39:46 +0300;  author: jurta;  state: Exp;  lines: +80 -42;
>> [...]
>> (Info-index-next): Decrement line number.

I don't think that the branch is corrupted.

What is now known as bzr revision number 49780 was the point where the
rmail-mbox branch was created on CVS. That branch synched at least once
with mainline. At certain point, the branch was merged into
mainline. Much later, Emacs migrated to bzr. And after that, on revision
99255, a fake merge was created for "injecting" the rmail-mbox branch
into the bzr history. My hypothesis is that all history that was merged
from mainline into rmail-mbox during its lifespan now is shown by
`annotate' as coming from that branch. Try

bzr log -n0 -r 99255 | less

you will see the fake merge and, scrolling down, that 49780.1.32 is
commented as "sync with trunk".

git uses a different heuristics for `annotate' and displays the right
thing (this is a case where git's "we track content, not files" shows
its strength.)

IIRC, revision 99255 was famous because it forced bzr clients to
download about 100 MB while updating the local mirrors.

Stefan, how did you create that merge revision?

Re: broken bzr history?

[Stefan Monnier]

> Stefan, how did you create that merge revision?

IIRC it was something like:

  bzr merge <branch>
  [... inspect bzr diff to make sure there's nothing left unmerged ...]
  bzr revert .
  bzr commit -m <msg>

In any case, it was a stupid idea on my part, and I'm "glad" to see that
I'll get to regret it some more in the future.


        Stefan

Re: broken bzr history?

[Óscar Fuentes]

Stefan Monnier <monnier@iro.umontreal.ca> writes:

>> Stefan, how did you create that merge revision?
>
> IIRC it was something like:
>
>   bzr merge <branch>
>   [... inspect bzr diff to make sure there's nothing left unmerged ...]
>   bzr revert .
>   bzr commit -m <msg>
>
> In any case, it was a stupid idea on my part, and I'm "glad" to see that
> I'll get to regret it some more in the future.

Well, that method was what I used while migrating some svn repos to bzr,
after the bzr developers sanctioned it. I guess that they are not aware
of the effects on `annotate'.

bug#5652: 23.1.92; Info-index puts cursor at wrong position

[Juri Linkov]

> revision 1.393
> date: 2004-04-27 09:39:46 +0300;  author: jurta;  state: Exp;  lines: +80 -42;
> [...]
> (Info-index-next): Decrement line number.

This log shows that my last patch is correct.  The 2004-04-27 change
decremented line number by 1 to put point to the same line as designated
by the index line numbers.  And after the 2008-10-18 change that moves
point one line down, it's necessary to compensate this and to decrement
by 2.  Patch installed.

-- 
Juri Linkov
http://www.jurta.org/emacs/