Bugzilla – Full Text Bug Listing
| Summary: | [Workbench] Extension-Point for HyperlinkDetectors | ||
|---|---|---|---|
| Product: | [Eclipse Project] Platform | Reporter: | Eugene Kuleshov <ekuleshov> |
| Component: | UI | Assignee: | Kevin McGuire <Kevin_McGuire> |
| Status: | RESOLVED INVALID | QA Contact: | |
| Severity: | enhancement | ||
| Priority: | P3 | CC: | bokowski, daniel_megert, eclipse, for.work.things, gunnar, Kevin_McGuire, loskutov, Michael.Valenta, mik.kersten, Mike_Wilson, pombredanne, remy.suen, robert.elves, wmitsuda |
| Version: | 3.2 | ||
| Target Milestone: | --- | ||
| Hardware: | PC | ||
| OS: | All | ||
| Whiteboard: | |||
| Bug Depends on: | |||
| Bug Blocks: | 88293, 153932 | ||
|
Description
Eugene Kuleshov
Kevin, Boris, can you comment on this please? Alse see Daniel's comments and speculations: https://bugs.eclipse.org/bugs/show_bug.cgi?id=88293#c47 https://bugs.eclipse.org/bugs/show_bug.cgi?id=88293#c53 Any news on this? Eugene has put a bunch of work into this that we would all benefit from, but I think that he's currently blocked by this bug. I did not have time yet to look at this more closely. To me, it does not seem like a good idea to let everybody contribute code that needs to run on every keypress in an editor. Would it be sufficient to have contributed patterns (e.g. bug [0-9]*) and then once these patterns match, some contributed code is called when the link is clicked? I guess I am asking for a high-level description of the problem that someone who doesn't know much about Platform/Text can understand. Here's a quick try at a high-level description. It assumes that this is done via the current hyperlink detectors support, but it could potentially be done via contributing patterns that are resolved by the API in order to make it safer. Making textual references to structured elements is an important part of the Eclipse UI because it makes it possible to open those elements without having to search for them or navigate deeply tree views. Examples of where this is working well is the Console's hyperlinking of Java stack elements, and the Java editor's @see tags. An example of where this kind of hyperlinking behavior has been extended is Mylar's task editor, which hyperlinks both Java elements and "bug 123" references. However, currently Platform's extensibiltiy is insufficient to make this support surface consistently in the SDK and be extensible by 3rd parties: * Hyperlink detectors can not be contributed to editors such as the Java editor. For example, Mylar's "bug 123" detector should work for Java comments. * Hyperlink detectors can not be contributed to non workbench editor text viewers and editors that show structured elements. For example, Mylar's "bug 123" detector should work in history view comments. (In reply to comment #3) > I did not have time yet to look at this more closely. > > To me, it does not seem like a good idea to let everybody contribute code that > needs to run on every keypress in an editor. > > Would it be sufficient to have contributed patterns (e.g. bug [0-9]*) and then > once these patterns match, some contributed code is called when the link is > clicked? The problem with this kind of pattern is that some detecors need to have different matching patterns depends on edited or linked resource. So, jira task for project foo will have pattern "FOO-[0-9]*" and task for project bar will have pattern "BAR-[0-9]". So, that should work in CVS/SVN History view, in Commit comments (those are linked trough resources) and in the Editors. That is why I choose to delegate thi kind of logic to the detector as opposed to contribute patterns back to platform. > Hyperlink detectors can not be contributed to editors such as the Java > editor. For example, Mylar's "bug 123" detector should work for Java comments. > But what about Bugzilla's "bug 123" detector? What about when specific editors want their own interpretation of that string? I see potential for this to grow into another complex framework for managing overlapping, conflicting contributions... and that would make me very unhappy. >* Hyperlink detectors can not be contributed to editors such as the Java >editor. For example, Mylar's "bug 123" detector should work for Java comments. Mik, as you probably know this is covered and committed for 3.3 as bug 88293. (In reply to comment #6) > But what about Bugzilla's "bug 123" detector? What about when specific editors > want their own interpretation of that string? I see potential for this to grow > into another complex framework for managing overlapping, conflicting > contributions... and that would make me very unhappy. By the way, my initial interest and the reason I put effort contributing to bug 88293 is to enable hyperlinking for comments in Team/History view. See bug 153932 I apologize for not getting to this earlier. Boris and I chatted about this bug last Friday. I understand why this feature would be very cool. Being able to tie the content in one view/editor via hyperlinks to other contributed views, through third party interpretation of the source, is very powerful. However, I have some general concerns: 1. How to make it performant? Both Mike and Boris have commented on this and I share the concern. What we can't have is that every source view gets interpreted by every helpful hyperlink extender because this creates an unbounded performance problem. Basically, JDT text browsing can suddenly slow down due to someone else's hyperlink code. Thus I understood Boris' question as, "Can we pull out some kind of declarative description of the links, whose code runs as part of the platform, so that we can bound the computational cost?". The answer from the other posts seems to be "no". I believe such a declarative approach is necessary (but not sufficient) for this support to be feasable. 2. How to make the experience predictable and reasonable? Mike touched on this. I am puzzled by the situation where two different hyperlink extenders link-ify the same piece of text. What happens when you click on it? Get a popup with the different links? What happens if an expression gets linked by one extender, and the individual words by another? An extreme fail case is where the total of the multiple extenders results in every word being considered a link by someone. I will concede however that we already struggled with similar dynamics with decorators, where third party extenders get to run code and attach UI information on existing artifacts. Lessons learned is that the code must run in a background thread and thus the user cannot be reliant on the decorators being present (they act more like hints). But this is not the case with links. (In reply to comment #5) > The problem with this kind of pattern is that some detecors need to have > different matching patterns depends on edited or linked resource. So, jira task > for project foo will have pattern "FOO-[0-9]*" and task for project bar will > have pattern "BAR-[0-9]". What is wrong with referring to issues of other projects from within a project? Shouldn't the pattern for Jira tasks therefore be "[A-Z]+-[0-9]+"? Do you have other examples where a simple pattern match would not work? What about something like: $PROJECT_NAME-[0-9]* Currently on Mylar we do not have a use case that can't be handled by a regexp pattern (Eugene: please holler if there's something you have in mind). And the need to bound the matching computation sounds very reasonable to me. So, what if this were supported with something like an IHyperlinkPattern class that has a method like getPatternRule(), and a mechanism for binding IHyperlink's to to the pattern. It's possible that this could also be done purely as an extension point where you specify the regexp/pattern, hyperlink class, and text content type / region that it should work for. Then Platform/Text is responsible for the coloring (i.e. making links text blue), and the nice thing is that it all happens in one safe place. Then clients like Mylar have no need to implement their own scanner and separate damage/repair and hyperlinking code as we're stuck with now. Regarding multiple patterns matching different hyperlinks, I do think that this is an important use case. For example, if Mylar sees a fully URL link to a bug in our Task Editor (instead of "bug 123"), and the corresponding task is in the user's Task List, it needs to be able to open that task with the Task Editor by default. The same thing should work in the History view. Here's an idea for a generic UI that avoids the problem of having one detector declare itself as the "default": * If single detector for a region hyperlink left-click opens link (as it does now) * If multiple detectors left-click for a region opens an in-place menu with an item for each detector, e.g. Just fixed bug 123 [Open with Web Browser] [Open with Task Editor] [Add to Bookmarks] [Choose default hyperlink behavior...] * That last item allows the user to select the default detector for left-click. Right-click can always add the "Choose default.." item to the popup menu, or this menu can be forced to pop up when a modifier is pressed. Or the menu can pop as a tooltip-style hover. This UI is somewhat similar to Microsoft's Smart Tags, but in my opinion lighter-weight and involving fewer clicks. I discussed it some on bug 88293 and showed Tom Eicher some mockups at EclipseCon because I think it could also be useful in the Java Editor. >Then Platform/Text is responsible for the coloring (i.e. making links text
>blue), and the nice thing is that it all happens in one safe place.
Note that this would work for all text "fields" that use a source viewer but not when normal Text, Combo or other widgets are used. However, I am against a general mechanism that contributes all registered hyperlink detectors to all source viewers without the user having any control over it. At the end every single word in the editor and CVS commit dialog will be hyperlinked (probably with more than one detector) which makes the feature useless if it can't be controlled by the user.
(In reply to comment #13) > Note that this would work for all text "fields" that use a source viewer but > not when normal Text, Combo or other widgets are used. However, I am against a > general mechanism that contributes all registered hyperlink detectors to all > source viewers without the user having any control over it. At the end every > single word in the editor and CVS commit dialog will be hyperlinked (probably > with more than one detector) which makes the feature useless if it can't be > controlled by the user. It wasn't been suggested to automatically add detectors everywhere. On the other hand, I don't see why platform should make that impossible to do. Maybe that is what users wanted... By the way, I wonder how multiline patterns would work. E.g. "bug\n123". In my experience Java regexps are quite bad when multiline is enabled. So, it does not guarantee you anything about performance and you can get into indefinite recursion if somebody will register a broken pattern. Given that, I'd suggest to leave responsibity on performance constraints to the specific detector implementations. This is probably similar to completion and quickfixes proposals. (In reply to comment #10) > What is wrong with referring to issues of other projects from within a project? > Shouldn't the pattern for Jira tasks therefore be "[A-Z]+-[0-9]+"? > Do you have other examples where a simple pattern match would not work? Please note that we may have two projects in the workspace that are using different Jira servers, but project names in Jira could be the same, e.g. both SPR-[0-9]+. So, we do need to know resource, so detector could establish a correct link between resource/project and issue tracking system server. Mylar already maintain this linking between projects and issue tracking systems. I hope that will be extended in the future and we wull be able to pull information about this linking from Maven's metadata. > This is probably similar to completion
Yes and that's why
- we detect and inform the user when a processor generates an exception
and give the user a link to the preferences where he can disable the bad guy
- we measure time and warn the user when a processor takes too long
and give the user a link to the preference where he can disable the bad guy
This is already hard when constraint to a specific editor and/or content but I
wonder how to do that for any given client which can have totally different
kind of content (CVS commit comment, Java source, a novella, etc.). Also, I
might want to disable some hyperlink detector for CVS comments but not when
writing Java source.
(In reply to comment #17) > Also, I might want to disable some hyperlink detector for CVS comments but not when > writing Java source. I still not entirely sure why you'll need that. Anyways, the patch I submitted does not change the way, how Java editors register its own detectors. And yet it allow to register global detectors that could be picked up by any plugin (if wanted to). E.g. I was going to contribute another patch for bug 153932 that would do that. So, comments in History view would use all globally registered detectors. Just a quick response to Eugene's comment regarding multi-line matches. Assuming that the support allowed the org.eclipse.jface.text.rules.PatternRule to be specified, then this should work fine for MultiLineRule (what we currently use for adding Mylar's Java stack trace hyperlink detector to source viewers). Regarding Danni's points about UI: can't that be addressed very simply by allowing the user to disable a hyperlink 'detector', e.g. by adding a "Configure options..." item to the dialog I propose in comment#12? Such a preference page could also allow the default detector for a pattern to be selected by a user. It seems in keeping with the good stuff you guys have done with content assist, and similarly the user could be prompted for disablement if detectors misbehave (e.g. take more than x millis to return). Regarding extensibility, I think what's important is for a 3rd party to be able to contribute a detector to source viewers without that source viewer needing to be modified, because a 3rd party can present more structure to link to than the viewer itself (e.g., Mylar needs to add a detector to the History view's comments viewer). That doesn't mean that all detectors have to apply to all source viewers, just that we need some extensibility mechanism to support this. (In reply to comment #19) > Regarding Danni's points about UI: can't that be addressed very simply by > allowing the user to disable a hyperlink 'detector', ... > Regarding extensibility, I think what's important is for a 3rd party to be able > to contribute a detector to source viewers without that source viewer needing > to be modified, because a 3rd party can present more structure to link to than > the viewer itself (e.g., Mylar needs to add a detector to the History view's > comments viewer). That doesn't mean that all detectors have to apply to all > source viewers, just that we need some extensibility mechanism to support this. I agree with Danni's comments that we can't just attach hyperlinking to every place text shows up. Its not enough that the user be able to turn it off; it has to be usable to start with. This may mean that the converse would have to happen; that you (the user) only get the support if you explicitly enable it, or if the specific views were identified apriori by Mylar/whoever as being linked sources. Its this problem we see often in Eclipse that nobody can or wants to know about anybody. Specifically, using Mylar as an expample: - the viewer/editor can't know about Mylar because it pre-exists Mylar (e.g. JDT source editor) - Mylar can't know about all the places that linkable source can show up because they don't know the environment its being used in. This leaves the poor user to sort it out, which drives up the complexity of their experience. Thus as a general approach, you'd need to make sure that something reasonable happens out of the box. Perhaps Mylar *does* know and identify a specific set of editors and views to have link support, with others added via preference if the user felt there was benefit. I think I would expect that to be in the Mylar prefences, not in a general preference page of "which controls should support which kinds of link interpreters", the latter being somewhat obtuse for most users. With respect to performance, I am uncomfortable putting in support that potentially slows down existing work patterns. That is, there should be zero cost to my Java editing experience because I happen to have Mylar plugins. If however I turn on "Mylar linking" then I suppose I am also accepting the fact that other things get slower, but then we'll need a heap of code as Danni points out to protect against exceptions in extenders, to report poor performance, etc. (ie. so you know who "did ya"). If nothing else this is important so that when a performance issue is reported, its clearer which component to report the bug against. Can somebody clarify for me if that regexp contribution going to be added statically or API will be to request regexps from hyperlink detectors for each new resource? I don't think 1st option would perform any better then allowing detector to parse text on his own, because you may end up with hundrets of regexps (e.g. source forge, codehaus and java.net have lots of projects)... (In reply to comment #20) > I agree with Danni's comments that we can't just attach hyperlinking to every > place text shows up. Its not enough that the user be able to turn it off; it > has to be usable to start with. This may mean that the converse would have to > happen; that you (the user) only get the support if you explicitly enable it, > or if the specific views were identified apriori by Mylar/whoever as being > linked sources. That is the thing. I wasn't proposing to add detectors everywhere. First of all we need a registry for those global detectors, then components could pull and apply detectors from that registry where it makes sense. See bug 153932 for example... >Regarding comment 19: >Such a >preference page could also allow the default detector for a pattern to be >selected by a user. And that default one is the same for JDT, CDT, and writing novellas? I doubt. Regarding comment 18: >Anyways, the patch I submitted does not change the way, how Java editors >register its own detectors. Correct, but - because the Java editor ignores the extension-point with your patch, BUT bug 88293 was filed exactly for that reason - it modifies all other clients (e.g a CDT or Ant editor) that use a simple source viewer configuration - I know you want ;-) that, but... Platform Text's SourceViewerConfiguration would never install a global contribution out of the box to all clients read out from the extension-point provided by this bug. >And yet it allow to register global detectors that >could be picked up by any plugin (if wanted to) The "if want to" is the point: with your patch it was the other way around i.e. all existing clients automatically get global contributions even if they do not want it. I can live with an enhanced version of what I outlined in bug 88293, comment 47: the client's adapter could tell whether it allows global (probably pattern based) detectors hyperlink. re comment 22: >That is the thing. I wasn't proposing to add detectors everywhere. but that is exactly what your patch in bug 88293 does and what you express in bug 88293: > That is the whole point to get it contributed to all source viewers! Dani, I don't get your point about why it would be bad to have a single page for hyperlink detector prefs, that's exactly how the MS Office Smart Tag preference page works and the UI is very clear, even with a 1/2 dozen 3rd party contributions showing up on the prefs page. They call their detectors "Recognizers", they get installed automatically if contributed by an add-in, can be turned of by the user. And their detectors are available in text fields, not just editors. I agree most of Kevin's and Dani's concerns summarized nicely on comment#20. Maybe the result will be good enough if only source viewers that declare themselves as accepting contributed hyperlink detectors get them (safer, but the tradeoff makes for a less extensibility as pointed out by Eugene). I also hope that we all agree that this is important functionality for Platform to provide. If so, I wonder if the best thing to do at this point is for someone from Platform to describe how this should be implemented, and then for us to iterate on that to ensure that we have some mechanism of extending it. >Dani, I don't get your point about why it would be bad to have a single page >for hyperlink detector prefs Do you refer to comment 18? I wasn't talking about the page (having one page to configure it is goodness) but about specifying the default detector for a pattern. OK, I could see the benefit of that simplicity: users just configure which detectors are enabled, and detectors are responsible for communicating to users what they're detecting via their labels, which seems to work fine in the Smart Tag case. The only case I know of that this leaves open is the case of detectors that can do more for hyperlinks (i.e. open the hyperlink target in a rich Eclipse-based editor instead of web browser), and maybe this has to be handled in a similar case to left-ruler annotations, with specialized detectors being allowed to 'overlay' themselves 'over' the default hyperlink detector and become default. If two conflict in this way the users picks the one they want. Right now we're in a weird state where source viewers get the URLHyperlinkDetector, but the mechanism is not extensible (I'm actually not sure if it's possible for a source viewer to disable the URLHyperlinkDetector). Btw, in terms of both infrastructure and UI this is starting to feel similar to the way that the Platform supports Label Decorations, where most views should support them but users can turn them off. In eclipse we currently see two different models for showing hyperlinks: A) Lazy (implicit) links. Example: JDT source editor You use combination of pointer hover and keysequence to discover if a word is a link. B) Eager (explicit) links. Example: Console. The entire source is processed (on fill, on paste, etc) and links get identified and marked-up immediately. Are we talking about (A) or (B) for the proposed extension? It seems like (B). These two approaches have very different performance dynamics. Specifically, because (B) requires all source be processed by every extender to determine if a word/expression is a link, its relatively expensive to do (M x N, where M is source length and N number of extenders). (A) on the other hand is relatively cheap to do because its only when the user performs the hover/key that you check, a check which is limited to the proximity of the pointer (c x N where c is a constant, the text region to be checked, say the line). I would like to make the argument though that (A/lazy) would be an easier sell. Most of the problems we've identified are concerning (B/eager). Having every extension parse the source on fill/append/paste is an MxN performance concern. Solving it with patterns etc. is going to be work to implement. Or say instead there's some kind of timing deadline in the API contract (with odd results of the links not showing because they took to long). Or you look for links and mark them in the background. Etc. Because these are all fairly complex implementations, they are frankly unlikely to actually get implemented. Furthermore, the work involved for a given editor/view to participate is high because fill and paste must now have their contents processed, thus its a bit harder to sell to the editor/view owners. Finally, there is some slight concern that "everything ends up being a link to someone", so we have a sea of links which is ugly and non-performant. For (A), the performance is a lot more tenable. We don't need pattern matching. Instead, the extension points fire only on hover+key, only for that region. If one of the extensions is expensive then that performance problem can be more easely identified. If you never look for links then there is no performance cost. This approach also avoids the "sea of links" problem. (A) can be further optimized if the first extension to detect a link wins (say user has a preference page of all link detectors and can order them, with the native link detector such as JDT in its source editor always first). This also avoids the oddities of overlapping links, two links to different things, etc. The downside to (A) clearly is that the user must learn what might be a link so they know where to try to hover. There's some hunt and peck involved. In JDT source this learning happens quite quickly because most everything is a link. Its not clear for other uses. However, if we thought that regular expressions could've been used to detect links, then humans might also be good at spotting that same pattern (perhaps). I think we are all in agreement that third party links are a cool idea, but at present it doesn't seem we're confident that we have the right technical design. The result might be that nothing happens. (A) is not as slick as (B), but at least you *can* link. Comments? I think "A" is acceptable. Though for small source viewers (like one in history comments) "B" is most likely acceptable as well. From my point of view, that would be implementation details and optimization that should not affect much the decision on design of the extention point, which is already taking way too long (including time spent on bug 88293). From the discussions, A and B are looking like different extension points, so no its not just an implementation detail (e.g A gets a text section and returns a single link, B gets the entire source and returns multiple links). Besides, view and editors writers would need a clear guideline on how to implement their part, so having two solutions which are chosen based on average amount of text content isn't ideal. Wrt. how long this is taking: this "links everywhere" item isn't on our plan. There is a plan item for extending links in text editors, but that's it. We are spending (unallocated) time on this larger topic because there is interest in the community and we think its a cool idea, but we can't proceed without a solid design and contribution from the community. I think that it would be 100x better to have A for 3.3 than to have nothing, and I appreciate the problem of this not having emerged until after the plan. A lot of this came up on bug 88293 before the 3.3 planning, and it seems that this discussion is really about getting a consistent solution to "links in editors", because of the close relation between source viewers and editors. So I guess first we need to settle on Lazy vs. Explicit links? One point against is that only advanced users seem know about Lazy links. For example, in 3.1 had lazy links of "bug 123" in .java comment regions, were forced to pull them in 3.2 (hence bug 88293), nobody complained, and the same users who had the feature are now requesting the linking, not realizing they had it! As another data point, I think an 'advanced' user of Word, and just today I realized that it has Lazy links for all cross references, thanks exploring other UIs in thinking about this bug. Other than discoverability, the other two problems I see with Lazy links are multiple targets (if two do the same thing, should be fine if user can configure which works), and inconsistency with the URLHyperlinkDetector, which gives explicit links to source viewers. On the flipside, we may be able to convince users of try holding Ctrl on anything you want to click, just like we have mostly of convinced them to try hitting Ctrl+space everywhere (although the lightbulb helps there). Also, it sounds like we have better hope of having Lazy links in any source viewer for 3.3? Finally, I assume that this will not preclude Explicit links in the editor, which I think are really important for non-obvious items (i.e. not-Java elements, but 3rd party structured elements such as custom annotations)? (In reply to comment #30) Thanks for the comments Mik. I think that lazy links in the JDT editors "work" because most everything can be a link (it happens to also be a good reason to not make them eager/explicit because everything would be underlined!). So you get to the point where the user just kind of assumes anything could be a link and tries it. Actually I recently made a similar comment about content assist: if it just works most everywhere you don't need to tell the user its available because it's just assumed, sort of part of the platform. Thus the irony is that the more extenders we get who linkify text, the more everything is a potential link, so lazy links become both the better solution (no sea of links) and quite intuitive. > Other than discoverability, the other two problems I see with Lazy links are > multiple targets (if two do the same thing, should be fine if user can > configure which works), That seems the most obvious solution, although I hate having to drop the problem on the user. And while its easy to assume that a global preference is enough, there's always going to be that one guy ... :) I think we are all assuming though that link overlap is improbable in practice. > and inconsistency with the URLHyperlinkDetector, which > gives explicit links to source viewers. Explicit links would still be supported by those who control the content of the editor/viewer. Or is the question whether URLHyperlinkDetector could also be used for the lazy linking support? > Also, it > sounds like we have better hope of having Lazy links in any source viewer for > 3.3? That's certainly my read of the discussion. You know, it just doesn't otherwise feel like we're converging on a solution after (as Eugene will lament <g>) all this discussion. > Finally, I assume that this will not preclude Explicit links in the > editor, which I think are really important for non-obvious items (i.e. not-Java > elements, but 3rd party structured elements such as custom annotations)? If you mean "3rd party explicit links in other's source", then from a technical point of view I don't see it precluding it. However, if lazy links proved good enough most of the time then I am guessing that it'd be tough to motivate the work required. As a way of off-loading trying to off-load the lazy link problem from the user: is it possible/performant to get tooltips for lazy links? That way if the user hovered over something like "bug 123" a tooltip would show and say "Ctrl+click to follow link"? What Microsoft Office 2003 does is the following for a lazy link with tooltips (in 2007 they're the slightly fancier hovers but idnetical): <place it's going to go> (E.g. "current document", or target URL) CTRL + Click to follow link (In reply to comment #31) Kevin, this is not funny at all. It actually painful, because this issue is preventing me as experienced user from saving sime while reviewing code changes. Probably unlike most of Eclipse folks, I have to deal with code from about 10 different projects on a daily basis. So, these hyperlinks would be a real time saver, especially links from history and incoming changes. While latter is almost covered by Mylar, linking had been requested over 1.5 years ago (in bug 88293) and it is still not planned feature... (In reply to comment #32) That remind me another long standing request. Tooltips currently only show single marker per line. There has been request to aggregate all markers within single tooltip... However it is unrelated to this issue. Eugene, I meant "I feel your pain". I'm trying to move the ball forward on this. Such a seeminlgy simple extension has wide reaching implications and requires a tonne of discussion in Eclipse, which sits under a huge world of plugins and products. We *all* wish we could make the process work quicker. But we're making progress! (In reply to comment #32) Mik, doesn't this mean that the extensions would need to fire to discover the links on hover? I'm wondering what the performance would be like since people usually expect hovers to be quite fast/responsive, which may not match us needing to run the link detector extensions. I agree with Kevin that the performance of general hovers will take a hit if the hyperlink detector extensions need to detect hyperlinks during a general hover. There really wouldn't be a difference between hovering and ctrl+hovering except for text decoration. >While >latter is almost covered by Mylar, linking had been requested over 1.5 years >ago (in bug 88293) and it is still not planned feature... Please. Bug 88293 is tagged for 3.3 and on the Text plan. Note that bug 88293 really was filed against JDT editor and also the first patch provided by Mik was only covering that scenario. The problem with the hover is that often there's already other hover info, e.g. Javadoc or problem description, etc. In addition simply dialogs like the commit dialog might no have (or want) hover support installed. Boris and I spent quite a bit of time discussing this, trying to find something that'd balance all the requirements, but we did not reach a conclusion. We are proceeding with text editor extensions (bug #88293) but deferring for the time the "hyperlinks everywhere" version. We still like the idea of more pervasive hyperlink support, we just don't have the cycles to address it right now. From my point of view, i.e. supporting Mylar users, this is unfortunate but not a showstopper. It will be great to have hyperlink extensibility in the editor where we all spend so much of our time. But in my opinion the "hyperlinks everywhere" facilities competing platforms (e.g. Web 2.0, Windows/Office/Vista) are a key part of the high quality interaction that we see on those platforms, have been there for quite a while, and it is a shame that as stated the Eclipse platform will not see this until mid 2008. I can't speak for Eugene but that's a big part of why I have been pushing getting this into the Platform, and it is disappointing to see this go into the RESOLVED LATER bucket instead of getting a future milestone, even if that's beyond 3.3. On Mylar we will continue using the following UI work-arounds. 1) Add the hyperlink support to our own text fields by making them text viewers, continue providing the custom extension point that lets plug-ins add hyperlink detectors. 2) Continue using the form Hyperlink objects that go 'beside' the text areas where applicable (i.e. the UI hack PDE uses for linking things like objectClass*). 3) Contribute popup menu actions to resolve hyperlinks when we can get at the corresponding text or at a viewer element that corresponds to the text (e.g. as we do via "Open Corresponding Task" from History view entries). These have the obvious usability and scalability issues, so if others have better suggestions on how this kind of hyperlinking should be implemented by those extending the 3.3 Platform please post. Kevin, Boris and other folks who in control of planning for this feature. Can you please at least decide what implementation of this feature would be acceptable for you? Since this feature have quite big interest in the community I am sure you will get a decent contribution if you manage to provide basic requirements or acceptance criteria. I think it would be a good step to at least provide a common extension point that would allow plugin providers to contribute their own hyperlink detectors (including global ones). Then it will be up to specific components if they want to use those detectors or not. Also note, that non-editors (i.e. text areas inside views, like history view) usually dealing with quite small text sizes, so it is hard to imagine performance impact for those. There is a plugin that's called "Sunshade" that have a very narrow function like this (regexpes text directly to filename, line#, col#s). Also check bug 164240 - which if not a dupe, would be easy to implement once this enhancement is implemented. Also please look at bug 164241 - given that one will have to match specific regions of text in this enhancement request, it would be rather easy, I presume, to potentially colorize this text to specified colors, background colors, and possibly also text style? I would be a huge boon for developers of applications that typically output megabytes of loglines (while developing, having everything incl DEBUG and TRACE turned on) - if I could colorize all bean instantiations in Spring to yellow-on-black, or the servlet entry line in a webapp to something-on-something, one would much faster be able to find back to where to start actually parsing the output, instead of just skimming.. (There are plenty of perception research that points out that colors "stand out" much much more than shape: Take a field of 20 x 20 'L's. Now find the 6 L's that's upside down. Take another field of 20 x 20 blue 'L's. Now find the 6 red ones. Which way is faster by hundreds of times?) (In reply to comment #39) Thanks for the comments. We do feel this work has cool potential. Your request for requirements for contribution are completely valid. Sorry its taken some time for us to put this together, it required a lot of thought. We’d like to encourage you in this work, but we also need to make clear that our ability to participate at even the design level is going to be pretty limited. We’ll certainly look at designs to give thumbs up/feedback, as well as check patches of course, but won’t be able to participate in an ongoing iterative manner. With respect to us marking this bug “later” rather than tagging it for a specific future release, that’s just a reflection that we’re not able to take on the work in this release, and we don’t plan two releases ahead. It’s not an indication of the perceived value of the work. Here is a strawman for the goals/requirements and expected deliverables of a contribution: Goals ------ We have the following design goals/requirements: 1. User's workflow should not be impacted negatively by the existence of third-party links. That is, the user shouldn’t have to pay the link tax unless I’m actually using them. 2. We recommend lazy linking behaviour to avoid a "sea of links". By “lazy”, we mean that you don’t actually get the link underline/treatment unless you hover over the word. Another way to reveal them may be via a dedicated key sequence. The issue here is the problem of multiple independent plugins which, between them, end up thinking everything is a link. It will be up to individual views to determine how they wish to implement it lazy or not. 3. Detecting links in text must be fast 3a. No eager plug-in activation when “linkafying” text. 3b. When hovering over text to discover if its a link, the underline/cursor change should happen very quickly. 4. What gets to be a link? 4a. Conflicts can occur if two link detectors have link text in common. How is this handled? Does the user get a menu with both, or does one win, say based on ordering in preferences? (We assume latter). 4b. Is link text restricted to just a single word, or can phrases of words be links? If the latter, how do we handle line breaks? 4c. Note going with single word links makes the overlapping link problem a bit easier. 5. Hovering should perform well 5a. One could imagine that hyperlink providers may want to show a "preview" or some other computed information in the hover. Do we consider this a requirement? 5b. If yes, then any kind of preview or descriptive text off the link must be computed quickly. This is because for hover to “work”, timing between hover and hover text is critical. Therefore, for example we shouldn't activate plug-ins to computer hover text since that has an unknowable speed cost. 6. Don't care as much about what happens when you click on the link 6a. This is the point where plug-in would occur in this linking sequence. 7. Proposed solution 7a. We’re expecting its going to be declarative, regular expression based. This ensures the performance for link detection is cheap and bounded. 8. Needs to play well with what Platform/Text is providing as extension/mechanism 8a. Relationship between the two should be clear (developers shouldn’t be faced with two completely different programming models) 8b. We need a good rationale should we end up with two extension points 8c. Dani adds: I would expect Platform Text to be a client of this stuff, similar to decorators. Platform Text needs - an API to query a registry for hyperlinks for e.g. a given content type or editor type (see my comments in bug 88293 - esp. comment 47). - the hyperlink detector needs to get a hint at which region to detect a hyperlink, see IHyperlinkDetector Non-technical ---------------- 1. Would have to be ready well before API freeze. 1a. Specifically, Dani requires a first cut of the API & extension point by end of M4 since he would likely have dependency on it. We could then look at a small number of views supporting in 3.3 with more to follow in subsequent releases. 2. Needs to be validated by another consumer. We’ve always tried to ensure we have a “customer” for our work which isn’t ourselves. In the past when we haven't done that, the designs have suffered. Since this support will be pervasive, this level of external validation is even more critical. 2a. Vetted by a client unrelated to Mylar 2b. Implemented for a representative set of parts of the IDE (e.g., text editors, console, history view) Deliverables --------------- 1. Design 1a. use cases (does not need to be extensive) 1b. extension point 1c. regexp pattern syntax 1d. agreement over which parts of Eclipse will be link-enabled (at least, text editors and console, and one other part to validate design) 2. Implementation of the mechanism 2a. Extension point 2b. API 2c. Pattern matcher implementation 2d. Implementation of hyperlink support for the representative set of parts of the IDE (e.g., text editors, console, history view) 2e. Preference to enable/disable a given link detector (e.g. "Java Type"/"NLS". 2f. Preference to see/configure for which views/editors the detectors will be active. We believe this reflects the types of things we ourselves would’ve worked through if we were doing the work. Let us know if you have any questions. It seems like registry and other infrastructure has been implemented in scope of bug 88293. It doesn't seem like there is any work required for this. (In reply to comment #43) > It seems like registry and other infrastructure has been implemented in scope > of bug 88293. It doesn't seem like there is any work required for this. Closing bug as invalid since nothing to do for this bug. |