Re: [recommenders-dev] [DISCUSS] Solution about snipmatch's search resul

[Doug Wightman <douglasw@xxxxxxxxx>]

On Sat, Mar 24, 2012 at 3:46 AM, Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx> wrote:
> hi, just very brief answers because my flight is going in a few hours and
> nothing is packed ;)
>
>
> On 24.03.2012, at 08:29, Chen Cheng wrote:
>
> Hi Zi,
>
> Thank you for your response, it seems that we get consensus about the
> problems if we use content assist to show the research result. Comments
> below:
>
> 2012/3/24 Zi Ye <zi@xxxxxxx>
>>
>> Hi Chen,
>>
>> Doug and I spent lots of time exploring different options for displaying
>> and navigating through search results, including Eclipse's content assist.
>> We came to the conclusion that content assist was built for a very specific
>> type of workflow - that of traditional snippet insertion. i.e., the one you
>> described in #2. Here are what we consider to be the major problems with
>> using content assist for SnipMatch:
>>
>> SnipMatch allows for the input of simple phrases, and is sensitive to
>> grammatic structure. Content assist uses keywords, and for a good reason: it
>> does not use a separate input box. The user just types in a keyword directly
>> in the code, and content assist will evaluate that. This would not work for
>> SnipMatch, since things like auto-completion and syntax highlighting could
>> mess up the query before it is completed.
>
> I suggest may be we can use the *current line* in the editor as the input
> for SnipMatch. For example, user input "move fileName to targetFolder" in a
> seperate line, then press "ALT + /" to popup up content assist, snipmatch
> use the string "move fileName to targetFolder" as input to search for the
> target snippets, then display result. Does it make sense? Marcel & Doug, how
> do you think of it ?
>
>
> Short: I think we need the extra line and I wouldn't dismiss it.

Excellent idea, but I don't think this will work (we tested this early
on). If we use the current line, results would only be updated after
you finish typing. In this case, the user won't see feedback as they
type. This would make it difficult to discover snippets and to revise
the text (if you made an error, or wanted to try something different,
you would need to first escape from the results then continue
editing).

>
>
>
>>
>> As you already mentioned, content assist does not allow inline
>> specification of arguments. Instead, it expands a keyword into a snippet
>> with dummy arguments that are intelligently substituted with local variables
>> and such. All editing happens after the fact. To resort to this would defeat
>> the entire purpose of using SnipMatch, rendering it nothing more than a
>> crowd-sourced Eclipse snippet database. To think about this from the
>> end-user perspective: If I type "move fileName to targetFolder", the
>> inserted snippet should already be filled in with the proper arguments.
>> Otherwise, the user would have to parse the inserted code to see the "role"
>> that each dummy argument plays. This is a step that SnipMatch aims to
>> remove.
>
> Yeah, i didn't find any solution to input arguments before content assist
> insert target code into editor. In my idea, dummy arguments may be the best
> solution :-(
>
>
>
> I didn't get the whole discussion about the "variable thing"... in jface
> template language you define placeholders for any variable which will be
> filled at proposal time with the placeholder name and at insertion time
> (depending on your settings) with best guesses or in a link mode that allows
> you to jump between these templates and select from all existing variables
> which fits best. I see no problem here - but I guess I'm missing some
> important point here... ;)

Can a placeholder be filled with a specific variable at proposal time?
Supplying arguments in the search box - so that you don't have to
enter them in the code later - is a major feature of the current
version.

>
>
>>
>> As for live updating of code, I personally do not think it is necessary to
>> show it right in the Java Editor, but there should be some way for the user
>> to see how the code will look like while browsing through all the search
>> results. You could show this in a preview pane or something, but I
>> definitely think *some* kind of preview should be made easily accessible.

I'm also not too worried about this: live preview doesn't seem critical to me.

>
> Content assist has source code preview feature, this is really not a big
> problem :-)
>
>
> Think so too. If you have jface templates, we can reuse there
> JavaTemplateProposal which has some built-in functionality.
>
>
> I'll see if I can get a minute of an JDT expert next week. Maybe it's easier
> that we expect.

Awesome :)


>
> Bye
>
>
>
>>
>> Hope that helps!
>>
>> Zi
>>
>> On 24 March 2012 01:02, Chen Cheng <chengchendoc@xxxxxxxxx> wrote:
>>>
>>> Hi Marcel & Doug,
>>>
>>> Zi, if you are listening, please let us know your idea. Doug told us you
>>> are the UI expert :-)
>>>
>>> After the whole nignt's survey job, i think if we just use JDT's content
>>> assist and javaCompletionProposalComputer extend point to display the search
>>> result for SnipMatch, there are several problems (If there is anything wrong
>>> with my idea, let me know):
>>>
>>> 1. Where to input search key words?
>>>
>>> Content assist does not supply a text input box etc for us to input
>>> search key word, Usually it will use current editor's context to get
>>> completion proposals. So if we just use JDT's content assist solution, how
>>> about always use *current line* in editor as search key for snipmatch ?
>>>
>>> 2. How to input the arguments for the search result?
>>>
>>> I did not found any extend point to add this step for JDT's content
>>> assist. I think may be we can just use some dummy arguments, once user press
>>> ENTER, insert the code snippet with dummy arguments into the editor. User
>>> can change the arguments in the editor.
>>>
>>> 3. When i select candidate search result items by UP and DOWN key, should
>>> the content in Java editor change ?
>>>
>>> In my experience, all the editors(such as Java, HTML, XML editors) does
>>> not have this *real time* change feature. They just insert the target codes
>>> into the editor after you press ENTER. Before that, they will not insert the
>>> candidate codes into the editor and change along with your selection change.
>>> Maybe i ma wrong, if you guys have good solution, please tell me.
>>>
>>> --
>>> 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
>
>
> 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
>