Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] [SnipMatch] New search result display module trial version is finished

So, you mean it is possible for us the use Java Editor Template only, right?

HMM, I will try to look through both Template Grammar in SnipMatch and Java Editor Template, then give my opinion

2012/4/13 Doug Wightman <douglasw@xxxxxxxxx>
Okay, here's one case that we will eventually want to address if this
change is made (partially quoting from Zi): Let's say you wanted to
construct a foreach loop. You would need the user to specify a name
for the iterator. That's not an existing variable, it's a new one, so
you would use a new type - say, "identifier".

However, it shouldn't be difficult to augment the existing markup to
support this case, and others like it (e.g. if you want to get the
type of an iterable).

I think it's reasonable to use Eclipse Templates as much as possible -
Marcel's proposal seems reasonable to me. We can worry about these
edge cases down the road - 99% of the existing functionality can be
immediately supported.



On Thu, Apr 12, 2012 at 7:50 AM, Doug Wightman <douglasw@xxxxxxxxx> wrote:
>
> hmm - no, that's not a problem. Although I seem to remember there being one with iterables - will wait to hear from Zi.
>
>
> On Thu, Apr 12, 2012 at 7:49 AM, Doug Wightman <douglasw@xxxxxxxxx> wrote:
>>
>> Here's one case that might be problematic: can var() (or another) be used to match anything that is iterable?
>>
>>
>> On Thu, Apr 12, 2012 at 7:37 AM, Doug Wightman <douglasw@xxxxxxxxx> wrote:
>>>
>>> Consider this case: the user types "move file at str1 to folder str2" into the search box (where str1 and str2 are the names of local variables). SnipMatch can identify that this search query matches the pattern: "move file at $filePathString to folder $dirPathString".
>>>
>>> First, a lookup is performed to locate patterns that are similar (matching on individual tokens). Then, these results are filtered into two groups: patterns that are "in-order" with respect to the search query and those that aren't (e.g. if the search query was "file move str1", the pattern would be out of order, and should thus appear below all the in-order patterns in the result listing).
>>>
>>> Next, we remove in-order patterns when the expected parameters types don't match with the arguments (e.g. str1 and str2). This is important because there could be another pattern that is exactly identical except handles a different type (and also as a method of validation, giving the programmer confidence that the snippet will work). In order to perform this step, we need to retrieve the expected parameter types. "params" helps with this - otherwise, we would need to frequently extract the types from "code" within the json (for every pattern that might match a search query, every time the user types a letter).
>>>
>>> However, this isn't necessarily a good reason for params to be implemented as they are. If this was the only reason for this approach, we could instead generate params from the snippet code when the snippet is created (rather than having them be specified with a separate ui).
>>>
>>> I think there were two additional reasons for this approach, and I think it's ok to sacrifice them: (1) we were concerned that many potential snippet creators wouldn't know off-hand how to specify types (e.g. java.lang.String - and this is an easy one) - we figured a dropbox and/or suggestions, would be easier for users, and (2) we weren't certain that the JFace types would be sufficient for our purposes. In practice, I think JFace was sufficient, but I may be forgetting something - I'll check with Zi and get back to you.
>>>
>>> In summary: I think we'll still want params, for efficiency purposes, but we can generate them from the snippet code when the snippet is created. If it's important to conform with JFace, I'm ok with using "${filePathString:var(java.lang.String)}" so long as any default can be overridden when an argument is specified in the search query (i.e. str1).
>>>
>>>
>>> Doug
>>>
>>>
>>>
>>> On Thu, Apr 12, 2012 at 5:16 AM, Marcel Bruch <marcel.bruch@xxxxxxxxx> wrote:
>>>>
>>>> Hi Cheng,
>>>>
>>>> I had a closer look at the templates and I wonder whether we couldn't change them a little bit to make them conform to real JFace templates.
>>>>
>>>>  Example common/ 14.json looks as follows:
>>>>
>>>> {
>>>>   "patterns": [
>>>>     "move file at $filePathString to folder $dirPathString",
>>>>     "move file at $filePathString to directory $dirPathString"
>>>>   ],
>>>>   "params": [
>>>>     {
>>>>       "name": "filePathString",
>>>>       "majorType": "expr",
>>>>       "minorType": "String"
>>>>     },
>>>>     {
>>>>       "name": "dirPathString",
>>>>       "majorType": "expr",
>>>>       "minorType": "String"
>>>>     }
>>>>   ],
>>>>   "envName": "javasnippet",
>>>>   "majorType": "stmt",
>>>>   "minorType": "",
>>>>   "code": "${import(java.io.File)}\r\n\r\nFile ${file:freeName(file)} \u003d new File(${filePathString});\r\n${file}.renameTo(new File(${dirPathString} + File.separator + ${file}.getName()));",
>>>>   "summary": "Move the file at a string path to a directory string path.",
>>>>   "id": ""
>>>> }
>>>>
>>>> Can't we get rid of the params section when using the jface templates completely? For instance using a snippet such as follows (untested braindump)
>>>>
>>>>
>>>> ${import(java.io.File)} File ${file:newName(java.io.File)} = new File(${filePathString:var(java.lang.String)}); ${file}.renameTo(new File(${dirPathString:var(java.lang.String)+ File.separator + ${file}.getName()));
>>>>
>>>> Or something similar? There might be a little more changes but if this works, we could get rid of the whole parameter section, right?
>>>>
>>>>
>>>> (I'd prefer this over tests ATM since there are only 15 templates so far ;))
>>>>
>>>>
>>>> On 12.04.2012, at 08:58, Chen Cheng wrote:
>>>>
>>>> So, my following task is contributing unit test before GSoC starts (maybe fix some exist bugs), right?
>>>>
>>>> 2012/4/12 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
>>>>>
>>>>> Hi,
>>>>> On 12.04.2012, at 07:35, Chen Cheng wrote:
>>>>>
>>>>> Hi Marcel,
>>>>>
>>>>> 2012/4/12 Marcel Bruch <marcel.bruch@xxxxxxxxx>
>>>>>>
>>>>>> Hi Chen,
>>>>>>
>>>>>> You mentioned before, we should prepare a Snipmatch package before Eclipse Juno M2, so what will be focus on after search result display module before M2 ?
>>>>>>
>>>>>>
>>>>>> IMHO, focus should be:
>>>>>>
>>>>>> Doug: check in snipmatch into code recommenders repository
>>>>>> Chen: convert code to the new structure
>>>>>
>>>>>
>>>>> You mean change project name, re-factor packages etc?
>>>>> For example, change project name from SnipMatchPlugin -> "org.eclipse.recommenders.snipmatch
>>>>> Right?
>>>>>
>>>>>
>>>>> I'm hoping this will be done by Doug? Doug. Maybe it makes sense to commit all the code to gerrit first and work on this patchset until it is in a good shape?
>>>>>
>>>>>
>>>>>>
>>>>>> Chen: commit changes against gerrit. If possible create only patches smaller than 200 lines. if this is not possible create one large commit.
>>>>>
>>>>>
>>>>> I am not very sure why we have to create patches smaller than 200 lines. This is Eclipse's rule? Anyway, i will follow this rule.
>>>>>
>>>>>
>>>>> all patches below 200 lines don't need an IP check by the Eclipse Legal Team. If it's larger we have a lengthy process to follow. If your initial commit is hard to split into several smaller ones create one large commit to gerrit.
>>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> Doug: initiate an IP check for that patch.
>>>>>> All: wait for IP check
>>>>>>
>>>>>> In the meanwhile:
>>>>>> Integrate snipmatch into the build and write tests ;)
>>>>>
>>>>>
>>>>> I will start contribute unit test code soon, but i want to know, is there any *special* rules towards unit-test bundles in Eclipse community?
>>>>>
>>>>>
>>>>> Hard to say ;) You should have a look at the test bundles in our repository to get an idea.
>>>>> Marcel
>>>>>
>>>>>
>>>>>>
>>>>>>
>>>>>> My time is unfortunately very limited until the 18th April. We apply for a large funding and have the final presentation round net week. After that I'll have a close look.
>>>>>>
>>>>>> Marcel
>>>>>>
>>>>>> On 11.04.2012, at 11:01, Chen Cheng wrote:
>>>>>>
>>>>>> Hi all,
>>>>>>
>>>>>> SnipMatch's new search result display module is finished, i built it similar with JDT's content assit, you can find the GUI in the attach picture file. You guys can have a trial of it, then i can improve it according to the feedbacks. Or if there are any advises, you can just post it here.
>>>>>>
>>>>>> Marcel,
>>>>>> You mentioned before, we should prepare a Snipmatch package before Eclipse Juno M2, so what will be focus on after search result display module before M2 ?
>>>>>>
>>>>>> --
>>>>>> Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
>>>>>> <search_result_display.png>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> 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
>>>>>
>>>>>
>>>>> Thanks,
>>>>> Marcel
>>>>>
>>>>> --
>>>>> Eclipse Code Recommenders:
>>>>>  w www.eclipse.org/recommenders
>>>>>  tw www.twitter.com/marcelbruch
>>>>>  g+ www.gplus.to/marcelbruch
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>>>
>>>
>>
>
_______________________________________________
recommenders-dev mailing list
recommenders-dev@xxxxxxxxxxx
http://dev.eclipse.org/mailman/listinfo/recommenders-dev



--
Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]

Back to the top