On 9/4/2013 2:40 PM, Stephan Beal wrote:
On Wed, Sep 4, 2013 at 11:07 PM, David Given wrote:I'd appreciate any comments --- including any suggestions as to whether this is actually a useful feature. I, personally, find these things vastly easier to handle than 8-character hex strings. However I hear rumours that other peoples' opinions are valid too... As before, i find it really cool, if even if only for its conversational value. i can actually imagine that i'd use it (but won't really know that until trying it out). i will certainly be forking this into libfossil in some form or other. You've already done the sqlite3 binding, leaving me with little left to port :). If this can be "flavored" by clients (custom word lists), i'd probably spend way to much time playing with it. libfossil allows clients to plug in "crosslink handlers" which will, in theory, allow them to do filtering like this for event entries (though whether that will work in practice is as yet undetermined).
While thinking in the blue sky, it would also be neat if it did the prefix-match trick that fossil does now for hex ids. That is, if [TOAST], [TOAST MOZART], and [TOAST MOZART TULIP] all matched [74a95e62cf]; and naturally supporting even longer phrases to disambiguate past the first eight digits. Given the mapping of three words to 32 bits, however, there is some subtlety to address there so it may not be as trivial as just decoding what you got and shifting.
I'd also make sure decoding is case insensitive and allow the hyphenated forms to make it easier to type both at the command line and to present in an URL.
-- Ross Berteig r...@cheshireeng.com Cheshire Engineering Corp. http://www.CheshireEng.com/ _______________________________________________ fossil-users mailing list fossil-users@lists.fossil-scm.org http://lists.fossil-scm.org:8080/cgi-bin/mailman/listinfo/fossil-users
