Re: [PATCH 1/1] Squashed commit of the following:

[Doron Behar <doron.behar@xxxxxxxxx>]

Thanks again for you reply Oliver, I'll get to the issue of `ret` later
since I might need your advice on the matter of installed rocks' cache
policy function:

You asked me in one of the previous mails whether it is possible or not
to query luarocks instead of hard-coding the paths of the manifest
files. To your reminder, I compared their last modified date (Thanks to
you with `-nt` rather then `date -r`) with that of the cache files, here
is the original version after changing to `-nt`:

	(( $+functions[___luarocks_installed_rocks_cache_policy] )) ||
	___luarocks_installed_rocks_cache_policy(){ local cache_file="$1"
	  # TODO: use luarocks config to get these paths according to luarocks 
	  local user_manifest_file="${HOME}/.luarocks/lib/luarocks/rocks-5.3/manifest"
	  local system_manifest_file="/usr/lib/luarocks/rocks-5.3/manifest"
	  if [[ -f ${user_manifest_file} ]] || [[ -f ${system_manifest_file} ]]; then
	    if [[ -f ${cache_file} ]]; then
	      # if either one of the manifest files is newer then the cache:
	    if [ ${user_manifest_file} -nt ${cache_file} ] || [ ${system_manifest_file} -nt ${cache_file} ]; then
	      (( 1 ))
	    else
	      (( 0 ))
	      fi
	    else
	      (( 1 ))
	    fi
	  else
	    (( 1 ))
	  fi
	}

The good news as for the TODO comment I wrote there is that it is
possible to do so: Using `luarocks config --lua-ver` for the version
(now hard-coded to 5.3) and `luarocks config --rock-trees`.

However, the bad news is that I'm afraid that calling `luarocks config`
twice like that whenever I query the cache validity, is a huge
performance hit.

The solution which will most likely best solve this issue is to use a
similar cache mechanism for these values as well. This *inner* cache's
validity should be checked against the cache files' and the luarocks
configuration files (system and user) modification date. What makes this
even more complicated is the fact that the locations of the user and
system configuration file can be queried for that as well. And yet
again, even running `luarocks` twice for getting these values will bring
a performance hit as well.

Anyway, I've come to the conclusion that I'll need to write inside this
cache policy function what's written in the cache related functions
(mostly `_store_cache` and `_retrieve_cache`) and customise it for my
parameters, it'll take some time so I'll send it here when it is ready.
I think it's better to take care of `ret` afterwards.

On Wed, May 30, 2018 at 05:43:07PM +0200, Oliver Kiddle wrote:
> Doron Behar wrote:
> > O.K, I used `ret` instead yet currently I don't see any use in this
> > variable since I didn't structured the completion file with `return ret`
> > at the end of any of the functions as I've seen in other completion
> > functions I read.
> 
> You need something like it in the final function. You're calling
> _arguments and ignoring the return status from it. This can break things
> - approximate completion mostly.
> 
> It's only really that function where you need it.
> 
> > Jesus, using `zstyle` is complicated, I hope I'll master this skill one
> > day..  Where can I find in the documentation more explanations about the
> > relation between zstyle and completion functions?
> 
> It looks worse than it is. You can see the styles and contexts for a
> particular completion by pressing Ctrl-X h instead of Tab. With a
> numeric argument (Escape 1 for emacs mode) it provides more detail.
> 
> Oliver