Autocomplete-Lua provider

pablomayobre commented 7 years ago

This package implements it's own autocomplete-plus provider. It would be great if this could be integrated with the atom-autocomplete-lua package.

atom-autocomplete-lua has an interface that developers can use to add suggestions through packages to be displayed with the autocomplete package. Autocomplete-Lua does an actual parsing of the files with Lua Parse inferring types and some other stuff improving the quality of autocomplete suggestions.

It's just a suggestion and not really needed but I would like to see what are the pros and cons of doing this

rm-code commented 7 years ago

Looks nice. If it would improve love-atom I'm all for it.

rm-code commented 7 years ago

I just noticed I had already starred the atom-autocomplete-lua package, but must have forgotten about it in the meantime ^^

pablomayobre commented 7 years ago

Maybe start a secondary branch, it will probably be entirely different!

But yeah I guess it would bring some improvements to this package and reduce it's size and complexity making maintenance easier too.

I can help if you need it (I can debug and fix issues)

rm-code commented 7 years ago

Things to do:

[ ] Adjust generator script so the template fits the atom-autocomplete-lua format
[x] Handle function variants
[x] Load and use LÖVE completions
[x] Add atom-autocomplete-lua as dependency (received an error when trying it earlier)
[ ] Only provide LÖVE autocompletion in an open LÖVE project

rm-code commented 7 years ago

As far as I can tell using "atom-autocomplete-lua" will also break the current addition of LÖVE-only types.

E.g. currently love-atom allows you to type Text and will provide all functions available to the Text module. It will then add a snippet with the actual module name as a variable ${1:Text}:add(${3:textstring (string)}...) which allows the user to replace it with an actual variable name.

I don't see a way to currently handle this with atom-autocomplete-lua, but maybe I'm missing something.

pablomayobre commented 7 years ago

Adjust generator script so the template fits the atom-autocomplete-lua format

I can do this if you want, it's pretty simple

Only provide LÖVE autocompletion in an open LÖVE project

How would you detect that? Wouldn't it be good enough to provide it regardless? You would need to type love anyway to get the suggestions

Load and use LÖVE completions

This is simply loading the JSON isn't it?

pablomayobre commented 7 years ago

I don't see a way to currently handle this with atom-autocomplete-lua, but maybe I'm missing something.

You can define named types which can have methods associated to them, then when you define say for example love.graphics.newImage you would say that it returns a value of Image type.

If atom-autocomplete-lua is intelligent as it says and can infer types then the snippets won't be needed. It will automatically suggest Image methods on a variable which was assigned the value returned by love.graphics.newImage

rm-code commented 7 years ago

I can do this if you want, it's pretty simple

Sure, if you want to :) I just can't do it today, but would do it tomorrow.

How would you detect that? Wouldn't it be good enough to provide it regardless? You would need to type love anyway to get the suggestions

Dunno, the Defold IDE does it apparently so I figured we might be able to do it as well. I just put it in the list so I don't forget to look into it.

You can define named types which can have methods associated to them

Ok that would be cool. I'll try.

Oh and I just remembered we apparently could include all the function variants too finally (updated the list).

pablomayobre commented 7 years ago

Dunno, the Defold IDE does it apparently so I figured we might be able to do it as well. I just put it in the list so I don't forget to look into it.

They search for a file called game.project somewhere in the project and if found then that's a Defold project... not sure how to translate that to LÖVE. If we searched for main.lua or conf.lua you wouldn't be able to develop libraries, since those don't have those files, but they may still use LÖVEs API.

Sure, if you want to :) I just can't do it today, but would do it tomorrow.

