Futher improve the completion.

[skx]

We've had a recent improvement of TAB-completion implemented in #328, this allowed us to operation specific completions:

• Completion of file/directory-pathes
  • Including spaces.
• Completion of email-addresses
  • Via an external program (e.g. lbdb).
• Completion of lua code

Unfortunately these improvements have come at a cost, the general get_line no longer has all these completions by default. The current assumption is that you'll complete on one of these approaches - which makes a lot of sense, when you're composing an email you're only going to complete on an email-address, and when you're adding an attachment you're only going to complete on a (file) path.

It should be possible to improve the current situation a little more, even if that involves a revert of some/all the code. Completing on paths with spaces, for example, would have been a trivial bug to resolve if it had been reported initially.

I like the context-based completion, and I suspect we could make the read-line completion default to completing against all known contexts to restore the previous behavior of being able to complete things like:

• return_report("steve@example.com" )
• process_today( "/home/steve/Maildir/Automated-root/")

[fischerling]

Completing on paths with spaces, for example, would have been a trivial bug to resolve if it had been reported initially.

Not want to argue with you but this was not trivial. The token split was done in c++ and is reasenable for lua but not for file paths.

If you are just nor pleased by complete_lua and complete_shell, which I have to admid I use not that often, then I think the easiest solution is to add paths and addresses on top of it by default.

do lua completions stuff

_, paths = complete_path(lua_token)
_, addresses = complete_address(lua_token)

add them to the lua completions

same for shell completions.

[skx]

Yeah the problem is that I do use the lua & shell completion a lot - which is why I noticed this morning it was all failing for me. Doing the split in lua, instead of C++ shouldn't be too hard, the problem is really deciding what the right result should be.

I think it is obvious that:

• Completing Lua function-names is important.
• Completing paths, quoted or not, is important.
  • And we need to cope with spaces in paths.
• Completing email-addresses, whether read from a file, or an external process, is definitely useful.
  • I'd done something similar though I used a flat-file.

Having the ability to complete specific things in a specific way - i.e. only email addresses, or only paths, is a great addition - but the default of completing "everything" I think I realize now must be present.

[fischerling]

When would you use complete "everything" ?
By default on Screen:get_line ? This would be to much 10 out of 11 times.

A get_everything is really easy just use set_completion_context("path", "address", "lua", "path"). This will only complete filepaths at the start of the line.

What is wrong with just add addresses and paths to lua and shell by default ?

[skx]

I frequently type ! to execute shell-commands, many of which operate on the current filename so I'll type things like:

 !/bin/blah Global:current_message():path()

I also invoke Lua functions with files/paths/objects as arguments - so:

 :blah( "~/foo.txt" )

Or:

:process_message( "steve@example.com");

Completing paths/things only at the start of a line isn't enough for those last things.

It might be too much to complete all tokens, but it is something that used to be available and something I relied upon. So it needs to come back. I'll take a look at your suggestion early next week, if adding all the contexts works then that's good. Though I still need to be able to complete paths as arguments to Lua functions - from the :-prompt, and they will be quoted as they are Lua arguments, so that needs to work.

(That's why the split was done in the C++ code, it might be something ilke that needs to come back. It wasn't so hard to write in C++.)

[skx]

PS. Perhaps an alterantive:

• If i reverted the recent changes 100%
  • But fixed path-completion with spaces
  • And allowed email lookups via an external program

Would that be enough to make you happy?

[fischerling]

Though I still need to be able to complete paths as arguments to Lua functions - from the :-prompt, and they will be quoted as they are Lua arguments, so that needs to work.

This works with #336.

I think I would be fine. But the current design has some advantages:

• No enforced tokens. Each context decide on its own how to complete
• Smaller "blocks" are easier to extend and combine in the user config
• Completion of relative paths

[skx]

• No enforced tokens. Each context decide on its own how to complete
  • This is nice.
• Smaller "blocks" are easier to extend and combine in the user config
  • Sure, but also we could have just added a hook function or a user-table to get the same effect.
• Completion of relative paths
  • This is nice, but I could personally live without it. I tend to use "~/[TAB]" to get my prefix, or even "/tm[TAB]" if I'm working with temporary files.
  • Calling out to /bin/pwd is definitely a mistake though. I suspect we need primitives for getting/setting the process-wide CWD exported from C++.
  • If only to avoid injection attacks.

[skx]

I've tried several approaches here over the past few days, but all of them are terrible.

I've not forgotten though, every time I hit TAB I remember!