Autocomplete-Lua provider #7

pablomayobre · 2017-04-15T17:52:56Z

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 · 2017-04-15T17:55:15Z

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

rm-code · 2017-04-15T17:58:19Z

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

pablomayobre · 2017-04-15T18:18:06Z

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)

As discussed in #7 love-atom can use atom-autocomplete-lua to handle autocompletion in lua files.

rm-code · 2017-04-25T21:05:39Z

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

rm-code · 2017-04-25T21:20:48Z

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 · 2017-04-25T21:22:43Z

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 · 2017-04-25T21:39:46Z

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 · 2017-04-25T22:33:50Z

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 · 2017-04-26T01:21:57Z

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 · 2017-04-26T05:44:07Z

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.

As discussed in #7 love-atom will be rewritten to work as a provider for atom-autocomplete-lua instead of working as a standalone provider. Removed the old love-provider file and transitioned away from Coffeescript into ES6 with the Standard JS linter.

rm-code · 2017-04-26T21:52:09Z

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 · 2017-04-26T23:42:37Z

Functions, Callbacks and Module-Functions should work now:

rm-code · 2017-04-29T00:11:15Z

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 · 2017-04-29T01:01:25Z

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 · 2017-04-29T10:54:59Z

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 · 2017-04-29T11:23:27Z

"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 · 2017-04-29T12:53:18Z

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

rm-code · 2017-04-29T13:50:06Z

As discussed in #7 love-atom will be rewritten to work as a provider for atom-autocomplete-lua instead of working as a standalone provider. Removed the old love-provider file and transitioned away from Coffeescript into ES6 with the Standard JS linter.

rm-code · 2017-04-29T14:31:54Z

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 · 2017-04-29T14:37:48Z

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 · 2017-04-29T14:39:43Z

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

pablomayobre · 2017-04-29T14:44:12Z

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 · 2017-04-29T14:50:22Z

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 added a commit that referenced this issue Apr 25, 2017

Use love-atom provider for atom-autocomplete-lua

86306a8

As discussed in #7 love-atom can use atom-autocomplete-lua to handle autocompletion in lua files.

rm-code mentioned this issue Apr 27, 2017

Generator #8

Merged

rm-code closed this as completed Apr 29, 2017

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

Autocomplete-Lua provider #7

Autocomplete-Lua provider #7

pablomayobre commented Apr 15, 2017

rm-code commented Apr 15, 2017

rm-code commented Apr 15, 2017

pablomayobre commented Apr 15, 2017

rm-code commented Apr 25, 2017 •

edited

Loading

rm-code commented Apr 25, 2017

pablomayobre commented Apr 25, 2017 •

edited

Loading

pablomayobre commented Apr 25, 2017 •

edited

Loading

rm-code commented Apr 25, 2017

pablomayobre commented Apr 26, 2017 •

edited

Loading

pablomayobre commented Apr 26, 2017 •

edited

Loading

rm-code commented Apr 26, 2017 •

edited

Loading

rm-code commented Apr 26, 2017

rm-code commented Apr 29, 2017

pablomayobre commented Apr 29, 2017 •

edited

Loading

rm-code commented Apr 29, 2017

rm-code commented Apr 29, 2017

pablomayobre commented Apr 29, 2017

rm-code commented Apr 29, 2017 •

edited

Loading

rm-code commented Apr 29, 2017

pablomayobre commented Apr 29, 2017

rm-code commented Apr 29, 2017

pablomayobre commented Apr 29, 2017 •

edited

Loading

rm-code commented Apr 29, 2017

Autocomplete-Lua provider #7

Autocomplete-Lua provider #7

Comments

pablomayobre commented Apr 15, 2017

rm-code commented Apr 15, 2017

rm-code commented Apr 15, 2017

pablomayobre commented Apr 15, 2017

rm-code commented Apr 25, 2017 • edited Loading

rm-code commented Apr 25, 2017

pablomayobre commented Apr 25, 2017 • edited Loading

pablomayobre commented Apr 25, 2017 • edited Loading

rm-code commented Apr 25, 2017

pablomayobre commented Apr 26, 2017 • edited Loading

pablomayobre commented Apr 26, 2017 • edited Loading

rm-code commented Apr 26, 2017 • edited Loading

rm-code commented Apr 26, 2017

rm-code commented Apr 29, 2017

pablomayobre commented Apr 29, 2017 • edited Loading

rm-code commented Apr 29, 2017

rm-code commented Apr 29, 2017

pablomayobre commented Apr 29, 2017

rm-code commented Apr 29, 2017 • edited Loading

rm-code commented Apr 29, 2017

pablomayobre commented Apr 29, 2017

rm-code commented Apr 29, 2017

pablomayobre commented Apr 29, 2017 • edited Loading

rm-code commented Apr 29, 2017

rm-code commented Apr 25, 2017 •

edited

Loading

pablomayobre commented Apr 25, 2017 •

edited

Loading

pablomayobre commented Apr 25, 2017 •

edited

Loading

pablomayobre commented Apr 26, 2017 •

edited

Loading

pablomayobre commented Apr 26, 2017 •

edited

Loading

rm-code commented Apr 26, 2017 •

edited

Loading

pablomayobre commented Apr 29, 2017 •

edited

Loading

rm-code commented Apr 29, 2017 •

edited

Loading

pablomayobre commented Apr 29, 2017 •

edited

Loading