From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Visher Subject: File Scoped Properties? Date: Thu, 5 Mar 2020 10:28:20 -0500 Message-ID: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000912d7205a01d32bf" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:47124) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9sQv-0000hV-Gn for emacs-orgmode@gnu.org; Thu, 05 Mar 2020 10:29:10 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9sQu-0001yD-7L for emacs-orgmode@gnu.org; Thu, 05 Mar 2020 10:29:09 -0500 Received: from mail-wr1-x42f.google.com ([2a00:1450:4864:20::42f]:38501) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1j9sQu-0001xk-12 for emacs-orgmode@gnu.org; Thu, 05 Mar 2020 10:29:08 -0500 Received: by mail-wr1-x42f.google.com with SMTP id t11so7537898wrw.5 for ; Thu, 05 Mar 2020 07:29:07 -0800 (PST) List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Emacs Org Mode mailing list --000000000000912d7205a01d32bf Content-Type: text/plain; charset="UTF-8" Hello, I'm trying to get org-attach to use a different data directory for a particular file. My understanding is that this is controlled by `org-attach-id-dir` by default but can be overridden at the file or entry level by use of the `DIR` property. I can successfully override it at the entry level by adding `DIR` to the entries properties but I can't figure out how to set it for all entries in the file. I tried: ``` #+DIR: ~/.foo/data ``` as the first line of the file. 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. Any ideas? -- In Christ, Timmy V. https://blog.twonegatives.com https://five.sentenc.es --000000000000912d7205a01d32bf Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I'm trying to get org-attach= to use a different data directory for a particular file.

My understanding is that this is controlled by `org-attach-id-dir` = by default but can be overridden=C2=A0at the file or entry level by use of = the `DIR` property. I can successfully override it at the entry level by ad= ding `DIR` to the entries properties but I can't figure out how to set = it for all entries in the file.

I tried:

```
#+DIR: ~/.foo/data
```
as the first line of the file.

I _am_= able to get it to work by adding a file local variable like

=
```
# Local Variables:
# org-attach-id-dir: "~/.foo/d= ata"
# End:
```

but then whenever I= open the file it tells me it's possibly not safe to set that.

Any ideas?

