micro
micro copied to clipboard
feat: adds GetArg and GetWord methods to Buffer
Turns the GetArg function into a buffer object method to be used by lua plugins.
Example:
function init()
local config = import('micro/config')
config.MakeCommand('ex', function(bp, args) end, function(buf)
local cmds = { '-h', '--help' }
local input, argstart = buf:GetArg()
local completions = {}
local suggestions = {}
for _, a in pairs(cmds) do
local i, j = a:find(input, 1, true)
if i == 1 then
table.insert(suggestions, a)
table.insert(completions, a:sub(j + 1))
end
end
table.sort(completions)
table.sort(suggestions)
return completions, suggestions
end)
end
Closes #3111
Idk it seems to me other functions in the buffer/autocomplete.go
file looks like utility functions for internal usage of the micro which aren't intended to be used by the buffer itself so they aren't just functions and not methods of buffer
Is it really not imported? Idk where it is done but maybe it would more convenient to export it to lua (if it is still not exported).
What do you think? @dmaluka @JoeKar
I can add it to the buffer module to be used with import('micro/buffer')
like that:
local buffer = import('micro/buffer')
function complete(buf)
local input, argstart = buffer.GetArg(buf)
end
The main idea would be to make the GetArg function available so that lua plugins can build their own complete commands.
@dustdfg I added GetArg to the micro/buffer import
Exporting GetArg()
is most probably the most straight proposal. :+1:
I would actually prefer the first version, i.e. making GetArg
a buffer object method, to avoid unnecessary additions to the "primary" documentation in plugins.md
(to keep it small).
Also, if export GetArg
, why not export GetWord
as well?
@dmaluka
I also prefer the first for the same reason, in addition to avoiding an import and for me it makes more sense to buf:GetArg()
than buffer.GetArg(buf)
, but whatever the majority decides I support.
I also thought about exporting GetWord
, it would be a good idea, but I preferred to leave the changes minimal for what I needed. Maybe this is the right occasion for this, do I add GetWord
to the pull request?
I also exported GetWord so it could be used to build plugins
My vote is still for exporting GetArg and GetWord as buffer methods...
Me too, @dustdfg and @JoeKar, what do you think?
Me too, @dustdfg and @JoeKar, what do you think?
Ok maybe it is better. The functions are used only by buffer itself and is pretended to be used by Compliters
that get it as parameter so maybe.... Idk it feels a bit unnatural for me but does it really matter so much? Anyway I think it will be merged by @zyedidia (if it will be) so the last word of which style should be used doesn't belong to none of us
Hm, most probably I wasn't attentive enough in the moment I suggested to just export GetArg()
(and later GetWord()
highlighted by @dmaluka), because @dmaluka has his finger already in the wound:
buffer.GetArg(b)
used from package buffer
using a pointer to Buffer
as argument, which indeed looks strange in the moment directly compared to be a method of the same itself (b.GetArg()
) as already started with https://github.com/zyedidia/micro/commit/607922bc28757b5cfe1168ff982db669fe45a19d.
So @taconi I've to excuse, changed my mind and support your first and @dmaluka approach. Sorry that it took that long to respond and for the confusion.
Hopefully we will get to the point at which these changes don't rot at private branches/PRs any longer.
[...] Idk it feels a bit unnatural for me but does it really matter so much?
For me, the buffer itself should know how to fetch this information. It makes more semantic sense to ask the buffer to get the last word over the cursor (b.GetArg()
) than to ask a third party (buffer.GetArg(b)
).
I believe this is another unnecessary step towards creating completers.
I returned the PR to use via buf:GetArg()
, buf:GetWord()