suggestions for etm2

[Eike Nicklas]

Hi Dan,

here are a few suggestions for etm2:

* Upcoming tasks (tasks due in a few days that use the @b option) are
currently not ordered by their due date in the day view (which they
used to in etm1 and which in my opinion would be the most useful way).

* For items that are repeated at a list of dates, etm2 uses datetimes
in the @+ list while etm1 only used dates (as you explained recently).
This change is not handled by one2two.py.txt. I am not sure if it can
be handled unambiguously, but one could use the time given after @s for
all the datetimes given after @+ (currently, no time is appended to the
dates after @+, i.e. they default to 12:00).

All the best,

Eike

[Daniel Graham]

comments below:

> * Upcoming tasks (tasks due in a few days that use the @b option) are
> currently not ordered by their due date in the day view (which they
> used to in etm1 and which in my opinion would be the most useful way).

They are supposed to be ordered by their due date. My first attempt to duplicate this problem failed - could you send me an example of a couple of tasks that illustrate the problem?

> * For items that are repeated at a list of dates, etm2 uses datetimes
> in the @+ list while etm1 only used dates (as you explained recently).
> This change is not handled by one2two.py.txt. I am not sure if it can
> be handled unambiguously, but one could use the time given after @s for
> all the datetimes given after @+ (currently, no time is appended to the
> dates after @+, i.e. they default to 12:00).

I'll work on this. Thanks for the suggestion.

[Dan]

 * For items that are repeated at a list of dates, etm2 uses datetimes

 in the @+ list while etm1 only used dates (as you explained recently).
 This change is not handled by one2two.py.txt. I am not sure if it can
 be handled unambiguously, but one could use the time given after @s for
 all the datetimes given after @+ (currently, no time is appended to the
 dates after @+, i.e. they default to 12:00).

I've just uploaded a new version of one2two that hopefully does what you suggest. Please let me know how it works for you.

-Dan

[lawquest]

I probably shouldn't post this as I was sleepy and not paying attention, so can't give details, but I was working on a project last night using the timer, and I worked past midnight....About 1 am the timer showed 4 hours and 47 minutes (why I recall that I don't know, but it was about right as I had started on the project about 8 pm, taking a couple of short breaks).  I can't remember if I saved it or not, but I do recall that not long after I noticed the 4:47 in the little window at the bottom of the screen (by the "pause" button), it had changed to "0."  I then saved and the saved file showed 1 minute.  I manually inserted 4h47m into the file.  

Next time I work past midnight on a timed project I will pay more attention and report.

John

[Dan]

 * Upcoming tasks (tasks due in a few days that use the @b option) are
 currently not ordered by their due date in the day view (which they
 used to in etm1 and which in my opinion would be the most useful way).

I found a conflict between priority and date that may have caused the problem. It's fixed in 2.0.129.

-Dan

[Eike Nicklas]

Hi Dan,

thanks for the quick fix. The new version of one2two fixes the issue.

Eike

[Eike Nicklas]

Hi Dan,

I can not test 2.0.129 since it does not start:

$ python etm-2.0.129/etm_qt.py
version change: 2.0.125 to 2.0.129
Traceback (most recent call last):
File "etm-2.0.129/etm_qt.py", line 26, in <module>
etmView.main()
File "/home/eike/apps/etm-2.0.129/etmQt/etmView.py", line 2536, in
main
refresh = window.refreshViews()
File "/home/eike/apps/etm-2.0.129/etmQt/etmView.py", line 1360, in
refreshViews
self.scrollToDate(self.active_date)
File "/home/eike/apps/etm-2.0.129/etmQt/etmView.py", line 1471, in
scrollToDate
self.setWeek(curr_day)
File "/home/eike/apps/etm-2.0.129/etmQt/etmView.py", line 1552, in
setWeek
header = "%s - %s" % (weekbeg.strftime('%b %d'),
weekend.strftime('%d, %Y'))
UnicodeDecodeError: 'ascii' codec can't decode byte 0xc3 in position 1:
ordinal not in range(128)


etm-2.0.125 still works without problems. I don't have any intermediate
versions to text when the error was introduced.

Eike

[Daniel Graham]

You and your umlauts! ;-)

