bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

 emacs -Q
 C-u C-h i /path/to/elisp RET
 g Handling Errors RET

Now press TAB repeatedly to move point to the "Definition of signal"
hyperlink, and press RET => you will find yourself in the "Signaling
Errors" node, but 3 lines above the place where the description of
`signal' begins.

I see this on GNU/Linux with Texinfo 4.12 and on MS-Windows with
Texinfo 4.8.  (But I don't think makeinfo is the culprit, see below.)

This is a regression from Emacs 22.3, which behaves as expected.
Emacs 23.1 has the same problem as the current pretest.  (Both 22.3
and 23.1 were tested with the same Info files as 23.1.94.)  The trunk
has the same problem as well.


In GNU Emacs 23.1.94.1 (i386-mingw-nt5.1.2600)
 of 2010-03-12 on HOME-C4E4A596F7
Windowing system distributor `Microsoft Corp.', version 5.1.2600
configured using `configure --with-gcc (3.4)'

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: ENU
  value of $XMODIFIERS: nil
  locale-coding-system: cp1255
  default enable-multibyte-characters: t

Major mode: Mail

Minor modes in effect:
  shell-dirtrack-mode: t
  diff-auto-refine-mode: t
  flyspell-mode: t
  desktop-save-mode: t
  show-paren-mode: t
  display-time-mode: t
  tooltip-mode: t
  mouse-wheel-mode: t
  tool-bar-mode: t
  menu-bar-mode: t
  file-name-shadow-mode: t
  global-font-lock-mode: t
  font-lock-mode: t
  blink-cursor-mode: t
  auto-encryption-mode: t
  auto-compression-mode: t
  temp-buffer-resize-mode: t
  line-number-mode: t
  abbrev-mode: t

Recent input:
C-z C-z C-z C-z C-z C-z <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <switch-frame> 
l <return> <help-echo> C-x = <switch-frame> <help-echo> 
<help-echo> <help-echo> <help-echo> <switch-frame> 
<help-echo> <help-echo> <help-echo> <C-home> C-x C-x 
<switch-frame> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <help-echo> <help-echo> <help-echo> 
<help-echo> <help-echo> <switch-frame> <switch-frame> 
<help-echo> <help-echo> <help-echo> <switch-frame> 
<help-echo> <help-echo> <help-echo> <help-echo> <switch-frame> 
C-x C-s C-x 4 a H o w SPC t o SPC r e - t h r o w SPC 
a SPC s i g n a l SPC c a u g h t SPC b y SPC c i o 
<backspace> o n d i t i o n - c a s e <C-left> <C-left> 
<right> <delete> <M-right> . C-x C-s <help-echo> <M-end> 
<help-echo> <help-echo> <M-home> <up> <up> C-SPC <down> 
<down> <down> M-w <M-end> C-y <up> <up> <up> <delete> 
<delete> <delete> <down> <delete> SPC <left> <up> <return> 
<up> <return> <up> E x p l a i n SPC h o w SPC t o 
SPC r e - t h r o w SPC a SPC s i g n a l . <right> 
<down> <down> <down> <delete> C-x C-s C-x # C-x k <return> 
<M-home> C-x k <return> <C-next> <C-next> <C-next> 
<C-next> <C-next> <C-next> <C-next> <C-next> <C-next> 
<C-next> <M-end> r C-c C-y C-x C-x C-SPC <down> <down> 
<down> <up> C-w <down> <down> <down> <down> C-SPC <next> 
<down> <down> <down> <down> <down> <down> <down> <down> 
<down> C-w M-z M-z M-z M-z <down> <down> <C-end> C-w 
<return> I S-SPC a d d e d SPC t h i s SPC t o SPC 
t h e SPC E L i s p SPC m a n u a l . <return> <C-home> 
C-c C-s <switch-frame> <switch-frame> M-x r e p o p 
<backspace> r t - e m <tab> <return>

Recent messages:
Saving file d:/gnu/bzr/emacs/emacs-23/doc/lispref/ChangeLog...
Wrote d:/gnu/bzr/emacs/emacs-23/doc/lispref/ChangeLog
When done with a buffer, type C-x #
Mark set [2 times]
Saving file d:/usr/tmp/bzr_log.59l73j...
Wrote d:/usr/tmp/bzr_log.59l73j
Mark set [5 times]
Sending...
Added to d:/usr/eli/rmail/SENT.MAIL
Sending...done

Load-path shadows:
None found.

Features:
(shadow emacsbug debug rmailedit tramp-imap assoc tramp-gw tramp-fish
tramp-cache tramp-ftp tramp-cmds tramp shell format-spec tramp-compat
trampver iso-transl compare-w whitespace diff-mode texinfo crm
thingatpt rmailout mule-util ebuff-menu electric descr-text dabbrev pp
help-mode view auth-source message ecomplete rfc822 mml mml-sec
password-cache mm-decode mm-bodies mm-encode mailcap mail-parse
rfc2231 rfc2047 rfc2045 qp ietf-drums nnheader gnus-util netrc mm-util
mail-prsvr gmm-utils wid-edit mailheader canlock hashcash smtpmail
multi-isearch mailalias mailabbrev sendmail conf-mode newcomment
ld-script sh-script executable dired-x dired-aux dired tcl generic
nxml-uchnm rng-xsd xsd-regexp rng-cmpct rng-nxml rng-valid rng-loc
rng-uri rng-parse nxml-parse rng-match rng-dt rng-util rng-pttrn
nxml-ns nxml-mode nxml-outln nxml-rap nxml-util nxml-glyph nxml-enc
xmltok sgml-mode arc-mode archive-mode parse-time python-21 python
comint ring org-wl org-w3m org-vm org-rmail org-mhe org-mew org-irc
org-jsinfo org-infojs org-html org-exp org-exp-blocks org-agenda
org-info org-gnus org-bibtex org-bbdb org byte-opt bytecomp
byte-compile advice help-fns advice-preload org-footnote org-src
org-list org-faces org-compat org-macs time-date noutline outline
easy-mmode flyspell ispell add-log jka-compr vc-bzr sha1 hex-util
make-mode info cc-mode cc-fonts easymenu cc-menus cc-cmds cc-styles
cc-align cc-engine cc-vars cc-defs regexp-opt vc-cvs rmailsum rmail
mail-utils desktop server filecache saveplace generic-x paren battery
time tooltip ediff-hook vc-hooks lisp-float-type mwheel dos-w32
disp-table ls-lisp w32-win w32-vars tool-bar dnd fontset image fringe
lisp-mode register page menu-bar rfn-eshadow timer select scroll-bar
mldrag mouse 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#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> Date: Wed, 31 Mar 2010 12:58:25 +0300
> From: Eli Zaretskii <eliz@gnu.org>

s/in accurate/inaccurate/

Sorry for sloppy typing.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>  emacs -Q
>  C-u C-h i /path/to/elisp RET
>  g Handling Errors RET
>
> Now press TAB repeatedly to move point to the "Definition of signal"
> hyperlink, and press RET => you will find yourself in the "Signaling
> Errors" node, but 3 lines above the place where the description of
> `signal' begins.
>
> I see this on GNU/Linux with Texinfo 4.12 and on MS-Windows with
> Texinfo 4.8.  (But I don't think makeinfo is the culprit, see below.)
>
> This is a regression from Emacs 22.3, which behaves as expected.
> Emacs 23.1 has the same problem as the current pretest.  (Both 22.3
> and 23.1 were tested with the same Info files as 23.1.94.)  The trunk
> has the same problem as well.

This is a known side-effect of the breadcrumbs feature.
When you set `Info-breadcrumbs-depth' to 0, everything is ok.

In bug#4147 we tried to put Info breadcrumbs in the header window.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: 5809@debbugs.gnu.org
> Date: Wed, 31 Mar 2010 18:08:04 +0300
> 
> This is a known side-effect of the breadcrumbs feature.
> When you set `Info-breadcrumbs-depth' to 0, everything is ok.

I hope this will be fixed nonetheless.  There's no particular reason
why the breadcrumbs should defeat cross-references.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>> This is a known side-effect of the breadcrumbs feature.
>> When you set `Info-breadcrumbs-depth' to 0, everything is ok.
>
> I hope this will be fixed nonetheless.  There's no particular reason
> why the breadcrumbs should defeat cross-references.

Maybe we should disable breadcrumbs in 23.2?

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: 5809@debbugs.gnu.org
> Date: Thu, 01 Apr 2010 21:06:27 +0300
> 
> >> This is a known side-effect of the breadcrumbs feature.
> >> When you set `Info-breadcrumbs-depth' to 0, everything is ok.
> >
> > I hope this will be fixed nonetheless.  There's no particular reason
> > why the breadcrumbs should defeat cross-references.
> 
> Maybe we should disable breadcrumbs in 23.2?

I cannot believe this is so hard to fix properly.  Can you describe
the details?

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>> >> This is a known side-effect of the breadcrumbs feature.
>> >> When you set `Info-breadcrumbs-depth' to 0, everything is ok.
>> >
>> > I hope this will be fixed nonetheless.  There's no particular reason
>> > why the breadcrumbs should defeat cross-references.
>>
>> Maybe we should disable breadcrumbs in 23.2?
>
> I cannot believe this is so hard to fix properly.  Can you describe
> the details?

Info breadcrumbs are currently implemented by inserting a string into
the Info buffer.  This breaks all point positions that Info functions
are relied upon.  It is a daunting task to try to account these offsets
for the lengths of breadcrumb strings inserted in all visited nodes
above the current node in the current Info file.  This practically
means rewriting the core logic of info.el just before the release.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: 5809@debbugs.gnu.org
> Date: Thu, 01 Apr 2010 21:30:30 +0300
> 
> >> Maybe we should disable breadcrumbs in 23.2?
> >
> > I cannot believe this is so hard to fix properly.  Can you describe
> > the details?
> 
> Info breadcrumbs are currently implemented by inserting a string into
> the Info buffer.  This breaks all point positions that Info functions
> are relied upon.  It is a daunting task to try to account these offsets
> for the lengths of breadcrumb strings inserted in all visited nodes
> above the current node in the current Info file.  This practically
> means rewriting the core logic of info.el just before the release.

I was talking about fixing this on the trunk.  For Emacs 23.2, I
indeed think we should turn off this feature by default.

For the trunk, isn't it true that the function which actually goes to
a location is Info-find-node-2, and that all the others call it?  If
so, this is the main place to account for the inserted breadcrumbs.
We could maintain in some data structure the buffer positions and
length of each breadcrumbs line we insert, and then use that data
structure in Info-find-node-2 to compute the summary offset to be
applied in the current node.

WDYT?

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> Date: Thu, 01 Apr 2010 23:22:41 +0300
> From: Eli Zaretskii <eliz@gnu.org>
> Cc: 5809@debbugs.gnu.org
> 
> For the trunk, isn't it true that the function which actually goes to
> a location is Info-find-node-2, and that all the others call it?  If
> so, this is the main place to account for the inserted breadcrumbs.
> We could maintain in some data structure the buffer positions and
> length of each breadcrumbs line we insert, and then use that data
> structure in Info-find-node-2 to compute the summary offset to be
> applied in the current node.

Here's another, perhaps better idea: how about if, instead of
inserting breadcrumbs as text into the buffer, we put an overlay there
with a display property whose value is the breadcrumbs as a string?
This way, buffer positions are not affected at all.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>> For the trunk, isn't it true that the function which actually goes to
>> a location is Info-find-node-2, and that all the others call it?  If
>> so, this is the main place to account for the inserted breadcrumbs.
>> We could maintain in some data structure the buffer positions and
>> length of each breadcrumbs line we insert, and then use that data
>> structure in Info-find-node-2 to compute the summary offset to be
>> applied in the current node.
>
> Here's another, perhaps better idea: how about if, instead of
> inserting breadcrumbs as text into the buffer, we put an overlay there
> with a display property whose value is the breadcrumbs as a string?
> This way, buffer positions are not affected at all.

I already tried this and some other kludges that showed their disadvantages.

In bug#4147 we concluded that the best solution would be to put
breadcrumbs to the header line where breadcrumb navigation links
belong to along with the links to the up/next/previous nodes.

Currently the header line has the limitation in only one glyph row.
But this is a general problem that should be solved one way or the other,
so different modes like Info, proced, ruler-mode could have their
own header window.  There is a successful prototype implementation
in bug#4147 that you also helped to develop.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Stefan Monnier]

> Here's another, perhaps better idea: how about if, instead of
> inserting breadcrumbs as text into the buffer, we put an overlay there
> with a display property whose value is the breadcrumbs as a string?
> This way, buffer positions are not affected at all.

That was my thought as well, but then you can't "click" on breadcrumbs
with the keyboard any more.


        Stefan

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Stefan Monnier <monnier@iro.umontreal.ca>
> Cc: juri@jurta.org,  5809@debbugs.gnu.org
> Date: Thu, 01 Apr 2010 18:16:04 -0400
> 
> > Here's another, perhaps better idea: how about if, instead of
> > inserting breadcrumbs as text into the buffer, we put an overlay there
> > with a display property whose value is the breadcrumbs as a string?
> > This way, buffer positions are not affected at all.
> 
> That was my thought as well, but then you can't "click" on breadcrumbs
> with the keyboard any more.

"Clicking" on breadcrumbs with a keyboard is the same as typing "u",
so I don't see this as a loss.  And if we think this _is_ a loss, we
could add a new feature.  Or maybe using the `cursor' property on the
overlay will do the trick even without any new features.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> > > Here's another, perhaps better idea: how about if, instead of
> > > inserting breadcrumbs as text into the buffer, we put an 
> > > overlay there with a display property whose value is the 
> > > breadcrumbs as a string?
> > > This way, buffer positions are not affected at all.
> > 
> > That was my thought as well, but then you can't "click" on 
> > breadcrumbs with the keyboard any more.
> 
> "Clicking" on breadcrumbs with a keyboard is the same as typing "u",
> so I don't see this as a loss.  And if we think this _is_ a loss, we
> could add a new feature.  Or maybe using the `cursor' property on the
> overlay will do the trick even without any new features.

Obviously, the ideal situation will be if both (a) breadcrumbs function fully
and (b) cross references and other features that reference positions function
accurately. That's what we're looking for, and that quest is good.

If, however, we ultimately find we need to, or decide to, settle for something
less than ideal, then there are different desirable qualities that could be
dropped. IOW it would be a trade-off.

I would just point out that things such as cross references are not completely
broken by breadcrumbs, IIUC. You are taken to the correct node in all cases, I
believe. Point is just not always moved to the exact location we would like - it
is sometimes moved nearby.

It might be decided that always respecting destination position exactly is a
must-have or is considered more important than the convenience (in terms of
orientation/help and navigation) of breadcrumbs. But let's at least be aware
that a trade-off is involved. It should not be a foregone conclusion to toss out
the baby with the bathwater.

Keep in mind too that in some documentation systems, which don't even have the
fine-grained "node" size of Info (on average), cross references generally do not
take you to an exact destination position. They just get you to the appropriate
section.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <5809@debbugs.gnu.org>
> Date: Fri, 2 Apr 2010 07:17:35 -0700
> 
> Keep in mind too that in some documentation systems, which don't even have the
> fine-grained "node" size of Info (on average), cross references generally do not
> take you to an exact destination position. They just get you to the appropriate
> section.

That Info does support this feature is one of its advantages, and we
should not lose it, IMO.  Without it, reading a large manual as a
reference is a PITA.

Besides, it simply feels as a bug (and actually is): you are placed in
the middle of a sentence that, more often than not, has nothing to do
with the subject you are after.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> > Keep in mind too that in some documentation systems, which 
> > don't even have the fine-grained "node" size of Info (on
> > average), cross references generally do not
> > take you to an exact destination position. They just get 
> > you to the appropriate section.
> 
> That Info does support this feature is one of its advantages, and we
> should not lose it, IMO.  Without it, reading a large manual as a
> reference is a PITA.
> 
> Besides, it simply feels as a bug (and actually is): you are placed in
> the middle of a sentence that, more often than not, has nothing to do
> with the subject you are after.

I think everyone agrees that it is a desirable feature. If we can have both
exact cursor destination and breadcrumbs, that will be ideal. Both are useful
features.

It is somewhat disorienting to not have point land only nearby and not at
exactly the right spot. And it is disorienting to not immediately see where you
are in the document hierarchy (beyond just immediate up, next, and prev nodes).

We should aim to get both working properly together.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> > > Keep in mind too that in some documentation systems, which 
> > > don't even have the fine-grained "node" size of Info (on
> > > average), cross references generally do not
> > > take you to an exact destination position. They just get 
> > > you to the appropriate section.
> > 
> > That Info does support this feature is one of its advantages, and we
> > should not lose it, IMO.  Without it, reading a large manual as a
> > reference is a PITA.
> > 
> > Besides, it simply feels as a bug (and actually is): you 
> > are placed in the middle of a sentence that, more often
> > than not, has nothing to do with the subject you are after.
> 
> I think everyone agrees that it is a desirable feature. If we 
> can have both exact cursor destination and breadcrumbs, that
> will be ideal. Both are useful features.
> 
> It is somewhat disorienting to not have point land only 
> nearby and not at exactly the right spot. And it is
> disorienting to not immediately see where you
> are in the document hierarchy (beyond just immediate up, 
> next, and prev nodes).
> 
> We should aim to get both working properly together.

Also, *in practice* this is a *rare* problem. You are making a mountain out of a
mole hill.

I wonder if people discussing this have actually tried following many links in
the manuals. Most of the discussion has been about how to implement a solution
and not about the problem. Think about the user and actual use, not just about
implementation.

Follow the actual cross references in the Emacs and Elisp manuals, and you will
see that there are only a very *small* number of them that do not simply point
to the beginning of a node. And only those small number are the potential
candidates for target imprecision.

And even in a reference manual such as Elisp, where you might expect many cross
references to specific function and variable descriptions that occur in the
middle of a node, there are relatively few such mid-node cross references.

The one exception: index links to specific keys, functions, variables, and keys.
They do target precise mid-node positions.

But in fact only a small minority of even those exceptional cases do not act as
well as one might hope. Following the link places you quite near the precise
location and generally at a location that can still be considered the intended
target (e.g. within the correct, targeted 1-3 line description or paragraph).

Why would that be? Because (a) most breadcrumbs are short and (b) most function,
variable, and key descriptions are more than one line long. So being off by the
length of one or more breadcrumbs still takes you to the right description.

Again, try it and see for yourself. Follow a representative sample of links of
your choice, and see what proportion are in fact problematic. I'm sure you'll
find that it is *very* small.

So in practice this is not a real problem. There are many more important UI
difficulties and annoyances that could be addressed before trying to achieve
perfection here.

Again, if you can find a clean, simple way to make *everything* work well, so
much the better, obviously. But we should not make the perfect into the enemy of
the good - do not throw out the baby with the bathwater.

Don't let your enthusiasm for trying some new UI technique (`after-string',
`cursor' properties, multi-line headers etc.) carry you away - creating a
sledgehammer to kill a fly. Think about where you're going with the
implementation vs what you're really trying accomplish. What's the problem and
how bad is it in practice?

In truth, Eli's dramatic characterization of this problem as "a PITA" and

  you are placed in the middle of a sentence that,
  more often than not, has nothing to do with the
  subject you are after.

is quite overblown and inaccurate. It is simply not the case, except in rare
cases.

More often than not - in fact in the overwhelming majority of cases - you are
NOT placed in the middle of a sentence that has nothing to do with the subject
you are after. That's a fact, AFAICT.

Try it, instead of just treating this academically. Follow real links and you
will soon see what I mean. You are taken directly to the precise info you need
in 99.9% of the cases (no, I didn't count - but try it and make your own
estimate).

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: "Drew Adams" <drew.adams@oracle.com>
> Cc: <5809@debbugs.gnu.org>
> Date: Sun, 4 Apr 2010 13:39:00 -0700
> 
> Also, *in practice* this is a *rare* problem. You are making a mountain out of a
> mole hill.

Drew, please try being objective.  You were one of the main pushers
for introducing the breadcrumbs feature, so it's understandable that
you have bias, but please try to hold it back.

> In truth, Eli's dramatic characterization of this problem as "a PITA" and
> 
>   you are placed in the middle of a sentence that,
>   more often than not, has nothing to do with the
>   subject you are after.
> 
> is quite overblown and inaccurate. It is simply not the case, except in rare
> cases.

Well, perhaps I happen to hit only those ``rare cases'', because it
happens all the time to me.

The amount of offset depends on how many other nodes you visited in
the same sub-file, so it's somewhat unpredictable.

Anyway, Juri is actively working on a solution for this bug, and
almost has it done, so this argument is pointless and unnecessary.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> > Also, *in practice* this is a *rare* problem. You are 
> > making a mountain out of a mole hill.
> 
> Drew, please try being objective.  You were one of the main pushers
> for introducing the breadcrumbs feature, so it's understandable that
> you have bias, but please try to hold it back.

Eli, you please try being objective. That was my precisely my point:
*objectively measure* how much this is a real problem in practice. YOU do the
measurement - don't take my word for it. Judge for yourself, but judge only
after actually trying a sample of links.

No, BTW, I was not in fact a "pusher" of breadcrumbs for Emacs. I created
breadcrumbs for Info in my own library, and I eventually offered the idea (and
implementation) to Emacs. Stefan took it from there. I don't care to push it or
any particular implementation of it for Emacs. Do with it what you will.

Personally, I think breadcrumbs are helpful to users, but I really don't care
whether I convince Emacs developers of that. I still have and use the feature in
my own library, with my original code (somewhat different from the Emacs
implementation).

I have no problem with Emacs not adopting that feature or any of the other Info
enhancements I use - that should be clear by now. (In fact, it's much easier in
terms of maintenance when Emacs does not adopt a feature I have, if it
implements it only partially or differently, for example.)

And even if you don't believe me and you think I have some perverse motivation
for what I'm saying, the *facts* don't lie: There simply are very few
problematic links. Don't believe me; test for yourself - but be honest about
what you find.

My motivation is irrelevant, as is yours. Let us not second-guess motives or
descend to ad hominem argument: Drew's arguments and findings don't count,
because he's the one who came up with the idea for breadcrumbs in the first
place. You can be better than that, Eli.

My point was and still is that BOTH breadcrumbs AND being able to target a
precise mid-node position are helpful aids to users. I've been clear that IF you
can do them both cleanly and simply then please do so.

FWIW, until I actually tried sampling links today, you had me convinced, with
your single link-behaving-badly and your exaggerated language, that this was in
fact a real, practical problem.

I was surprised when I discovered that existing links do not bear out your
characterization of the situation. (I wondered about that, since I use this
feature all the time.)

After that discovery I thought it might help to put this in perspective -
objectively - hence my mail today. Ignore reality if you like - your choice.

> > In truth, Eli's dramatic characterization of this problem 
> > as "a PITA" and
> > 
> >   you are placed in the middle of a sentence that,
> >   more often than not, has nothing to do with the
> >   subject you are after.
> > 
> > is quite overblown and inaccurate. It is simply not the 
> > case, except in rare cases.
> 
> Well, perhaps I happen to hit only those ``rare cases'', because it
> happens all the time to me.

Yes, perhaps. Can you characterize that use?

I characterized the behavior of both (a) links in general and (b) index links,
which are an exception to the rule.

And my characterization was not only theoretical (logical), explaining *why* in
general there would be no real problem. It was also practical: I followed lots
(hundreds) of links in both manuals. How about you?

Use your own link traversal/sampling. Describe it to us, so we can understand
your use case where "it happens all the time". Is that just hyperbole? Does it
really happen to you for each link?

You truly must be doing something I haven't thought of. I have difficulty
finding links that don't work well. One of us is either exaggerating or doing
something very exceptional.

Pick links at random. Or start at the beginning of the manual and try each link
in order. Or start at the end. Or start with the index, which is where the
problem is most likely to arise. Even for index links, I think you'll find that
you've exaggerated the claim greatly.

For those willing to test this objectively, I propose two quick tests, to give
you a good idea: (a) links in the text (anywhere) and (b) links in an index.
Take just 2 minutes right now to click, click, click, seeing whether you end up
in the wrong place.

I am convinced that you will find the same thing I reported: there are *very*
few bad-behaving links. This is not a PITA.

> The amount of offset depends on how many other nodes you visited in
> the same sub-file, so it's somewhat unpredictable.

I'm aware of that. That's why I wrote

  So being off by the length of one or more breadcrumbs
                                    ^^^^^^^
  still takes you to the right description.

TRY it. Visit as many nodes and links as you like - the more the better.
Describe to us what you *actually* see: what percentage of the links do not take
you directly to the appropriate passage?  10%?  1%?  0.1%?

I gave you my guesstimate: 0.1% - a bad-link case such as you reported
represents maybe one in a thousand links. You give us your estimate. But please
do try actually following a fair number of links before estimating. Objective -
yes, please.

Don't just make the claim that it happens "all the time" to you, without letting
us know what links lead you to say that.

> Anyway, Juri is actively working on a solution for this bug, and
> almost has it done, so this argument is pointless and unnecessary.

I repeat:

  If you can find a clean, simple way to make
                    ^^^^^^^^^^^^^
  *everything* work well, so much the better, obviously.
  ^^^^^^^^^^^^

What I've heard so far about the solution in progress doesn't seem to fit that
description; it doesn't inspire confidence. The last I heard, there was even
talk about having to rebind keys (or else sacrifice keyboard link following).
"If you *really really really* want to make it work", as Stefan put it. Each
time some part of a solution was proposed there seemed to be drawbacks. Fixing
the fixes...

At some point the question becomes whether the cure might be worse than the
illness. The point of my message today was to take a second, objective look at
the illness. Is it "really really really" worth the complicated cure?

So I agree that not just this discussion but the whole enterprise - this bug fix
- has been rather pointless and unnecessary. There are far more important
problems to fix (a long list of them, including UI bugs).

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

> I am convinced that you will find the same thing I reported:
> there are *very* few bad-behaving links.

Please see bug#4147.  Breadcrumbs break Info search
and navigation in the history with `l'.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> > I am convinced that you will find the same thing I reported:
> > there are *very* few bad-behaving links.

You changed the subject below (different problem), so shall we assume that you
did in fact find the same thing I reported when you clicked on a representative
sample of links?

> Please see bug#4147.  Breadcrumbs break Info search
> and navigation in the history with `l'.

I suppose you mean this:

>> The odd behavior when point moves forward by a few
>> characters is caused by breadcrumbs inserted to the
>> Info buffer (the distance point moves forward is the
>> length of the breadcrumbs string).

That is indeed a very different symptom, even if the cause is the same.

And that symptom is more disorienting, even if being off by a few characters
also is not the end of the world. Users will wonder what's happening, and they
should not need to be puzzled that way.

No one disputes that making breadcrumbs work without causing such difficulties
is desirable. I questioned the other symptom's description as being "a PITA" and
happening "all the time". And I wondered whether the fixes being discussed were
clean and simple enough. (I might add "and general enough", since we seem
sometimes to have moved away from the search for a general solution that handles
also other, non-Info problems.)

I did, BTW, support your point that putting breadcrumbs in the header line has a
"significant advantage for orientation and navigability" (my words).

Looking over this thread, and particularly the thread for #4147, there have been
several different solution approaches proposed (mainly by you). That's good.
Better to think it over well before picking one and implementing it, since each
possible change seems to be fairly far-reaching in terms of
implementation/design, and the behavior consequences for this and other things
in Emacs are different depending on which is chosen. 

You obviously understand the various solutions better than I. Based on my
limited understanding, a multi-line header seems to be the best solution I've
heard so far (and it has other uses elsewhere).

It's too bad that the simple solution of using a newline in the header line
doesn't work without display-engine changes. Has anyone looked into what changes
to the display engine would be needed to fix that?

Don't get me wrong. I'm not at all against trying to find a better, general
header-line (or other general) mechanism to deal with problems such as this. On
the contrary.

But that merits a general design reflection, not just handling as a bug report
for a particular problem. Some such general discussion has already gone on in
these threads. It's good to continue that, but in emacs-devel under an
appropriate general topic, not just in the thread of a bug that deals with only
one or two aspects of the question.

At one time (in the #4147 thread) you said "The goal is to design a new window
infrastructure that supports window groups." Now you seem to be back to a
multi-line header line (via display-engine changes?), which might or might not
mean the same thing. Maybe that's the question: just what is the general design
goal?

As I said in the #4147 thread:

  In that case, I'd suggest that emacs-devel is the right
  place to discuss such redesign. IOW, leave the bug unfixed
  until the requisite design change allows fixing it, and
  discuss the design change in the dev mailing list, not
  just in this bug thread.

Yes, I do not think we should turn off breadcrumbs by default for Emacs 23.2.
The benefit outweighs the inconveniences, IMO - just one opinion. It is in order
to discuss just such trade-offs that I suggested that people actually click Info
links to see if Eli's problem is typical or exceptional. For Emacs 23.2, both
that problem and the search-off-by-a-few-chars problem do not merit turning off
breadcrumbs by default, IMO.

But I also agree that a general redesign of, say, header lines that helps with
the breadcrumbs problems and with other things (e.g. tabs) would be a good goal.
As you put it (in #4147):

  Currently the header line has the limitation in only
  one glyph row. But this is a general problem that should
  be solved one way or the other, so different modes like
  Info, proced, ruler-mode could have their own header window.

Until that general change is made, I say leave breadcrumbs displayed by default.

And I wish that such general changes were discussed in emacs-devel _as general
design changes_, and not just inside specific bug threads here and there. When
discussed in terms of this or that Info symptom the generality is lost, and the
focus oscillates between being narrow (for the particular problem symptom) and
general. 

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

> It's too bad that the simple solution of using a newline in the header
> line doesn't work without display-engine changes. Has anyone looked
> into what changes to the display engine would be needed to fix that?

Looking over the header-line implementation in the display-engine,
the header-line is treated like the mode-line at the top of the buffer.
And newlines are disallowed in the mode-line.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Stefan Monnier]

>> It's too bad that the simple solution of using a newline in the header
>> line doesn't work without display-engine changes. Has anyone looked
>> into what changes to the display engine would be needed to fix that?

A better option would be to allow multiple header-lines.  So minor modes
can use one without clashing with each-other or with major modes using
header-lines.


        Stefan

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1925 bytes --]

OK, FWIW, here's another idea. This doesn't respond to a general need for
multi-line headers or multiple headers or any of the other things discussed so
far. This is just an alternative breadcrumbs approach for Info.

The idea is to use the mode line, not a header line, for breadcrumbs. Please try
the attached patch, which is against info.el from today (it also works fine
against the 95 pretest). It will take you only a moment to try.

By default (in this patch at least) breadcrumbs are turned off. You can turn
them on using `Info-breadcrumbs-mode', which is in the Info menu as `Toggle
Breadcrumbs'. (That menu is of course also on the `Info' minor-mode lighter in
the mode line.)

