GNU bug report logs - #5809
23.1.94; cross-reference by anchor yields in accurate position

Previous Next

Package: emacs;

Reported by: Eli Zaretskii <eliz <at> gnu.org>

Date: Wed, 31 Mar 2010 10:00:03 UTC

Severity: normal

Done: Chong Yidong <cyd <at> stupidchicken.com>

Bug is archived. No further changes may be made.

Full log


Message #128 received at 5809 <at> debbugs.gnu.org (full text, mbox):

From: Stefan Monnier <monnier <at> iro.umontreal.ca>
To: Juri Linkov <juri <at> jurta.org>
Cc: 5809 <at> debbugs.gnu.org
Subject: Re: bug#5809: 23.1.94;
	cross-reference by anchor yields in accurate position
Date: Mon, 05 Apr 2010 16:09:00 -0400
> 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




This bug report was last modified 15 years and 89 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.