rm-code / love-atom Goto Github PK

Visual Studio Code has a Lua Debugger.

Maybe it can be adapted to Atom!?

https://marketplace.visualstudio.com/items?itemName=devCAT.lua-debug

This should start with textstring. Looking at the love-api this also should have generated correctly.

This is a feature request, which would be fairly easy to add to this package.

Changing line 50 in the generator to

arguments[#arguments].displayName = string.format( '[%s=%s]', v.name, v.default )

This would autocomplete functions like:

love.graphics.printf(string,x, y, [align=left], [r=0], [sx=1], [sy=sx], [ox=0], [oy=0], [kx=0], [ky=0])

Note that the argument list can become quite long, so this should be carefully considered

This bug seems to be specifically and uniquely related to the love.filesystem.getInfo call. Unlike other LÖVE calls, this one returns a table with named fields inside of it. As soon as any field is accessed in the results (not necessarily an existing field, but just a field from the results), the entire autocomplete suite (not just love-atom) stops responding after the first character is typed.

The same issue does not occur if you call any other function that returns a table. I've also tested writing my own function that returned a table with named fields, but it works fine. Accessing these fields using brackets does not solve the issue. Disabling the love-atom package does solve the issue.

Instead of using the "snippets" functionality this plugin should make use of the Provider API.

This would make the system more flexible and probably faster too. As far as I can tell it would require a cson or json format for the snippets.

By using a custom prefix it should be possible to improve the suggestions:

https://github.com/atom/autocomplete-plus/wiki/Provider-API#generating-a-new-prefix

When I define a variable that links to some love-module, autocomplete will work with this variable and it's awesome! But if it is a global variable which is defined from separate file, autocomplite will not work. :( I realy want to use a global reductions for all my project. Like this:

ld  = love.data
le  = love.event
lfs = love.filesystem
lf  = love.font
lg  = love.graphics
li  = love.image
lj  = love.joystick
lk  = love.keyboard
lm  = love.mouse
lp  = love.physics
ls  = love.sound
lsy = love.system
lth = love.thread
lt  = love.timer
lto = love.touch
lv  = love.video
lw  = love.window
lu  = require "lume"
lu.extend(math, love.math)

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

Failed to activate the love-atom package
Cannot find module 'fuzzaldrin'
Traceback:
Error: Cannot find module 'fuzzaldrin' at Module._resolveFilename (module.js:455:15) at Module._resolveFilename (/usr/lib/electron/resources/electron.asar/common/reset-search-paths.js:35:12) at Function.Module._resolveFilename (/usr/lib/atom/src/module-cache.js:383:52) at Function.Module._load (module.js:403:25) at Object.<anonymous> (/home/clyybber/.atom/packages/love-atom/lib/love-provider.coffee:3:11) at Object.<anonymous> (/home/clyybber/.atom/packages/love-atom/lib/love-provider.coffee:1:1) at Module.load (module.js:473:32) at tryModuleLoad (module.js:432:12) at Function.Module._load (module.js:424:3) at Object.<anonymous> (/home/clyybber/.atom/packages/love-atom/lib/love-atom.coffee:2:16) at Object.<anonymous> (/home/clyybber/.atom/packages/love-atom/lib/love-atom.coffee:2:1) at Module.load (module.js:473:32) at tryModuleLoad (module.js:432:12) at Function.Module._load (module.js:424:3) at Package.module.exports.Package.requireMainModule (/usr/lib/atom/src/package.js:721:27) at Package.module.exports.Package.activateNow (/usr/lib/atom/src/package.js:173:16) at /usr/lib/atom/src/package.js:156:32 at Package.module.exports.Package.measure (/usr/lib/atom/src/package.js:92:15) at /usr/lib/atom/src/package.js:149:26 at Package.module.exports.Package.activate (/usr/lib/atom/src/package.js:146:34) at PackageManager.module.exports.PackageManager.activatePackage (/usr/lib/atom/src/package-manager.js:530:21) at /usr/lib/atom/src/package-manager.js:511:29 at Config.module.exports.Config.transactAsync (/usr/lib/atom/src/config.js:337:18) at PackageManager.module.exports.PackageManager.activatePackages (/usr/lib/atom/src/package-manager.js:506:19) at PackageManager.module.exports.PackageManager.activate (/usr/lib/atom/src/package-manager.js:489:46) at /usr/lib/atom/src/atom-environment.js:779:28

I think that this package could have a good spec. Even though it's pretty simple, testing could be leveraged to a CI to make sure that nothing breaks from a release to the next. This would help to reduce problems in future PRs, when changing the version of love-atom or when a change in atom-autocomplete-lua breaks something.

The test would run with apm test, would install atom-autocomplete-lua and love-atom and then would get the suggestions from atom-autocomplete-lua somehow. I'll explore this stuff and gather the info here.

Testing is currently kinda awkward since you need to disable the real love-atom and install the fork as a development package, I would love to be able to push commits and see if they build in a CI service

Looks like it affects only those constructors that have multiple variants 👍

Hi,
I tried to get the autocompletion running and it simply didn't work.
Checked the console for "Activate LOVE-Provider. Baby don't hurt me!" which was there.

After searching for any configuration I simply added the "language-lua" package in addition and now the autocompletion works.
If think most of the time people will have "language-lua" installed if they work with Lua, but if its really a dependency, it should be mentioned in the README.md or added to the plugins dependencies which will get automatically installed.

namely, most getters seems to be missing it, because with no arguments presumably you don't notice that it isn't there in the first place.

I'm using it in lua-lsp instead of atom, but this causes issues from my perspective: a no-argument function probably isn't a method and making the distinction would be nice~