--000000000000912d7205a01d32bf-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: =?utf-8?B?R3VzdGF2IFdpa3N0csO2bQ==?= Subject: RE: File Scoped Properties? Date: Thu, 5 Mar 2020 22:53:54 +0000 Message-ID: References: Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="_000_HE1PR02MB303345141875293D6F1E8CD3DAE20HE1PR02MB3033eurp_" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:39507) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1j9zNS-0004jT-8I for emacs-orgmode@gnu.org; Thu, 05 Mar 2020 17:54:03 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1j9zNQ-0003mt-Ot for emacs-orgmode@gnu.org; Thu, 05 Mar 2020 17:54:02 -0500 Received: from mail-eopbgr60126.outbound.protection.outlook.com ([40.107.6.126]:61565 helo=EUR04-DB3-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1j9zNQ-0003in-8j for emacs-orgmode@gnu.org; Thu, 05 Mar 2020 17:54:00 -0500 In-Reply-To: Content-Language: en-US List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Tim Visher , Emacs Org Mode mailing list --_000_HE1PR02MB303345141875293D6F1E8CD3DAE20HE1PR02MB3033eurp_ Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: base64 SGkgVGltLA0KDQpGaXJzdCB5b3UgbXVzdCBtYWtlIHN1cmUgdG8gYWxsb3cgcHJvcGVydHkgaW5o ZXJpdGFuY2UuIFRoYXQgY2FuIGJlIGRvbmUgYnkgc2V0dGluZyBvcmctYXR0YWNoLXVzZS1pbmhl cml0YW5jZSB0byB0LiBUaGVuIGFkZCB0aGUgRElSIHByb3BlcnR5IHRvIGEgcHJvcGVydHkgYmxv Y2sgZm9yIHRoZSBmaWxlLCBvciB1c2luZyBhIHByb3BlcnR5IGtleXdvcmQuIEkuZS4gZWl0aGVy IHRoaXM6DQoNCiMrYmVnaW5fc3JjIG9yZw0KICA6UFJPUEVSVElFUzoNCiAgOkRJUjogICAgICB+ Ly5mb28vZGF0YQ0KICA6RU5EOg0KIytlbmRfc3JjDQoNCiMrYmVnaW5fc3JjIG9yZw0KICAsIytQ Uk9QRVJUWSBESVIgfi8uZm9vL2RhdGENCiMrZW5kX3NyYw0KDQpSdW5uaW5nIG9yZy1hdHRhY2gg d2l0aCBvcHRpb24gcyB3aWxsIGdpdmUgeW91IGEgcHJvbXB0IHRoYXQgd2lsbCBzZXQgRElSIGZv ciB5b3UuIElmIHlvdSBpbnZva2UgdGhhdCBiZWZvcmUgZmlyc3QgaGVhZGxpbmUgaXQgc2hvdWxk IHJlc3VsdCBpbiBhIERJUiBwcm9wZXJ0eSB0aGF0IGFwcGxpZXMgZm9yIHRoZSB3aG9sZSBidWZm ZXIgKHdoZW4gb3JnLWF0dGFjaC11c2UtaW5oZXJpdGFuY2UgaXMgc2V0IHRvIHQgdGhhdCBpcyku IE5vdGUgdGhhdCBwcm9wZXJ0eSBibG9ja3MgYmVmb3JlIGZpcnN0IGhlYWRsaW5lIGlzIGEgbmV3 IGZlYXR1cmUgZm9yIHZlcnNpb24gOS40IGFuZCBjdXJyZW50bHkgb25seSBleGlzdCBpbiB0aGUg bWFzdGVyIGJyYW5jaC4NCg0KUmVnYXJkcw0KR3VzdGF2DQoNCkZyb206IEVtYWNzLW9yZ21vZGUg PGVtYWNzLW9yZ21vZGUtYm91bmNlcytndXN0YXY9d2hpbC5zZUBnbnUub3JnPiBPbiBCZWhhbGYg T2YgVGltIFZpc2hlcg0KU2VudDogZGVuIDUgbWFycyAyMDIwIDE2OjI4DQpUbzogRW1hY3MgT3Jn IE1vZGUgbWFpbGluZyBsaXN0IDxlbWFjcy1vcmdtb2RlQGdudS5vcmc+DQpTdWJqZWN0OiBGaWxl IFNjb3BlZCBQcm9wZXJ0aWVzPw0KDQpIZWxsbywNCg0KSSdtIHRyeWluZyB0byBnZXQgb3JnLWF0 dGFjaCB0byB1c2UgYSBkaWZmZXJlbnQgZGF0YSBkaXJlY3RvcnkgZm9yIGEgcGFydGljdWxhciBm aWxlLg0KDQpNeSB1bmRlcnN0YW5kaW5nIGlzIHRoYXQgdGhpcyBpcyBjb250cm9sbGVkIGJ5IGBv cmctYXR0YWNoLWlkLWRpcmAgYnkgZGVmYXVsdCBidXQgY2FuIGJlIG92ZXJyaWRkZW4gYXQgdGhl IGZpbGUgb3IgZW50cnkgbGV2ZWwgYnkgdXNlIG9mIHRoZSBgRElSYCBwcm9wZXJ0eS4gSSBjYW4g c3VjY2Vzc2Z1bGx5IG92ZXJyaWRlIGl0IGF0IHRoZSBlbnRyeSBsZXZlbCBieSBhZGRpbmcgYERJ UmAgdG8gdGhlIGVudHJpZXMgcHJvcGVydGllcyBidXQgSSBjYW4ndCBmaWd1cmUgb3V0IGhvdyB0 byBzZXQgaXQgZm9yIGFsbCBlbnRyaWVzIGluIHRoZSBmaWxlLg0KDQpJIHRyaWVkOg0KDQpgYGAN CiMrRElSOiB+Ly5mb28vZGF0YQ0KYGBgDQoNCmFzIHRoZSBmaXJzdCBsaW5lIG9mIHRoZSBmaWxl Lg0KDQpJIF9hbV8gYWJsZSB0byBnZXQgaXQgdG8gd29yayBieSBhZGRpbmcgYSBmaWxlIGxvY2Fs IHZhcmlhYmxlIGxpa2UNCg0KYGBgDQojIExvY2FsIFZhcmlhYmxlczoNCiMgb3JnLWF0dGFjaC1p ZC1kaXI6ICJ+Ly5mb28vZGF0YSINCiMgRW5kOg0KYGBgDQoNCmJ1dCB0aGVuIHdoZW5ldmVyIEkg b3BlbiB0aGUgZmlsZSBpdCB0ZWxscyBtZSBpdCdzIHBvc3NpYmx5IG5vdCBzYWZlIHRvIHNldCB0 aGF0Lg0KDQpBbnkgaWRlYXM/DQoNCi0tDQoNCkluIENocmlzdCwNCg0KVGltbXkgVi4NCg0KaHR0 cHM6Ly9ibG9nLnR3b25lZ2F0aXZlcy5jb20NCmh0dHBzOi8vZml2ZS5zZW50ZW5jLmVzDQo= --_000_HE1PR02MB303345141875293D6F1E8CD3DAE20HE1PR02MB3033eurp_ Content-Type: text/html; charset="utf-8" Content-Transfer-Encoding: base64 PGh0bWwgeG1sbnM6dj0idXJuOnNjaGVtYXMtbWljcm9zb2Z0LWNvbTp2bWwiIHhtbG5zOm89InVy bjpzY2hlbWFzLW1pY3Jvc29mdC1jb206b2ZmaWNlOm9mZmljZSIgeG1sbnM6dz0idXJuOnNjaGVt YXMtbWljcm9zb2Z0LWNvbTpvZmZpY2U6d29yZCIgeG1sbnM6bT0iaHR0cDovL3NjaGVtYXMubWlj cm9zb2Z0LmNvbS9vZmZpY2UvMjAwNC8xMi9vbW1sIiB4bWxucz0iaHR0cDovL3d3dy53My5vcmcv VFIvUkVDLWh0bWw0MCI+DQo8aGVhZD4NCjxtZXRhIGh0dHAtZXF1aXY9IkNvbnRlbnQtVHlwZSIg Y29udGVudD0idGV4dC9odG1sOyBjaGFyc2V0PXV0Zi04Ij4NCjxtZXRhIG5hbWU9IkdlbmVyYXRv ciIgY29udGVudD0iTWljcm9zb2Z0IFdvcmQgMTUgKGZpbHRlcmVkIG1lZGl1bSkiPg0KPHN0eWxl PjwhLS0NCi8qIEZvbnQgRGVmaW5pdGlvbnMgKi8NCkBmb250LWZhY2UNCgl7Zm9udC1mYW1pbHk6 IkNhbWJyaWEgTWF0aCI7DQoJcGFub3NlLTE6MiA0IDUgMyA1IDQgNiAzIDIgNDt9DQpAZm9udC1m YWNlDQoJe2ZvbnQtZmFtaWx5OkNhbGlicmk7DQoJcGFub3NlLTE6MiAxNSA1IDIgMiAyIDQgMyAy IDQ7fQ0KLyogU3R5bGUgRGVmaW5pdGlvbnMgKi8NCnAuTXNvTm9ybWFsLCBsaS5Nc29Ob3JtYWws IGRpdi5Nc29Ob3JtYWwNCgl7bWFyZ2luOjBjbTsNCgltYXJnaW4tYm90dG9tOi4wMDAxcHQ7DQoJ Zm9udC1zaXplOjExLjBwdDsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJpZjt9DQph OmxpbmssIHNwYW4uTXNvSHlwZXJsaW5rDQoJe21zby1zdHlsZS1wcmlvcml0eTo5OTsNCgljb2xv cjpibHVlOw0KCXRleHQtZGVjb3JhdGlvbjp1bmRlcmxpbmU7fQ0Kc3Bhbi5FbWFpbFN0eWxlMTgN Cgl7bXNvLXN0eWxlLXR5cGU6cGVyc29uYWwtcmVwbHk7DQoJZm9udC1mYW1pbHk6IkNhbGlicmki LHNhbnMtc2VyaWY7DQoJY29sb3I6d2luZG93dGV4dDt9DQouTXNvQ2hwRGVmYXVsdA0KCXttc28t c3R5bGUtdHlwZTpleHBvcnQtb25seTsNCglmb250LWZhbWlseToiQ2FsaWJyaSIsc2Fucy1zZXJp ZjsNCgltc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUzt9DQpAcGFnZSBXb3JkU2VjdGlvbjENCgl7 c2l6ZTo2MTIuMHB0IDc5Mi4wcHQ7DQoJbWFyZ2luOjcwLjg1cHQgNzAuODVwdCA3MC44NXB0IDcw Ljg1cHQ7fQ0KZGl2LldvcmRTZWN0aW9uMQ0KCXtwYWdlOldvcmRTZWN0aW9uMTt9DQotLT48L3N0 eWxlPjwhLS1baWYgZ3RlIG1zbyA5XT48eG1sPg0KPG86c2hhcGVkZWZhdWx0cyB2OmV4dD0iZWRp dCIgc3BpZG1heD0iMTAyNiIgLz4NCjwveG1sPjwhW2VuZGlmXS0tPjwhLS1baWYgZ3RlIG1zbyA5 XT48eG1sPg0KPG86c2hhcGVsYXlvdXQgdjpleHQ9ImVkaXQiPg0KPG86aWRtYXAgdjpleHQ9ImVk aXQiIGRhdGE9IjEiIC8+DQo8L286c2hhcGVsYXlvdXQ+PC94bWw+PCFbZW5kaWZdLS0+DQo8L2hl YWQ+DQo8Ym9keSBsYW5nPSJTViIgbGluaz0iYmx1ZSIgdmxpbms9InB1cnBsZSI+DQo8ZGl2IGNs YXNzPSJXb3JkU2VjdGlvbjEiPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1z by1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5IaSBUaW0sPG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVO LVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48 c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5GaXJz dCB5b3UgbXVzdCBtYWtlIHN1cmUgdG8gYWxsb3cgcHJvcGVydHkgaW5oZXJpdGFuY2UuIFRoYXQg Y2FuIGJlIGRvbmUgYnkgc2V0dGluZw0KPGk+b3JnLWF0dGFjaC11c2UtaW5oZXJpdGFuY2U8L2k+ IHRvIHQuIFRoZW4gYWRkIHRoZSBESVIgcHJvcGVydHkgdG8gYSBwcm9wZXJ0eSBibG9jayBmb3Ig dGhlIGZpbGUsIG9yIHVzaW5nIGEgcHJvcGVydHkga2V5d29yZC4gSS5lLiBlaXRoZXIgdGhpczo8 bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJF Ti1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwvbzpw Pjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5 bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj4jJiM0MztiZWdpbl9zcmMgb3JnPG86cD48 L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMi IHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7IDpQUk9QRVJUSUVTOjxv OnA+PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVO LVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPiZuYnNwOyA6RElSOiZuYnNw OyZuYnNwOyZuYnNwOyZuYnNwOyZuYnNwOw0KPC9zcGFuPn4vLmZvby9kYXRhPHNwYW4gbGFuZz0i RU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+PG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+Jm5ic3A7IDpFTkQ6PG86cD48L286cD48L3NwYW4+ PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28t ZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+IyYjNDM7ZW5kX3NyYzxvOnA+PC9vOnA+PC9zcGFuPjwv cD4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZh cmVhc3QtbGFuZ3VhZ2U6RU4tVVMiPjxvOnA+Jm5ic3A7PC9vOnA+PC9zcGFuPjwvcD4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPjxzcGFuIGxhbmc9IkVOLVVTIiBzdHlsZT0ibXNvLWZhcmVhc3QtbGFu Z3VhZ2U6RU4tVVMiPiMmIzQzO2JlZ2luX3NyYyBvcmc8bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0 LWxhbmd1YWdlOkVOLVVTIj4mbmJzcDsgLCMmIzQzO1BST1BFUlRZIERJUg0KPC9zcGFuPjxzcGFu IGxhbmc9IkVOLVVTIj5+Ly5mb28vZGF0YTwvc3Bhbj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9 Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBj bGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxh bmd1YWdlOkVOLVVTIj4jJiM0MztlbmRfc3JjPG86cD48L286cD48L3NwYW4+PC9wPg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5n dWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05v cm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFzdC1sYW5ndWFnZTpFTi1V UyI+UnVubmluZw0KPGk+b3JnLWF0dGFjaCA8L2k+d2l0aCBvcHRpb248aT4gPC9pPnMgd2lsbCBn aXZlIHlvdSBhIHByb21wdCB0aGF0IHdpbGwgc2V0IERJUiBmb3IgeW91LiBJZiB5b3UgaW52b2tl IHRoYXQgYmVmb3JlIGZpcnN0IGhlYWRsaW5lIGl0IHNob3VsZCByZXN1bHQgaW4gYSBESVIgcHJv cGVydHkgdGhhdCBhcHBsaWVzIGZvciB0aGUgd2hvbGUgYnVmZmVyICh3aGVuDQo8aT5vcmctYXR0 YWNoLXVzZS1pbmhlcml0YW5jZTwvaT4gaXMgc2V0IHRvIHQgdGhhdCBpcykuIE5vdGUgdGhhdCBw cm9wZXJ0eSBibG9ja3MgYmVmb3JlIGZpcnN0IGhlYWRsaW5lIGlzIGEgbmV3IGZlYXR1cmUgZm9y IHZlcnNpb24gOS40IGFuZCBjdXJyZW50bHkgb25seSBleGlzdCBpbiB0aGUgbWFzdGVyIGJyYW5j aC48bzpwPjwvbzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5n PSJFTi1VUyIgc3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj48bzpwPiZuYnNwOzwv bzpwPjwvc3Bhbj48L3A+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48c3BhbiBsYW5nPSJFTi1VUyIg c3R5bGU9Im1zby1mYXJlYXN0LWxhbmd1YWdlOkVOLVVTIj5SZWdhcmRzPG86cD48L286cD48L3Nw YW4+PC9wPg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJt c28tZmFyZWFzdC1sYW5ndWFnZTpFTi1VUyI+R3VzdGF2PG86cD48L286cD48L3NwYW4+PC9wPg0K PHAgY2xhc3M9Ik1zb05vcm1hbCI+PHNwYW4gbGFuZz0iRU4tVVMiIHN0eWxlPSJtc28tZmFyZWFz dC1sYW5ndWFnZTpFTi1VUyI+PG86cD4mbmJzcDs8L286cD48L3NwYW4+PC9wPg0KPGRpdiBzdHls ZT0iYm9yZGVyOm5vbmU7Ym9yZGVyLWxlZnQ6c29saWQgYmx1ZSAxLjVwdDtwYWRkaW5nOjBjbSAw Y20gMGNtIDQuMHB0Ij4NCjxkaXY+DQo8ZGl2IHN0eWxlPSJib3JkZXI6bm9uZTtib3JkZXItdG9w OnNvbGlkICNFMUUxRTEgMS4wcHQ7cGFkZGluZzozLjBwdCAwY20gMGNtIDBjbSI+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48Yj48c3BhbiBsYW5nPSJFTi1VUyI+RnJvbTo8L3NwYW4+PC9iPjxzcGFu IGxhbmc9IkVOLVVTIj4gRW1hY3Mtb3JnbW9kZSAmbHQ7ZW1hY3Mtb3JnbW9kZS1ib3VuY2VzJiM0 MztndXN0YXY9d2hpbC5zZUBnbnUub3JnJmd0Ow0KPGI+T24gQmVoYWxmIE9mIDwvYj5UaW0gVmlz aGVyPGJyPg0KPGI+U2VudDo8L2I+IGRlbiA1IG1hcnMgMjAyMCAxNjoyODxicj4NCjxiPlRvOjwv Yj4gRW1hY3MgT3JnIE1vZGUgbWFpbGluZyBsaXN0ICZsdDtlbWFjcy1vcmdtb2RlQGdudS5vcmcm Z3Q7PGJyPg0KPGI+U3ViamVjdDo8L2I+IEZpbGUgU2NvcGVkIFByb3BlcnRpZXM/PG86cD48L286 cD48L3NwYW4+PC9wPg0KPC9kaXY+DQo8L2Rpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPjxzcGFu IGxhbmc9IkVOLVVTIj48bzpwPiZuYnNwOzwvbzpwPjwvc3Bhbj48L3A+DQo8ZGl2Pg0KPHAgY2xh c3M9Ik1zb05vcm1hbCI+SGVsbG8sPG86cD48L286cD48L3A+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0i TXNvTm9ybWFsIj5JJ20gdHJ5aW5nIHRvIGdldCBvcmctYXR0YWNoIHRvIHVzZSBhIGRpZmZlcmVu dCBkYXRhIGRpcmVjdG9yeSBmb3IgYSBwYXJ0aWN1bGFyIGZpbGUuPG86cD48L286cD48L3A+DQo8 L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPk15IHVuZGVyc3RhbmRpbmcgaXMg dGhhdCB0aGlzIGlzIGNvbnRyb2xsZWQgYnkgYG9yZy1hdHRhY2gtaWQtZGlyYCBieSBkZWZhdWx0 IGJ1dCBjYW4gYmUgb3ZlcnJpZGRlbiZuYnNwO2F0IHRoZSBmaWxlIG9yIGVudHJ5IGxldmVsIGJ5 IHVzZSBvZiB0aGUgYERJUmAgcHJvcGVydHkuIEkgY2FuIHN1Y2Nlc3NmdWxseSBvdmVycmlkZSBp dCBhdCB0aGUgZW50cnkgbGV2ZWwgYnkgYWRkaW5nIGBESVJgIHRvIHRoZSBlbnRyaWVzDQogcHJv cGVydGllcyBidXQgSSBjYW4ndCBmaWd1cmUgb3V0IGhvdyB0byBzZXQgaXQgZm9yIGFsbCBlbnRy aWVzIGluIHRoZSBmaWxlLjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9 Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj5JIHRyaWVkOjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5gYGA8bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxw IGNsYXNzPSJNc29Ob3JtYWwiPiMmIzQzO0RJUjogfi8uZm9vL2RhdGE8bzpwPjwvbzpwPjwvcD4N CjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmBgYDxvOnA+PC9vOnA+PC9wPg0K PC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+ DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj5hcyB0aGUgZmlyc3QgbGluZSBv ZiB0aGUgZmlsZS48bzpwPjwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29O b3JtYWwiPjxvOnA+Jm5ic3A7PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAgY2xhc3M9Ik1z b05vcm1hbCI+SSBfYW1fIGFibGUgdG8gZ2V0IGl0IHRvIHdvcmsgYnkgYWRkaW5nIGEgZmlsZSBs b2NhbCB2YXJpYWJsZSBsaWtlPG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFz cz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNs YXNzPSJNc29Ob3JtYWwiPmBgYDxicj4NCiMgTG9jYWwgVmFyaWFibGVzOjxicj4NCiMgb3JnLWF0 dGFjaC1pZC1kaXI6ICZxdW90O34vLmZvby9kYXRhJnF1b3Q7PGJyPg0KIyBFbmQ6PGJyPg0KYGBg PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpw PiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0KPGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPmJ1 dCB0aGVuIHdoZW5ldmVyIEkgb3BlbiB0aGUgZmlsZSBpdCB0ZWxscyBtZSBpdCdzIHBvc3NpYmx5 IG5vdCBzYWZlIHRvIHNldCB0aGF0LjxvOnA+PC9vOnA+PC9wPg0KPC9kaXY+DQo8ZGl2Pg0KPHAg Y2xhc3M9Ik1zb05vcm1hbCI+PG86cD4mbmJzcDs8L286cD48L3A+DQo8L2Rpdj4NCjxkaXY+DQo8 cCBjbGFzcz0iTXNvTm9ybWFsIj5BbnkgaWRlYXM/PG86cD48L286cD48L3A+DQo8L2Rpdj4NCjxk aXY+DQo8cCBjbGFzcz0iTXNvTm9ybWFsIj48bzpwPiZuYnNwOzwvbzpwPjwvcD4NCjwvZGl2Pg0K PGRpdj4NCjxwIGNsYXNzPSJNc29Ob3JtYWwiPi0tPGJyPg0KPGJyPg0KSW4gQ2hyaXN0LDxicj4N Cjxicj4NClRpbW15IFYuPGJyPg0KPGJyPg0KPGEgaHJlZj0iaHR0cHM6Ly9ibG9nLnR3b25lZ2F0 aXZlcy5jb20iPmh0dHBzOi8vYmxvZy50d29uZWdhdGl2ZXMuY29tPC9hPjxicj4NCjxhIGhyZWY9 Imh0dHBzOi8vZml2ZS5zZW50ZW5jLmVzIj5odHRwczovL2ZpdmUuc2VudGVuYy5lczwvYT48bzpw PjwvbzpwPjwvcD4NCjwvZGl2Pg0KPC9kaXY+DQo8L2Rpdj4NCjwvZGl2Pg0KPC9ib2R5Pg0KPC9o dG1sPg0K --_000_HE1PR02MB303345141875293D6F1E8CD3DAE20HE1PR02MB3033eurp_-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: "Fraga, Eric" Subject: Re: File Scoped Properties? Date: Fri, 6 Mar 2020 06:51:27 +0000 Message-ID: <87mu8ugemp.fsf@ucl.ac.uk> References: Mime-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:55934) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jA6pX-000335-9T for emacs-orgmode@gnu.org; Fri, 06 Mar 2020 01:51:32 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jA6pW-0006K7-70 for emacs-orgmode@gnu.org; Fri, 06 Mar 2020 01:51:31 -0500 Received: from mail-vi1eur05on2119.outbound.protection.outlook.com ([40.107.21.119]:53280 helo=EUR05-VI1-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jA6pV-0006Fj-Sg for emacs-orgmode@gnu.org; Fri, 06 Mar 2020 01:51:30 -0500 In-Reply-To: (Tim Visher's message of "Thu, 5 Mar 2020 10:28:20 -0500") Content-Language: en-US List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Tim Visher Cc: Emacs Org Mode mailing list 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 s= et > 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. It's a form of security to ensure you don't have a file do something you don't want it to do. If you are happy for that variable to be set by files in this way generally, Emacs does give you the option of saving this information in the customization file and you won't get asked again. It's not that setting this variable this way is dangerous per se. But, for instance, this variable could be set by some file you receive from somebody else to a destination that is off your computer, e.g. using tramp. This is the closest that Emacs comes to being vulnerable to viruses (computer, not COVID-19 ;-)). --=20 : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Visher Subject: Re: File Scoped Properties? Date: Fri, 6 Mar 2020 09:09:07 -0500 Message-ID: References: <87mu8ugemp.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="0000000000002a5a9e05a0303534" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:49089) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jADfq-00040G-CT for emacs-orgmode@gnu.org; Fri, 06 Mar 2020 09:10:00 -0500 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jADfo-0003HE-L9 for emacs-orgmode@gnu.org; Fri, 06 Mar 2020 09:09:58 -0500 Received: from mail-wr1-x430.google.com ([2a00:1450:4864:20::430]:43417) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jADfo-00033J-Dg for emacs-orgmode@gnu.org; Fri, 06 Mar 2020 09:09:56 -0500 Received: by mail-wr1-x430.google.com with SMTP id v9so2505874wrf.10 for ; Fri, 06 Mar 2020 06:09:55 -0800 (PST) In-Reply-To: <87mu8ugemp.fsf@ucl.ac.uk> List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: "Fraga, Eric" Cc: Emacs Org Mode mailing list --0000000000002a5a9e05a0303534 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Thanks for the response, Eric. :) On Fri, Mar 6, 2020 at 1:51 AM Fraga, Eric 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. > Yep. That's fully understood. I'm less clear on why certain variables are considered safe and some are not but that doesn't seem relevant. I've done enough with file local and directory local variables in the past that I have a pretty clear understanding of what they do. 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=E2=80=93value pairs. When they are associated with a si= ngle entry or with a tree=E2=80=A6," for instance, seems to imply by "When they = are associated with a single entry=E2=80=A6" that they can be associated with a= ll 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: ` 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 `#+` as i= n `#+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: ` 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'l= l 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. :) -- In Christ, Timmy V. https://blog.twonegatives.com https://five.sentenc.es --0000000000002a5a9e05a0303534 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Thanks for the response, Eric. :)

