Autocomplete-Lua provider about love-atom HOT 23 CLOSED

from love-atom.

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

from love-atom.

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

from love-atom.

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

from love-atom.

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)

from love-atom.

Things to do:

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

from love-atom.

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.

from love-atom.

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?

from love-atom.

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

from love-atom.

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).

from love-atom.

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 😃

from love-atom.

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.

from love-atom.

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

from love-atom.

Functions, Callbacks and Module-Functions should work now:

from love-atom.

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.

from love-atom.

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

from love-atom.

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.

from love-atom.

"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"
               }
            }
         }
      }
   }
},

from love-atom.

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

from love-atom.

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.

from love-atom.

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"

from love-atom.

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

from love-atom.

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.

from love-atom.