* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position @ 2010-03-31 9:58 Eli Zaretskii 2010-03-31 11:17 ` Eli Zaretskii ` (2 more replies) 0 siblings, 3 replies; 49+ messages in thread From: Eli Zaretskii @ 2010-03-31 9:58 UTC (permalink / raw To: 5809 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) ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-03-31 9:58 bug#5809: 23.1.94; cross-reference by anchor yields in accurate position Eli Zaretskii @ 2010-03-31 11:17 ` Eli Zaretskii 2010-03-31 15:08 ` Juri Linkov 2010-04-25 18:28 ` Chong Yidong 2 siblings, 0 replies; 49+ messages in thread From: Eli Zaretskii @ 2010-03-31 11:17 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 > Date: Wed, 31 Mar 2010 12:58:25 +0300 > From: Eli Zaretskii <eliz@gnu.org> s/in accurate/inaccurate/ Sorry for sloppy typing. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-03-31 9:58 bug#5809: 23.1.94; cross-reference by anchor yields in accurate position Eli Zaretskii 2010-03-31 11:17 ` Eli Zaretskii @ 2010-03-31 15:08 ` Juri Linkov 2010-03-31 15:55 ` Eli Zaretskii 2010-04-25 18:28 ` Chong Yidong 2 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-03-31 15:08 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-03-31 15:08 ` Juri Linkov @ 2010-03-31 15:55 ` Eli Zaretskii 2010-04-01 18:06 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2010-03-31 15:55 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-03-31 15:55 ` Eli Zaretskii @ 2010-04-01 18:06 ` Juri Linkov 2010-04-01 18:13 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-01 18:06 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 >> 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 18:06 ` Juri Linkov @ 2010-04-01 18:13 ` Eli Zaretskii 2010-04-01 18:30 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2010-04-01 18:13 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 18:13 ` Eli Zaretskii @ 2010-04-01 18:30 ` Juri Linkov 2010-04-01 20:22 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-01 18:30 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 >> >> 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 18:30 ` Juri Linkov @ 2010-04-01 20:22 ` Eli Zaretskii 2010-04-01 20:49 ` Eli Zaretskii 2010-04-01 21:09 ` Juri Linkov 0 siblings, 2 replies; 49+ messages in thread From: Eli Zaretskii @ 2010-04-01 20:22 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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? ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 20:22 ` Eli Zaretskii @ 2010-04-01 20:49 ` Eli Zaretskii 2010-04-01 21:10 ` Juri Linkov 2010-04-01 22:16 ` Stefan Monnier 2010-04-01 21:09 ` Juri Linkov 1 sibling, 2 replies; 49+ messages in thread From: Eli Zaretskii @ 2010-04-01 20:49 UTC (permalink / raw To: juri, 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 20:49 ` Eli Zaretskii @ 2010-04-01 21:10 ` Juri Linkov 2010-04-01 22:16 ` Stefan Monnier 1 sibling, 0 replies; 49+ messages in thread From: Juri Linkov @ 2010-04-01 21:10 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 >> 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 20:49 ` Eli Zaretskii 2010-04-01 21:10 ` Juri Linkov @ 2010-04-01 22:16 ` Stefan Monnier 2010-04-02 7:07 ` Eli Zaretskii 2010-04-02 16:14 ` Juri Linkov 1 sibling, 2 replies; 49+ messages in thread From: Stefan Monnier @ 2010-04-01 22:16 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 > 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 22:16 ` Stefan Monnier @ 2010-04-02 7:07 ` Eli Zaretskii 2010-04-02 14:17 ` Drew Adams 2010-04-05 6:38 ` Drew Adams 2010-04-02 16:14 ` Juri Linkov 1 sibling, 2 replies; 49+ messages in thread From: Eli Zaretskii @ 2010-04-02 7:07 UTC (permalink / raw To: Stefan Monnier; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 7:07 ` Eli Zaretskii @ 2010-04-02 14:17 ` Drew Adams 2010-04-02 14:39 ` Eli Zaretskii 2010-04-05 6:38 ` Drew Adams 1 sibling, 1 reply; 49+ messages in thread From: Drew Adams @ 2010-04-02 14:17 UTC (permalink / raw To: 'Eli Zaretskii', 'Stefan Monnier'; +Cc: 5809 > > > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 14:17 ` Drew Adams @ 2010-04-02 14:39 ` Eli Zaretskii 2010-04-02 15:26 ` Drew Adams 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2010-04-02 14:39 UTC (permalink / raw To: Drew Adams; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 14:39 ` Eli Zaretskii @ 2010-04-02 15:26 ` Drew Adams 2010-04-04 20:39 ` Drew Adams 0 siblings, 1 reply; 49+ messages in thread From: Drew Adams @ 2010-04-02 15:26 UTC (permalink / raw To: 'Eli Zaretskii'; +Cc: 5809 > > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 15:26 ` Drew Adams @ 2010-04-04 20:39 ` Drew Adams 2010-04-04 20:47 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Drew Adams @ 2010-04-04 20:39 UTC (permalink / raw To: 'Eli Zaretskii'; +Cc: 5809 > > > 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). ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 20:39 ` Drew Adams @ 2010-04-04 20:47 ` Eli Zaretskii 2010-04-04 22:51 ` Drew Adams 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2010-04-04 20:47 UTC (permalink / raw To: Drew Adams; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 20:47 ` Eli Zaretskii @ 2010-04-04 22:51 ` Drew Adams 2010-04-04 23:58 ` Juri Linkov 2010-04-05 16:45 ` Juri Linkov 0 siblings, 2 replies; 49+ messages in thread From: Drew Adams @ 2010-04-04 22:51 UTC (permalink / raw To: 'Eli Zaretskii'; +Cc: 5809 > > 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). ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 22:51 ` Drew Adams @ 2010-04-04 23:58 ` Juri Linkov 2010-04-05 7:01 ` Drew Adams 2010-04-05 16:45 ` Juri Linkov 1 sibling, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-04 23:58 UTC (permalink / raw To: Drew Adams; +Cc: 5809 > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 23:58 ` Juri Linkov @ 2010-04-05 7:01 ` Drew Adams 2010-04-05 16:42 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Drew Adams @ 2010-04-05 7:01 UTC (permalink / raw To: 'Juri Linkov'; +Cc: 5809 > > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 7:01 ` Drew Adams @ 2010-04-05 16:42 ` Juri Linkov 2010-04-05 20:11 ` Stefan Monnier 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-05 16:42 UTC (permalink / raw To: Drew Adams; +Cc: 5809 > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 16:42 ` Juri Linkov @ 2010-04-05 20:11 ` Stefan Monnier 2010-04-05 23:17 ` Drew Adams 0 siblings, 1 reply; 49+ messages in thread From: Stefan Monnier @ 2010-04-05 20:11 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 >> 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 20:11 ` Stefan Monnier @ 2010-04-05 23:17 ` Drew Adams 2010-04-06 5:49 ` Drew Adams 0 siblings, 1 reply; 49+ messages in thread From: Drew Adams @ 2010-04-05 23:17 UTC (permalink / raw To: 'Stefan Monnier', 'Juri Linkov', 'Eli Zaretskii' Cc: 5809 [-- 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 23:17 ` Drew Adams @ 2010-04-06 5:49 ` Drew Adams 2010-04-06 17:46 ` Drew Adams 0 siblings, 1 reply; 49+ messages in thread From: Drew Adams @ 2010-04-06 5:49 UTC (permalink / raw To: 'Stefan Monnier', 'Juri Linkov', 'Eli Zaretskii' Cc: 5809 > 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). ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-06 5:49 ` Drew Adams @ 2010-04-06 17:46 ` Drew Adams 0 siblings, 0 replies; 49+ messages in thread From: Drew Adams @ 2010-04-06 17:46 UTC (permalink / raw To: 'Stefan Monnier', 'Juri Linkov', 'Eli Zaretskii' Cc: 5809 [-- 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 22:51 ` Drew Adams 2010-04-04 23:58 ` Juri Linkov @ 2010-04-05 16:45 ` Juri Linkov 2010-04-05 17:12 ` Drew Adams 2010-04-05 21:55 ` Eli Zaretskii 1 sibling, 2 replies; 49+ messages in thread From: Juri Linkov @ 2010-04-05 16:45 UTC (permalink / raw To: Drew Adams; +Cc: 5809 > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 16:45 ` Juri Linkov @ 2010-04-05 17:12 ` Drew Adams 2010-04-05 21:55 ` Eli Zaretskii 1 sibling, 0 replies; 49+ messages in thread From: Drew Adams @ 2010-04-05 17:12 UTC (permalink / raw To: 'Juri Linkov'; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 16:45 ` Juri Linkov 2010-04-05 17:12 ` Drew Adams @ 2010-04-05 21:55 ` Eli Zaretskii 1 sibling, 0 replies; 49+ messages in thread From: Eli Zaretskii @ 2010-04-05 21:55 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 7:07 ` Eli Zaretskii 2010-04-02 14:17 ` Drew Adams @ 2010-04-05 6:38 ` Drew Adams 1 sibling, 0 replies; 49+ messages in thread From: Drew Adams @ 2010-04-05 6:38 UTC (permalink / raw To: 'Eli Zaretskii', 'Stefan Monnier'; +Cc: 5809 > > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 22:16 ` Stefan Monnier 2010-04-02 7:07 ` Eli Zaretskii @ 2010-04-02 16:14 ` Juri Linkov 2010-04-02 16:31 ` Drew Adams ` (2 more replies) 1 sibling, 3 replies; 49+ messages in thread From: Juri Linkov @ 2010-04-02 16:14 UTC (permalink / raw To: Stefan Monnier; +Cc: 5809 >> 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 16:14 ` Juri Linkov @ 2010-04-02 16:31 ` Drew Adams 2010-04-02 17:41 ` Eli Zaretskii 2010-04-02 18:01 ` Stefan Monnier 2 siblings, 0 replies; 49+ messages in thread From: Drew Adams @ 2010-04-02 16:31 UTC (permalink / raw To: 'Juri Linkov', 'Stefan Monnier'; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 16:14 ` Juri Linkov 2010-04-02 16:31 ` Drew Adams @ 2010-04-02 17:41 ` Eli Zaretskii 2010-04-02 18:01 ` Stefan Monnier 2 siblings, 0 replies; 49+ messages in thread From: Eli Zaretskii @ 2010-04-02 17:41 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 16:14 ` Juri Linkov 2010-04-02 16:31 ` Drew Adams 2010-04-02 17:41 ` Eli Zaretskii @ 2010-04-02 18:01 ` Stefan Monnier 2010-04-02 23:11 ` Juri Linkov 2 siblings, 1 reply; 49+ messages in thread From: Stefan Monnier @ 2010-04-02 18:01 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 >>> 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 18:01 ` Stefan Monnier @ 2010-04-02 23:11 ` Juri Linkov 2010-04-03 22:04 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-02 23:11 UTC (permalink / raw To: Stefan Monnier; +Cc: 5809 > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-02 23:11 ` Juri Linkov @ 2010-04-03 22:04 ` Juri Linkov 2010-04-04 6:12 ` Eli Zaretskii 2010-04-04 14:31 ` Stefan Monnier 0 siblings, 2 replies; 49+ messages in thread From: Juri Linkov @ 2010-04-03 22:04 UTC (permalink / raw To: Stefan Monnier; +Cc: 5809 >> 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-03 22:04 ` Juri Linkov @ 2010-04-04 6:12 ` Eli Zaretskii 2010-04-04 11:07 ` Juri Linkov 2010-04-04 14:31 ` Stefan Monnier 1 sibling, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2010-04-04 6:12 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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.) ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 6:12 ` Eli Zaretskii @ 2010-04-04 11:07 ` Juri Linkov 2010-04-04 12:12 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-04 11:07 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 >> 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 11:07 ` Juri Linkov @ 2010-04-04 12:12 ` Eli Zaretskii 2010-04-04 23:51 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Eli Zaretskii @ 2010-04-04 12:12 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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'. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 12:12 ` Eli Zaretskii @ 2010-04-04 23:51 ` Juri Linkov 2010-04-05 5:26 ` Eli Zaretskii 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-04 23:51 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 23:51 ` Juri Linkov @ 2010-04-05 5:26 ` Eli Zaretskii 0 siblings, 0 replies; 49+ messages in thread From: Eli Zaretskii @ 2010-04-05 5:26 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-03 22:04 ` Juri Linkov 2010-04-04 6:12 ` Eli Zaretskii @ 2010-04-04 14:31 ` Stefan Monnier 2010-04-04 23:52 ` Juri Linkov 1 sibling, 1 reply; 49+ messages in thread From: Stefan Monnier @ 2010-04-04 14:31 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 14:31 ` Stefan Monnier @ 2010-04-04 23:52 ` Juri Linkov 2010-04-05 2:06 ` Stefan Monnier 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-04 23:52 UTC (permalink / raw To: Stefan Monnier; +Cc: 5809 >> 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-04 23:52 ` Juri Linkov @ 2010-04-05 2:06 ` Stefan Monnier 2010-04-05 16:50 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Stefan Monnier @ 2010-04-05 2:06 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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. ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 2:06 ` Stefan Monnier @ 2010-04-05 16:50 ` Juri Linkov 2010-04-05 20:09 ` Stefan Monnier 0 siblings, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-05 16:50 UTC (permalink / raw To: Stefan Monnier; +Cc: 5809 >> 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 16:50 ` Juri Linkov @ 2010-04-05 20:09 ` Stefan Monnier 2010-04-05 22:17 ` Juri Linkov 0 siblings, 1 reply; 49+ messages in thread From: Stefan Monnier @ 2010-04-05 20:09 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 > 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-05 20:09 ` Stefan Monnier @ 2010-04-05 22:17 ` Juri Linkov 0 siblings, 0 replies; 49+ messages in thread From: Juri Linkov @ 2010-04-05 22:17 UTC (permalink / raw To: Stefan Monnier; +Cc: 5809 > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 20:22 ` Eli Zaretskii 2010-04-01 20:49 ` Eli Zaretskii @ 2010-04-01 21:09 ` Juri Linkov 2010-04-02 18:03 ` Stefan Monnier 1 sibling, 1 reply; 49+ messages in thread From: Juri Linkov @ 2010-04-01 21:09 UTC (permalink / raw To: Eli Zaretskii; +Cc: 5809 > 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/ ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-04-01 21:09 ` Juri Linkov @ 2010-04-02 18:03 ` Stefan Monnier 0 siblings, 0 replies; 49+ messages in thread From: Stefan Monnier @ 2010-04-02 18:03 UTC (permalink / raw To: Juri Linkov; +Cc: 5809 >> 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 ^ permalink raw reply [flat|nested] 49+ messages in thread
* bug#5809: 23.1.94; cross-reference by anchor yields in accurate position 2010-03-31 9:58 bug#5809: 23.1.94; cross-reference by anchor yields in accurate position Eli Zaretskii 2010-03-31 11:17 ` Eli Zaretskii 2010-03-31 15:08 ` Juri Linkov @ 2010-04-25 18:28 ` Chong Yidong 2 siblings, 0 replies; 49+ messages in thread From: Chong Yidong @ 2010-04-25 18:28 UTC (permalink / raw To: Juri Linkov; +Cc: 5809-done > Installed to the emacs-23 branch (with code for grey background > commented out). Thanks. ^ permalink raw reply [flat|nested] 49+ messages in thread
end of thread, other threads:[~2010-04-25 18:28 UTC | newest] Thread overview: 49+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2010-03-31 9:58 bug#5809: 23.1.94; cross-reference by anchor yields in accurate position Eli Zaretskii 2010-03-31 11:17 ` Eli Zaretskii 2010-03-31 15:08 ` Juri Linkov 2010-03-31 15:55 ` Eli Zaretskii 2010-04-01 18:06 ` Juri Linkov 2010-04-01 18:13 ` Eli Zaretskii 2010-04-01 18:30 ` Juri Linkov 2010-04-01 20:22 ` Eli Zaretskii 2010-04-01 20:49 ` Eli Zaretskii 2010-04-01 21:10 ` Juri Linkov 2010-04-01 22:16 ` Stefan Monnier 2010-04-02 7:07 ` Eli Zaretskii 2010-04-02 14:17 ` Drew Adams 2010-04-02 14:39 ` Eli Zaretskii 2010-04-02 15:26 ` Drew Adams 2010-04-04 20:39 ` Drew Adams 2010-04-04 20:47 ` Eli Zaretskii 2010-04-04 22:51 ` Drew Adams 2010-04-04 23:58 ` Juri Linkov 2010-04-05 7:01 ` Drew Adams 2010-04-05 16:42 ` Juri Linkov 2010-04-05 20:11 ` Stefan Monnier 2010-04-05 23:17 ` Drew Adams 2010-04-06 5:49 ` Drew Adams 2010-04-06 17:46 ` Drew Adams 2010-04-05 16:45 ` Juri Linkov 2010-04-05 17:12 ` Drew Adams 2010-04-05 21:55 ` Eli Zaretskii 2010-04-05 6:38 ` Drew Adams 2010-04-02 16:14 ` Juri Linkov 2010-04-02 16:31 ` Drew Adams 2010-04-02 17:41 ` Eli Zaretskii 2010-04-02 18:01 ` Stefan Monnier 2010-04-02 23:11 ` Juri Linkov 2010-04-03 22:04 ` Juri Linkov 2010-04-04 6:12 ` Eli Zaretskii 2010-04-04 11:07 ` Juri Linkov 2010-04-04 12:12 ` Eli Zaretskii 2010-04-04 23:51 ` Juri Linkov 2010-04-05 5:26 ` Eli Zaretskii 2010-04-04 14:31 ` Stefan Monnier 2010-04-04 23:52 ` Juri Linkov 2010-04-05 2:06 ` Stefan Monnier 2010-04-05 16:50 ` Juri Linkov 2010-04-05 20:09 ` Stefan Monnier 2010-04-05 22:17 ` Juri Linkov 2010-04-01 21:09 ` Juri Linkov 2010-04-02 18:03 ` Stefan Monnier 2010-04-25 18:28 ` Chong Yidong
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).