Re: breadcrumbs for Info . . . . . .

[Stefan Monnier]

>> I'm not so sure.  The same reasons that might push someone to want to
>> see "*Note <FOO>::" in the main text might push someone to want to see
>> them in the breadcrumbs.  The reasons are typically the someone
>> unclea(r|n) behavior of invisible text when you move cursor around or
>> when you copy&paste it.

> I don't see that (as a) problem, I guess. Could you elaborate? Are you
> talking about someone copying and pasting the breadcrumbs links

Yes, for example.

> (why)?

Because some people work differently than you do.  Why do you think we
have the Info-hide-note-references variable in the first place?

>> I think it's a good feature, so I suggest you go back to the previous
>> version which didn't mess around with Info-hide-note-references, 

> The previous version also messed around with `Info-hide-note-references'.
> Otherwise, you would have seen "See Top > See Foo > See Bar" instead of just
> "Top > Foo > Bar".

Yes, I overlooked that.  I think this part was OK.  It only changes the
way Info-hide-note-references works, but not whether
Info-hide-note-references is obeyed or not.

> The code just ignores `Info-hide-note-references' (values other than
> those that hide), for the first 4 lines of each node.

Yes, and that is the part I don't like.

> You can think of the breadcrumbs line as part of an extended header
> area. (And you might even want to remove the Up link from the header
> now, since it is no longer needed - the breadcrumbs subsume Up.)

It would be nice to merge the two lines; but Info node titles
tend to be longish, so I don't think there's enough room for that.
As for removing "up", it might be a good idea.

In any case we'll want to add a Info-insert-breadcrumbs config var for
people like Thien-Thi.

> It might be cleaner to create and use a new link type that is never
> displayed as "See" or "*Note", but always just as the link
> text. Perhaps that's what you meant, above.

Yes, that's what I meant.  Maybe it could even be just an `insert-text-button'.

> That might be better than simply adopting a rule that *Note within the
> header area is never displayed with text other than the link text.

Yes.

> And there might be additional uses for such a link type, other than
> breadcrumbs - I don't know.

Indeed: there's no reason why the header line links should use
a different mechanism than the breadcrumbs links.

> But it would be more work, and I'm not sure it would be worth it.

I think it would improve the result noticeably.

> In any case, I won't be working on that.  If you want to install the current
> version now (after people test it), and then later try to do what you want,
> that's OK by me.

As I said, the current way it works is acceptable to me, so we can
indeed improve it later on.

>> then rework the code to stay with the 80-columns limit, 

> I did not widen the code. In fact, I made it narrower, in passing, by
> splitting a very long string (via \ at line end).

Yes, I saw that.  I know the info.el code is pretty bad w.r.t
line length.  But that's no excuse for using more than 80 columns in
new code ;-)

> The code I added was
> shorter than the existing lines. Nevertheless, I've shortened all of
> the lines to 80 max, as you asked - see attachment. 

Thank you.  Could you provide it as a patch?

> Personally, I think that's quite silly and makes the code less
> readable. And it is far, far, far, f a r from being a convention that
> is followed in the Emacs sources. (And I don't see you insisting on it
> whenever changes are made.) Many files are ridiculously wide. Have fun
> condensing them all to illegibleness. 

I often make changes like that to a file to bring it back within
80 columns.  BTW, w.r.t readability, a better way to make it fit in 80
columns is to move your breadcrumbs code into its own function (that
will give you an extra 8 columns).  Actually, it'd be a good change
(the Info-fontify-node function needs a lot of such splitting) which
would obviate the need for the "Add breadcrumbs" comment.

> Better to concentrate on factoring code and creating helper functions, to
> shorten some of the tome-length monster functions. That would have the side
> effect of shortening line lengths AND produce readable code. IMO, that is a
> better cleanup goal than simply shortening lines.

Of course: long lines are generally a symptom.
I'm glad we agree.


        Stefan