Re: Patch to improve org date manipulation

["T. V. Raman" <tv.raman.tv@xxxxxxxxxxx>]

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 <bart@xxxxxxxxxxx> 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 <bart@xxxxxxxxxxx> 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 "emacspeak-request@xxxxxxxxxxx" with a
subject of "unsubscribe" or "help".