Sun, 24 Apr 2016 18:41:23 +0900 templatekw: add new-style template expansion to {manifest}
Yuya Nishihara <yuya@tcha.org> [Sun, 24 Apr 2016 18:41:23 +0900] rev 34330
templatekw: add new-style template expansion to {manifest} The goal is to allow us to easily access to nested data. The dot operator will be introduced later so we can write '{p1.files}' instead of '{revset("p1()") % "{files}"}' for example. In the example above, 'p1' needs to carry a mapping dict along with its string representation. If it were a list or a dict, it could be wrapped semi-transparently with the _hybrid class, but for non-list/dict types, it would be difficult to proxy all necessary functions to underlying value type because several core operations may conflict with the ones of the underlying value: - hash(value) should be different from hash(wrapped(value)), which means dict[wrapped(value)] would be invalid - 'value == wrapped(value)' would be false, breaks 'ifcontains' - len(wrapped(value)) may be either len(value) or len(iter(wrapped(value))) So the wrapper has no proxy functions and its scope designed to be minimal. It's unwrapped at eval*() functions so we don't have to care for a wrapped object unless it's really needed: # most template functions just call evalfuncarg() unwrapped_value = evalfuncarg(context, mapping, args[n]) # if wrapped value is needed, use evalrawexp() maybe_wrapped_value = evalrawexp(context, mapping, args[n]) Another idea was to wrap every template variable with a tagging class, but which seemed uneasy without a static type checker. This patch updates {manifest} to a mappable as an example.
Mon, 24 Apr 2017 21:37:11 +0900 templater: adjust binding strength of '%' and '|' operators (BC)
Yuya Nishihara <yuya@tcha.org> [Mon, 24 Apr 2017 21:37:11 +0900] rev 34329
templater: adjust binding strength of '%' and '|' operators (BC) This makes 'foo|bar%baz' parsed as '(foo|bar)%baz', not 'foo|(bar%baz)'. Perhaps it was a mistake that '%' preceded '|'. Both '|' and '%' can be considered a kind of function application, and '|' is more like a '.' operator seen in OO languages. So IMHO '|' should have the same (or higher) binding as '%'. The BC breakage should be minimal since both '|' and '%' operators have strict requirements for their operands and 'foo|bar%baz' was invalid: - right-hand side of '|' must be a symbol - left-hand side of '%' must be a dict or list - right-hand side of '%' must be a string or symbol
Sun, 24 Sep 2017 15:22:46 +0900 templatekw: just pass underlying value (or key) to joinfmt() function
Yuya Nishihara <yuya@tcha.org> [Sun, 24 Sep 2017 15:22:46 +0900] rev 34328
templatekw: just pass underlying value (or key) to joinfmt() function Before, iter(hybrid) was proxied to hybrid.gen, which generated formatted strings. That's why we had to apply joinfmt() to the dicts generated by hybrid.itermaps(). Since this weird API was fixed at a0f2d83f8083, we can get rid of the makemap() calls from join().
Sun, 24 Sep 2017 12:43:57 +0900 scmutil: extract helper functions that returns human-readable change id
Yuya Nishihara <yuya@tcha.org> [Sun, 24 Sep 2017 12:43:57 +0900] rev 34327
scmutil: extract helper functions that returns human-readable change id We do "'%d:%s' % (ctx...)" at several places, so let's formalize it. A low- level function, formatrevnode(ui, rev, node), is extracted so we can pass a manifest rev/node pair. Note that hex() for manifest output can be replaced with hexfunc() because it is printed only when debugflag is set. i18n/de.po is updated so test-log.t passes with no error.
Sat, 02 Sep 2017 23:13:54 +0900 templater: extract helper to just evaluate template expression
Yuya Nishihara <yuya@tcha.org> [Sat, 02 Sep 2017 23:13:54 +0900] rev 34326
templater: extract helper to just evaluate template expression A named function can be easily grepped and is probably good for code readability.
Sat, 02 Sep 2017 23:09:34 +0900 templater: do not destructure operands in buildmap()
Yuya Nishihara <yuya@tcha.org> [Sat, 02 Sep 2017 23:09:34 +0900] rev 34325
templater: do not destructure operands in buildmap() This makes the next patch slightly simpler.
(0) -30000 -10000 -3000 -1000 -300 -100 -30 -10 -6 +6 +10 +30 +100 +300 +1000 +3000 +10000 tip