Re: [flux-dev] QuickFix prototype in Github

[Jayaprakash Arthanareeswaran <jarthana@xxxxxxxxxx>]

Hi Eric,

As mentioned in today's call, I managed
to get it up and running. In fact, even able to make the quick fix button
(the + image) appears on my Java problem markers. 

I see couple of problems for myself
to solve:

1. Typically the way it works in the
IDE is, the user is shown the list quick fix proposals and upon selecting
one of them, the fix is applied. To keep things simpler, I will skip this
part for now and just go with 
directly applying quick fix without
showing the proposal. I know this will not cut the mustard, but just want
to get it working.

2. I want to store the problem ID (unique,
sent by JDT) in orion problems and later use it when the user want the
quick fix applied. I see no problems in adding the extra field to the problem,
like below:

         
               
               
      resourceMetadata.liveMarkers[i] = {
         
               
               
               
      'id'
: data.problems[i].id,
         
               
               
               
      'description'
: data.problems[i].description,
        //
               
               
               
       'line' : data.problems[i].line,
         
               
               
               
      'severity'
: data.problems[i].severity,
         
               
               
               
      'start'
: /*(data.problems[i].start
- lineOffset) + 1*/ data.problems[i].start,
         
               
               
               
      'end'
: /*data.problems[i].end
- lineOffset*/ data.problems[i].end
         
               
               
              };

But, is there a way to retrieve this
from the annotation or editor context later? This is how my code looks
like now:

     
  var fixIllegalKeywordImpl
= {
         
      execute: function(editorContext,
context) {
         
               
      if
(!context.annotation)
         
               
              return
null;
         
      
         
               
      return
editorContext.getText().then(function(text)
{
         
               
              var
textModel = new
TextModel.TextModel(text);
         
               
      });
         
      }
        };


Thanks for your help!

Jay



From:      
 Eric Moffatt <emoffatt@xxxxxxxxxx>
To:      
 Flux developer discussions
<flux-dev@xxxxxxxxxxx>
Date:      
 11/11/2014 09:41 PM
Subject:    
   Re: [flux-dev]
QuickFix prototype in Github
Sent by:    
   flux-dev-bounces@xxxxxxxxxxx

---

Jay, it shouldn't be too bad. Let me
know if you run into any issues or have suggestions to make it even better...
Eric

Jayaprakash
Arthanareeswaran ---11/11/2014 05:19:36 AM---Hello Eric, Thanks for the
valuable information. Since I pushed the quickfix changes,

From:	Jayaprakash Arthanareeswaran <jarthana@xxxxxxxxxx>
To:	Flux developer discussions <flux-dev@xxxxxxxxxxx>,
Date:	11/11/2014 05:19 AM
Subject:	Re: [flux-dev] QuickFix prototype in Github
Sent by:	flux-dev-bounces@xxxxxxxxxxx

---

Hello Eric, 

Thanks for the valuable information. Since I pushed the quickfix changes,
I haven't had time to look at integrating things with Orion. I am planning
to spend some time this week on this. 
I will take a look at the QuickFixTest you pointed out and hopefully it
will not as complicated as I feared initially :) 

Regards, 
Jay 



From:        Eric
Moffatt <emoffatt@xxxxxxxxxx> 
To:        Flux
developer discussions <flux-dev@xxxxxxxxxxx>
Date:        11/07/2014
10:02 PM 
Subject:        Re:
[flux-dev] QuickFix prototype in Github 
Sent by:        flux-dev-bounces@xxxxxxxxxxx

---

Jay, we've committed the code for 'quickfix' commands to the Orion GIT
repo...you should be able to try it out !

The basic idea is that you can create a pretty well vanilla 'editor' command
to provide the fix for a given annotation. When the hover comes up over
an annotation we use the commands' 'validationProperties' to filter out
only the ones appropriate to the annotation we're over and render a toolbar
from any commands that pass the filter, giving us this:

There's an example provided called QuickFixTest that implements fixes for
two different annotations (showing that you can implement all your quick
fixes in one plugin). The two things to note when looking at the example
are that the commands have a 'scopeId' of 'quickfix' (marking these commands
as candidates for the quickfix hover) and that the validationProperties
filter based on the annotation's 'title'. This is an interim hack until
we can get folks to add a unique 'id' to each annotation, then we'll change
over to check that (which will be trivial).

To use the example install the QuickFixTest plugin and open a CSS file
containing the following code...

/* $HeaderHeight */
.headerLayout {
height: 0px;
}

.foo {

}

If it's working you should see two annotations. Hovering over either should
provide you with a popup that shows the annotation and has a button which,
when clicked, will 'fix' the problem (see above).

