[only RFC, not merge] Second implementation of the "commit templates" feature
Adeodato Simó
dato at net.com.org.es
Mon Aug 14 02:47:23 BST 2006
* Adeodato Simó [Thu, 10 Aug 2006 21:43:25 +0200]:
> only John's comment about StringIO/bzrlib.user_encoding() is left
> temporarily unaddressed, I believe
Ah, I understand the involved issues now. Not that it helps much,
though, since now I understand the trickyness of the situation as well. ;-)
Basically, it boils down to:
- commit templates should provide their infotext() as an unicode()
object, since that's what edit_commit_message() wants.
- however, not all commit templates are able to do that. In particular,
the "diff" bit can't, because it can't really assume that the contents
are in bzrlib.user_encoding (cmd_diff has encoding_type = 'exact',
not 'strict').
Because of the above:
- commit templates will probably need an encoding_type member, like
Command (because of this I'll probably move _CommitTemplateBit to
being a public class, and have register_commit_template receive an
instance of it instead of a function, or something).
- I was initially happy to see that I could make use of
edit_commit_message() without any API breaking. However, it now has
to support receiving str() instead of unicode(), and it's going to
end up ugly, so I'm thining I'll refactor code in edit_commit_message()
into CommitTemplateFile or so, and will leave a dummy deprecated
implementation of edit_commit_message(), as I did with
make_commit_message_template().
Suggestions or comments always welcome.
Cheers,
--
Adeodato Simó dato at net.com.org.es
Debian Developer adeodato at debian.org
Listening to: Mecano - Dalí
More information about the bazaar
mailing list