* hyperlinks in variable's value - links to libraries @ 2006-01-01 21:19 Drew Adams 2006-01-06 3:23 ` Drew Adams 0 siblings, 1 reply; 12+ messages in thread From: Drew Adams @ 2006-01-01 21:19 UTC (permalink / raw) Between April and June 2005, the code in help-fns.el that defines `describe-variable' had this line commented out, with this comment: ;; Hyperlinks in variable's value are quite frequently ;; inappropriate e.g C-h v <RET> features <RET> ;; (help-xref-on-pp from (point)) mea culpa - I think I might have been the one to report the bug that the links in the value of `features' were inappropriate. What I said, however, was that they should instead be links to the libraries, not links to something else that happened to have the same name as a library (which was the "inappropriate" part). In any case, I disagree with the "fix" of commenting out this line - at the least, I would like such links to be an option. In fact, I have a tiny library that does only this: add links to libraries. This is the entire library (below). I'd suggest it or the equivalent as a patch. However, adding such links can be slow, so I would like to see an option for adding links to libraries. Although it can be slow, it is very useful: if you're checking `features', for instance (though this is not the only place such links would appear), you want to know not only if a given library has been loaded, but you (I, at least) sometimes want to then open one of those libraries. IOW, looking at `features' should be an entry point to accessing the features listed. Needless to say, if `describe-variable' is not changed back by uncommenting that line, I'll also need to add a redefinition of `describe-variable' to my little library... ---8<-------------------- ;; REPLACES ORIGINAL IN `help-mode.el'. ;; Buttonizes names of libraries also. ;; To see the effect, try `C-h v features', and click on a library name. ;; (defun help-xref-on-pp (from to) "Add xrefs for symbols in `pp's output between FROM and TO." (if (> (- to from) 5000) nil (with-syntax-table emacs-lisp-mode-syntax-table (save-excursion (save-restriction (narrow-to-region from to) (goto-char (point-min)) (condition-case nil (while (not (eobp)) (cond ((looking-at "\"") (forward-sexp 1)) ((looking-at "#<") (search-forward ">" nil 'move)) ((looking-at "\\(\\(\\sw\\|\\s_\\)+\\)") (let* ((sym (intern-soft (match-string 1))) (type (cond ((fboundp sym) 'help-function) ((or (memq sym '(t nil)) (keywordp sym)) nil) ((and sym (boundp sym)) 'help-variable) ((and sym (locate-library (symbol-name sym))) 'help-library)))) (when type (help-xref-button 1 type sym))) (goto-char (match-end 1))) (t (forward-char 1)))) (error nil))))))) (define-button-type 'help-library :supertype 'help-xref 'help-function #'(lambda (x) (find-library (symbol-name x))) 'help-echo (purecopy "mouse-2, RET: find this library")) ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: hyperlinks in variable's value - links to libraries 2006-01-01 21:19 hyperlinks in variable's value - links to libraries Drew Adams @ 2006-01-06 3:23 ` Drew Adams 2006-01-06 4:44 ` Stefan Monnier 2006-01-06 4:47 ` Nick Roberts 0 siblings, 2 replies; 12+ messages in thread From: Drew Adams @ 2006-01-06 3:23 UTC (permalink / raw) Resending. Shall I assume no one is interested? ;; Hyperlinks in variable's value are quite frequently ;; inappropriate e.g C-h v <RET> features <RET> ;; (help-xref-on-pp from (point)) I disagree with the "fix" of commenting out this line - at the least, I would like such links to be an option. Although it can be slow, it is very useful: looking at `features' should be an entry point to accessing the features listed. ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: hyperlinks in variable's value - links to libraries 2006-01-06 3:23 ` Drew Adams @ 2006-01-06 4:44 ` Stefan Monnier 2006-01-06 9:14 ` Lennart Borgman 2006-01-06 17:10 ` Drew Adams 2006-01-06 4:47 ` Nick Roberts 1 sibling, 2 replies; 12+ messages in thread From: Stefan Monnier @ 2006-01-06 4:44 UTC (permalink / raw) Cc: Emacs-Devel > Resending. Shall I assume no one is interested? > ;; Hyperlinks in variable's value are quite frequently > ;; inappropriate e.g C-h v <RET> features <RET> > ;; (help-xref-on-pp from (point)) > I disagree with the "fix" of commenting out this > line - at the least, I would like such links to be an option. > Although it can be slow, it is very useful: looking at `features' > should be an entry point to accessing the features listed. I originally coded up the help-xref-on-pp feature. I think it was a good feature, except that it didn't work quite right: it sometimes added "spurious" xrefs and other times missed good xrefs. Also it significantly slows down the construction of the *Help* text, so much so that we had to put an arbitrary limit (hard coded at 5000 chars right now) above which the highlighting is disabled. So I added another feature, which is that clicking mouse-2 anywhere in the buffer (not just on a visually announced xref with mouse-face highlight and everything) will try to interpret the symbol under point as a var-name, fun-name, or face-name. This has the advantage of working no matter how large the output is. It also works in the docstrings where the author forgot to mark symbols with `...'. The main disadvantage of course is the lack of visual cue which makes this feature barely known. Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: hyperlinks in variable's value - links to libraries 2006-01-06 4:44 ` Stefan Monnier @ 2006-01-06 9:14 ` Lennart Borgman 2006-01-06 17:10 ` Drew Adams 1 sibling, 0 replies; 12+ messages in thread From: Lennart Borgman @ 2006-01-06 9:14 UTC (permalink / raw) Cc: Drew Adams, Emacs-Devel Stefan Monnier wrote: >So I added another feature, which is that clicking mouse-2 anywhere in the >buffer (not just on a visually announced xref with mouse-face highlight and >everything) will try to interpret the symbol under point as a var-name, >fun-name, or face-name. This has the advantage of working no matter how >large the output is. It also works in the docstrings where the author forgot >to mark symbols with `...'. >The main disadvantage of course is the lack of visual cue which makes this >feature barely known. > > And that it does not work from the keyboard. Could it perhaps be made to work from the keyboard too? ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: hyperlinks in variable's value - links to libraries 2006-01-06 4:44 ` Stefan Monnier 2006-01-06 9:14 ` Lennart Borgman @ 2006-01-06 17:10 ` Drew Adams 2006-01-09 1:35 ` Stefan Monnier 1 sibling, 1 reply; 12+ messages in thread From: Drew Adams @ 2006-01-06 17:10 UTC (permalink / raw) > ;; Hyperlinks in variable's value are quite frequently > ;; inappropriate e.g C-h v <RET> features <RET> > ;; (help-xref-on-pp from (point)) > I disagree with the "fix" of commenting out this > line - at the least, I would like such links to be an option. > Although it can be slow, it is very useful: looking at `features' > should be an entry point to accessing the features listed. I originally coded up the help-xref-on-pp feature. I think it was a good feature, except that it didn't work quite right: it sometimes added "spurious" xrefs and other times missed good xrefs. Yes. And some of the spurious xrefs were library names that were instead linked to descriptions of a variable or function with the same name. Also it significantly slows down the construction of the *Help* text, Definitely. so much so that we had to put an arbitrary limit (hard coded at 5000 chars right now) above which the highlighting is disabled. I think that's not a very good solution (arbitrary limit). See my other message, where I propose adding the links only upon demand. So I added another feature, which is that clicking mouse-2 anywhere in the buffer (not just on a visually announced xref with mouse-face highlight and everything) will try to interpret the symbol under point as a var-name, fun-name, or face-name. This has the advantage of working no matter how large the output is. I don't understand how this helps much. Are you saying that a lot of time was spent actually adding the link faces (i.e. highlighting)? What I was referring to was the time needed to look up the link destinations - in the case of linking to libraries, `locate-library' can take a while. It also works in the docstrings where the author forgot to mark symbols with `...'. The main disadvantage of course is the lack of visual cue which makes this feature barely known. Yes, that usability limitation is pretty important. I think having a `Show Links' button would be a better solution: 1) The user would know (could be informed ahead of time) that the link display might take a moment. 2) The resulting links would be visible (e.g. underlined). ^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: hyperlinks in variable's value - links to libraries 2006-01-06 17:10 ` Drew Adams @ 2006-01-09 1:35 ` Stefan Monnier 0 siblings, 0 replies; 12+ messages in thread From: Stefan Monnier @ 2006-01-09 1:35 UTC (permalink / raw) Cc: Emacs-Devel > So I added another feature, which is that clicking mouse-2 > anywhere in the buffer (not just on a visually announced xref with > mouse-face highlight and everything) will try to interpret the symbol > under point as a var-name, fun-name, or face-name. This has the > advantage of working no matter how large the output is. > I don't understand how this helps much. Are you saying that a lot of time > was spent actually adding the link faces (i.e. highlighting)? What I was > referring to was the time needed to look up the link destinations - in the > case of linking to libraries, `locate-library' can take a while. When you middle-click, there's only one symbol to lookup, so even if it takes "a while" it's instantaneous. OTOH when you have to add xrefs everywhere, you have to look at every single symbol and do the work there. > It also works in the docstrings where the author forgot > to mark symbols with `...'. The main disadvantage of course is the > lack of visual cue which makes this feature barely known. > Yes, that usability limitation is pretty important. I think the lack of keyboard and menu bindings is more important and easier (aka trivial) to fix. Note also that if you're looking at the value of `features' and feel like visiting the library that provide "toto", you may want to simply do M-x find-library RET toto RET. It's not like adding xrefs is crucial, it's just a convenience. Stefan ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: hyperlinks in variable's value - links to libraries 2006-01-06 3:23 ` Drew Adams 2006-01-06 4:44 ` Stefan Monnier @ 2006-01-06 4:47 ` Nick Roberts 2006-01-06 17:10 ` Drew Adams 1 sibling, 1 reply; 12+ messages in thread From: Nick Roberts @ 2006-01-06 4:47 UTC (permalink / raw) Cc: Emacs-Devel > Resending. Shall I assume no one is interested? > > ;; Hyperlinks in variable's value are quite frequently > ;; inappropriate e.g C-h v <RET> features <RET> > ;; (help-xref-on-pp from (point)) > > I disagree with the "fix" of commenting out this > line - at the least, I would like such links to be an option. I commented it out, rather than remove it, in case someone came up with a better solution, not for someone to lobby to revert it. I don't think it was in response to a report you made and `features' was just an example, although I can't remember the others. Many variables like mode-line-format or after-load-list have a lot of underlining, some of which isn't that helpful (a user is hardly likely to want click on concat or user-init-file) and it makes it harder to see what you're looking at. I think its best not to lead users anywhere than up the garden path. The doc strings on the other hand can be more carefully crafted to DTRT. > Although it can be slow, it is very useful: looking at `features' > should be an entry point to accessing the features listed. The links are still available on mouse-2 as help-follow, they're just not underlined or highlighted. Having a help-echo saying "mouse-2, RET: describe this function" while over a feature is not helpful IMO, a hinder-echo you could say. Nick ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: hyperlinks in variable's value - links to libraries 2006-01-06 4:47 ` Nick Roberts @ 2006-01-06 17:10 ` Drew Adams 2006-01-06 22:35 ` Nick Roberts 0 siblings, 1 reply; 12+ messages in thread From: Drew Adams @ 2006-01-06 17:10 UTC (permalink / raw) > ;; Hyperlinks in variable's value are quite frequently > ;; inappropriate e.g C-h v <RET> features <RET> > ;; (help-xref-on-pp from (point)) > > I disagree with the "fix" of commenting out this > line - at the least, I would like such links to be an option. I commented it out, rather than remove it, in case someone came up with a better solution, Good idea. not for someone to lobby to revert it. I'm certainly not lobbying to just revert it. I would like to see: 1. It reverted, so *Help* buffers can once again link users to related source code and object (e.g. variable) descriptions. 2. *Libraries* also be linked, in addition to functions and variables - see the code I sent, as an example. This is especially useful for `C-h v features'. 3. An option be added, so users can skip adding *Help* links to save time, if they like. 4. In addition to #3, a button in *Help* to show links. If the option in #3 were turned off, then the buffer would be displayed without the time-consuming object links (variables, libraries, etc.), but you could still click a `Show Links' button to add the links. IOW, add the links only upon demand. 5. After links have been shown once, the button would change to `Hide Links', to enhance readibility (reduce visual clutter). Once the links have been calculated (`Show Links'), the link info would be kept - it would not be lost via `Hide Links' - so redisplay via `Show Links' would be fast. I'm especially interested in #2. I don't think it was in response to a report you made Maybe you're right. I can't find any message where I mentioned that (and Emacs bug reports don't go through my email client, so I get no copy of the bug-report msg, and I'm too lazy to search the emacs-pretest archive). and `features' was just an example, although I can't remember the others. The other you mentioned (2005-05-17, subject Forward button in help buffer) was `gud-minor-mode'. Many variables like mode-line-format or after-load-list have a lot of underlining, some of which isn't that helpful (a user is hardly likely to want click on concat or user-init-file) and it makes it harder to see what you're looking at. Visual clutter is not a reason to not link things; it is a reason to get rid of visual clutter. The solution to visual overload from underlining when a buffer is mainly links (i.e. link-dense) is to not have the face show that a link is present, but rely on mouseover to show that. If a buffer is truly link-dense, then users discover right away that things are linked, because the mouse is always over a link. But see below - *Help* is not a good candidate for this approach. If I didn't know what `concat' and `user-init-file' are, I might well want to click them to find out. Users are various, with different backgrounds, different needs, interacting in different contexts. I think its best not to lead users anywhere than up the garden path. Meaning? Example? The doc strings on the other hand can be more carefully crafted to DTRT. What's the connection? I want to see the list of features when I use `C-h v features'. How does rewriting the doc string affect the current discussion? > Although it can be slow, it is very useful: looking at `features' > should be an entry point to accessing the features listed. The links are still available on mouse-2 as help-follow, they're just not underlined or highlighted. That would be appropriate if all *Help* buffers were link-dense, so that random mouseover would show users that most things are linked. It's not appropriate for *Help* however, because most *Help* buffers are not link-dense. The main problem, for me, is that library names are not linked to libraries. That is the suggestion I'm making. Having a help-echo saying "mouse-2, RET: describe this function" while over a feature is not helpful IMO, a hinder-echo you could say. I have no stake in help-echoes. I too find them annoying often. A link should be indicated by a face (preferably blue underline), unless the buffer is always link-dense (and especially if the buffer is essentially a list or table). Dired, *grep*, and Buffer List are examples of such link-dense tables - there is no need for a face to indicate links in such buffers. Other buffers, including *Help* and *Info* should show links with a special face (underline). ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: hyperlinks in variable's value - links to libraries 2006-01-06 17:10 ` Drew Adams @ 2006-01-06 22:35 ` Nick Roberts 2006-01-07 1:01 ` Drew Adams 0 siblings, 1 reply; 12+ messages in thread From: Nick Roberts @ 2006-01-06 22:35 UTC (permalink / raw) Cc: Emacs-Devel > I'm certainly not lobbying to just revert it. I would like to see: > > 1. It reverted, so *Help* buffers can once again link users to related > source code and object (e.g. variable) descriptions. > > 2. *Libraries* also be linked, in addition to functions and variables - see > the code I sent, as an example. This is especially useful for `C-h v > features'. It still doesn't know what its looking at. It would link the first match which would in many cases would still be to the function. Also the variable features is a list of features, not libraries e.g text-properties, overlay base64 are provided in bindings.el > 3. An option be added, so users can skip adding *Help* links to save time, > if they like. > > 4. In addition to #3, a button in *Help* to show links. If the option in #3 > were turned off, then the buffer would be displayed without the > time-consuming object links (variables, libraries, etc.), but you could > still click a `Show Links' button to add the links. IOW, add the links only > upon demand. Another option! Another button! The idea is to make it easier, not harder to navigate the links. > 5. After links have been shown once, the button would change to `Hide > Links', to enhance readibility (reduce visual clutter). Once the links have > been calculated (`Show Links'), the link info would be kept - it would not > be lost via `Hide Links' - so redisplay via `Show Links' would be fast. Kept where? The help buffer is generally regenerated through the [back] button. ... > Many variables like mode-line-format or after-load-list have a lot of > underlining, some of which isn't that helpful (a user is hardly > likely to want click on concat or user-init-file) and it makes it > harder to see what you're looking at. > > Visual clutter is not a reason to not link things; it is a reason to get rid > of visual clutter. > > The solution to visual overload from underlining when a buffer is mainly > links (i.e. link-dense) is to not have the face show that a link is present, > but rely on mouseover to show that. If a buffer is truly link-dense, then > users discover right away that things are linked, because the mouse is > always over a link. But see below - *Help* is not a good candidate for this > approach. Sounds too complicated to me. Also confusing to the user who won't understand why the visual cues are changing. > If I didn't know what `concat' and `user-init-file' are, I might well want > to click them to find out. Users are various, with different backgrounds, > different needs, interacting in different contexts. Its a tangent from finding out about after-load-list. > I think its best not to lead users anywhere than up the garden path. > > Meaning? I don't agree with you. > Example? What you are suggesting. > The doc strings on the other hand can be more carefully > crafted to DTRT. > > What's the connection? I want to see the list of features when I use `C-h v > features'. How does rewriting the doc string affect the current discussion? If a link is inappropriate, quotes aren't used in the doc string. Preceding the symbol name with the keyword `variable', 'function' etc ensures that the correct link is made. > > Although it can be slow, it is very useful: looking at `features' > > should be an entry point to accessing the features listed. > > The links are still available on mouse-2 as help-follow, > they're just not underlined or highlighted. > > That would be appropriate if all *Help* buffers were link-dense, so that > random mouseover would show users that most things are linked. It's not > appropriate for *Help* however, because most *Help* buffers are not > link-dense. If the doc strings were marked up for links in the indiscriminate way that variable values are , every `if' and `or' would be linked. Nick ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: hyperlinks in variable's value - links to libraries 2006-01-06 22:35 ` Nick Roberts @ 2006-01-07 1:01 ` Drew Adams 2006-01-07 2:14 ` Nick Roberts 0 siblings, 1 reply; 12+ messages in thread From: Drew Adams @ 2006-01-07 1:01 UTC (permalink / raw) > I'm certainly not lobbying to just revert it. I would like to see: > > 1. It reverted, so *Help* buffers can once again link users > to related source code and object (e.g. variable) descriptions. > > 2. *Libraries* also be linked, in addition to functions and > variables - see the code I sent, as an example. This is > especially useful for `C-h v features'. It still doesn't know what its looking at. It would link the first match which would in many cases would still be to the function. Also the variable features is a list of features, not libraries e.g text-properties, overlay base64 are provided in bindings.el Yes, of course. However, in practice, it works quite well. The problem of multiple names of different types is pretty well handled by ordering (priority) - see the code I sent. The problem of multiple features with different names is not a problem in practice either, because those features simply don't end up with links. Only features that are the names of libraries are linked (to those libraries). That's 99+% of the features, BTW. I've used this for quite a while, and I have yet to notice any problem. Generally, you don't find a mix of other (e.g. variable, function) names with library names. I'd encourage people to just try it, to see whether or not it is worth it. By "worth it", I mean worth adding an option - not forcing people to have links to libraries. > 3. An option be added, so users can skip adding *Help* links > to save time, if they like. > > 4. In addition to #3, a button in *Help* to show links. If > the option in #3 were turned off, then the buffer would be > displayed without the time-consuming object links (variables, > libraries, etc.), but you could still click a `Show Links' > button to add the links. IOW, add the links only upon demand. Another option! Another button! Yes. The idea is to make it easier, not harder Precisely. to navigate the links. Huh? If there are no links, then, it's hardly easier to navigate them (or perhaps it is, vacuously ;-)). Screaming that another option or button complicates things is a fine general argument but a silly argument in any specific context. Just what is made easier by the addition of the links, an option, and a toggle button? Just what is made more difficult by their addition? It's a judgement call, of course. It's worth discussing (weighing), IMO. > 5. After links have been shown once, the button would change to `Hide > Links', to enhance readibility (reduce visual clutter). Once > the links have been calculated (`Show Links'), the link info would be kept > - it would not be lost via `Hide Links' - so redisplay via `Show Links' > would be fast. Kept where? The help buffer is generally regenerated through the [back] button. I think you're confusing caching a *Help* buffer for navigation forward and backward (something I did not propose - but I wouldn't be against it) with what I did propose: retaining the link information in the buffer as displayed - that is, for the same *Help* screen text - across toggling of the `Show/Hide Links' button. There are several ways that could be done. The idea is simply to keep the links and faces there, but disable them (links) and hide them (faces). Navigating to a different *Help* screen (different text) would result in regeneration. The cost for adding links is in calculating the link destinations and creating the text properties or overlays. Once that's done, the links could remain, but their appearance and enabling could be "neutralized", at no added cost. ... > Many variables like mode-line-format or after-load-list > have a lot of underlining, some of which isn't that helpful > (a user is hardly likely to want click on concat or > user-init-file) and it makes it harder to see what you're > looking at. > > Visual clutter is not a reason to not link things; it is a > reason to get rid of visual clutter. > > The solution to visual overload from underlining when a > buffer is mainly links (i.e. link-dense) is to not have the > face show that a link is present, but rely on mouseover to > show that. If a buffer is truly link-dense, then > users discover right away that things are linked, because > the mouse is always over a link. But see below - *Help* is > not a good candidate for this approach. Sounds too complicated to me. Also confusing to the user who won't understand why the visual cues are changing. It's common on Web pages. If your mouse is always over one link or another (e.g. in an image map or a dense table listing), and the mouseover indicates it is a link, you don't need the text to be underlined without mouseover. It may sound complicated to you, but thousands of ordinary folk seem to have no problem with it everyday. It may be complicated to describe, but not to use. > If I didn't know what `concat' and `user-init-file' are, I > might well want to click them to find out. Users are various, > with different backgrounds, different needs, interacting in > different contexts. Its a tangent from finding out about after-load-list. Sorry, I don't follow you at all - I have no idea what you're talking about. > I think its best not to lead users anywhere than up the > garden path. > > Meaning? I don't agree with you. > Example? What you are suggesting. Leading someone down the garden path means leading them astray - deceiving them. How does what I suggest lead users astray? Please state your argument more clearly; I'm not following you. > The doc strings on the other hand can be more carefully > crafted to DTRT. > > What's the connection? I want to see the list of features > when I use `C-h v features'. How does rewriting the doc string > affect the current discussion? If a link is inappropriate, quotes aren't used in the doc string. Are you perhaps saying that it is easier to just identify the terms to be linked as those that are quoted, rather than trying to also link some terms that are not quoted? That's certainly true. I don't know how well the trial of linking variable etc. names worked - I haven't seen problems with it, but I imagine there could be some. Maybe we need to experiment with it more. Preceding the symbol name with the keyword `variable', 'function' etc ensures that the correct link is made. "Ensures"? No. It can help - but you can also get some anomalies with that approach. Trying to insert links automatically in natural-language text is bound to have some hiccups, no matter how it is done - I suppose we agree on that. I haven't seen problems in practice, but I'm sure there would be some. The question is whether such problems would outweigh the benefit. And see below, on stopwords. IIUC, you are mainly discussing ways to implement linking - how to identify the proper text to which to apply a link. I am mainly discussing the value of linking to libraries from their names. Different ways to identify the proper names could be examined. If nothing else, even if it were done as a one-off exception, I would like to see the features that are also library names be linked to their libraries when I do `C-h v features'. The value would be the same as having a link on the library name in a function or variable description. > > Although it can be slow, it is very useful: > > looking at `features' > > should be an entry point to accessing the features listed. > > The links are still available on mouse-2 as help-follow, > they're just not underlined or highlighted. > > That would be appropriate if all *Help* buffers were > link-dense, so that random mouseover would show users that > most things are linked. It's not appropriate for *Help* however, > because most *Help* buffers are not link-dense. If the doc strings were marked up for links in the indiscriminate way that variable values are , every `if' and `or' would be linked. So, have a simple stopwords list. This is by no means an unsurmountable problem. A surprisingly small stoplist filters out most insignificant English words when indexing; the stopwords list for a programming language would be much tinier yet. Plus, I assume that we wouldn't choose to link from more than one occurrence of the same word in the same *Help* buffer. That is, even without a stoplist, only the first `if' and `or' would be linked. And, again, I don't really care that much about linking symbol names other than libraries. Just as you can click the word `abbrev' in "Defined in abbrev" at the end of *Help* for `C-h v abbrev-mode', so I like being able to click a library name in the value displayed by `C-h v features'. There is no "every `if' and `or' would be linked" in that case. ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: hyperlinks in variable's value - links to libraries 2006-01-07 1:01 ` Drew Adams @ 2006-01-07 2:14 ` Nick Roberts 2006-01-07 15:38 ` Drew Adams 0 siblings, 1 reply; 12+ messages in thread From: Nick Roberts @ 2006-01-07 2:14 UTC (permalink / raw) Cc: Emacs-Devel > It still doesn't know what its looking at. It would link the > first match which would in many cases would still be to the > function. Also the variable features is a list of features, > not libraries e.g text-properties, overlay > base64 are provided in bindings.el > > Yes, of course. However, in practice, it works quite well... I don't think it does. > The problem of multiple names of different types is pretty well handled by > ordering (priority) - see the code I sent. When I tried it it linked to a function if there was one, and only to a library if there was no function with the same name. ... > Screaming that another option or button complicates things is a fine general > argument but a silly argument in any specific context. I wasn't screaming but I probably I will end up doing so if I carry on, so I'll stop now. Nick ^ permalink raw reply [flat|nested] 12+ messages in thread
* RE: hyperlinks in variable's value - links to libraries 2006-01-07 2:14 ` Nick Roberts @ 2006-01-07 15:38 ` Drew Adams 0 siblings, 0 replies; 12+ messages in thread From: Drew Adams @ 2006-01-07 15:38 UTC (permalink / raw) > Yes, of course. However, in practice, it works quite well... I don't think it does. > The problem of multiple names of different types is pretty > well handled by ordering (priority) - see the code I sent. When I tried it it linked to a function if there was one, and only to a library if there was no function with the same name. Yes. I found that works well, in practice. The priority could be changed, of course, but a function foo in a library foo is generally a tighter focus, so a better bet on average. This is the way the code already worked, for dealing with function and variable names. I just added library names. As I said, mixes of either function or variable names and library names are uncommon in *Help* buffers. You might get the occasional foo function or variable being linked to, instead of foo library, in the `features' list, but that is not a big problem, because you still end up in the library code (via one more link, "defined in foo"). ^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2006-01-09 1:35 UTC | newest] Thread overview: 12+ messages (download: mbox.gz follow: Atom feed -- links below jump to the message on this page -- 2006-01-01 21:19 hyperlinks in variable's value - links to libraries Drew Adams 2006-01-06 3:23 ` Drew Adams 2006-01-06 4:44 ` Stefan Monnier 2006-01-06 9:14 ` Lennart Borgman 2006-01-06 17:10 ` Drew Adams 2006-01-09 1:35 ` Stefan Monnier 2006-01-06 4:47 ` Nick Roberts 2006-01-06 17:10 ` Drew Adams 2006-01-06 22:35 ` Nick Roberts 2006-01-07 1:01 ` Drew Adams 2006-01-07 2:14 ` Nick Roberts 2006-01-07 15:38 ` Drew Adams
Code repositories for project(s) associated with this external index https://git.savannah.gnu.org/cgit/emacs.git https://git.savannah.gnu.org/cgit/emacs/org-mode.git This is an external index of several public inboxes, see mirroring instructions on how to clone and mirror all data and code used by this external index.