Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] [SnipMatch] Search result display's parameters solution

To clarify: when I said "as it is implemented now", I meant in the
version of SnipMatch that was originally submitted to Eclipse. I.e. as
shown in the video.


On Thu, Apr 5, 2012 at 10:37 PM, Doug Wightman <douglasw@xxxxxxxxx> wrote:
> 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
>>


Back to the top