On Fri, Mar 6, 2020 at 1:51 AM Fraga, Eric <e.fraga@ucl.ac.uk> wrot= e:
On Thursday,=C2=A0 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 sa= fe to set
> that.

You've already received a more org-ish response but I'll give you a= n
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.

Yep. That's fully understood. I'm less cl= ear on why certain variables are considered safe and some are not but that = doesn't seem relevant. I've done enough with file local and directo= ry local variables in the past that I have a pretty clear understanding of = what they do.

My question was more around why I ha= d to do it at all since based on my reading of the manual it seems like I s= hould've been able to do this with some kind of file-wide property. Spe= cifically, I've never been able to wrap my head around `(info "(or= g) Property Syntax")`.

"Properties are k= ey=E2=80=93value pairs. When they are associated with a single entry or wit= h a tree=E2=80=A6," for instance, seems to imply by "When they ar= e associated with a single entry=E2=80=A6" that they can be associated= with all the entries (or a particular tree or node).

<= div>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= 9;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 ea= rlier) use the `#+PROPERTY: <PROPERTY_NAME> <PROPERTY_VALUE>` s= yntax.

  2. Even then by default org-attach property inheritance= is set to `'selective` and `org-use-property-inheritance` is set to of= f. I've now customized `org-use-property-inheritance` to `'("D= IR")` which I believe says that I consider the `DIR` property to be a = possible candidate for inheritance and no others. I'm a little concerne= d 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 a= nything. 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. := )

--0000000000002a5a9e05a0303534-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Eric S Fraga Subject: Re: File Scoped Properties? Date: Sun, 08 Mar 2020 12:52:17 +0000 Message-ID: <87imjf3t6m.fsf@ucl.ac.uk> References: <87mu8ugemp.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: text/plain Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:48254) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jAvPq-0005p4-CC for emacs-orgmode@gnu.org; Sun, 08 Mar 2020 08:52:23 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jAvPp-0007Hi-8Q for emacs-orgmode@gnu.org; Sun, 08 Mar 2020 08:52:22 -0400 Received: from mail-db8eur05on2111.outbound.protection.outlook.com ([40.107.20.111]:5216 helo=EUR05-DB8-obe.outbound.protection.outlook.com) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_256_CBC_SHA1:32) (Exim 4.71) (envelope-from ) id 1jAvPo-0007H3-VY for emacs-orgmode@gnu.org; Sun, 08 Mar 2020 08:52:21 -0400 In-Reply-To: (Tim Visher's message of "Fri, 6 Mar 2020 09:09:07 -0500") List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: Tim Visher Cc: Emacs Org Mode mailing list On Friday, 6 Mar 2020 at 09:09, Tim Visher wrote: > I'm less clear on why certain variables are considered safe and some > are not but that doesn't seem relevant. My understanding is that all (most?) variables are considered unsafe unless you tell emacs otherwise. I know that my emacs custom variable include safe-local-variable-values which is a long list of variables that I have at one time or another told emacs are "safe". -- : Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880 From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Visher Subject: Re: File Scoped Properties? Date: Mon, 9 Mar 2020 09:24:29 -0400 Message-ID: References: <87mu8ugemp.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="00000000000048553905a06befdd" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:40330) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jBIPL-0005Id-DB for emacs-orgmode@gnu.org; Mon, 09 Mar 2020 09:25:24 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jBIPJ-0000fb-KJ for emacs-orgmode@gnu.org; Mon, 09 Mar 2020 09:25:23 -0400 Received: from mail-wr1-x42b.google.com ([2a00:1450:4864:20::42b]:40768) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jBIPJ-0000ey-Da for emacs-orgmode@gnu.org; Mon, 09 Mar 2020 09:25:21 -0400 Received: by mail-wr1-x42b.google.com with SMTP id p2so10303563wrw.7 for ; Mon, 09 Mar 2020 06:25:21 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: "Fraga, Eric" Cc: Emacs Org Mode mailing list --00000000000048553905a06befdd Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Fri, Mar 6, 2020 at 9:09 AM Tim Visher wrote: > Thanks for the response, Eric. :) > > On Fri, Mar 6, 2020 at 1:51 AM Fraga, Eric 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 t= o >> 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 wr= ap > my head around `(info "(org) Property Syntax")`. > > "Properties are key=E2=80=93value pairs. When they are associated with a = single > entry or with a tree=E2=80=A6," for instance, seems to imply by "When the= y are > associated with a single entry=E2=80=A6" 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: ` syntax. I've been tryin= g to > figure out how I misinterpreted that in the past and I _think_ it was > because I assumed that the `#+PROPERTY` was actually `#+` as= in > `#+DIR` rather than `#+PROPERTY: DIR`. It looks like to set a file loc= al > property in an org file you _must_ (at least on 9.3 or earlier) use th= e > `#+PROPERTY: ` 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 no= w > customized `org-use-property-inheritance` to `'("DIR")` which I believ= e > 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. (=EF=BC=8D=E2=80=B8=E1=83=9A) 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 =3D=3D `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. :) --00000000000048553905a06befdd Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
On Fri, Mar 6, 2020 at 9:09 AM Tim Visher= <tim.visher@gmail.com> w= rote:
Thanks for the response, Eric. :)

