Improving content assist sorting to understand Scala-specific concepts
Migrated from http://lampsvn.epfl.ch/trac/scala/ticket/1715
Reporter ijuma
The Eclipse plugin relies on JDT's RelevanceSorter for sorting completion proposals. This does not take into account Scala-specific concepts (see comment:3:ticket:1643 and replies for an example). It's not particularly high priority, but it seems like a good idea to implement one that does.
Miles suggested asking the mailing list for opinions on what's the best way.
For future reference, I had a look and RelevanceSorter relies on CompletionProposalComparator for the actual work.
Reporter ijuma
The Eclipse plugin relies on JDT's RelevanceSorter for sorting completion proposals. This does not take into account Scala-specific concepts (see comment:3:ticket:1643 and replies for an example). It's not particularly high priority, but it seems like a good idea to implement one that does.
Miles suggested asking the mailing list for opinions on what's the best way.
For future reference, I had a look and RelevanceSorter relies on CompletionProposalComparator for the actual work.
Leave a comment
on 2009-02-13 19:17 *
By tracImporter
Trac author: ijuma
I did some investigation and there is a difference between the values in JavaCompletionProposal.fRelevance when JDT is being used versus SDT.
The JDT fills relevant values there so the sorting is done correctly.
SDT on the other hand uses instances of UIPlugin$ProjectImpl$FileImpl$$anon$1 (search for new JavaCompletionProposal in UIPlugin.scala) and the value is always 0. So, even though the same code is used for sorting, different data is supplied and this explains the unsatisfactory results.
I did some investigation and there is a difference between the values in JavaCompletionProposal.fRelevance when JDT is being used versus SDT.
The JDT fills relevant values there so the sorting is done correctly.
SDT on the other hand uses instances of UIPlugin$ProjectImpl$FileImpl$$anon$1 (search for new JavaCompletionProposal in UIPlugin.scala) and the value is always 0. So, even though the same code is used for sorting, different data is supplied and this explains the unsatisfactory results.
Updating tickets (#1000069, #1000195, #1000213, #1000223, #1000006, #1000021, #1000038, #1000048, #1000051, #1000052, #1000075, #1000103, #1000109, #1000115, #1000119, #1000156, #1000186, #1000207, #1000238, #1000262, #1000263, #380, #389, #683, #1238, #1331, #1635, #1645, #1715, #1729, #1744, #1783, #1839, #1869, #1885, #1890, #1902, #1918, #1919, #1924, #1925, #1946, #1964, #1991, #2131, #2233, #2342, #2348, #2408, #2459, #2499, #2523, #2572, #2582, #2602, #2614, #2615, #2675, #2710, #2745, #2763, #2816, #2830, #2834, #2878, #2879, #2887, #2888, #2901, #2911, #2912, #2922, #2937, #2938, #2942, #2951, #2955, #2957, #2961, #2964, #2965, #2974, #2975, #2989, #2990, #3002, #3055, #3070, #3087, #3135, #3139, #3173, #3182, #3184, #3200, #3213, #3214, #3221, #3243, #3251)
on 2011-03-24 17:18 *
By Iulian Dragos
Updating tickets (#1000199, #1000200, #1000201, #1000204, #1000205, #1000209, #1000210, #1000211, #1000212, #1000215, #1000217, #1000218, #1000220, #1000222, #1000226, #1000227, #1000228, #1000230, #1000231, #1000232, #1000233, #1000235, #1000236, #1000237, #1000239, #1000240, #1000241, #1000242, #1000243, #1000244, #1000248, #1000249, #1000252, #1000253, #1000254, #1000255, #1000256, #1000258, #1000259, #1000032, #1000059, #1000062, #1000163, #1000197, #1000216, #1000221, #1000224, #1000121, #1000175, #1000219, #1000251, #1000069, #1000195, #1000213, #1000223, #1000006, #1000021, #1000038, #1000048, #1000051, #1000052, #1000075, #1000103, #1000109, #1000115, #1000119, #1000156, #1000186, #1000207, #1000238, #1000262, #1000263, #380, #389, #683, #1238, #1331, #1635, #1645, #1715, #1729, #1744, #1783, #1839, #1869, #1885, #1890, #1902, #1918, #1919, #1924, #1925, #1946, #1964, #1991, #2131, #2233, #2342, #2348, #2408)
on 2015-03-13 22:15 *
By Simon Schäfer
Version changed from 2.0.0-final-29 to 4.0.0
Milestone changed from Enhancements to -none-