Improve completion

[fischerling]

I was annoyed because I couldn't complete file paths with spaces in them.
After reading the code I realized that I can't fix this because the c++ code makes assumption where to
complete.

So I came up with a more generic fix. Completions are now context aware.
To achieve this the function 'on_complete' now behaves like a filter for the line buffer used in CSreen:get_line. It calls the active context specific functions, which are called complete_context, collects their results, builds and returns the buffer.

This change comes with three contexts:

• address: using an external addressbook to complete email addresses
• path: complete file paths now even if they contain white space :)
• lua: no real changes here

What do you think ? It is really complicated but it's the best I came up with.

[skx]

Good catch :)

[skx]

What do you think ? It is really complicated but it's the best I came up with.

I think it's a great idea, but I'd need to read the commits carefully before accepting. Thanks again for a great idea, that looks sane at first glance.

It might be the weekend before I have free time to review, but so far it looks great :)

[skx]

Merged - with a couple of new issues filed.

• PATH completion no longer adds trailing / #331
• Completion prompts unnecessarily if only one choice. #330

Also suddenly realized that I cannot complete "save_attachment( "/home/skx/blah" )" as neatly as in the past - the Lua-completion won't complete the path-name in the argument, which used to be possible.

[fischerling]

You can use the file completion in the lua context like this:

do
  local _complete_lua = complete_lua

  complete_lua = function(buffer)

    local token, ret = _complete_lua(buffer)
    local _, comps = complete_path(token)
    for _, comp in ipairs(comps) do
      table.insert(ret, comp)
    end
    return token, ret
  end
end

[skx]

The more I use this new code the less I'm happy with it. I think it is obvious that your intention was a good one, and I can see the value in the context-based approach.

I just keep finding things that are odd. Like I want to complete an email address in my Lua function names - from my local address-book - and that is now failing because the completion of "emails" is distinct from the completion of "lua".

(i.e. I want to complete "process_reports( "steve@example.com" )" by only typing:

• ":pro[TAB]"
• "ste[TAB]"
• ")

Similarly typing "!" to execute a Unix command now no longer has completion because it isn't hooked up to the path function.

I'm torn between reverting it, and the previous commits, or trying to overhaul a third time :(

[skx]

We could merge the completions, such that they'd attempt all possible contexts, but thats the only straightforward solution I see.

i.e. "complete_path" could complete "/blah" - but would ignore anything not starting with "/"
i.e. "complete_eamil" could complete "foo@" - but would ignore any non-match
i.e. "complete_lua" could complete "compl" - but would ignore non-matches

Then we'd choose from the union. It seems like there should be no collisions, and this would allow "general" completion. Of course in some situations (adding attachments), or forward/compose we could use the more specific approaches.

[fischerling]

All contexts are distinct by default. You can extend your lua context with all the other contexts if you like.

Just add them to the returned table of complete_lua with the token complete_lua returns.

[skx]

I agree that it is possible, but what I'm trying to say is that by default we should be completing against all contexts - to give us back the kind of completion we had previously.

(As well as the new abilities which you've added.)

[fischerling]

We could also add other completions to complete_lua by default.

The Problem with the union approach I see is that we have to use different token for different contexts.
i.e white space is allowed in paths but is a seperator for lua code.

And the seperated building blocks are easier to extend than a union function.

We have to situations with "broader" completions: lua and shell
And two with "narrower" completions: email and paths

For shell I didn't write completions because I didn't know the seperators to split on.
But we can easily add a function splitting on the same chars as lua '(' and ' ' and ',' and run complete_{path, address} with it.

[skx]

Yeah the problem is that lua-arguments can be "anything", which certainly includes (quoted) email-addresses, and paths.

I've filed a bug to update/change the handling as #334 and we can discuss/experiment there.