Rule-based preferences - format marker RFC, etc.

[Ian Clatworthy]

Harald Meland wrote:

> This seems a little strange to me.  I thought the idea of introducing
> this namespace keyword was to have the keyword somehow describe *how*
> the rest of the section name goes about matching a subset of your
> tree.

Thanks for your comments.

The keywords can certainly do that. They might also describe what the
name-value pairs are, e.g.

  [preferences *.html]
  keywords=escape

  [requires]
  bzr=1.8
  bzr-keywords=0.2

> Are you saying that this "for" keyword is meant to match the behaviour
> of e.g. a shell-script for loop?  If so, the support for "RE:" you
> mentioned earlier seems a poor match (no pun intended) to this shell
> analogy.

It wasn't meant to imply looping, just be readable.

> (BTW, given that we're going to have keywords anyway, wouldn't it make
> sense to separate the regular glob behavior of this "for" keyword from
> the extended regexp-match behaviour?)

It could, though I hesitant to break consistency with ignore patterns.
Breaking consistency is likely to confuse users and it complicates
the code.

> And, when you sometime in the future decide that you need to expand
> your keyword set, starting out with "for" seems very generic; if you
> e.g. decide that you want to allow users to specify their files by
> file-id, you add e.g. 'file-id' -- and then risk confusing users by
> having one match-mechanism-centered keyword and one "some kind of
> iteration, I guess" keyword.  How will users know that the "for"
> keyword doesn allow iteration over e.g. file-id prefixes?

I was imagining the pattern language being extended to support a
ID: prefix. In hindsight, that doesn't make sense because there's
no point ignoring something already assigned an ID and because
REs could also apply to them, in theory at least.

Without implementing any of these ideas now, the trick as you mention
is to decide what people might want in the future and pick a keyword
now that makes sense in the broader namespace. Easy, eh? :-)

It sounds like 'name' is a better choice than 'for'. That would fit
in nicely if keywords like 'id', 'type' and 'executable' were
useful later, e.g.

  [name *.bat]
  eol=dos

  [type symlink]
  ...

Ian C.