[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: breadcrumbs for Info . . . . . .
From: |
Stefan Monnier |
Subject: |
Re: breadcrumbs for Info . . . . . . |
Date: |
Fri, 13 Jun 2008 09:58:38 -0400 |
User-agent: |
Gnus/5.13 (Gnus v5.13) Emacs/23.0.60 (gnu/linux) |
>> 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
- RE: breadcrumbs for Info . . . . . ., (continued)
- Re: breadcrumbs for Info . . . . . ., Stefan Monnier, 2008/06/13
- RE: breadcrumbs for Info . . . . . ., Drew Adams, 2008/06/13
- Re: breadcrumbs for Info . . . . . ., Stefan Monnier, 2008/06/13
- Re: breadcrumbs for Info . . . . . ., Thien-Thi Nguyen, 2008/06/13
- Re: breadcrumbs for Info . . . . . ., Eli Zaretskii, 2008/06/14
- Re: breadcrumbs for Info . . . . . ., Thien-Thi Nguyen, 2008/06/14
- Re: breadcrumbs for Info . . . . . .,
Stefan Monnier <=
- RE: breadcrumbs for Info . . . . . ., Drew Adams, 2008/06/13
- Re: breadcrumbs for Info . . . . . ., Stefan Monnier, 2008/06/13
- RE: breadcrumbs for Info . . . . . ., Drew Adams, 2008/06/13
- Re: breadcrumbs for Info . . . . . ., Stefan Monnier, 2008/06/13
- RE: breadcrumbs for Info . . . . . ., Drew Adams, 2008/06/14
- Re: breadcrumbs for Info . . . . . ., Stefan Monnier, 2008/06/14
- RE: breadcrumbs for Info . . . . . ., Drew Adams, 2008/06/14
- Re: breadcrumbs for Info . . . . . ., Stefan Monnier, 2008/06/14
- Re: breadcrumbs for Info . . . . . ., Juri Linkov, 2008/06/14
- RE: breadcrumbs for Info . . . . . ., Drew Adams, 2008/06/15