man it's been a slow day... I've only made about 15~16 commits on tpsh, one of which was merging branches lol. The main focuses of today's tinkering has been minor bugfixes (mostly related to and tweaking the completion function.

Previously my completer would just take a quick approach, but always doing completions for built in commands, stored macros, known programs, and filenames. Now it has some notion of *what* it should complete.

$ b^I -> assume it can be anything
$ echo b^ -> assume it's a file (formally a full eval() was done)
$ builtin l^I -> complete built-in commands
$ alias x -> complete to names in %Macros.



When I get the time, I want to make the completion function have a more hot-plug-in nature to it. A pre-completion hook, completion hook, and post-completion hook; the pre getting to modify the thing before completion, the completion hook being able to totally replace do_completion() aside from the pre/post hooks; and the post-hook having a change to modify the completions being returned. The current working idea is: a TPSH_WHAT_HOOK environment variable being set to A. perl code to generate a CODE ref from, or B. an external program to delegate to. (e.g. TPSH_COMPLETION_HOOK="compl.rb" would pass compl.rb the necessary data, and expect the program to generate a \n delimited list on its stdout for tpsh to parse). Odds are there will be more variables to tune it with later, as well as the API avail. being documented in the manual page My main reason for desiring this style of dynamically configurable completion is so I could do things like, seting up my tpshrc to "ignore" any 'lost+found' entries in filename completions; i.e. /usr/local/l^I expands to /usr/local/local not /usr/local/lo - completion list for local / lost+found. I know the zsh (which I use a lot) is noted for it's configurable completion and spelling correction, but honestly I've never customized it beyond the lines zsh's setup program added to my rc, let along RTFM'd about it lol.

Making it easy to add command sensitive completions through the hooks would be nice too, e.g. `man 2 foo^I` and have a hook spot the man 2 and go about completing foo to manual pages in section 2, hehe. (the only zsh feature I abuse, actually lol)


Really what needs doing atm in tpsh, is cleaning up the lex/eval subroutines and merging them and a few related changes with resolve_cmd(). Basically the principal adjustment needed is to go from line-based handling of commands, to (properly) breaking them lexically for storage into an execution queue. Generally though I like how stuffs coming along, except for a few odds and ends here and there.



At one point,tpsh relied on a list of "this command marks something to skip macro expansion on", a quick solution until expand_aliases() could be rewritten. One night I found myself working on a scratch file with commands to modify said list (add, rm, and show the non expanding commands list via expr or array slice/index). That's when I threw my hands up in disguest, and decided tomorrows job would be fixing expand_aliases (note to self: s/aliases/macro/). Imagine if you tried to type 'unalias ls' and the shell expanded ls to it's aliased value, that kinda stuff. Kind a cool to be able to configure that, but kinda wrong to need a linear look up on each pass through the loop (ugh!).


To add built-in commands to manipulate said list rather then fix the problem, just was not something I was NOT willing to do... because to my eyes, it would be like a pox on my honour as a programmer: to gamma-weld such a cheap trick into place with built in commands to configure and abuse it rather then fix it -- thus the macro expansion system got re-implemented, much more correctly this time. (didn't have time to sort positional params and what nots).




I am also VERY glad that tpsh is being developed with git, rather then cvs! (I've also spent part of tonight learning more about gits plumbing)