Community
Participate
Working Groups
In 0.2-M4, you can now use URL's such as: http://localhost:8080/coding.html#file=/file/UGEcINDiAB8bJO_Yskwmnw/static/js/e4.js&line=89 http://localhost:8080/coding.html#file=/file/UGEcINDiAB8bJO_Yskwmnw/static/navigate-tree.html&char=4495,4508 These URL formats are inspired by http://en.wikipedia.org/wiki/Fragment_identifier#Proposals http://tools.ietf.org/html/rfc5147 Improvements: - It would be nice to be able to index within a line, such as http://localhost:8080/coding.html#file=/file/UGEcINDiAB8bJO_Yskwmnw/static/js/e4.js&line=88&char=0,5 but I've got some bugs with indexing and some order dependencies and assumptions (that line must appear before char) I need to do a better job of documenting how we handle conflicting parameters in this case. - I did not implement ranges of lines (line=89,92) because we didn't need it yet. - for the outliner, we need to support something like - go to line 88 and highlight the token "foo" on that line. That one is kind of weird, because you need the editor model to figure out which line of text you are on. So the code that constructs the URL would have to pass the token in the hash so that the editor could interpret it. Maybe something like http://localhost:8080/coding.html#file=/file/UGEcINDiAB8bJO_Yskwmnw/static/js/e4.js&line=88&highlight=foo Until this is addressed, the outliner will position you to the right line, but won't highlight the method name as it did before - the same kind of highlight token mentioned above is needed for the search use case: (9:05:21 AM) johnart: susanmccourt: No, Lucene doesn't seem to provide line numbers, I spent a bit of time looking into it but didn't find a solution yet (9:08:08 AM) johnart: Accurate line numbers for search is actually quite a difficult problem. We have a whole framework in eclipse for keeping that data correct as the document changes. A low tech solution would be to just search the individual document when it is opened in the editor. (9:09:35 AM) johnart: For example a google search doesn't give you line numbers, you just have to search within the file after you open it... So we should probably support highlight=foo - with no other params, just highlight the first found (as if a ctrl-f were done on that token) - if a line number is also passed, the match is looked for in the line (the outliner case) - if a char position (or range) is passed, the match is looked for using the range.
(In reply to comment #0) > > So we should probably support > highlight=foo > - with no other params, just highlight the first found (as if a ctrl-f were > done on that token) > - if a line number is also passed, the match is looked for in the line (the > outliner case) > - if a char position (or range) is passed, the match is looked for using the > range. I'd like to get the first case "highlight=foo" working for the June release. As it is now, when you use global search and click on a link, you are unhelpfully placed at the beginning of the file and have to go Ctrl-F yourself. ;-)
Update: we now know the line number of a search hit, so we can now navigate directly to a line from global search. So the biggest pain point in not fixing this bug is now gone. The issue is now one of polish. Both the outliner and the global search results can position you to the correct line, but they do not highlight the token.
Reassigning to inbox. I had this assigned to me so I could fix the "search results don't take you to the right line" problem. The remaining work would be nice but it not as important.
Adding a dependency to bug 358769. I think it would make sense to add the "find next occurrence of token" support to the URL in general way (as a command/parameter combination) than in inventing something in particular.
*** Bug 362717 has been marked as a duplicate of this bug. ***
(In reply to comment #5) > *** Bug 362717 has been marked as a duplicate of this bug. *** I believe the "find next occurrence of token" will trigger the find&replace UI in editor, with your new command framework. But please correct me if otherwise.
Closing as part of a mass clean up of inactive bugs. Please reopen if this problem still occurs or is relevant to you. For more details see: https://dev.eclipse.org/mhonarc/lists/orion-dev/msg03444.html
