FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 30 Mar 2016 02:10:44 +0900] rev 28695
registrar: add templatefunc to mark a function as template function (API)
This patch also adds loadfunction() to templater, because this
combination helps to figure out how they cooperate with each other.
Listing up loadfunction() in dispatch.extraloaders causes implicit
loading template function at loading (3rd party) extension.
This patch explicitly tests whether templatefunc decorator works as
expected, because there is no bundled extension, which defines
template function.
This change requires that "templatefunc" attribute of (3rd party)
extension is registrar.templatefunc or so.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 30 Mar 2016 02:10:44 +0900] rev 28694
keyword: use templatefilter to mark a function as template filter
This patch also adds test for filter 'svnisodate' and 'svnutcdate' for
safety, because there is no test using them, yet.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 30 Mar 2016 02:10:44 +0900] rev 28693
templatefilters: use templatefilter to mark a function as template filter
Using decorator can localize changes for adding (or removing) a
template filter function in source code.
This patch also removes leading ":FILTER:" part in help document of
each filters, because using templatefilter makes it useless.
This patch uses not 'filter' but 'templatefilter' as a decorator name,
because the former name hides Python built-in one, even though the
latter is a little redundant in 'templatefilters.py'.
FUJIWARA Katsunori <foozy@lares.dti.ne.jp> [Wed, 30 Mar 2016 02:10:44 +0900] rev 28692
registrar: add templatefilter to mark a function as template filter (API)
This patch also adds loadfilter() to templatefilters, because this
combination helps to figure out how they cooperate with each other.
Listing up loadfilter() in dispatch.extraloaders causes implicit
loading template filter functions at loading (3rd party) extension.
This change requires that "templatefilter" attribute of (3rd party)
extension is registrar.templatefilter or so.
Yuya Nishihara <yuya@tcha.org> [Sun, 14 Feb 2016 20:43:30 +0900] rev 28691
revset: inline _getaliasarg() function
This function is now much simpler than before. Inlining small functions helps
to extract a reusable alias processor.
Yuya Nishihara <yuya@tcha.org> [Sun, 14 Feb 2016 20:27:08 +0900] rev 28690
revset: drop redundant check for unknown alias arguments
Since _parsealiasdefn() rejects unknown alias arguments, _checkaliasarg() is
unnecessary. New test is added to make sure unknown '$n' symbols are rejected.
Yuya Nishihara <yuya@tcha.org> [Sun, 14 Feb 2016 19:48:33 +0900] rev 28689
revset: move tagging of alias arguments from tokenization to parsing phase
In short, this patch moves the hack from tokenizedefn() to _relabelaliasargs(),
which is called after parsing. This change aims to eliminate tight dependency
on the revset tokenizer.
Before this patch, we had to rewrite an alias argument to a pseudo function:
"$1" -> "_aliasarg('$1')"
('symbol', '$1') -> ('function', ('symbol', '_aliasarg'), ('string', '$1'))
This was because the tokenizer must generate tokens that are syntactically
valid. By moving the process to the parsing phase, we can assign a unique tag
to an alias argument.
('symbol', '$1') -> ('_aliasarg', '$1')
Since new _aliasarg node never be generated from a user input, we no longer
have to verify a user input at findaliases(). The test for _aliasarg("$1") is
removed as it is syntactically valid and should pass the parsing phase.