On the hover popup side of things Curtis Windatt has been doing some excellent
work on providing a 'UI Delegate' for the hover popup. We can't directly
allow HTML as input since plugin code is 'untrusted'; the delegate pattern
allows HTML but sandboxes it in an IFRAME to prevent it from possibly corrupting
the actual page. Here are a few examples...(from https://bugs.eclipse.org/bugs/show_bug.cgi?id=449240):

This one shows using an external service to define an image for some css
class...

This one shows a naive 'color' display (we're already looking into using
a more refined color 'picker')...

Coming soon to tooling near Orion...

Command Bindings: We'll have a command that will 'show' the tooltip
on demand as opposed to on a 'hover', This command will be parameterized
allowing for a subset of the existing hover plugins to be invoked. This
allows for Ctrl-1 like operations for folks who keep their hands on the
KB all the time...input welcome, now's the time !

Editors in the tooltip: While this one will likely take some time the
goal is to allow us to match (for some definition of 'match...;-) what
you see in Chrome's debugger where it'll show you the actual code for a
method if you hover over it or the code for a CSS class...

Feel free to provide feedback or scenarios that you think would be useful,
Eric

Jayaprakash
Arthanareeswaran ---11/04/2014 11:57:09 PM---Hi Martin, Right now, this
is how it's done:

From:	Jayaprakash Arthanareeswaran <jarthana@xxxxxxxxxx>
To:	Flux developer discussions <flux-dev@xxxxxxxxxxx>,
Date:	11/04/2014 11:57 PM
Subject:	Re: [flux-dev] QuickFix prototype in Github
Sent by:	flux-dev-bounces@xxxxxxxxxxx

---

Hi Martin, 

Right now, this is how it's done: 

On request for applying a particular proposal, the JDT service simply asks
the proposal for the preview content and replace the current document's
content. After this, the service sends a "liveResourceChanged"
message back to the editor. Here is some bits of relevant code:

String preview
= proposal.getPreviewContent();
... 
document.addDocumentListener(this.documentListener);
document.replace(0, preview.length(),
preview);
... 
responseMessage.put("offset",
this.documentListener.event.getOffset());
responseMessage.put("removedCharCount",
this.documentListener.event.getLength());
responseMessage.put("addedCharacters",
this.documentListener.event.getText());
this.messagingConnector.send("liveResourceChanged",
responseMessage);

Replacing the whole content is definitely not ideal. The JDT/UI code that
updates the document (in the IDE) seems to be tied closely to some UI elements.
But I believe there's still a way to compute this, but I haven't gotten
there yet. 

Regards, 
Jay 



From:        Martin
Lippert <mlippert@xxxxxxxxx> 
To:        Flux
developer discussions <flux-dev@xxxxxxxxxxx>
Date:        11/05/2014
01:16 AM 
Subject:        Re:
[flux-dev] QuickFix prototype in Github 
Sent by:        flux-dev-bounces@xxxxxxxxxxx

---

Hey Jay,

this is awesome. Haven’t looked at the code yet, but I am curious to learn
how you are doing the file rewrite. Wanna share and discuss details here?

Cheers,
-Martin

> 
> Hello, 
> 
> I have pushed a first cut prototype of a quickfix prototype here:
https://github.com/jarthana/flux
> 
> Even for a prototype, this is in initial stage and I have added only
the JDT side of things. Just so people can try out this feature, I have
put some stuff in the embeddededitor.js. 
> 
> Currently the way the feature can be used is: 
> 
> 1. Keep the cursor at the problem location and press F6 - this will
display the suggested quick fixes as bullet list in a hover. 
> 2. Keep the cursor at the problem location and press Ctrl + F6 - This
will compute the quick fixes and apply the first quick fix automatically
and rewrite the file being edited. 
> 
> The way I see the above use cases being integrated eventually: The
quick fix service will cache the last quick fixes it sent to the editor
in user session. The quick fixes are recognized by an ID, which will be
sent back to the JDT service when the user selects one of them in the editor.
Upon receiving confirmation, the fix will be applied. 
> 
> I have also put up a demo of the prototype here: http://youtu.be/DfQTuX2Kd8c
> 
> Regards, 
> Jay 
> _______________________________________________
> flux-dev mailing list
> flux-dev@xxxxxxxxxxx
> To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
> https://dev.eclipse.org/mailman/listinfo/flux-dev

_______________________________________________
flux-dev mailing list
flux-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/flux-dev
_______________________________________________
flux-dev mailing list
flux-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/flux-dev
_______________________________________________
flux-dev mailing list
flux-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/flux-dev
_______________________________________________
flux-dev mailing list
flux-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/flux-dev
_______________________________________________
flux-dev mailing list
flux-dev@xxxxxxxxxxx
To change your delivery options, retrieve your password, or unsubscribe
from this list, visit
https://dev.eclipse.org/mailman/listinfo/flux-dev