Fw: place a header from an archive file back in its original location

2024-06-16 Thread JARZz
Is there any org-mode function (or even a package) that can place a header back 
in its original file from an archive based on the:ARCHIVE_FILE:?

I understand this can be done with refile, but this a manual process which also 
requires the ARCHIVE properties to be cleaned.

for context, I wrote about it on my blog: 
https://taonaw.com/2024/06/15/rethinking-and-organizing.html

- JTR

>

change org-attach *middle* dir

2022-03-04 Thread JARZz
Hi,

I know you org-attach-id-dir can change the parent directory from "data" (which 
I believe is default) to whatever you put there, but I want to change the 
directory under​ that.

My org-ids are set for the iso date method. This means that by default, 
attachments are saved into /data/20/220304

the 20 is the first two letters of the ID, which is 2022 for the year. This 
doesn't make much sense in my case, since all attachments, pretty much for the 
next 80 years or so, are going to fit in that dir.. I'd like to either remove 
that dir entirely (so that the ID dirs are stored in full under the data 
folder) or that perhaps I can change it so that the sub dir will include the 
first 4 characters, in my case, 2022, which makes way more sense.

How do I do that?

(setq org-attach-id-dir (concat org-directory "a_2022/"))

Sent with [ProtonMail](https://protonmail.com/) secure email.

Re: searching agenda from TRAMP

2021-10-01 Thread JARZz
> Does opening org files manually take a lot of time for you?
>
> Are you using org-id?
>
> Can you track down the problematic function using M-x profiler-start /

These are good questions.
I *do* use org-id. I started doing this more recently. I use a package called 
super-links. That could be a cause of it?

I can run profiler-start but I'm not sure what I'm looking for. Everything 
works OK (as far as I can tell), it's only when I want to search something 
specific it takes forever and a half. But of course, I'll take the advise above 
and try to run clean Emacs, see what happens then.



searching agenda from TRAMP

2021-09-30 Thread JARZz
Hello all,

I have a case of a somewhat irregular org mode setup. Here are the givens:

- I have many org files. One for each week of the year, including a couple of 
generic ones, IE journal.org, routines.org, wiki.org, etc. All in all it's 
about 120 files or so, all loaded to my org-agenda.

- I've set up Emacs on a mac at work. I do not want my org files stored locally 
on that machine since it does not belong to me. Instead, I utilized using TRAMP 
to load the files. I access my remote ssh server with a key and it works OK.

- I need to use agenda searches with specific information, such as user names, 
machines names, program names etc. in my agenda to find specific cases.

As long as I worked with my files locally, things were OK. TRAMP slows me down 
a lot, though. I know the problem is not the connection because scp and ssh 
session works like a breeze. It seems the issues happens with indexing the 
files.

I don't know what happens behind the scenes exactly, but it takes a good minute 
or to load my agenda with all the files, and it can take 10-15 minutes to 
search through them for a specific string. This problem also happens when I 
used sshfs, which makes me believe more strongly the problem is, again, not 
with the ssh connection itself, but with the indexing.

Is there a way to seep this up? Or perhaps a workaround you think might work? I 
want to use the GUI Emacs. What do you think? Also, what causes this?