On Thu, Apr 5, 2012 at 10:56 PM, Chen Cheng <
chengchendoc@xxxxxxxxx> wrote:
> Ok, I will skip the parameters input step. Once user select one target snip
> match item, i add insert the code snip with default parameters into current
> editor.
>
>
> 2012/4/6 Doug Wightman <
douglasw@xxxxxxxxx>
>>
>> I think we should implement it as it is implemented now - but you
>> shouldn't worry about that right now. For now, just get the simply
>> string matching working (ignore parameters - just insert the
>> defaults). As long as you're certain that we _can_ insert parameters
>> that we detect in the search box, then we can work out the rest once
>> GSoC officially starts.
>>
>> The current version of SnipMatch handles this very gracefully:
>> checking if tokens (words) in the search box match local variables and
>> then attempting to match them with the search pattern. But as long as
>> you're certain that we can implement it, I wouldn't worry too much
>> about this right now, it's not the current priority :) I'll step you
>> through it soon (and, fortunately, we've got the tough parts written
>> already!).
>>
>> Doug
>>
>>
>>
>> On Thu, Apr 5, 2012 at 10:28 PM, Chen Cheng <
chengchendoc@xxxxxxxxx>
>> wrote:
>> > Good idea, user input both search string and parameters in search box.
>> > But
>> > there is still a problem, suppose user input "print random number" in
>> > search
>> > box. Which is the target search string, which is the parameter ? How can
>> > we
>> > identify them ?
>> >
>> > May be use this grammar "print random $parameter1", if some words start
>> > with
>> > "$", we consider it as parameter ? If user miss some parameters, we just
>> > insert default parameters for him. Is this OK?
>> >
>> >
>> > 2012/4/5 Doug Wightman <
douglasw@xxxxxxxxx>
>> >>
>> >> Cheng,
>> >>
>> >> I also like the idea of removing that dialog box, so long as doing so
>> >> doesn't cripple the functionality. _If_ parameters are included in the
>> >> search box (rather than entered in the parameter dialog box), will
>> >> they still be used to modify the inserted code?
>> >>
>> >> This might be a reasonable compromise. When parameters aren't
>> >> specified in the search box (e.g. the user types "print" instead of
>> >> "print hello"), it inserts defaults, and those defaults can be
>> >> selected using the Eclipse Templates-style form filling code. However,
>> >> when parameters are included (e.g. "print hello"), the inserted code
>> >> _does_ include them (e.g. System.out.println("hello");). What do you
>> >> think?
>> >>
>> >> Parameters are a critical component of SnipMatch. We wrote a ton of
>> >> code to support parameters (not just strings, also local variables).
>> >> This is one of the major advantages of this system (i.e. significantly
>> >> fewer characters need to be typed).
>> >>
>> >> Doug
>> >>
>> >>
>> >> On Thu, Apr 5, 2012 at 9:23 AM, Chen Cheng <
chengchendoc@xxxxxxxxx>
>> >> wrote:
>> >> > Hi all,
>> >> >
>> >> > We have to decide search result display's parameters solution now.
>> >> > Here
>> >> > is
>> >> > my personally idea:
>> >> >
>> >> > As i am improving the search result display module, want it to be
>> >> > similar
>> >> > with JDT's content assist, but Eclipse content assist does not have
>> >> > any
>> >> > "parameters input" dialog, so i want to remove the parameters dialog
>> >> > in
>> >> > SnipMatch, or it will looks strange, and does not match Eclipse
>> >> > users'
>> >> > habit. Meanwhile:
>> >> >
>> >> > 1. Use default parameter values for inserted code snip, this is how
>> >> > JDT's
>> >> > content assist work. For example, there is such a method in class:
>> >> >
>> >> > public static void test1(int intValue, String str, double
>> >> > doubleValue){
>> >> > //Do anything here
>> >> > }
>> >> >
>> >> > We pop up content assist in main method, we can find method test1 in
>> >> > content
>> >> > assist's list(see attach file a.png), then, if we select test1, it
>> >> > will
>> >> > insert following code into current place:
>> >> >
>> >> > test1(intValue, str, doubleValue)
>> >> >
>> >> > See, JDT's content assist just use default value for the
>> >> > parameters(usually
>> >> > parameters used to define the method), there isn't any parameters
>> >> > input
>> >> > dialog. This is how Eclipse usually does. I think SnipMatch should
>> >> > also
>> >> > follow this rule.
>> >> >
>> >> > 2. The dummy parameters inserted into editor are usually "string"
>> >> > user
>> >> > defined when they create the json format code snip file, but user can
>> >> > change
>> >> > them in code snip edit panel( I will improve SnipMatch's code snip
>> >> > edit
>> >> > panel, this part is in GSoC's proposal).
>> >> >
>> >> > Your ideas ?
>> >> >
>> >> > --
>> >> > Best Regards From Cheng Chen [
chengchendoc@xxxxxxxxx]
>> >> >
>> >> > _______________________________________________
>> >> > recommenders-dev mailing list
>> >> >
recommenders-dev@xxxxxxxxxxx
>> >> >
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>> >> >
>> >> _______________________________________________
>> >> recommenders-dev mailing list
>> >>
recommenders-dev@xxxxxxxxxxx
>> >>
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>> >
>> >
>> >
>> >
>> > --
>> > Best Regards From Cheng Chen [
chengchendoc@xxxxxxxxx]
>> >
>> > _______________________________________________
>> > recommenders-dev mailing list
>> >
recommenders-dev@xxxxxxxxxxx
>> >
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>> >
>> _______________________________________________
>> recommenders-dev mailing list
>>
recommenders-dev@xxxxxxxxxxx
>>
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>
>
>
>
> --
> Best Regards From Cheng Chen [
chengchendoc@xxxxxxxxx]
>
> _______________________________________________
> recommenders-dev mailing list
>
recommenders-dev@xxxxxxxxxxx
>
http://dev.eclipse.org/mailman/listinfo/recommenders-dev
>
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev