These are chat archives for ceylon/ceylon-ide-eclipse

7th
Jun 2016
David Festal
@davidfestal
Jun 07 2016 00:00
it fixed the build. However the CeylonExplorer seems broken for Ceylon projects
I pushed the fixes for the IDE build
I'll continue tomorrow to look into the CeylonExplorer regression.
bye
David Festal
@davidfestal
Jun 07 2016 16:40
@bjansen : do you have an idea about this one:
ceylon/ceylon-ide-eclipse#1800
since you worked on the refactoring of refactorings ;-)
Bastien Jansen
@bjansen
Jun 07 2016 16:42
it looks like the refactoring was called before the file was typechecked?
editor.parseController.typecheckedRootNode == null
David Festal
@davidfestal
Jun 07 2016 16:43
might be, honestly I've nt followed all the changes of the last months in the refactorings
Bastien Jansen
@bjansen
Jun 07 2016 16:44
maybe the project was loading when you clicked on the menu?
David Festal
@davidfestal
Jun 07 2016 16:44
I'm not sure I clicked on a menu at all
I just saw that in the error log :-)
Bastien Jansen
@bjansen
Jun 07 2016 16:45
I see DynamicMenuContributionItem in the stack, so I suppose it was the case
David Festal
@davidfestal
Jun 07 2016 16:46
it can be that it is when the menu activation is calculated
no ?
yes, it seems
so in this case it should be possible to have a null typecheckedRootNode
and IMO this should result in the menu item not being disaplayed
Bastien Jansen
@bjansen
Jun 07 2016 16:49
I agree
or at least it should be disabled
David Festal
@davidfestal
Jun 07 2016 16:49
true, that's what I meant yes
disabled is the right way
Bastien Jansen
@bjansen
Jun 07 2016 16:54
I think that's already the case, this instance was created to call isEnabled(), but to determine that we need the Data object, which assumes the typecheckedRootNode is not null
David Festal
@davidfestal
Jun 07 2016 16:54
yes, that's the problem
it still can be null, before any local typechecking occured
Bastien Jansen
@bjansen
Jun 07 2016 16:55
right
David Festal
@davidfestal
Jun 07 2016 16:55
of course not during the life of the editor, but at start
Gavin King
@gavinking
Jun 07 2016 19:51
@bjansen yt?
Bastien Jansen
@bjansen
Jun 07 2016 19:51
yes
Gavin King
@gavinking
Jun 07 2016 19:52
so when I extract a function (⌘M) and it creates a new toplevel function
i get popped up a dialog-based renaming
i thought you had already changed that stuff to not just reuse the Rename refactoring?
Bastien Jansen
@bjansen
Jun 07 2016 19:53
well I fixed the algorithm that checks if a declaration is visible from other files
and when you create a toplevel func, it's visible from other files
Gavin King
@gavinking
Jun 07 2016 19:54
yes, but when doing an Extract refactoring, we know it’s not visible from other files
Bastien Jansen
@bjansen
Jun 07 2016 19:54
although since you just created it, it's certainly not used yet
Gavin King
@gavinking
Jun 07 2016 19:54
since it’s brand new
so that log isn’t appropriate
Bastien Jansen
@bjansen
Jun 07 2016 19:57
I agree
can you open an issue so that I don't forget to fix that?
Gavin King
@gavinking
Jun 07 2016 19:57
sure
Bastien Jansen
@bjansen
Jun 07 2016 19:58
the popup that asks for the target scope (package, class etc) is also missing, but that's more an improvement than a bug
Gavin King
@gavinking
Jun 07 2016 19:58
ahyes
i’ll open a feature req
that’s only on extract method, isn’t it?
yes, it doesn’t make much sense for Extract Variable
Bastien Jansen
@bjansen
Jun 07 2016 19:59
I suppose, yes
Bastien Jansen
@bjansen
Jun 07 2016 20:15
it turns out bypassing the dialog-based renaming was easier than expected, it's fixed
Gavin King
@gavinking
Jun 07 2016 20:15
thanks