Samuel Wales writes:
> i should clarify. bulk archiving slows down even with /nonexistent/
> (have not tried empty) archives. as part of normal and expected
> operation, bulk creates the archive for the first entry, and then
> subsequent entries are added. those get slower and slower.
Hi. I j
It is for me. However, this all depends on how you configure things.
In my case, I have a standard structure for my org files. I have a
different org file for each 'topic' and each org file has headings for
* Tasks
* Notes
* Resources
* Comms
* General
and each of those headings has a prop
what is the current status of hierarchy in archive files? surely they
don't deal with updating categories and updating hierarchy structure
[sounds brittle and syncy]? i'm thinking it isn't hierarchical at
present, except when you have a doneified task with children?
On 8/11/21, Tim Cross wrote
thank you.
i will give up on archiving categories if needed to make archiving be
practical. will ahfe to try it as soon as i can.
On 8/11/21, Ihor Radchenko wrote:
> Samuel Wales writes:
>
>> thanks for the clarification. are you saying that, for every archived
>> entry, it calculates teh cat
I think the problem with just using append to file is that it won't
preserve the shape of the file. For example, if I had a file with
* Notes
** Note 1
blah blah
** Note 2 blah blah
* Tasks
** DONE task 1
** TODO Task 2
and I decide to archive note 1 and task 1, I would like them to both appe
Samuel Wales writes:
> thanks for the clarification. are you saying that, for every archived
> entry, it calculates teh category property, using the original org
> file, in order to add a category property to just one archived entry?
Nope. It does not just calculate category for the archived en
thanks for the clarification. are you saying that, for every archived
entry, it calculates teh category property, using the original org
file, in order to add a category property to just one archived entry?
that would certainly slow down more and more, but it sends me back to
my question about wh
Samuel Wales writes:
> i should clarify. bulk archiving slows down even with /nonexistent/
> (have not tried empty) archives. as part of normal and expected
> operation, bulk creates the archive for the first entry, and then
> subsequent entries are added. those get slower and slower.
That's
i should clarify. bulk archiving slows down even with /nonexistent/
(have not tried empty) archives. as part of normal and expected
operation, bulk creates the archive for the first entry, and then
subsequent entries are added. those get slower and slower.
i was trying to imply e.g. doing archi
Samuel Wales writes:
> [this is the case even with zero-size archive files; after a few
> entries it slows down.]
Do you get the same behaviour with the following code?
(setq org-archive-save-context-info '(file time))
Best,
Ihor
i have not bulk archived in a year or two, because it is too slow for
me. i am curious why, when appending to an archive file,
append-to-file or write-region are not used, to merely put the entries
there instead of loading the archive file into emacs?
[this is the case even with zero-size archive
Ihor Radchenko writes:
> David Masterson writes:
>
>> Interesting, but then how do you get the list? I mean is there an
>> agenda to use?
>
> Generally yes, you can use agenda. Or you can use sparse tree (more manual).
> For agenda, if you customise org-log-done, you can use
> org-agenda-log-mo
Samuel Wales writes:
> that makes sense. but why would appending to an archive as the result
> of bulk archiving lag? if the problem is large archive files, which
> i'd bet is the case for a lot of users and not just me, then could org
> in principle be changed so that all it does is append? t
thank you for your detaild reply.
more below.
On 2/28/21, Ihor Radchenko wrote:
> details why). So, many org commands tend to lag on large archives.
that makes sense. but why would appending to an archive as the result
of bulk archiving lag? if the problem is large archive files, which
i'd be
Samuel Wales writes:
> Hi Ihor,
>
> it never occurred to me that bulk archiving could be sped up by
> changing anything about the archive files. i assumed that archiving
> worked by appending to those files, so once the initial find-file was
> performed, there should be no additional slowness.
Hi Ihor,
it never occurred to me that bulk archiving could be sped up by
changing anything about the archive files. i assumed that archiving
worked by appending to those files, so once the initial find-file was
performed, there should be no additional slowness.
yet i tried a new file with no arc
Samuel Wales writes:
> [currently the archiver is so slow i can't use it]
Are your existing archives very big (few Mbs)? If so, you may try to
speed up the archiving using feature/org-fold branch [1]. If that is not
enough, I recommend splitting archives on yearly basis [2] or disabling
font-lo
Samuel Wales writes:
> perhaps also changing org-archive-file-header-format to allow a format
> thingie for a timestamp would allow you to take parts of an archive
> file and move them into one per year without having to put the date in
> each archived entry.
FYI: I have implemented automatic pe
David Masterson writes:
> Interesting, but then how do you get the list? I mean is there an
> agenda to use?
Generally yes, you can use agenda. Or you can use sparse tree (more manual).
For agenda, if you customise org-log-done, you can use
org-agenda-log-mode ("v l" or "v L" in an agenda buffe
note that there is an issue when you try to name your archive files
using years like computer-2000.org_archive. it can take seconds to
find-file big files so it is understandable to want to name files like
that.
however, if you change the name of an archive file, it will not be
found by org when
Tim Cross writes:
> David Masterson writes:
>
>> What would you use to then make a list of all meetings you had last year?
>
> For me, archiving is about data I'm unlikely to need again, but just in
> case I do, it is in the archive. I rarely look at my archives. However,
> when I do archive, I
David Masterson writes:
> Tim Cross writes:
>
>> David Masterson writes:
>>
>> For me, my TODOs are setup so that they record a date stamp for when
>> they were added and whenever they change state e.g. started, done,
>> delegated etc.
>
> So, you use progress logging.
Yes.
>
>> For non-TOD
Eric S Fraga writes:
> My approach is simple. For TODO items, I archive to separate file when
> done. That file is easily searchable, e.g. using C-c /.
Ah! org-occur! That's something forgot about and looks useful.
> I keep both the original file and the archive file under revision
> control,
Tim Cross writes:
> David Masterson writes:
>
>> There are many ways of maintaining history in a group of Org files:
>> 1. Archive within a file
>> 2. Archive to a separate (archive) file
>> 3. Special TODO types for history
>> 4. Special TAG types for history
>> 5. etc.
>>
>> My question is, if
Ihor Radchenko writes:
> David Masterson writes:
>> My question is, if you have meetings/phone calls as TODOs, what is the
>> preferred way to handle when they move into history so that, *much*
>> later, you can easily produce a list of all of the meetings/phone calls
>> with dates and times of
org does indeed have a lot of related features, maybe too many even.
here is some of what i do.
- if i doneify, it means i will likely not need to search for it.
archived to a file.
[currently the archiver is so slow i can't use it]
CLOSED: [2012-11-08 Thu 19:40]
- state logging for repeaters
On 2021-02-26 01:22, David Masterson wrote:
There are many ways of maintaining history in a group of Org files:
1. Archive within a file
2. Archive to a separate (archive) file
3. Special TODO types for history
4. Special TAG types for history
5. etc.
My question is, if you have meetings/phone c
My approach is simple. For TODO items, I archive to separate file when
done. That file is easily searchable, e.g. using C-c /.
I keep both the original file and the archive file under revision
control, just in case.
> The issue (I think) is, when you mark the TODO as DONE, you lose the
> info o
David Masterson writes:
> There are many ways of maintaining history in a group of Org files:
> 1. Archive within a file
> 2. Archive to a separate (archive) file
> 3. Special TODO types for history
> 4. Special TAG types for history
> 5. etc.
>
> My question is, if you have meetings/phone call
David Masterson writes:
> My question is, if you have meetings/phone calls as TODOs, what is the
> preferred way to handle when they move into history so that, *much*
> later, you can easily produce a list of all of the meetings/phone calls
> with dates and times of them? The issue (I think) is
There are many ways of maintaining history in a group of Org files:
1. Archive within a file
2. Archive to a separate (archive) file
3. Special TODO types for history
4. Special TAG types for history
5. etc.
My question is, if you have meetings/phone calls as TODOs, what is the
preferred way to ha
31 matches
Mail list logo
