On Wed, Nov 18, 2009 at 12:41 AM, Blixt <[email protected]> wrote: > I experienced the same problem as you (I think). My solution was to > simply put all replacements I wanted to do in a list (every item > containing the range and text for the replacement), and then doing the > replacements closest to the end of the blip first, then continuing > towards the start. Here's some sample code: > > items = [] > # Normally you would add to "items" dynamically, the below is just an > example. > # I put it in two steps so you don't miss that one item is actually a > tuple of two values. > item = (waveapi.document.Range(10, 20), 'Hello World!') > items.append(item) > > # Sort the "items" list so that the ranges closest to the end of the > document come first. > items.sort(lambda a, b: cmp(b[0].start, a[0].start)) > > # Loop through each item and perform the replacement. > for rng, text in items: > document.SetTextInRange(rng, text) > # Here you can also set annotations etc... > >
That would have worked for me some time ago, but now it gets much more complicated since I have annotations as well. Thanks for the idea :-) > > On Nov 17, 1:08 am, Raphaël Pinson <[email protected]> wrote: >> Hi guys, >> >> It's my first post to this list, so I'm sorry I'm going to complain, >> but before I do that I want to thank the Wave team for this great >> product. It's a lot of fun using, very useful and fun to program bots. >> >> Now, I've been working on a bot for a few days. This is a Bible bot, >> found >> onhttps://launchpad.net/wavebiblebotandhttp://wave-samples-gallery.appspot.com/about_app?app_id=70035. >> >> This bot is written in python. It is inspired by the Wikifier bot >> quite a bit. Its function is to detect and replace tags with verses or >> verse links. Now, to the point. >> >> Bear with me, this is long, and I really hope the Wave API developers >> are around reading this. >> >> === Issues with SetTextInRange === >> >> When I began writing the bot, I used SetText like the Wikifier python >> robot does. I soon realized it was ruining all the existing >> annotations of the blip, so I stopped using it and began playing with >> ranges and SetTextInRange, which is what I use now. >> >> Then I found something weird, that I haven't understood yet: when I >> make several replacements in a blip, positions are somehow slided by 1 >> character after each replacement. Let me take an example. Let's say I >> want to replace 3 tags that I have identified. >> >> For each tag, I make sure to get the position from >> blip.GetDocument().GetText() each time, in order to not use an >> obsolete text. The position returned for the first tag is correct, and >> I replace it. Then I switch to the second tag, and once I replace it, >> it gets one character to the left of the returned position, and I >> replace it (and it gets ugly). Then I switch to the third tag, and it >> gets slided two characters to the left, and so on. >> >> I've scratched my head on this and I don't get it. As a patch in my >> code, I have a "replaced" variable which I indent everytime I call >> SetTextInRange, and I add its value to the calculated position for >> every tag. This is the first issue I've found. >> >> === Stretching it further, the "replaced" counter mess === >> >> Now the problem is that I had two functions, placeVerses(blip, >> replaced) and placeVerseLinks(blip, replaced), called one after the >> other. The first one would replace all verse quotes, while the second >> one would replace all verse links. Easy! Well, no! The "replaced" >> counter got in the way when I began to mix "verse" and "verselink" >> tags in one blip, as SetTextInRange would get called to replace a tag >> that was previous to a tag already replaced, hence messing up with the >> "replaced" counter again... >> >> As a result, I fixed this by merging my two functions into one, with >> the "replaced" counter inside it only, to ensure that all tags would >> be replaced in order. This new function is called placeTags(blip) and >> is getting quite big now ;-) >> >> === Annotations, langs... === >> >> Once this was fixed^Wpatched, I began to work on a fun thing again : >> detecting the blip's language using annotations in order to adjust the >> default Bible version automatically. It's kind of easy, since while >> you edit your blip, Wave places "lang" annotations with the value of >> the detected language. Well, it turned out to work great with blips >> that use only one language. But then I tried mixing languages inside a >> blip, to see what would happen... and I lost my mind trying to >> understand how ranges evolve when you use SetTextInRange. >> >> After fighting with it quite a bit, it seems to me that when you call >> SetTextInRange, lang annotations' ranges are not modified, which makes >> it quite hard to find the language applied to one of my tags once I >> have replaced some other tags before. I came up with two options : >> * try to calculate all the languages for my tags before replacing them >> and use this list later on. This is nice and clean, except I might >> have several tags that are identical but are in different language >> paragraphs, which ruins this method. >> * keep a counter (again) called blipDelta that I fill with the delta >> generated by each replacement using SetTextInRange. Then I remove this >> delta every time I need to get the language of a tag, thus referring >> to the initial ranges of the blip, since they seem to not be modified >> when using SetTextInRange. >> >> This second solution works... not always! and I really can't figure >> out how the ranges I see in my logs relate to the ranges I see in the >> debug editor in the sandbox. I ended up adding some ugly conditions to >> make it work most of the time in these (far stretched, granted) >> situations. >> >> Seehttp://www.youtube.com/watch?v=ZG9ZOSWjnMYfor an example of case >> I fought with and fixed in an ugly way. >> >> Now if you're not afraid to scare yourself, my code is available >> onhttp://bazaar.launchpad.net/~raphink/wavebiblebot/trunk/files. All of >> the issues I listed here are found in biblebot.py. >> >> I'd be more than happy to have answers about these issues I've faced. >> >> Regards, >> >> Raphaël Pinson > > -- > > You received this message because you are subscribed to the Google Groups > "Google Wave API" group. > To post to this group, send email to [email protected]. > To unsubscribe from this group, send email to > [email protected]. > For more options, visit this group at > http://groups.google.com/group/google-wave-api?hl=. > > > -- You received this message because you are subscribed to the Google Groups "Google Wave API" group. To post to this group, send email to [email protected]. To unsubscribe from this group, send email to [email protected]. For more options, visit this group at http://groups.google.com/group/google-wave-api?hl=.