I've added more of your decode magic to 2.0.131 and am hoping that it fixes the problem. I can't figure out why you didn't have the same problem with March in 2.0.125.

-Dan

[Eike Nicklas]

sorry for the decoding issues, I know they are a real pain :-(

unfortunately, the problem persists in 2.0.131:

$ python etm_qt.py
version change: 2.0.129 to 2.0.131

Traceback (most recent call last):

File "etm_qt.py", line 26, in <module>
etmView.main()
File "/home/eike/apps/etm-2.0.131/etmQt/etmView.py", line 2534, in
main
refresh = window.refreshViews()
File "/home/eike/apps/etm-2.0.131/etmQt/etmView.py", line 1358, in
refreshViews
self.scrollToDate(self.active_date)
File "/home/eike/apps/etm-2.0.131/etmQt/etmView.py", line 1469, in
scrollToDate
self.setWeek(curr_day)
File "/home/eike/apps/etm-2.0.131/etmQt/etmView.py", line 1556, in
setWeek
header = leadingzero.sub('', header).decode('utf-8')
File "/usr/lib/python2.7/encodings/utf_8.py", line 16, in decode
return codecs.utf_8_decode(input, errors, True)
UnicodeEncodeError: 'ascii' codec can't encode character u'\xe4' in

position 1: ordinal not in range(128)

This is not a problem with displaying the items, with an empty
~.etm/data/ the same problem occurs.

Eike

[lawquest]

So, I also found out that, probably at the same time, somehow, without ever going out of etm, I completely erased 03.txt.  I used Mercurial to restore it so all is fine, I think.  However, a bit of a start when I discovered it.  As I said, I am going to pay more attention and try to catch it when it happens, if it happens again.    

[Daniel Graham]

There is no procedure in etm for removing a data file. You can delete items and be warned about doing so and you can open an entire file for editing, remove all the contents and save the changes but the file would still be there. And, in both cases, the mercurial history would show the changes to the file and when they happened. What did the history show?

Do you ever open the data files in an external editor or manipulate the data files outside etm, e.g., with dropbox?

[lawquest]

03-325.tmp has everything (hg cat /home/johwhi/.etm/data/monthly/2013/03.txt -r 325 > /home/johwhi/.etm/data/monthly/2013/03-325.tmp). 03-326.tmp has only one entry.  Here is relevant output from  hg log /home/johwhi/.etm/data/monthly/2013/03.txt | less:
 

changeset:   326:c048ceb4d9f4

user:        John White <jo...@whitelawchartered.com>

date:        Fri Mar 08 00:50:19 2013 -0800

summary:     edited file

changeset:   325:2782ec14fcf0

user:        John White <jo...@whitelawchartered.com>

date:        Thu Mar 07 21:09:55 2013 -0800

summary:     added lines

I tried using hg_history (per F-1) but could not figure it out.  No idea what I did at 1 o'clock in the morning that would have caused the problem.  Seriously doubt I was using dropbox or anything else, other than the programs I was then working on (probably lyx and google drive).  I know I was getting ready for a 10:30 meeting Friday morning.  I know I did not intentionally access 03.txt with any third party program.

John 

[Daniel Graham]

The notation "summary: edited file" means that the file itself was edited in etm and that the changes were saved at 00:50:19 on March 8. Since the file contained everything before this edit and only one item afterwards, the conclusion seems pretty obvious unless, of course, you have an alibi for this time. ;-) 

[lawquest]

No alibi.  As I said in my first post (about the strange loss of 4.47 hours), I was using the timer.  I started it about 8 pm, with a couple breaks, and it was showing 4.47 hours about 1 a.m., and then, for no reason I could understand, showed 0 hours (actual, 1 minute in the file itself).  At the time I posted about the 4.47 hour loss, I had not discovered that all of 03.txt had been deleted.  I must have done something when I was pausing the timer or changing the action file to cause it to add the 4.47 hours back in..  As I indicated in my first post, I thought what I perceived as rather strange activity by ETM might have had something to do with the fact that I was using the timer at the same time the day changed.  

Anyway, as I also said, I will pay more attention should this happen again so I can give you better information.

John