Okey! I'm not sure I can do it for tomorrow but I'll try... If you happen to work on it tomorrow, be sure to check this branch on my fork (I'll upload my changes there if I make any), so that you don't end up doing the same thing (you can copy whatever progress I had made by then!)

Oh and I just remembered we apparently could include all the function variants too finally (updated the list).

This is pretty cool 🎉, this would all happen on that script that generates the JSON so it would still be pretty simple 😃

pablomayobre commented 7 years ago

First, here is an structure of what the JSON should look like:

{
  "global": {
    "type": "table",
    "fields": {
      "love":{
        "type": "table",
        "fields": {
          modules: {
            "type": "table",
            "fields": {
              functions: {
                "type": "function",
                ...
              }
            }
          }
          callbacks: {
            "type": "function",
            ...
          }
          functions: {
            "type": "function",
            ...
          }
        }
      }
    }
  },
  "namedTypes":{
    Enums: {
      "type": "string"
    },
    Types: {
      "type": "table",
      "fields": {},
      "metatable": {
        "type": "table",
        "fields": {
          "__index": {
            "type": "table",
            "fields": {
              methods: {
                "type": "function",
                ...
              }
            }
          }
        }
      }
    }
  },
  "luaVersion": "luajit-2.0",
  "packagePath": "./?.lua,./?/init.lua"
}

Things highlighted in red are references to actual things in the love-api table or that stuff is missing like descriptions, arguments, types etc. Also Types and Enums are all Types and Enums found on every single module and not only in the main one.

There is an issue though, there is no easy way to represent SuperTypes.

This means that there are two problems:

We can't use parents like Drawable to represent all its children like Canvas, Image, Mesh, ParticlSystem, etc as in love.graphics.draw(Drawable)
A Type that inherits from a SuperType needs to have all the methods provided by all the SuperTypes, this means copying around the same variables over and over again

Currently what I'm doing is spreading the objects. This means that if love.graphics.draw accepts a Drawable I would provide variants for all the different Drawable SubTypes. Same goes the other way, when I define the methods of a Type, I also copy all the methods from it's SuperTypes. This will most likely result in a HUGE JSON file...

The second option, use metatable.__index in a clever way to point to the direct parent SuperType of a Type... could work but should be thorougly tested, and love-api only tells you ALL the SuperTypes and not the direct parent SuperType. This would only fix the second problem and not the first one but is the most elegant solution.

Types: {
  "type": "table",
  "fields": {
    methods: {
      "type": "function",
      ...
    }
  },
  "metatable": {
    "type": "table",
    "fields": {
      "__index": {
        "type": "ref",
        "name": SuperType,
      }
    }
  }
}

Third option is that the generator could generate a JS file instead of JSON and make use of variables to do all this... somewhat simplifying the file... ugly solution though.

rm-code commented 7 years ago

Started working on the generator https://github.com/rm-code/love-atom/tree/generator (it's another branch on top of lua-autocomplete).

NOTE: This is far from producing anything usable yet :P

rm-code commented 7 years ago

Functions, Callbacks and Module-Functions should work now:

bildschirmfoto 2017-04-27 um 01 40 57

rm-code commented 7 years ago

We can't use parents like Drawable to represent all its children like Canvas, Image, Mesh, ParticlSystem, etc as in love.graphics.draw(Drawable)

Do you have any examples where this would be an issue?

Currently what I'm doing is spreading the objects. This means that if love.graphics.draw accepts a Drawable I would provide variants for all the different Drawable SubTypes. Same goes the other way, when I define the methods of a Type, I also copy all the methods from it's SuperTypes. This will most likely result in a HUGE JSON file...

I mean I don't see the issue here. Why would there be a need to add the suggestions for a Drawable? When you write your code you have a concrete SubType like Image anyway.

I think it would be enough to simply add all the methods from Supertypes to the Subtypes. This wouldn't be many btw. Drawable and Texture don't specify any methods for example.

pablomayobre commented 7 years ago

Do you have any examples where this would be an issue?

Not really... Haven't tested though but I guess there won't be

I think it would be enough to simply add all the methods from Supertypes to the Subtypes. This wouldn't be many btw. Drawable and Texture don't specify any methods for example.

Try the metamethod alternative first if possible, it may shield better results with shorter JSON file. As suggested in this comment on #8

rm-code commented 7 years ago

Try the metamethod alternative first if possible, it may shield better results with shorter JSON file. As suggested in this comment on #8

I'll do once the basic type support is working.

Not sure why, but atom-autocomplete-lua is not giving me the type support. Types use this format:

"ChainShape":{
   "type":"table",
   "fields":{
      "setPreviousVertex":{
         "type":"function",
         "description":"Sets a vertex that establishes a connection to the previous shape.\n\nThis can help prevent unwanted collisions when a flat shape slides along the edge and moves over to the new shape.",
         "args":[
            {
               "name":"x"
            },
            {
               "name":"y"
            }
         ],
         "link":"https://love2d.org/wiki/ChainShape:setPreviousVertex"
      },

local cs = love.physics.newChainShape(loop, points)
cs:

I'm not getting any suggestions for cs here.

rm-code commented 7 years ago

"Cursor":{
   "type":"table",
   "fields":[

   ],
   "metatable":{
      "type":"table",
      "fields":{
         "__index":{
            "type":"table",
            "fields":{
               "getType":{
                  "type":"function",
                  "description":"Gets the type of the Cursor.",
                  "returnTypes":[
                     {
                        "type":"ref",
                        "name":"CursorType"
                     }
                  ],
                  "link":"https://love2d.org/wiki/Cursor:getType"
               }
            }
         }
      }
   }
},

pablomayobre commented 7 years ago

Yeah, I saw that too the other day with a basic table... there may be an issue in atom-autocomplete-lua.

rm-code commented 7 years ago

bildschirmfoto 2017-04-29 um 15 49 24

rm-code commented 7 years ago

I just merged the branches into master.

@Positive07 I got the supertypes to work, but there seems to be an issue with some of the Types / constructors still (e.g. love.filesystem.newFile works, but love.filesystem.newFileData doesn't).

I'm back later tonight, but maybe you can test it a bit in the meantime.

pablomayobre commented 7 years ago

THIS IS GREAT! Will test it out as soon as I can. Now I hope I can get PR #108 merged in Luacheck and PR #14 merged in atom-autocomplete-lua

In the meantime I'll try debugging this 🎉 😄

PS: I suggest adding this two lines into the JSON or the provider:

  "luaVersion": "luajit-2.0",
  "packagePath": "./?.lua,./?/init.lua"

rm-code commented 7 years ago

Oh yeah I meant to ask what those two lines are doing exactly.

pablomayobre commented 7 years ago

Well LÖVE adds the init.lua way of adding files, and since atom-autocomplete-lua uses this paths to tell what the require should return, it's better to add the packagePath variable pointed above.

Also LÖVE uses LuaJIT so that is the reason for the luaVersion.

With this two lines there wouldn't be a need for a .luacompleterc in a LÖVE project. And since the provider has priority 20, a .luacompleterc (which has priority 10) can overwrite this values, this means that there is no pain in adding them.

rm-code commented 7 years ago

Done. I'll close this ticket. If any issues pop up it makes more sense to open new tickets for each of them.

rm-code / love-atom

Autocomplete-Lua provider #7