One additional filter to keywords wanted

[Matt Mackall]

On Thu, 2012-02-16 at 12:58 -0800, Alexander Leschinsky wrote:
> 
> On Feb 17, 1:58 am, Matt Mackall <m... at selenic.com> wrote:
> > I don't think it's possible to introduce this into Mercurial proper
> > without introducing a concept of variables into queries.
> 
> Matt, I DID NOT ask for final ready-to-use implementation of such
> task.

To be frank, I had no idea what you were asking for.

>  It was only example of situation, where  converting output of
> {files} output to fileset will be helpful
> My mindflow
> 
> 1. We have to get intersection of two filesets for hg locate: a) added
> by user b) affected by last commit
> 2. Fileset for a-condition we must to get from revset, b-condition is
> ready to store fileset, we can save it in listfile: file
> 3. Clean output of files-only we'll get with macro {file_adds} in
> template
> 4. Pattern can use listfile:, but {file_adds} output data not in
> listfile format
> 
> BINGO! In we'll get listfile from `hg log` in listfile1 in 1st
> command( smth. like `hg log -r "author('user')" --template "{file_adds|
> listfile}"`), listfile2 from `hg locate -r tip` in 2nd command, 3-rd
> command `hg locate "set:listfile1 and listfile2"` will be final output

A closer reading of the command line templating chapter of the book will
reveal that this is already possible. It's just a nuisance, because
there's nothing like a join operator in the templating language and you
need to use a style file. We'd like to do:

 --template "{join(file_adds, '\n')}\n"

or even

 --template "{file_adds % '\n' }\n"

I actually rewrote the core templater to allow adding joins, ifs, inline
subtemplates, etc. and then ran into the fact that the command line
templater has a horrible short-sighted hack that makes its list
processing completely different from hgweb and actually fixing it a
bloody nuisance.

So no, we won't add your template hack to make the current command line
template hack more usable. No more hacks, it's time to clean it up.


Also note that your file_adds approach is really slow given the way
file_adds actually works. It's much more efficient to trace the history
of individual files one by one as in my answer to the SO question.

-- 
Mathematics is the supreme nostalgia of our time.