Re: Patch to improve org date manipulation

["Bart Bunting" <bart@xxxxxxxxxxx>]

Fair point.

So that leaves us with finding the timestamp ourselves and caching a
copy prior to the call to ad-do-it in an around advice.

Perhaps a save-excursion then search back from point for either a
lessthan < or left bracket [ to start
the timestamp and then search forward for a > or ] to end the timestamp.

I think I can manage that.  I still am unsure of how to find the
difference between the two strings once Ihave them other than using the append method
that you suggested is not the best way.

Can you think of an idiomatic way of comparing two strings to find the
position at which they first differ?

I know this may not be the most efficient approach but in reality it
won't be called all that often so shouldn't matter if we can't find a
more efficient option.
 
Does this sound like a sane aproach?
Kind regards
Bart

"T. V. Raman" <tv.raman.tv@xxxxxxxxxxx> writes:

> 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
Bart
-- 


Kind regards

Bart

-----------------------------------------------------------------------------
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".