Currently, the templating layer tends to treat each namespace
as a one-off, with explicit usage of {bookmarks}, {tags}, {branch},
etc instead of using {namespaces}. It would be really useful if
we could iterate over namespaces and operate on them generically.
However, some consumers may wish to differentiate namespaces by
whether they are built-in to core Mercurial or provided by extensions.
Expected use cases include ignoring non-built-in namespaces or
emitting a generic label for non-built-in namespaces.
This commit introduces an attribute on namespace instances
that says whether the namespace is "built-in" and then exposes
this to the templating layer.
As part of this, we implement a reusable extension for defining
custom names on each changeset for testing. A second consumer
will be introduced in a subsequent commit.
Due to a quirk of our module importer setup on Python 3, all calls and
definitions of methods named iteritems() get rewritten at import
time. Unfortunately, this means there's not a good portable way to
access these methods from non-module-loader'ed code like our unit
tests. This change fixes that, which also unblocks test-manifest.py
from passing under Python 3.
We don't presently define any itervalues methods, or we'd need to give
those similar treatment.
Before this patch, revset predicate "tag()" and "named('tags')" differ
from each other, because the former doesn't include "tip" but the
latter does.
For equivalence, "named('tags')" shouldn't include the revision
corresponded to "tip". But just removing "tip" from the "tags"
namespace causes breaking backward compatibility, even though "tip"
itself is planned to be eliminated, as mentioned below.
http://selenic.com/pipermail/mercurial-devel/2015-February/066157.html
To mask specific names ("tip" in this case) for "named()" predicate,
this patch introduces "deprecated" into "namespaces", and makes
"named()" predicate examine whether each names are masked by the
namespace, to which they belong.
"named()" will really work correctly after 3.3.1 (see a3c326a7f57a for
detail), and fixing this on STABLE before 3.3.1 can prevent initial
users of "named()" from expecting "named('tags')" to include "tip".
It is reason why this patch is posted for STABLE, even though problem
itself isn't so serious.
This may have to be flagged as "(BC)", if applied on DEFAULT.
Before this patch, "_()" is used incorrectly for "tag:" and
"bookmark:" fields. "changeset_printer()" looks up keys composed at
runtime, and it prevents "xgettext" command from getting strings to be
translated from source files.
Then, *.po files merged with updated "hg.pot" lose msgids for "tag:"
and "bookmark:".
This patch introduces "logfmt" information into "namespace" to show
l10n-ed messages "hg log" (or "changeset_printer()") correctly.
For similarity to other namespaces, this patch specifies "logfmt" for
"branches" namespace, even though it isn't needed (branch information
is handled in "changeset_printer()" specially).
To find related code paths out easily, this patch adds "i18n: column
positioning ..." comment to the line composing "logfmt" by default,
even though this line itself doesn't contain any strings to be
translated.
Previously, there was no way to change the color label used for 'hg log'
output. This patch just adds the member to the object, a future patch will
change 'hg log' to use this.
Previously, there was no way to change the name used for 'hg log' output. This
was inconvenient for extensions that want a template name longer than 12
characters (e.g. remotebookmarks) but a different name for 'hg log'.
This patch only adds the member to the object, a future patch will update the
'hg log' code.
Previously, in the namespaces api, the only caller of branchtip was singlenode
which happened to raise the same exception that branchtip raised: KeyError.
This is a minor change but will allow upcoming patches to use repo.branchtip to
not raise an exception if a branch doesn't exist. After that, it will be
possible for extensions to use the namespace api in a stable way.
Iterating over all the namespaces is a common operation, naturally, so we add
those methods now. Since we are using a sorted dictionary, this method just
calls the underlying __iter__ or iteritems method.
Currently, we have no way to list all the names in a given namespace. This is
needed for things such as tab completion. Future patches will use this patch
for exactly that purpose.
Now that there is an object for each individual namespace, we use the
templatename property on that object instead of the method on the collection of
namespaces.
Since the namespaces object uses an underlying (sorted) dictionary to store the
namespaces, it makes sense to expose this to naturally gain access to those
namespaces.
This isn't as bad as the diff seems, it only looks like scary. In this patch,
we use the 'namespace' object instead of accessing keys in a dictionary.
This required the 'templatename' and 'names' method to change their
implementation. Later, we will remove these functions entirely due to a better
api.
Currently, we use a dictionary object to store the namespace properties. This
is python so let's use an object. This will allow us to be more flexible in our
method signatures in the future.
For any namespace, we generate a template keyword. For example, given a
namespace 'babar', we automatically have the ability to use it in a template:
hg log -r . -T '{babars % "King: {babar}\n"}'
Furthermore, we only generate this keyword for a namespace if one doesn't
already exist. This is necessary for 'branches' and 'bookmarks' since both of
those have concepts of 'current' (something outside the namespace api) and also
allows extensions to override default behavior if desired.
This patch adds a node-to-name map property to the namespace. This is necessary
because we cannot simply invert the name-to-node map because we do not assume
the name-to-node map to be unique (for example, consider named branches: many
nodes have one branch name).
The node-to-name is helpful in log commands where we are already iterating over
a set of nodes and want to display some kind of naming information to the user.
This patch adds the public api for getting the template name of a namespace so
that the next patch can use it to generate a template keyword automatically.
The template name property will be used in upcoming patches to automatically
generate a template keyword. For example, given a namespace called 'babars', we
will automatically generate a template keyword 'babar' such that we can use it
in the following way,
$ hg log -r . -T '{babars % "King: {babar}\n"}'
Note that the exception-catching from the previous branchtip check is moved up
to catch exceptions from the try block surrounding the namespace lookup.
It turns out that maintaining a reference of any sort (even weak!) to the repo
when constructed doesn't work because we may at some point pass in a repoview
filtered by something other than what the initial repo was.
This marks the first use of abstracting our different types of named objects
(bookmarks, tags, branches, etc.) and upcoming patches will use this to
simplify logic.
This patch begins the work to provide a way to register a namespace to handle
'names'. Benefits of this would be,
- improved templating: This would provide {name} which could output any branch,
bookmark, tag, or any extension registered namespace all without having the
extension doing any extra work
- improved tab completion: Since this provides a single source of all 'names',
tab completion would not need to know of each namespace
- changeset lookup: Similar to before, a unified place to get all 'names' will
allow finding changesets without any extension code having to reimplement
this
Also, 6c946e059d3b has shown us that for internal code which expects a certain
type of method or behavior, we should provide an easy way for extensions to
check this behavior.