When breadcrumbs are shown, they are all that is shown in the mode line. Mouse-2
on a node of the breadcrumbs path takes you to that node. Mouse-1 anywhere on
the breadcrumbs brings up a `Breadcrumbs' menu, with these items:

 Set Breadcrumbs Depth
 Toggle Breadcrumbs
 Previous Node
 Next Node

The previous and next items are there only when there is really a previous or
next node. Setting the depth here (first menu item) does not change the value of
option `Info-breadcrumbs-depth'.

It's pretty simple - give it a try; you might like it. The mode line, like the
header line, is always handy - no need to scroll.

A possible change: Add a menu item `Customize Breadcrumbs Depth' for customizing
`Info-breadcrumbs-depth', the default depth.

Another possible change: Put back the size indication mode when breadcrumbs are
shown. I don't miss it (the scroll bar is enough), but you might want it. There
is probably room for it, even for manuals that have several levels and long node
names.

Another possible change: put back the read-only/writable indicator. Or perhaps
just turn off breadcrumbs mode whenever someone edits an Info node.

I don't think you'll miss any of the other stuff that is normally in the mode
line. I don't.

[-- Attachment #2: info-2010-04-05.patch --]
[-- Type: application/octet-stream, Size: 10179 bytes --]

diff -cw info-BZR-2010-04-05.el info-patched-2010-04-05.el
*** info-BZR-2010-04-05.el	Mon Apr  5 07:48:52 2010
--- info-patched-2010-04-05.el	Mon Apr  5 15:41:04 2010
***************
*** 240,245 ****
--- 240,248 ----
  0 means do not display breadcrumbs."
    :type 'integer)
  
+ (defvar Info-breadcrumbs-depth-internal Info-breadcrumbs-depth
+   "Current breadcrumbs depth for Info.")
+ 
  (defcustom Info-search-whitespace-regexp "\\s-+"
    "If non-nil, regular expression to match a sequence of whitespace chars.
  This applies to Info search for regular expressions.
***************
*** 1053,1061 ****
  	    (Info-select-node)
  	    (goto-char (point-min))
  	    (forward-line 1)		       ; skip header line
- 	    (when (> Info-breadcrumbs-depth 0) ; skip breadcrumbs line
- 	      (forward-line 1))
- 
  	    (cond (anchorpos
                     (let ((new-history (list Info-current-file
                                              (substring-no-properties nodename))))
--- 1056,1061 ----
***************
*** 1076,1082 ****
          (let ((hist (car Info-history)))
            (setq Info-history (cdr Info-history))
            (Info-find-node (nth 0 hist) (nth 1 hist) t)
!           (goto-char (nth 2 hist))))))
  
  ;; Cache the contents of the (virtual) dir file, once we have merged
  ;; it for the first time, so we can save time subsequently.
--- 1076,1083 ----
          (let ((hist (car Info-history)))
            (setq Info-history (cdr Info-history))
            (Info-find-node (nth 0 hist) (nth 1 hist) t)
!           (goto-char (nth 2 hist)))))
!   (if Info-breadcrumbs-mode (Info-insert-breadcrumbs) (Info-set-mode-line)))
  
  ;; Cache the contents of the (virtual) dir file, once we have merged
  ;; it for the first time, so we can save time subsequently.
