Cacheing org-last-changed-timestamp in the around advice may or may not work reliably -- the function that sets that variable may be called from places other than the commands you're advicing. So what you are trying is guaranteed to work only for sequential invocations of these commands. >>>>> "Bart" == Bart Bunting <firstname.lastname@example.org> writes: Bart> Hi Raman, Thanks for taking the time to provide a clear Bart> explanation. Bart> Bart> I think there is a slight misunderstanding as to the Bart> behaviour I was trying to get. Although your Bart> implementation covers a case I was not considering Bart> which is that it only speaks the timestamp, where my Bart> one would read text after the timestamp as well. Bart> Bart> The real difference is that if for example I change the Bart> day using my version All I hear read is the day number Bart> and weekday name. If I change the month then I hear the Bart> month, day and weekday name and so on for the year. Bart> Bart> The advantage of this is when you are changing the day Bart> or time up and down you hear only the relevant Bart> information which is the day or time that changed and Bart> not the bits such as year and month that did not. Bart> Bart> A side effect of checking for differences between the Bart> two strings is that if you are moving by day and happen Bart> to cross a month boundary then the month is spoken as Bart> well as the day. Bart> Bart> So to get this behaviour back but leveraging what you Bart> have found about the date being stored by org can I do Bart> something like this: Bart> Bart> - revert to around advice - capture the Bart> org-last-changed-timestamp before calling ad-do-it - Bart> compare the two values and speak the difference. Bart> Bart> Given your advice regarding the use of append can you Bart> suggest an idiom to achieve the same thing where you Bart> have two strings and you want to find the first Bart> difference? Bart> Bart> Bart> Bart> >> >> Couple of comments on your original patch. >> >> 1. Note that emacs provides built-in functions >> line-beginning-position and line-end-position -- so you >> dont need to do a save-excursion and move point to >> beginning of line, etc. >> >> >> 2. The idiom of turning a string into a list of chars, >> popping off the front etc is very Pythonic and would >> perform well in Python; it is not a good idiom to use in >> Lisp code, it would perform badly. >> >> Moreover , it wouldn't readily make sense to someone >> reading lisp code (I had to read it twice to understand >> it):-) This is more a question of idioms and culture >> variations in different languages, but is good to be aware >> of since it's the common idioms that are also good with >> respect to performance. In lisp, if you turn a string into >> a list of chars, you end up creating new memory. >> >> 3. In this case, I went back and looked at the >> implementation in org-mode for the functions being >> advised. >> >> Reasoning: if that function was going to display that >> timestamp, and that was what we wanted to speak, then it >> would be easier to find that string, rather than doing a >> diff of the previous contents with the new contents. >> >> This then took me to the function that computes the >> timestamp string to display. I alsos noticed that not only >> does the function computing the string to display return >> that string as its return value, org actually caches it in >> a variable. If org hadn't cached it, then I would have >> advised that function to cache the variable in an >> emacspeak created variable -- a useful trick to keep in >> mind. >> >> 4. But since org caches it in a named variable, I went >> ahead and used it in the advice. >> >> 5. I also turned it into an after advice since it doesn't >> look like we need the power of an around advice. So the >> explanation turned out to be longer than the code;-) >> >> `(defadvice ,f (after emacspeak pre act comp) "Provide >> auditory feedback." (when (ems-interactive-p ) >> (emacspeak-auditory-icon 'select-object) (dtk-speak >> org-last-changed-timestamp))) >> -- >> >> -- >> >> -- >> >> -- >> >> >> On 5/9/13, Bart Bunting <email@example.com> wrote: >>> Good afternoon, >>> >>> Please find attached a small patch that modifies the way >>> emacspeak speaks org dates when they are changed with >>> s-up and s-down. >>> >>> Previously emacspeak would speak the entire line. I found >>> this a little verbose and wanted to hear just the >>> relevant information. >>> >>> This patch attempts to address this by doing the >>> following: - Compare the date before and after the >>> change. - Find where the two strings differ. - Move point >>> to the difference and then move back past any numbers. - >>> Speak the line from this point. >>> >>> >>> I welcome peoples thoughts on both the efficacy of this >>> aproach and my coding style. . Kind regards >>> >>> Bart >>> Bart> Bart -- Bart> Bart> Bart> Kind regards Bart> Bart> Bart -- Best Regards, --raman ----------------------------------------------------------------------------- To unsubscribe from the emacspeak list or change your address on the emacspeak list send mail to "firstname.lastname@example.org" with a subject of "unsubscribe" or "help".
If you have questions about this archive or had problems using it, please send mail to:email@example.com No Soliciting!
Emacspeak List Archive | 2010 | 2009 | 2008 | 2007 | 2006 | 2005 | 2004 | 2003 | 2002 | 2001 | 2000 | 1999 | 1998 | Pre 1998
Emacspeak Files | Emacspeak Blog | Search the archive