emacs-orgmode@gnu.org archives
 help / color / mirror / code / Atom feed
From: Tim Visher <tim.visher@gmail.com>
To: "Fraga, Eric" <e.fraga@ucl.ac.uk>
Cc: Emacs Org Mode mailing list <emacs-orgmode@gnu.org>
Subject: Re: File Scoped Properties?
Date: Tue, 24 Mar 2020 20:57:15 -0400	[thread overview]
Message-ID: <CAHa53uxgFN1gkowS80qOuP5dbNvAg8VBNzGR+qZbApVi-v_7kA@mail.gmail.com> (raw)
In-Reply-To: <CAHa53uwLEBpiq7tzRfzUESROzBKeqJOucRhVy8m50Y01dHOjmA@mail.gmail.com>

[-- Attachment #1: Type: text/plain, Size: 3976 bytes --]

On Mon, Mar 9, 2020 at 9:24 AM Tim Visher <tim.visher@gmail.com> wrote:

> On Fri, Mar 6, 2020 at 9:09 AM Tim Visher <tim.visher@gmail.com> wrote:
>
>> Thanks for the response, Eric. :)
>>
>> On Fri, Mar 6, 2020 at 1:51 AM Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
>>
>>> On Thursday,  5 Mar 2020 at 10:28, Tim Visher wrote:
>>> > I _am_ able to get it to work by adding a file local variable like
>>> >
>>> > ```
>>> > # Local Variables:
>>> > # org-attach-id-dir: "~/.foo/data"
>>> > # End:
>>> > ```
>>> >
>>> > but then whenever I open the file it tells me it's possibly not safe
>>> to set
>>> > that.
>>>
>>> You've already received a more org-ish response but I'll give you an
>>> Emacs response to this part of your post: Emacs is simply making sure
>>> you are aware that a variable is being set when visiting a file.
>>>
>>
>> My question was more around why I had to do it at all since based on my
>> reading of the manual it seems like I should've been able to do this with
>> some kind of file-wide property. Specifically, I've never been able to wrap
>> my head around `(info "(org) Property Syntax")`.
>>
>> "Properties are key–value pairs. When they are associated with a single
>> entry or with a tree…," for instance, seems to imply by "When they are
>> associated with a single entry…" that they can be associated with all the
>> entries (or a particular tree or node).
>>
>> Anyway, I think between you and Gustav I finally have this sorted.
>>
>>    1. To set properties at the top level of a file you need to use the
>>    `#+PROPERTY: <PROPERTY_NAME> <PROPERTY_VALUE>` syntax. I've been trying to
>>    figure out how I misinterpreted that in the past and I _think_ it was
>>    because I assumed that the `#+PROPERTY` was actually `#+<PROPERTY>` as in
>>    `#+DIR` rather than `#+PROPERTY: DIR`. It looks like to set a file local
>>    property in an org file you _must_ (at least on 9.3 or earlier) use the
>>    `#+PROPERTY: <PROPERTY_NAME> <PROPERTY_VALUE>` syntax.
>>
>>    2. Even then by default org-attach property inheritance is set to
>>    `'selective` and `org-use-property-inheritance` is set to off. I've now
>>    customized `org-use-property-inheritance` to `'("DIR")` which I believe
>>    says that I consider the `DIR` property to be a possible candidate for
>>    inheritance and no others. I'm a little concerned about performance
>>    implications as the manual gives me all kinds of scary warnings but we'll
>>    see about that.
>>
>> Anyway this appears to work as I expect it to. I don't have to set a
>> file-local variable to anything. I'm using org properties. And
>> `org-attach-dir` now returns the proper directory for this file.
>>
>> Thanks all! If you think I'm still misunderstanding something please
>> correct me. :)
>>
>
> I'll go ahead and correct myself. (-‸ლ)
>
> It turns out that I wasn't understanding what the `DIR` property actually
> does. If `DIR` is set, it makes that the attachment directory, period. In
> other words it's different than the default `./data/` prefix directory in
> that ID paths are not then suffixed upon the end of it like
> `./data/XX/XXXXX-XXX-XXX/` for each entry. Instead, if you have `DIR` set,
> that headings attachment directory == `DIR`.
>
> So the way to change the attachment directory prefix is just not to mess
> with `DIR` at all. Instead, you must set the variable `org-attach-id-dir`,
> and if you want that to be local to a file the natural way to do that is
> with a file-local variable.
>
> ```
> # Local Variables:
> # org-attach-id-dir: "~/.foo/data"
> # End:
> ```
>
> Cheers. :)
>

This ended up producing more of a learning opportunity than I had initially
suspected and I wrote it up on my blog. In case anyone else is interested
in the details:
https://blog.twonegatives.com/post/613474532727095296/how-to-set-the-attach-directory-prefix-for

Happy Org!

[-- Attachment #2: Type: text/html, Size: 5167 bytes --]

      reply	other threads:[~2020-03-25  0:57 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2020-03-05 15:28 File Scoped Properties? Tim Visher
2020-03-05 22:53 ` Gustav Wikström
2020-03-06  6:51 ` Fraga, Eric
2020-03-06 14:09   ` Tim Visher
2020-03-08 12:52     ` Eric S Fraga
2020-03-09 13:24     ` Tim Visher
2020-03-25  0:57       ` Tim Visher [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://www.orgmode.org/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=CAHa53uxgFN1gkowS80qOuP5dbNvAg8VBNzGR+qZbApVi-v_7kA@mail.gmail.com \
    --to=tim.visher@gmail.com \
    --cc=e.fraga@ucl.ac.uk \
    --cc=emacs-orgmode@gnu.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
Code repositories for project(s) associated with this public inbox

	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).