***************
*** 3690,3695 ****
--- 3691,3698 ----
      :help "Go to final node in this file"]
     ("Menu Item" ["You should never see this" report-emacs-bug t])
     ("Reference" ["You should never see this" report-emacs-bug t])
+    ["Toggle Breadcrumbs" Info-breadcrumbs-mode
+     :help "Toggle showing breadcrumbs in the mode line"]
     ["Search..." Info-search
      :help "Search for regular expression in this Info file"]
     ["Search Next" Info-search-next
***************
*** 4196,4237 ****
    (let ((nodes (Info-toc-nodes Info-current-file))
  	(node Info-current-node)
          (crumbs ())
!         (depth Info-breadcrumbs-depth))
! 
      ;; Get ancestors from the cached parent-children node info
      (while (and (not (equal "Top" node)) (> depth 0))
        (setq node (nth 1 (assoc node nodes)))
!       (if node (push node crumbs))
        (setq depth (1- depth)))
- 
      ;; Add bottom node.
!     (when Info-use-header-line
!       ;; Let it disappear if crumbs is nil.
!       (nconc crumbs (list Info-current-node)))
!     (when (or Info-use-header-line crumbs)
        ;; Add top node (and continuation if needed).
!       (setq crumbs
! 	    (cons "Top" (if (member (pop crumbs) '(nil "Top"))
! 			    crumbs (cons nil crumbs))))
!       ;; Eliminate duplicate.
!       (forward-line 1)
        (dolist (node crumbs)
! 	(let ((text
! 	       (if (not (equal node "Top")) node
! 		 (format "(%s)Top"
  			 (if (stringp Info-current-file)
  			     (file-name-nondirectory Info-current-file)
  			   ;; Some legacy code can still use a symbol.
! 			   Info-current-file)))))
! 	  (insert (if (bolp) "" " > ")
! 		  (cond
! 		   ((null node) "...")
! 		   ((equal node Info-current-node)
! 		    ;; No point linking to ourselves.
! 		    (propertize text 'font-lock-face 'info-header-node))
! 		   (t
! 		    (concat "*Note " text "::"))))))
!       (insert "\n"))))
  
  (defun Info-fontify-node ()
    "Fontify the node."
--- 4199,4275 ----
    (let ((nodes   (Info-toc-nodes Info-current-file))
  	(node    Info-current-node)
          (crumbs  ())
!         (depth   Info-breadcrumbs-depth-internal)
!         (text    ""))
      ;; Get ancestors from the cached parent-children node info
      (while (and (not (equal "Top" node)) (> depth 0))
        (setq node  (nth 1 (assoc node nodes)))
!       (when node (push node crumbs))
        (setq depth  (1- depth)))
      ;; Add bottom node.
!     (setq crumbs  (nconc crumbs (list Info-current-node)))
!     (when crumbs
        ;; Add top node (and continuation if needed).
!       (setq crumbs  (cons "Top" (if (member (pop crumbs) '(nil "Top"))
!                                     crumbs
!                                   (cons nil crumbs))))
        (dolist (node  crumbs)
!         (when node
!           (setq node                    ; Breadcrumbs map
!                 (propertize node
!                             'local-map (let ((map       (make-sparse-keymap))
!                                              (menu-map  (make-sparse-keymap "Breadcrumbs")))
!                                          (define-key menu-map [Info-prev]
!                                            `(menu-item "Previous Node" Info-prev
!                                                        :visible ,(Info-check-pointer "prev[ious]*")
!                                                        :help "Go to the previous node"))
!                                          (define-key menu-map [Info-next]
!                                            `(menu-item "Next Node" Info-next
!                                                        :visible ,(Info-check-pointer "next")
!                                                        :help "Go to the next node"))
!                                          (define-key menu-map [separator] '("--"))
!                                          (define-key menu-map [Info-breadcrumbs-mode]
!                                            `(menu-item "Toggle Breadcrumbs" Info-breadcrumbs-mode
!                                                        :help "Toggle displaying breadcrumbs in the Info mode-line"
!                                                        :button (:toggle . Info-breadcrumbs-mode)))
!                                          (define-key menu-map [Info-set-breadcrumbs-depth]
!                                            `(menu-item "Set Breadcrumbs Depth" Info-set-breadcrumbs-depth
!                                                        :help "Set depth of breadcrumbs to show in the mode-line"))
!                                          (define-key map [mode-line down-mouse-1] menu-map)
!                                          (define-key map [mode-line down-mouse-2]
!                                            `(lambda () (interactive) (Info-goto-node ,node)))
!                                          map)
!                             'help-echo (concat "mouse-1: Menu"
!                                                (if (equal node Info-current-node)"" ", mouse-2: Go to this node")))))
! 	(let ((nodetext  (if (not (equal node "Top"))
!                              node
!                            (format "(%s)%s"
                                     (if (stringp Info-current-file)
                                         (file-name-nondirectory Info-current-file)
                                       ;; Some legacy code can still use a symbol.
!                                      Info-current-file)
!                                    node))))
!           (setq text (concat text (if (equal node "Top") "" " > ")
!                              (if node nodetext "...")))))
!       (make-local-variable 'mode-line-format) ; Needed for Emacs 21+.
!       (setq mode-line-format  text))))
! 
! (define-minor-mode Info-breadcrumbs-mode
!     "Toggle the use of breadcrumbs in Info mode line.
! With arg, show breadcrumbs iff arg is positive."
!   :group 'mode-line :group 'info
!   (if (not Info-breadcrumbs-mode)
!       (setq Info-breadcrumbs-depth-internal  0
!             mode-line-format                 default-mode-line-format)
!     (setq Info-breadcrumbs-depth-internal  Info-breadcrumbs-depth)
!     (Info-insert-breadcrumbs)))
! 
! (defun Info-set-breadcrumbs-depth ()
!   "Set current breadcrumbs depth to a value read from user."
!   (interactive)
!   (setq Info-breadcrumbs-depth-internal  (read-number "New breadcrumbs depth: "
!                                                       Info-breadcrumbs-depth-internal))
!   (Info-insert-breadcrumbs))
  
  (defun Info-fontify-node ()
    "Fontify the node."
***************
*** 4278,4286 ****
  		((string-equal (downcase tag) "next") Info-next-link-keymap)
  		((string-equal (downcase tag) "up"  ) Info-up-link-keymap))))))
  
-         (when (> Info-breadcrumbs-depth 0)
-           (Info-insert-breadcrumbs))
- 
          ;; Treat header line.
          (when Info-use-header-line
            (goto-char (point-min))
--- 4316,4321 ----
***************
*** 4307,4321 ****
  				"%"
  				;; Preserve text properties on duplicated `%'.
  				(lambda (s) (concat s s)) header))
!             ;; Hide the part of the first line
!             ;; that is in the header, if it is just part.
!             (cond
!              ((> Info-breadcrumbs-depth 0)
!               (put-text-property (point-min) (1+ header-end) 'invisible t))
!              ((not (bobp))
                ;; Hide the punctuation at the end, too.
                (skip-chars-backward " \t,")
!               (put-text-property (point) header-end 'invisible t))))))
  
        ;; Fontify titles
        (goto-char (point-min))
--- 4342,4352 ----
  				"%"
  				;; Preserve text properties on duplicated `%'.
  				(lambda (s) (concat s s)) header))
!             ;; Hide the part of the first line that is in the header, if it is just part.
              ;; Hide the punctuation at the end, too.
+             (unless (bobp)
                (skip-chars-backward " \t,")
!               (put-text-property (point) header-end 'invisible t)))))
  
        ;; Fontify titles
        (goto-char (point-min))

Diff finished.  Mon Apr 05 15:41:59 2010

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> A possible change: Add a menu item `Customize Breadcrumbs 
> Depth' for customizing
> `Info-breadcrumbs-depth', the default depth.
> 
> Another possible change: Put back the size indication mode 
> when breadcrumbs are
> shown. I don't miss it (the scroll bar is enough), but you 
> might want it. There
> is probably room for it, even for manuals that have several 
> levels and long node
> names.
> 
> Another possible change: put back the read-only/writable 
> indicator. Or perhaps
> just turn off breadcrumbs mode whenever someone edits an Info node.

Another possible change: Put `Info-scroll-up'/`down' on mouse-1/mouse-3 for the
current node name (similar to what is the case now).

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

[-- Attachment #1: Type: text/plain, Size: 1297 bytes --]

I hope you will take a minute to try the patch.

> Another possible change: Put `Info-scroll-up'/`down' on 
> mouse-1/mouse-3 for the current node name (similar to what
> is the case now).

I did that. Attached is a better patch:

. mouse-2: the breadcrumbs menu
. mouse-1/3: Info-scroll-* for the current node
             go-to-clicked-node for ancestor nodes

And it does the usual mouseover highlighting on a node name to show it is
mouse-active (which I had forgotten in the previous patch).

----

Better yet would be the following (I did not do this in the patch): Swap mouse-2
and mouse-3, and swap the scroll directions.

For the current node:
. mouse-1: Info-mouse-scroll-down
. mouse-2: Info-mouse-scroll-up
. mouse-3: breadcrumbs menu

For ancestor nodes:
. mouse-1: go to clicked node
. mouse-2: go to clicked node
. mouse-3: breadcrumbs menu

That would be better for these reasons:

1. mouse-1 and mouse-2 both go to the clicked ancestor node, just as they both
follow links (by default).

2. mouse-1 is to the left of mouse-2, so mouse-1 should move left and mouse-2
right. It is perverse to cross these directions. See bug #5841.

3. mouse-3 as a menu is very common outside Emacs and not unexpected for lots of
users. mouse-2 (in Emacs and outside it) is rarely used for a menu.

[-- Attachment #2: info-2010-04-06.patch --]
[-- Type: application/octet-stream, Size: 10692 bytes --]

diff -cw info-BZR-2010-04-05.el info-patched-2010-04-06.el
*** info-BZR-2010-04-05.el	Mon Apr  5 07:48:52 2010
--- info-patched-2010-04-06.el	Tue Apr  6 09:04:46 2010
***************
*** 240,245 ****
--- 240,248 ----
  0 means do not display breadcrumbs."
    :type 'integer)
  
+ (defvar Info-breadcrumbs-depth-internal Info-breadcrumbs-depth
+   "Current breadcrumbs depth for Info.")
+ 
  (defcustom Info-search-whitespace-regexp "\\s-+"
    "If non-nil, regular expression to match a sequence of whitespace chars.
  This applies to Info search for regular expressions.
***************
*** 1053,1061 ****
  	    (Info-select-node)
  	    (goto-char (point-min))
  	    (forward-line 1)		       ; skip header line
- 	    (when (> Info-breadcrumbs-depth 0) ; skip breadcrumbs line
- 	      (forward-line 1))
- 
  	    (cond (anchorpos
                     (let ((new-history (list Info-current-file
                                              (substring-no-properties nodename))))
--- 1056,1061 ----
***************
*** 1076,1082 ****
          (let ((hist (car Info-history)))
            (setq Info-history (cdr Info-history))
            (Info-find-node (nth 0 hist) (nth 1 hist) t)
!           (goto-char (nth 2 hist))))))
  
  ;; Cache the contents of the (virtual) dir file, once we have merged
  ;; it for the first time, so we can save time subsequently.
--- 1076,1083 ----
          (let ((hist (car Info-history)))
            (setq Info-history (cdr Info-history))
            (Info-find-node (nth 0 hist) (nth 1 hist) t)
!           (goto-char (nth 2 hist)))))
!   (if Info-breadcrumbs-mode (Info-insert-breadcrumbs) (Info-set-mode-line)))
  
  ;; Cache the contents of the (virtual) dir file, once we have merged
  ;; it for the first time, so we can save time subsequently.
***************
*** 3690,3695 ****
--- 3691,3698 ----
      :help "Go to final node in this file"]
     ("Menu Item" ["You should never see this" report-emacs-bug t])
     ("Reference" ["You should never see this" report-emacs-bug t])
+    ["Toggle Breadcrumbs" Info-breadcrumbs-mode
+     :help "Toggle showing breadcrumbs in the mode line"]
     ["Search..." Info-search
      :help "Search for regular expression in this Info file"]
     ["Search Next" Info-search-next
***************
*** 4196,4237 ****
    (let ((nodes (Info-toc-nodes Info-current-file))
  	(node Info-current-node)
          (crumbs ())
!         (depth Info-breadcrumbs-depth))
! 
      ;; Get ancestors from the cached parent-children node info
      (while (and (not (equal "Top" node)) (> depth 0))
        (setq node (nth 1 (assoc node nodes)))
!       (if node (push node crumbs))
        (setq depth (1- depth)))
- 
      ;; Add bottom node.
!     (when Info-use-header-line
!       ;; Let it disappear if crumbs is nil.
!       (nconc crumbs (list Info-current-node)))
!     (when (or Info-use-header-line crumbs)
        ;; Add top node (and continuation if needed).
!       (setq crumbs
! 	    (cons "Top" (if (member (pop crumbs) '(nil "Top"))
! 			    crumbs (cons nil crumbs))))
!       ;; Eliminate duplicate.
!       (forward-line 1)
        (dolist (node crumbs)
! 	(let ((text
! 	       (if (not (equal node "Top")) node
! 		 (format "(%s)Top"
  			 (if (stringp Info-current-file)
  			     (file-name-nondirectory Info-current-file)
  			   ;; Some legacy code can still use a symbol.
! 			   Info-current-file)))))
! 	  (insert (if (bolp) "" " > ")
! 		  (cond
! 		   ((null node) "...")
! 		   ((equal node Info-current-node)
! 		    ;; No point linking to ourselves.
! 		    (propertize text 'font-lock-face 'info-header-node))
! 		   (t
! 		    (concat "*Note " text "::"))))))
!       (insert "\n"))))
  
  (defun Info-fontify-node ()
    "Fontify the node."
--- 4199,4286 ----
    (let ((nodes   (Info-toc-nodes Info-current-file))
  	(node    Info-current-node)
          (crumbs  ())
!         (depth   Info-breadcrumbs-depth-internal)
!         (text    ""))
      ;; Get ancestors from the cached parent-children node info
      (while (and (not (equal "Top" node)) (> depth 0))
        (setq node  (nth 1 (assoc node nodes)))
!       (when node (push node crumbs))
        (setq depth  (1- depth)))
      ;; Add bottom node.
!     (setq crumbs  (nconc crumbs (list Info-current-node)))
!     (when crumbs
        ;; Add top node (and continuation if needed).
!       (setq crumbs  (cons "Top" (if (member (pop crumbs) '(nil "Top"))
!                                     crumbs
!                                   (cons nil crumbs))))
        (dolist (node  crumbs)
!         (let ((crumbs-map  (make-sparse-keymap))
!               (menu-map    (make-sparse-keymap "Breadcrumbs")))
!           (define-key crumbs-map [mode-line mouse-2] menu-map)
!           (when node
!             (define-key menu-map [Info-prev]
!               `(menu-item "Previous Node" Info-prev
!                           :visible ,(Info-check-pointer "prev[ious]*")
!                           :help "Go to the previous node"))
!             (define-key menu-map [Info-next]
!               `(menu-item "Next Node" Info-next
!                           :visible ,(Info-check-pointer "next")
!                           :help "Go to the next node"))
!             (define-key menu-map [separator] '("--"))
!             (define-key menu-map [Info-breadcrumbs-mode]
!               `(menu-item "Toggle Breadcrumbs" Info-breadcrumbs-mode
!                           :help "Toggle displaying breadcrumbs in the Info mode-line"
!                           :button (:toggle . Info-breadcrumbs-mode)))
!             (define-key menu-map [Info-set-breadcrumbs-depth]
!               `(menu-item "Set Breadcrumbs Depth" Info-set-breadcrumbs-depth
!                           :help "Set depth of breadcrumbs to show in the mode-line"))
!             (setq node  (if (equal node Info-current-node)
!                             (propertize (replace-regexp-in-string "%" "%%" Info-current-node)
!                                         'face 'mode-line-buffer-id
!                                         'help-echo "mouse-1: scroll forward, mouse-2: menu, mouse-3: scroll back"
!                                         'mouse-face 'mode-line-highlight
!                                         'local-map
!                                         (progn
!                                           (define-key crumbs-map [mode-line mouse-1] 'Info-mouse-scroll-up)
!                                           (define-key crumbs-map [mode-line mouse-3] 'Info-mouse-scroll-down)
!                                           crumbs-map))
!                           (propertize node
!                                       'local-map (progn
!                                                    (define-key crumbs-map [mode-line mouse-1]
!                                                      `(lambda () (interactive) (Info-goto-node ,node)))
!                                                    (define-key crumbs-map [mode-line mouse-3]
!                                                      `(lambda () (interactive) (Info-goto-node ,node)))
!                                                    crumbs-map)
!                                       'mouse-face 'mode-line-highlight
!                                       'help-echo "mouse-1, mouse-3: Go to this node; mouse-2: Menu")))))
! 	(let ((nodetext  (if (not (equal node "Top"))
!                              node
!                            (concat (format "(%s)"
                                             (if (stringp Info-current-file)
                                                 (file-name-nondirectory Info-current-file)
                                               ;; Some legacy code can still use a symbol.
!                                              Info-current-file))
!                                    node))))
!           (setq text  (concat text (if (equal node "Top") "" " > ") (if node nodetext "...")))))
!       (make-local-variable 'mode-line-format) ; Needed for Emacs 21+.
!       (setq mode-line-format  text))))
! 
! (define-minor-mode Info-breadcrumbs-mode
!     "Toggle the use of breadcrumbs in Info mode line.
! With arg, show breadcrumbs iff arg is positive."
!   :group 'mode-line :group 'info
!   (if (not Info-breadcrumbs-mode)
!       (setq Info-breadcrumbs-depth-internal  0
!             mode-line-format                 default-mode-line-format)
!     (setq Info-breadcrumbs-depth-internal  Info-breadcrumbs-depth)
!     (Info-insert-breadcrumbs)))
! 
! (defun Info-set-breadcrumbs-depth ()
!   "Set current breadcrumbs depth to a value read from user."
!   (interactive)
!   (setq Info-breadcrumbs-depth-internal  (read-number "New breadcrumbs depth: "
!                                                       Info-breadcrumbs-depth-internal))
!   (Info-insert-breadcrumbs))
  
  (defun Info-fontify-node ()
    "Fontify the node."
***************
*** 4278,4286 ****
  		((string-equal (downcase tag) "next") Info-next-link-keymap)
  		((string-equal (downcase tag) "up"  ) Info-up-link-keymap))))))
  
-         (when (> Info-breadcrumbs-depth 0)
-           (Info-insert-breadcrumbs))
- 
          ;; Treat header line.
          (when Info-use-header-line
            (goto-char (point-min))
--- 4327,4332 ----
***************
*** 4307,4321 ****
  				"%"
  				;; Preserve text properties on duplicated `%'.
  				(lambda (s) (concat s s)) header))
!             ;; Hide the part of the first line
!             ;; that is in the header, if it is just part.
!             (cond
!              ((> Info-breadcrumbs-depth 0)
!               (put-text-property (point-min) (1+ header-end) 'invisible t))
!              ((not (bobp))
                ;; Hide the punctuation at the end, too.
                (skip-chars-backward " \t,")
!               (put-text-property (point) header-end 'invisible t))))))
  
        ;; Fontify titles
        (goto-char (point-min))
--- 4353,4363 ----
  				"%"
  				;; Preserve text properties on duplicated `%'.
  				(lambda (s) (concat s s)) header))
!             ;; Hide the part of the first line that is in the header, if it is just part.
              ;; Hide the punctuation at the end, too.
+             (unless (bobp)
                (skip-chars-backward " \t,")
!               (put-text-property (point) header-end 'invisible t)))))
  
        ;; Fontify titles
        (goto-char (point-min))

Diff finished.  Tue Apr 06 09:10:17 2010

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

> TRY it. Visit as many nodes and links as you like - the more the
> better.  Describe to us what you *actually* see: what percentage of
> the links do not take you directly to the appropriate passage?
> 10%?  1%?  0.1%?

No need to blindly trying to click all links.  You can open the file
`info/elisp' and count all strings that start with "Ref:"
(they are anchors that put the cursor to a mid-node position).

There are 66 lines with "Ref:" (that fail to go directly to the
appropriate place) and 839 lines with "Node:" (that succeed since
they put the cursor to the beginning of the node).

The ratio of 66 to 839 is 8%.  So you guess of 10% is closer to the
actual percentage.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> No need to blindly trying to click all links.  You can open the file
> `info/elisp' and count all strings that start with "Ref:"
> (they are anchors that put the cursor to a mid-node position).
> 
> There are 66 lines with "Ref:" (that fail to go directly to the
> appropriate place) and 839 lines with "Node:" (that succeed since
> they put the cursor to the beginning of the node).
> 
> The ratio of 66 to 839 is 8%.  So you guess of 10% is closer to the
> actual percentage.

Thanks. I wasn't aware of that. Now we know. Neither "all the time" nor "very
rare". At least in terms of _numbers_ of links (see #2 below).

1. But what do you mean here by "fail to go directly to the appropriate place"?
As I pointed out, failing to go to the precise location is not a problem in the
vast majority of cases, since the link still takes you to the appropriate
paragraph or correct 1-3 line description. Does your measure take that into
account?

IOW, even if 10% of the links do not behave precisely, but 99.9% of those
fail-to-go-directly links still get you to the correct paragraph (or correct 1-2
line function/var description), then the 10% number is far too high as a measure
of the real problem.

2. I'm still assuming, based on experience, that it is mainly the index links
that target mid-node locations. So a secondary question would be how often the
different kinds of links are followed in practice - e.g. index vs other links.
If there is a significant difference (either way), that could be important. This
is a user-practice question, which cannot be answered by counting links.

I myself use the index a lot, at least via `i'. I think it's important that
index links actually take you where they should. But if users generally use
index links less than text-body links, then that reduces the practical problem
still further.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: "'Eli Zaretskii'" <eliz@gnu.org>,  5809@debbugs.gnu.org
> Date: Mon, 05 Apr 2010 19:45:56 +0300
> 
> The ratio of 66 to 839 is 8%.  So you guess of 10% is closer to the
> actual percentage.

That's only one manual.  The Emacs manuals don't use @anchor very
much.  In the GDB manual, the ratio is 65 to 418 (15.5%), which is
twice the ratio we see in ELisp.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> > but then you can't "click" on breadcrumbs with the keyboard any more.
> 
> "Clicking" on breadcrumbs with a keyboard is the same as typing "u",
> so I don't see this as a loss.

No. Clicking or hitting return on a specific part of a breadcrumbs path takes
you directly to that ancestor node. `u' takes you only to the parent node.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>> Here's another, perhaps better idea: how about if, instead of
>> inserting breadcrumbs as text into the buffer, we put an overlay there
>> with a display property whose value is the breadcrumbs as a string?
>> This way, buffer positions are not affected at all.
>
> That was my thought as well, but then you can't "click" on breadcrumbs
> with the keyboard any more.

You can't click with the keyboard on the navigation up/next/prev links
in the header line too.  I have not seen any complaints on that.

The header line has one advantage over links - it doesn't scroll
and always stays on the top.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Drew Adams]

> The header line has one advantage over links - it doesn't scroll
> and always stays on the top.

Yes, that's a significant advantage for orientation and navigability, IMO.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: Eli Zaretskii <eliz@gnu.org>,  5809@debbugs.gnu.org
> Date: Fri, 02 Apr 2010 19:14:09 +0300
> 
> > That was my thought as well, but then you can't "click" on breadcrumbs
> > with the keyboard any more.
> 
> You can't click with the keyboard on the navigation up/next/prev links
> in the header line too.  I have not seen any complaints on that.
> 
> The header line has one advantage over links - it doesn't scroll
> and always stays on the top.

You can move the overlay upon scrolling to achieve the same effect.

The advantage of overlays is that you don't need any changes to the
display engine.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Stefan Monnier]

>>> Here's another, perhaps better idea: how about if, instead of
>>> inserting breadcrumbs as text into the buffer, we put an overlay there
>>> with a display property whose value is the breadcrumbs as a string?
>>> This way, buffer positions are not affected at all.
>> That was my thought as well, but then you can't "click" on breadcrumbs
>> with the keyboard any more.
> You can't click with the keyboard on the navigation up/next/prev links
> in the header line too.  I have not seen any complaints on that.

IIUC there are keyboard shortcuts to go up/next/prev, whereas there
aren't keyboard shortcuts to go to one of the breadcrumbs (other than
the last one which is just "up").

This said, I agree that not being able to click on them with the
keyboard is not the end of the world.
IOW, using an after-string would probably be an OK compromise for 23.2
(better than dropping breadcrumbs altogether).


        Stefan

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

> IOW, using an after-string would probably be an OK compromise for 23.2
> (better than dropping breadcrumbs altogether).

I'll try to implement an after-string for 23.2.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>> IOW, using an after-string would probably be an OK compromise for 23.2
>> (better than dropping breadcrumbs altogether).
>
> I'll try to implement an after-string for 23.2.

To be able to click on links that are not part of the Info file
and don't have the "*Note" format, this patch adds two new commands
`Info-mouse-follow-link' and `Info-follow-link' plus a new keymap
`Info-link-keymap' (it's like `Info-up-link-keymap' and friends).

`Info-insert-breadcrumbs' is renamed to `Info-breadcrumbs'
that returns a string with links.

There are still a problem.  I can't find a way to move the cursor
inside the overlay's after-string and click links inside it.
Any suggestions?

=== modified file 'lisp/info.el'
--- lisp/info.el	2010-03-03 19:23:20 +0000
+++ lisp/info.el	2010-04-03 22:03:23 +0000
@@ -1053,8 +1053,6 @@ (defun Info-find-node-2 (filename nodena
 	    (Info-select-node)
 	    (goto-char (point-min))
 	    (forward-line 1)		       ; skip header line
-	    (when (> Info-breadcrumbs-depth 0) ; skip breadcrumbs line
-	      (forward-line 1))
 
 	    (cond (anchorpos
                    (let ((new-history (list Info-current-file
@@ -3551,6 +3549,20 @@ (defun Info-try-follow-nearest-node (&op
      ((setq node (Info-get-token (point) "Prev: " "Prev: \\([^,\n\t]*\\)"))
       (Info-goto-node node fork)))
     node))
+
+(defun Info-mouse-follow-link (click)
+  "Follow a link under point."
+  (interactive "e")
+  (mouse-set-point click)
+  (Info-follow-link))
+
+(defun Info-follow-link ()
+  "Follow a link under point."
+  (interactive)
+  (let ((link-args (get-text-property (point) 'link-args)))
+    (when link-args
+      (Info-goto-node link-args))))
+
 \f
 (defvar Info-mode-map
   (let ((map (make-keymap)))
@@ -4141,11 +4153,23 @@ (defvar Info-up-link-keymap
     keymap)
   "Keymap to put on the Up link in the text or the header line.")
 
-(defun Info-insert-breadcrumbs ()
+(defvar Info-link-keymap
+  (let ((keymap (make-sparse-keymap)))
+    (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
+    (define-key keymap [header-line mouse-2] 'Info-mouse-follow-link)
+    (define-key keymap [header-line down-mouse-1] 'ignore)
+    (define-key keymap [mouse-2] 'Info-mouse-follow-link)
+    (define-key keymap [follow-link] 'mouse-face)
+    (define-key keymap "\r" 'Info-follow-link)
+    keymap)
+  "Keymap to put on the link in the text or the header line.")
+
+(defun Info-breadcrumbs ()
   (let ((nodes (Info-toc-nodes Info-current-file))
 	(node Info-current-node)
         (crumbs ())
-        (depth Info-breadcrumbs-depth))
+        (depth Info-breadcrumbs-depth)
+	line)
 
     ;; Get ancestors from the cached parent-children node info
     (while (and (not (equal "Top" node)) (> depth 0))
@@ -4172,15 +4196,24 @@ (defun Info-insert-breadcrumbs ()
 			     (file-name-nondirectory Info-current-file)
 			   ;; Some legacy code can still use a symbol.
 			   Info-current-file)))))
-	  (insert (if (bolp) "" " > ")
-		  (cond
-		   ((null node) "...")
-		   ((equal node Info-current-node)
-		    ;; No point linking to ourselves.
-		    (propertize text 'font-lock-face 'info-header-node))
-		   (t
-		    (concat "*Note " text "::"))))))
-      (insert "\n"))))
+	  (setq line (concat
+		      line
+		      (if (null line) "" " > ")
+		      (cond
+		       ((null node) "...")
+		       ((equal node Info-current-node)
+			;; No point linking to ourselves.
+			(propertize text 'font-lock-face 'info-header-node))
+		       (t
+			(propertize text
+				    'mouse-face 'highlight
+				    'font-lock-face 'info-header-xref
+				    'help-echo "mouse-2: Go to node"
+				    'keymap Info-link-keymap
+				    'link-args text)
+			))))))
+      (setq line (concat line "\n")))
+    line))
 
 (defun Info-fontify-node ()
   "Fontify the node."
@@ -4227,8 +4260,8 @@ (defun Info-fontify-node ()
 		((string-equal (downcase tag) "next") Info-next-link-keymap)
 		((string-equal (downcase tag) "up"  ) Info-up-link-keymap))))))
 
-        (when (> Info-breadcrumbs-depth 0)
-          (Info-insert-breadcrumbs))
+        ;; (when (> Info-breadcrumbs-depth 0)
+        ;;   (insert (Info-breadcrumbs)))
 
         ;; Treat header line.
         (when Info-use-header-line
@@ -4260,7 +4293,10 @@ (defun Info-fontify-node ()
             ;; that is in the header, if it is just part.
             (cond
              ((> Info-breadcrumbs-depth 0)
-              (put-text-property (point-min) (1+ header-end) 'invisible t))
+              (put-text-property (point-min) (1+ header-end) 'invisible t)
+	      (overlay-put
+	       (make-overlay header-end (1+ header-end))
+	       'after-string (propertize (Info-breadcrumbs) 'cursor t)))
              ((not (bobp))
               ;; Hide the punctuation at the end, too.
               (skip-chars-backward " \t,")

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Date: Sun, 04 Apr 2010 01:04:45 +0300
> Cc: 5809@debbugs.gnu.org
> 
> >> IOW, using an after-string would probably be an OK compromise for 23.2
> >> (better than dropping breadcrumbs altogether).
> >
> > I'll try to implement an after-string for 23.2.
> 
> To be able to click on links that are not part of the Info file
> and don't have the "*Note" format, this patch adds two new commands
> `Info-mouse-follow-link' and `Info-follow-link' plus a new keymap
> `Info-link-keymap' (it's like `Info-up-link-keymap' and friends).
> 
> `Info-insert-breadcrumbs' is renamed to `Info-breadcrumbs'
> that returns a string with links.

Thank you!

> There are still a problem.  I can't find a way to move the cursor
> inside the overlay's after-string and click links inside it.
> Any suggestions?

Does it work to change the character of the overlay string on which
you put the `cursor' property?  (You will need to redefine C-f, C-b,
and friends for that.)

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>> There are still a problem.  I can't find a way to move the cursor
>> inside the overlay's after-string and click links inside it.
>> Any suggestions?
>
> Does it work to change the character of the overlay string on which
> you put the `cursor' property?  (You will need to redefine C-f, C-b,
> and friends for that.)

Sorry, I don't understand what do you mean.  Could you modify the example
you recently sent to emacs-devel:

    (let ((pos (goto-char (point-max))))
      (insert "foobar")
      (overlay-put
	(make-overlay (+ pos 2) (+ pos 3))
	'after-string (propertize "-" 'cursor t)))

to allow the cursor to move inside 'after-string and to not jump over it?

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: monnier@iro.umontreal.ca,  5809@debbugs.gnu.org
> Date: Sun, 04 Apr 2010 14:07:28 +0300
> 
> >> There are still a problem.  I can't find a way to move the cursor
> >> inside the overlay's after-string and click links inside it.
> >> Any suggestions?
> >
> > Does it work to change the character of the overlay string on which
> > you put the `cursor' property?  (You will need to redefine C-f, C-b,
> > and friends for that.)
> 
> Sorry, I don't understand what do you mean.  Could you modify the example
> you recently sent to emacs-devel:
> 
>     (let ((pos (goto-char (point-max))))
>       (insert "foobar")
>       (overlay-put
> 	(make-overlay (+ pos 2) (+ pos 3))
> 	'after-string (propertize "-" 'cursor t)))
> 
> to allow the cursor to move inside 'after-string and to not jump over it?

Compare the results of evaluating the two forms below:

    (let ((pos (goto-char (point-max))))
      (insert "foobar")
      (overlay-put
	(make-overlay (+ pos 2) (+ pos 3))
	'after-string (concat "1" (propertize "2" 'cursor t) "34")))


    (let ((pos (goto-char (point-max))))
      (insert "foobar")
      (overlay-put
	(make-overlay (+ pos 2) (+ pos 3))
	'after-string (concat "12" (propertize "3" 'cursor t) "4")))

Both display "foo1234bar", with "1234" coming from the `after-string'
overlay.

When you type C-f on the second `o' in "foo", the cursor will be
displayed on `2' with the first form and on `3' with the second.  More
generally, the cursor will be displayed on the character in "1234"
which you propertize with a non-nil `cursor' property.

What I meant in my suggestion is to move the property from one
character to another of the `after-string' when the user types C-f
with cursor on the overlay.  E.g., if the cursor is on `2' and I type
C-f, modify the `after-string' from

     (concat "1" (propertize "2" 'cursor t) "34")
to
     (concat "12" (propertize "3" 'cursor t) "4")

Then it will appear as if the cursor moved inside the `after-string'.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

> What I meant in my suggestion is to move the property from one
> character to another of the `after-string' when the user types C-f
> with cursor on the overlay.  E.g., if the cursor is on `2' and I type
> C-f, modify the `after-string' from
>
>      (concat "1" (propertize "2" 'cursor t) "34")
> to
>      (concat "12" (propertize "3" 'cursor t) "4")
>
> Then it will appear as if the cursor moved inside the `after-string'.

Thanks for the explanation.  It seems this is not a trivial change for 23.2.

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Eli Zaretskii]

> From: Juri Linkov <juri@jurta.org>
> Cc: monnier@iro.umontreal.ca,  5809@debbugs.gnu.org
> Date: Mon, 05 Apr 2010 02:51:23 +0300
> 
> > What I meant in my suggestion is to move the property from one
> > character to another of the `after-string' when the user types C-f
> > with cursor on the overlay.  E.g., if the cursor is on `2' and I type
> > C-f, modify the `after-string' from
> >
> >      (concat "1" (propertize "2" 'cursor t) "34")
> > to
> >      (concat "12" (propertize "3" 'cursor t) "4")
> >
> > Then it will appear as if the cursor moved inside the `after-string'.
> 
> Thanks for the explanation.  It seems this is not a trivial change for 23.2.

Yes, I agree.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Stefan Monnier]

> There are still a problem.  I can't find a way to move the cursor
> inside the overlay's after-string and click links inside it.

That's what I said would be the limitation: you can't "click" with
the keyboard.  I think it's an acceptable limitation for now.
Also you can't copy&paste the string (e.g. to make a bug report).

> Any suggestions?

If you *really really really* want to make it work, you can redefine
C-f/C-b and make it move "virtually" by setting/changing the `cursor'
property on those strings, and then do yet more ugly hacks when you hit
RET, etc... but I strongly recommend against it.


        Stefan

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>> There are still a problem.  I can't find a way to move the cursor
>> inside the overlay's after-string and click links inside it.
>
> That's what I said would be the limitation: you can't "click" with
> the keyboard.  I think it's an acceptable limitation for now.
> Also you can't copy&paste the string (e.g. to make a bug report).

We could change the background color of the overlay's after-string
to look like the header line (grey background) so users will expect
that only mouse clicks should work on grey areas.

This patch works with mouse clicks, but needs more testing:

=== modified file 'lisp/info.el'
--- lisp/info.el	2010-03-03 19:23:20 +0000
+++ lisp/info.el	2010-04-04 23:50:03 +0000
@@ -153,12 +153,12 @@ (defcustom Info-use-header-line t
   :group 'info)
 
 (defface info-header-xref
-  '((t :inherit info-xref))
+  '((t :inherit (info-xref header-line)))
   "Face for Info cross-references in a node header."
   :group 'info)
 
 (defface info-header-node
-  '((t :inherit info-node))
+  '((t :inherit (info-node header-line)))
   "Face for Info nodes in a node header."
   :group 'info)
 
@@ -1053,8 +1053,6 @@ (defun Info-find-node-2 (filename nodena
 	    (Info-select-node)
 	    (goto-char (point-min))
 	    (forward-line 1)		       ; skip header line
-	    (when (> Info-breadcrumbs-depth 0) ; skip breadcrumbs line
-	      (forward-line 1))
 
 	    (cond (anchorpos
                    (let ((new-history (list Info-current-file
@@ -3551,6 +3549,19 @@ (defun Info-try-follow-nearest-node (&op
      ((setq node (Info-get-token (point) "Prev: " "Prev: \\([^,\n\t]*\\)"))
       (Info-goto-node node fork)))
     node))
+
+(defun Info-mouse-follow-link (click)
+  "Follow a link under point."
+  (interactive "e")
+  (let* ((position (event-start click))
+	 (posn-string (and position (posn-string position)))
+	 (string (car-safe posn-string))
+	 (string-pos (cdr-safe posn-string))
+	 (link-args (and string string-pos
+			 (get-text-property string-pos 'link-args string))))
+    (when link-args
+      (Info-goto-node link-args))))
+
 \f
 (defvar Info-mode-map
   (let ((map (make-keymap)))
@@ -4141,11 +4152,22 @@ (defvar Info-up-link-keymap
     keymap)
   "Keymap to put on the Up link in the text or the header line.")
 
-(defun Info-insert-breadcrumbs ()
+(defvar Info-link-keymap
+  (let ((keymap (make-sparse-keymap)))
+    (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
+    (define-key keymap [header-line mouse-2] 'Info-mouse-follow-link)
+    (define-key keymap [header-line down-mouse-1] 'ignore)
+    (define-key keymap [mouse-2] 'Info-mouse-follow-link)
+    (define-key keymap [follow-link] 'mouse-face)
+    keymap)
+  "Keymap to put on the link in the text or the header line.")
+
+(defun Info-breadcrumbs ()
   (let ((nodes (Info-toc-nodes Info-current-file))
 	(node Info-current-node)
         (crumbs ())
-        (depth Info-breadcrumbs-depth))
+        (depth Info-breadcrumbs-depth)
+	line)
 
     ;; Get ancestors from the cached parent-children node info
     (while (and (not (equal "Top" node)) (> depth 0))
@@ -4172,15 +4194,24 @@ (defun Info-insert-breadcrumbs ()
 			     (file-name-nondirectory Info-current-file)
 			   ;; Some legacy code can still use a symbol.
 			   Info-current-file)))))
-	  (insert (if (bolp) "" " > ")
-		  (cond
-		   ((null node) "...")
-		   ((equal node Info-current-node)
-		    ;; No point linking to ourselves.
-		    (propertize text 'font-lock-face 'info-header-node))
-		   (t
-		    (concat "*Note " text "::"))))))
-      (insert "\n"))))
+	  (setq line (concat
+		      line
+		      (if (null line) "" (propertize " > " 'face 'header-line))
+		      (cond
+		       ((null node) (propertize "..." 'face 'header-line))
+		       ((equal node Info-current-node)
+			;; No point linking to ourselves.
+			(propertize text 'font-lock-face 'info-header-node))
+		       (t
+			(propertize text
+				    'mouse-face 'highlight
+				    'font-lock-face 'info-header-xref
+				    'help-echo "mouse-2: Go to node"
+				    'keymap Info-link-keymap
+				    'link-args text)
+			))))))
+      (setq line (concat line (propertize "\n" 'face 'header-line))))
+    line))
 
 (defun Info-fontify-node ()
   "Fontify the node."
@@ -4227,9 +4258,6 @@ (defun Info-fontify-node ()
 		((string-equal (downcase tag) "next") Info-next-link-keymap)
 		((string-equal (downcase tag) "up"  ) Info-up-link-keymap))))))
 
-        (when (> Info-breadcrumbs-depth 0)
-          (Info-insert-breadcrumbs))
-
         ;; Treat header line.
         (when Info-use-header-line
           (goto-char (point-min))
@@ -4260,7 +4288,10 @@ (defun Info-fontify-node ()
             ;; that is in the header, if it is just part.
             (cond
              ((> Info-breadcrumbs-depth 0)
-              (put-text-property (point-min) (1+ header-end) 'invisible t))
+              (put-text-property (point-min) (1+ header-end) 'invisible t)
+	      (overlay-put
+	       (make-overlay header-end (1+ header-end))
+	       'after-string (Info-breadcrumbs)))
              ((not (bobp))
               ;; Hide the punctuation at the end, too.
               (skip-chars-backward " \t,")

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Stefan Monnier]

> We could change the background color of the overlay's after-string
> to look like the header line (grey background) so users will expect
> that only mouse clicks should work on grey areas.

I'd rather not change this part of the visual appearance, but maybe it's
just my personal preference.  I think this decision should be taken
with the understanding that we will want to install a real-fix in
Emacs-24 so that we can click with the keyboard and copy&paste
the breadcrumbs and that we won't want to revert the visual appearance
at that point (people get used to visual appearances).

> -	    (when (> Info-breadcrumbs-depth 0) ; skip breadcrumbs line
> -	      (forward-line 1))

I'd keep it commented out, since it may be useful again when we revert
to using actual text rather than an after-string.
 
> +	  (setq line (concat
> +		      line
> +		      (if (null line) "" (propertize " > " 'face 'header-line))
> +		      (cond
> +		       ((null node) (propertize "..." 'face 'header-line))
> +		       ((equal node Info-current-node)
> +			;; No point linking to ourselves.
> +			(propertize text 'font-lock-face 'info-header-node))
> +		       (t
> +			(propertize text
> +				    'mouse-face 'highlight
> +				    'font-lock-face 'info-header-xref
> +				    'help-echo "mouse-2: Go to node"
> +				    'keymap Info-link-keymap
> +				    'link-args text)
> +			))))))

If we want to use this header-line appearance, couldn't we use something
like font-lock-append-text-property rather than apply `header-line'
bit-by-bit (and worse yet: in different ways for different parts).

I.e. the changes to info-header-xref and info-header-node faces earlier
in the patch are not a good idea (think of people who changed those
faces, for example).

> @@ -4227,9 +4258,6 @@ (defun Info-fontify-node ()
>  		((string-equal (downcase tag) "next") Info-next-link-keymap)
>  		((string-equal (downcase tag) "up"  ) Info-up-link-keymap))))))
 
> -        (when (> Info-breadcrumbs-depth 0)
> -          (Info-insert-breadcrumbs))
> -
>          ;; Treat header line.
>          (when Info-use-header-line
>            (goto-char (point-min))
> @@ -4260,7 +4288,10 @@ (defun Info-fontify-node ()
>              ;; that is in the header, if it is just part.
>              (cond
>               ((> Info-breadcrumbs-depth 0)
> -              (put-text-property (point-min) (1+ header-end) 'invisible t))
> +              (put-text-property (point-min) (1+ header-end) 'invisible t)
> +	      (overlay-put
> +	       (make-overlay header-end (1+ header-end))
> +	       'after-string (Info-breadcrumbs)))
>               ((not (bobp))
>                ;; Hide the punctuation at the end, too.
>                (skip-chars-backward " \t,")

Why is the `overlay-put' at a different place than the
former Info-insert-breadcrumbs?


        Stefan


PS: the rest of the patch looks OK, so if you can fix the above feel free
to install it.

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

>> We could change the background color of the overlay's after-string
>> to look like the header line (grey background) so users will expect
>> that only mouse clicks should work on grey areas.
>
> I'd rather not change this part of the visual appearance, but maybe it's
> just my personal preference.  I think this decision should be taken
> with the understanding that we will want to install a real-fix in
> Emacs-24 so that we can click with the keyboard and copy&paste
> the breadcrumbs and that we won't want to revert the visual appearance
> at that point (people get used to visual appearances).

I think both types of navigation links (breadcrumbs and up/next/prev)
should be treated equally.  If we'll implement clicking with the keyboard
and copy&paste in Emacs-24, it would be natural to apply this to the
up/next/prev links as well and change their visual appearance.

Or maybe to leave breadcrumbs and navigation links in the (multi-line?)
header line will be better because they don't scroll and stay on top.

In any case, it's important that the visual appearance should match the
user's expectation.  When the visual appearance of breadcrumbs is
the same as for the rest text of the Info buffer, users will be tempted
to use the keyboard on breadcrumbs.

> If we want to use this header-line appearance, couldn't we use something
> like font-lock-append-text-property rather than apply `header-line'
> bit-by-bit (and worse yet: in different ways for different parts).

Done in the patch below.

>> @@ -4260,7 +4288,10 @@ (defun Info-fontify-node ()
>>              ;; that is in the header, if it is just part.
>>              (cond
>>               ((> Info-breadcrumbs-depth 0)
>> -              (put-text-property (point-min) (1+ header-end) 'invisible t))
>> +              (put-text-property (point-min) (1+ header-end) 'invisible t)
>> +	      (overlay-put
>> +	       (make-overlay header-end (1+ header-end))
>> +	       'after-string (Info-breadcrumbs)))
>>               ((not (bobp))
>>                ;; Hide the punctuation at the end, too.
>>                (skip-chars-backward " \t,")
>
> Why is the `overlay-put' at a different place than the
> former Info-insert-breadcrumbs?

The overlay doesn't correctly interact with the `invisible' text property.
However, we can put 'invisible on the overlay instead of the text property:

    (let ((ov (make-overlay (point-min) (1+ header-end))))
      (overlay-put ov 'invisible t)
      (overlay-put ov 'after-string (Info-breadcrumbs))
      (overlay-put ov 'evaporate t))

> PS: the rest of the patch looks OK, so if you can fix the above
> feel free to install it.

I'll give this patch more testing before installing:

=== modified file 'lisp/info.el'
--- lisp/info.el	2010-03-03 19:23:20 +0000
+++ lisp/info.el	2010-04-05 16:48:03 +0000
@@ -1053,8 +1053,8 @@ (defun Info-find-node-2 (filename nodena
 	    (Info-select-node)
 	    (goto-char (point-min))
 	    (forward-line 1)		       ; skip header line
-	    (when (> Info-breadcrumbs-depth 0) ; skip breadcrumbs line
-	      (forward-line 1))
+	    ;; (when (> Info-breadcrumbs-depth 0) ; skip breadcrumbs line
+	    ;;   (forward-line 1))
 
 	    (cond (anchorpos
                    (let ((new-history (list Info-current-file
@@ -3551,6 +3551,19 @@ (defun Info-try-follow-nearest-node (&op
      ((setq node (Info-get-token (point) "Prev: " "Prev: \\([^,\n\t]*\\)"))
       (Info-goto-node node fork)))
     node))
+
+(defun Info-mouse-follow-link (click)
+  "Follow a link under point."
+  (interactive "e")
+  (let* ((position (event-start click))
+	 (posn-string (and position (posn-string position)))
+	 (string (car-safe posn-string))
+	 (string-pos (cdr-safe posn-string))
+	 (link-args (and string string-pos
+			 (get-text-property string-pos 'link-args string))))
+    (when link-args
+      (Info-goto-node link-args))))
+
 \f
 (defvar Info-mode-map
   (let ((map (make-keymap)))
@@ -4141,11 +4154,22 @@ (defvar Info-up-link-keymap
     keymap)
   "Keymap to put on the Up link in the text or the header line.")
 
-(defun Info-insert-breadcrumbs ()
+(defvar Info-link-keymap
+  (let ((keymap (make-sparse-keymap)))
+    (define-key keymap [header-line mouse-1] 'Info-mouse-follow-link)
+    (define-key keymap [header-line mouse-2] 'Info-mouse-follow-link)
+    (define-key keymap [header-line down-mouse-1] 'ignore)
+    (define-key keymap [mouse-2] 'Info-mouse-follow-link)
+    (define-key keymap [follow-link] 'mouse-face)
+    keymap)
+  "Keymap to put on the link in the text or the header line.")
+
+(defun Info-breadcrumbs ()
   (let ((nodes (Info-toc-nodes Info-current-file))
 	(node Info-current-node)
         (crumbs ())
-        (depth Info-breadcrumbs-depth))
+        (depth Info-breadcrumbs-depth)
+	line)
 
     ;; Get ancestors from the cached parent-children node info
     (while (and (not (equal "Top" node)) (> depth 0))
@@ -4172,15 +4196,26 @@ (defun Info-insert-breadcrumbs ()
 			     (file-name-nondirectory Info-current-file)
 			   ;; Some legacy code can still use a symbol.
 			   Info-current-file)))))
-	  (insert (if (bolp) "" " > ")
-		  (cond
-		   ((null node) "...")
-		   ((equal node Info-current-node)
-		    ;; No point linking to ourselves.
-		    (propertize text 'font-lock-face 'info-header-node))
-		   (t
-		    (concat "*Note " text "::"))))))
-      (insert "\n"))))
+	  (setq line (concat
+		      line
+		      (if (null line) "" " > ")
+		      (cond
+		       ((null node) "...")
+		       ((equal node Info-current-node)
+			;; No point linking to ourselves.
+			(propertize text 'font-lock-face 'info-header-node))
+		       (t
+			(propertize text
+				    'mouse-face 'highlight
+				    'font-lock-face 'info-header-xref
+				    'help-echo "mouse-2: Go to node"
+				    'keymap Info-link-keymap
+				    'link-args text)
+			))))))
+      (setq line (concat line "\n")))
+    (font-lock-append-text-property 0 (length line)
+				    'font-lock-face 'header-line line)
+    line))
 
 (defun Info-fontify-node ()
   "Fontify the node."
@@ -4227,8 +4262,8 @@ (defun Info-fontify-node ()
 		((string-equal (downcase tag) "next") Info-next-link-keymap)
 		((string-equal (downcase tag) "up"  ) Info-up-link-keymap))))))
 
-        (when (> Info-breadcrumbs-depth 0)
-          (Info-insert-breadcrumbs))
+        ;; (when (> Info-breadcrumbs-depth 0)
+        ;;   (insert (Info-breadcrumbs)))
 
         ;; Treat header line.
         (when Info-use-header-line
@@ -4260,7 +4295,10 @@ (defun Info-fontify-node ()
             ;; that is in the header, if it is just part.
             (cond
              ((> Info-breadcrumbs-depth 0)
-              (put-text-property (point-min) (1+ header-end) 'invisible t))
+	      (let ((ov (make-overlay (point-min) (1+ header-end))))
+		(overlay-put ov 'invisible t)
+		(overlay-put ov 'after-string (Info-breadcrumbs))
+		(overlay-put ov 'evaporate t)))
              ((not (bobp))
               ;; Hide the punctuation at the end, too.
               (skip-chars-backward " \t,")

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Stefan Monnier]

> I think both types of navigation links (breadcrumbs and up/next/prev)
> should be treated equally.  If we'll implement clicking with the keyboard
> and copy&paste in Emacs-24, it would be natural to apply this to the
> up/next/prev links as well and change their visual appearance.

The up/prev/next links are different because we don't want them to
scroll with the text.  I.e. we're willing to give up on keyboard-clicking
and copy&pasting to be able to use the header-line.

Maybe we'd want to put the breadcrumbs in the header-line as well, but
that would require 2 lines of header-line and I'm not sure I'd be in
favor of such a change (especially as computer displays tend to get
less and less tall nowadays, for reasons that escape me).

> In any case, it's important that the visual appearance should match the
> user's expectation.  When the visual appearance of breadcrumbs is
> the same as for the rest text of the Info buffer, users will be tempted
> to use the keyboard on breadcrumbs.

I think it's OK: it is a misfeature, so it's normal for people to
complain about them.  Let's not pretend it's a feature when it's not.
Or to reverse your argument: if it looks like a header-line, people will
report bugs about the fact that it doesn't stay at the top of the
display ;-)
I.e. in any case it won't match all the user's expectations and I don't
think this argument will give us a good basis on which to make a decision.

> The overlay doesn't correctly interact with the `invisible'
> text property.

Interesting.  That deserves a comment.

> However, we can put 'invisible on the overlay instead of the text property:
>     (let ((ov (make-overlay (point-min) (1+ header-end))))
>       (overlay-put ov 'invisible t)
>       (overlay-put ov 'after-string (Info-breadcrumbs))
>       (overlay-put ov 'evaporate t))

Yes, that's better, thank you.


        Stefan

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

> Or to reverse your argument: if it looks like a header-line, people will
> report bugs about the fact that it doesn't stay at the top of the
> display ;-)

Yeah, breadcrumbs now are not normal links and not a header-line.
But it's OK because when up/next/prev links are not in the header line
(when `Info-use-header-line' is nil) then TAB (`Info-next-reference')
doesn't go through up/next/prev links.  In this regard, they are like
breadcrumbs in an overlay.  There is one difference: it's possible
to type RET on up/next/prev in this case, but I think no one navigates
this way with the keyboard because it's too slow to move point
to a navigation link to type RET on it.

>> The overlay doesn't correctly interact with the `invisible'
>> text property.
>
> Interesting.  That deserves a comment.

Actually, nothing interesting because I meant that with the `invisible'
text property any overlay inside it becomes invisible, and there is no
other free place to put overlay on.

>> However, we can put 'invisible on the overlay instead of the text property:
>>     (let ((ov (make-overlay (point-min) (1+ header-end))))
>>       (overlay-put ov 'invisible t)
>>       (overlay-put ov 'after-string (Info-breadcrumbs))
>>       (overlay-put ov 'evaporate t))
>
> Yes, that's better, thank you.

Installed to the emacs-23 branch (with code for grey background commented out).

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Juri Linkov]

> I was talking about fixing this on the trunk.  For Emacs 23.2, I
> indeed think we should turn off this feature by default.

I'm going to install this on the `emacs-23' branch if there are no objections:

=== modified file 'lisp/info.el'
--- lisp/info.el	2010-03-03 19:23:20 +0000
+++ lisp/info.el	2010-04-01 20:57:33 +0000
@@ -235,7 +235,7 @@ (defcustom Info-refill-paragraphs nil
   :type 'boolean
   :group 'info)
 
-(defcustom Info-breadcrumbs-depth 4
+(defcustom Info-breadcrumbs-depth 0
   "Depth of breadcrumbs to display.
 0 means do not display breadcrumbs."
   :type 'integer)

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

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Stefan Monnier]

>> I was talking about fixing this on the trunk.  For Emacs 23.2, I
>> indeed think we should turn off this feature by default.
> I'm going to install this on the `emacs-23' branch if there are no
> objections:

That won't fix the bug, only hide it.


        Stefan

bug#5809: 23.1.94; cross-reference by anchor yields in accurate position

[Chong Yidong]

> Installed to the emacs-23 branch (with code for grey background
> commented out).

Thanks.