From: Stefan Monnier <monnier@IRO.UMontreal.CA>
To: "Drew Adams" <drew.adams@oracle.com>
Cc: 'Juri Linkov' <juri@jurta.org>, emacs-devel@gnu.org
Subject: Re: breadcrumbs for Info . . . . . .
Date: Fri, 13 Jun 2008 09:58:38 -0400 [thread overview]
Message-ID: <jwvprql4fh5.fsf-monnier+emacs@gnu.org> (raw)
In-Reply-To: <002401c8cd1f$98631650$0200a8c0@us.oracle.com> (Drew Adams's message of "Thu, 12 Jun 2008 23:34:55 -0700")
>> 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
next prev parent reply other threads:[~2008-06-13 13:58 UTC|newest]
Thread overview: 41+ messages / expand[flat|nested] mbox.gz Atom feed top
2008-06-10 23:52 breadcrumbs for Info . . . . . Drew Adams
2008-06-11 0:04 ` Juri Linkov
2008-06-11 3:18 ` Drew Adams
2008-06-11 9:34 ` Juri Linkov
2008-06-11 13:46 ` Drew Adams
2008-06-11 18:59 ` Eli Zaretskii
2008-06-11 22:40 ` Juri Linkov
2008-06-12 2:01 ` Miles Bader
2008-06-12 22:42 ` Drew Adams
2008-06-13 3:27 ` Stefan Monnier
2008-06-13 6:34 ` Drew Adams
2008-06-13 8:43 ` Thien-Thi Nguyen
2008-06-13 13:55 ` Drew Adams
2008-06-13 17:17 ` Thien-Thi Nguyen
2008-06-13 17:52 ` Drew Adams
2008-06-13 19:55 ` Thien-Thi Nguyen
2008-06-13 20:10 ` Drew Adams
2008-06-15 18:19 ` Juri Linkov
2008-06-13 14:05 ` Stefan Monnier
2008-06-13 15:12 ` Drew Adams
2008-06-13 17:16 ` Stefan Monnier
2008-06-13 18:32 ` Thien-Thi Nguyen
2008-06-14 9:47 ` Eli Zaretskii
2008-06-14 10:01 ` Thien-Thi Nguyen
2008-06-13 13:58 ` Stefan Monnier [this message]
2008-06-13 15:11 ` Drew Adams
2008-06-13 20:34 ` Stefan Monnier
2008-06-13 22:11 ` Drew Adams
2008-06-13 22:44 ` Stefan Monnier
2008-06-14 9:45 ` Drew Adams
2008-06-14 16:16 ` Stefan Monnier
2008-06-14 17:24 ` Drew Adams
2008-06-14 18:04 ` Stefan Monnier
2008-06-15 0:27 ` Juri Linkov
2008-06-15 7:33 ` Drew Adams
2008-06-15 18:23 ` Juri Linkov
2008-06-15 19:46 ` Drew Adams
2008-06-15 0:28 ` Juri Linkov
2008-06-15 2:04 ` Stefan Monnier
2008-06-15 18:18 ` Juri Linkov
2008-06-15 7:55 ` Drew Adams
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
List information: https://www.gnu.org/software/emacs/
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=jwvprql4fh5.fsf-monnier+emacs@gnu.org \
--to=monnier@iro.umontreal.ca \
--cc=drew.adams@oracle.com \
--cc=emacs-devel@gnu.org \
--cc=juri@jurta.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.savannah.gnu.org/cgit/emacs.git
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).