On Fri, Mar 6, 2020 at 1:51 AM Fraga, Er= ic <e.fraga@ucl.a= c.uk> wrote:
On Thursday,=C2=A0 5 Mar 2020 at 10:28, Ti= m 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 sa= fe to set
> that.

You've already received a more org-ish response but I'll give you a= n
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&= #39;ve never been able to wrap my head around `(info "(org) Property S= yntax")`.

"Properties are key=E2=80= =93value pairs. When they are associated with a single entry or with a tree= =E2=80=A6," for instance, seems to imply by "When they are associ= ated with a single entry=E2=80=A6" that they can be associated with al= l the entries (or a particular tree or node).

Anyw= ay, I think between you and Gustav I finally have this sorted.
  • To set properties at the top level of a file you need to use the `#+P= ROPERTY: <PROPERTY_NAME> <PROPERTY_VALUE>` syntax. I've bee= n 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 f= ile local property in an org file you _must_ (at least on 9.3 or earlier) u= se the `#+PROPERTY: <PROPERTY_NAME> <PROPERTY_VALUE>` syntax.
  • 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. :)
    <= /div>

    I'll go ahead and correct m= yself.=C2=A0(=EF=BC=8D=E2=80=B8=E1=83=9A)

    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 tha= t ID paths are not then suffixed upon the end of it like `./data/XX/XXXXX-X= XX-XXX/` for each entry. Instead, if you have `DIR` set, that headings atta= chment directory =3D=3D `DIR`.

    So the way to chang= e the attachment directory prefix is just not to mess with `DIR` at all. In= stead, 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 varia= ble.

    ```
    # Local Variables:
    # org-att= ach-id-dir: "~/.foo/data"
    # End:
    ```
    <= br>
    Cheers. :)
    --00000000000048553905a06befdd-- From mboxrd@z Thu Jan 1 00:00:00 1970 From: Tim Visher Subject: Re: File Scoped Properties? Date: Tue, 24 Mar 2020 20:57:15 -0400 Message-ID: References: <87mu8ugemp.fsf@ucl.ac.uk> Mime-Version: 1.0 Content-Type: multipart/alternative; boundary="000000000000a402e705a1a35b39" Return-path: Received: from eggs.gnu.org ([2001:470:142:3::10]:60193) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1jGuMm-0005Wv-Q8 for emacs-orgmode@gnu.org; Tue, 24 Mar 2020 20:57:58 -0400 Received: from Debian-exim by eggs.gnu.org with spam-scanned (Exim 4.71) (envelope-from ) id 1jGuMk-0003oy-SK for emacs-orgmode@gnu.org; Tue, 24 Mar 2020 20:57:56 -0400 Received: from mail-wr1-x434.google.com ([2a00:1450:4864:20::434]:39889) by eggs.gnu.org with esmtps (TLS1.0:RSA_AES_128_CBC_SHA1:16) (Exim 4.71) (envelope-from ) id 1jGuMk-0003ns-JC for emacs-orgmode@gnu.org; Tue, 24 Mar 2020 20:57:54 -0400 Received: by mail-wr1-x434.google.com with SMTP id p10so921190wrt.6 for ; Tue, 24 Mar 2020 17:57:54 -0700 (PDT) In-Reply-To: List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+geo-emacs-orgmode=m.gmane-mx.org@gnu.org Sender: "Emacs-orgmode" To: "Fraga, Eric" Cc: Emacs Org Mode mailing list --000000000000a402e705a1a35b39 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable On Mon, Mar 9, 2020 at 9:24 AM Tim Visher wrote: > On Fri, Mar 6, 2020 at 9:09 AM Tim Visher wrote: > >> Thanks for the response, Eric. :) >> >> On Fri, Mar 6, 2020 at 1:51 AM Fraga, Eric 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 wit= h >> some kind of file-wide property. Specifically, I've never been able to w= rap >> my head around `(info "(org) Property Syntax")`. >> >> "Properties are key=E2=80=93value pairs. When they are associated with a= single >> entry or with a tree=E2=80=A6," for instance, seems to imply by "When th= ey are >> associated with a single entry=E2=80=A6" that they can be associated wit= h 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: ` syntax. I've been tryi= ng to >> figure out how I misinterpreted that in the past and I _think_ it was >> because I assumed that the `#+PROPERTY` was actually `#+` a= s in >> `#+DIR` rather than `#+PROPERTY: DIR`. It looks like to set a file lo= cal >> property in an org file you _must_ (at least on 9.3 or earlier) use t= he >> `#+PROPERTY: ` 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 n= ow >> customized `org-use-property-inheritance` to `'("DIR")` which I belie= ve >> says that I consider the `DIR` property to be a possible candidate fo= r >> inheritance and no others. I'm a little concerned about performance >> implications as the manual gives me all kinds of scary warnings but w= e'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. (=EF=BC=8D=E2=80=B8=E1=83=9A) > > 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 =3D=3D `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! --000000000000a402e705a1a35b39 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
    On Mon, Mar 9, 2020 at 9:24 AM Tim Visher= <tim.visher@gmail.com> w= rote:
    On Fri, Mar 6, 2020 at 9= :09 AM Tim Visher <tim.visher@gmail.com> wrote:
    T= hanks for the response, Eric. :)

    On Fr= i, Mar 6, 2020 at 1:51 AM Fraga, Eric <e.fraga@ucl.ac.uk> wrote:
    On Thurs= day,=C2=A0 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 sa= fe to set
    > that.

    You've already received a more org-ish response but I'll give you a= n
    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&= #39;ve never been able to wrap my head around `(info "(org) Property S= yntax")`.

    "Properties are key=E2=80= =93value pairs. When they are associated with a single entry or with a tree= =E2=80=A6," for instance, seems to imply by "When they are associ= ated with a single entry=E2=80=A6" that they can be associated with al= l the entries (or a particular tree or node).

    Anyw= ay, I think between you and Gustav I finally have this sorted.
  • To set properties at the top level of a file you need to use the `#+P= ROPERTY: <PROPERTY_NAME> <PROPERTY_VALUE>` syntax. I've bee= n 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 f= ile local property in an org file you _must_ (at least on 9.3 or earlier) u= se the `#+PROPERTY: <PROPERTY_NAME> <PROPERTY_VALUE>` syntax.
  • 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. :)
    <= /div>

    I'll go ahead and correct m= yself.=C2=A0(=EF=BC=8D=E2=80=B8=E1=83=9A)

    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 tha= t ID paths are not then suffixed upon the end of it like `./data/XX/XXXXX-X= XX-XXX/` for each entry. Instead, if you have `DIR` set, that headings atta= chment directory =3D=3D `DIR`.

    So the way to chang= e the attachment directory prefix is just not to mess with `DIR` at all. In= stead, 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 varia= ble.

    ```
    # Local Variables:
    # org-att= ach-id-dir: "~/.foo/data"
    # End:
    ```
    <= br>
    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:=C2=A0https://blog.twonega= tives.com/post/613474532727095296/how-to-set-the-attach-directory-prefix-fo= r

    Happy Org!=C2=A0
    --000000000000a402e705a1a35b39--