From: Doron Behar <doron.behar@gmail.com>
To: zsh-workers@zsh.org
Subject: Re: [PATCH 1/1] Squashed commit of the following:
Date: Fri, 1 Jun 2018 10:18:54 +0300 [thread overview]
Message-ID: <20180601071850.4z3h6cvkuvva3nby@NUC.doronbehar.com> (raw)
In-Reply-To: <16604.1527694987@thecus>
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
next prev parent reply other threads:[~2018-06-01 7:18 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-05-26 16:14 [PATCH 0/1] *** Add luarocks completion *** doron.behar
2018-05-26 16:14 ` [PATCH 1/1] Squashed commit of the following: doron.behar
2018-05-28 10:48 ` Oliver Kiddle
2018-05-29 15:38 ` Doron Behar
2018-05-29 22:00 ` Oliver Kiddle
2018-05-30 12:47 ` Doron Behar
2018-05-30 15:43 ` Oliver Kiddle
2018-06-01 7:18 ` Doron Behar [this message]
2018-06-01 13:30 ` Doron Behar
2018-06-01 22:45 ` Oliver Kiddle
2018-06-03 21:46 ` Daniel Shahaf
2018-06-05 15:41 ` Doron Behar
2018-06-07 15:59 ` Oliver Kiddle
2018-06-07 16:20 ` Doron Behar
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20180601071850.4z3h6cvkuvva3nby@NUC.doronbehar.com \
--to=doron.behar@gmail.com \
--cc=zsh-workers@zsh.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
Code repositories for project(s) associated with this public inbox
https://git.vuxu.org/mirror/zsh/
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).