Skip to main content

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index] [List Home]
Re: [recommenders-dev] [snipmatch] worse popup behavior

The most difficult part is the time, in fact, i don't have confidence to finish these two parts in coming 6 weeks, especially the display module, it is not so easy. As my summer holiday start at the end of June, before that, i can not coding for SnipMatch full time because my research job in my Lab and Paper etc. So the time is some kind of hurry for me, i will try my best, but can not promise anything here.

2012/3/23 Doug Wightman <douglasw@xxxxxxxxx>
I agree that we absolutely need downloading and indexing of repositories.

In terms of displaying and inserting code snippets, reusing existing
(stable) code sounds good. However, I want to ensure that we won't
lose the following features:
-you still search in a search box, and you can include arguments (e.g.
local variables) in the search query. Note: with templates, these
arguments would then be used to pre-fill the templates.
-the result listing updates as you type

So long as we retain these two features, these changes make sense to
me. If either is at risk, let's explicitly discuss.

Given the timeframe, it might make the most sense to build each of
these changes (repository integration + new display system) in the
next 6 weeks: splitting the time between the two of them, then
polishing afterwards. But Marcel is in a much better position to judge
timeline and priorities. I really appreciate your feedback - it's
critical that we have a strong offering for M7.

I also want to hear from Chen: is this reasonable for you? Is there
anything that you think we need to cut?


Doug




On Fri, Mar 23, 2012 at 8:27 AM, Chen Cheng <chengchendoc@xxxxxxxxx> wrote:
> The only problem is the time, if we change display module now, we have too
> much things to do, we should decide the priority
>
>
> 2012/3/23 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
>>
>>
>> On 23.03.2012, at 11:49, Chen Cheng wrote:
>>
>> It seems that time is really emergency for us. About the two features:
>>
>> * downloading and indexing a local repository
>>
>> You mean current local search module, add EGit module to download snippet
>> files from remote repository automatic. And with some preference pages,
>> right ?
>>
>>
>> Exactly.
>>
>>
>> * code completion engine based on Eclipse standard features like templates
>> and Linking mode
>>
>> You mean abandoned current match result display module, change to Eclipse
>> standard features. I am not very clear what your words "templates and
>> Linking mode" mean, but i think the new search result display will looks
>> like Java Class Editor's content assist(see attach file assist.png), right ?
>>
>>
>> Yes. I'm proposing to reuse JDT's template framework for now. With linking
>> mode I refer to "the placeholders can be navigated by tab" feature of JDT's
>> templates . It also offers functionality like guessing arguments for
>> template variables.
>>
>>
>> Anyway, current match result display module works, but i don't think it is
>> a long term solution, if you mean change it. I agree.
>>
>>
>> Standing by for Doug's opinion. Must be 6AM in Canada ;)
>>
>> Thanks
>> Marcel
>>
>>
>>
>> 2012/3/23 Marcel Bruch <marcel.bruch@xxxxxxxxx>
>>>
>>> Hi Chen,
>>>
>>> this fix looks good to me and is good to go for EclipseCon demo. Thanks a
>>> lot.
>>>
>>>
>>> I'd like to initiate a discussion about how the whole template code
>>> insertion & display mechanism should look like for Juno - and discuss the
>>> important milestones.
>>>
>>> M6 is today. M7 is in 6 weeks and then projects do a feature freeze,
>>> i.e., all the time is put into testing, bug fixing and small improvements.
>>> Projects like JDT or RAP have feature freeze since M6 already. I'm a bit
>>> concerned that we'll run out of time to deliver a stable version of
>>> snipmatch. Doug, Zi, Cheng, how do you think about that?
>>>
>>> I'd propose to focus on just a few features and make them as stable as
>>> possible for Juno.
>>>
>>> Features could include:
>>>  * downloading and indexing a local repository
>>>  * code completion engine based on Eclipse standard features like
>>> templates and Linking mode
>>>
>>> Although I love the "insert directly in code" and the custom popup
>>> feature very much, I think, they are not stable and fast enough yet. I'm
>>> concerned that the success of Snipmatch depends on usability and that it
>>> will be hard to convince package owners to include it. I'll talk to some
>>> package maintainers at EclipseCon to learn about their requirements but
>>> before that I'd like to know your opinions on this.
>>>
>>> Thanks,
>>> Marcel
>>>
>>>
>>>
>>> On 23.03.2012, at 03:25, Chen Cheng wrote:
>>>
>>> Hi Marcel,
>>>
>>> I have fixed this issue, the popup window will not cover the inserted
>>> code anymore, and submit source code already.
>>>
>>> About the other issue "Is it possible to run the code without revealing
>>> the active editing position?", my current answer is NO, it seems that the
>>> "scrolls" job was done by editor itself, we can not fix it easily now. But i
>>> will add this into my TODO list and find solution in the future, in fact, we
>>> have plan to improve the whole search result display canvas.
>>>
>>> 2012/3/22 Marcel Bruch <bruch@xxxxxxxxxxxxxxxxxx>
>>>>
>>>> Hi Chen,
>>>>
>>>> I experienced a serious issue for the snipmatch demo:
>>>>
>>>> When I trigger completion at an empty location, enter "file", wait for
>>>> proposals and then scroll trough the proposals the popup window completely
>>>> covers the inserted code. With that behavior, we can't see the code that
>>>> gets inserted by snipmatch.
>>>>
>>>> Can you reproduce that? What can we do with this?
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> 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
>>>
>>
>>
>>
>> --
>> Best Regards From Cheng Chen [chengchendoc@xxxxxxxxx]
>> <assist.png>_______________________________________________
>>
>> 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



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

Back to the top