Oh, I never thought about it like this. Not having a consistent syntax
is a good reason not to include code like this in the core. Thanks.
--
Best Regards,
Nikolay Kudryavtsev
Nikolay Kudryavtsev writes:
> The main consistency problem is that t would not move log entries,
> like t moves them for org-clock-into-drawer.
There is a big difference here.
Clocks are perfectly defined in Org syntax, so one can collect them
without trouble.
However, there is no such thing a
I'm not suggesting t to be the default value. Here I totally agree with nil.
The main consistency problem is that t would not move log entries, like
t moves them for org-clock-into-drawer.
--
Best Regards,
Nikolay Kudryavtsev
Nikolay Kudryavtsev writes:
> So assuming somebody just discovers this variable(like me), decides
> that drawers is what he wants, now he has to move all those old
> entries manually. That's not too much work, but we already have
> a better behavior example in org-clock-into-drawer.
If default v
There are two things worth noting:
1. The original value for org-log-into-drawer is nil.
2. There seems to be no value that would enable movement of old records
into drawers.
So assuming somebody just discovers this variable(like me), decides that
drawers is what he wants, now he has to move a
Hello,
Nikolay Kudryavtsev writes:
> Currently when org-clock-into-drawer is set to t, it moves all old
> drawer-less clock records to a new drawer. But org-log-into-drawer
> does not do the same for log entries. I think it's logical for those
> two variables to follow the same convention.
You
Hello.
Currently when org-clock-into-drawer is set to t, it moves all old
drawer-less clock records to a new drawer. But org-log-into-drawer does
not do the same for log entries. I think it's logical for those two
variables to follow the same convention.
--
Best Regards,
Nikolay Kudryavtsev
