From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id WMuTL0cVn2PZkwAAbAwnHQ (envelope-from ) for ; Sun, 18 Dec 2022 14:27:35 +0100 Received: from aspmx1.migadu.com ([2001:41d0:8:6d80::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id 8PmVL0cVn2MKXQAA9RJhRA (envelope-from ) for ; Sun, 18 Dec 2022 14:27:35 +0100 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 5002C1BE63 for ; Sun, 18 Dec 2022 14:27:35 +0100 (CET) Received: from localhost ([::1] helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1p6tgp-0007jO-W0; Sun, 18 Dec 2022 08:26:52 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p6tgn-0007iw-K8 for emacs-orgmode@gnu.org; Sun, 18 Dec 2022 08:26:49 -0500 Received: from mout02.posteo.de ([185.67.36.66]) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1p6tgj-0003Rq-IV for emacs-orgmode@gnu.org; Sun, 18 Dec 2022 08:26:49 -0500 Received: from submission (posteo.de [185.67.36.169]) by mout02.posteo.de (Postfix) with ESMTPS id 124D1240104 for ; Sun, 18 Dec 2022 14:26:41 +0100 (CET) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=posteo.net; s=2017; t=1671370003; bh=Fa55t4c2Etv1zGVW6rUYapQDB56wyoaffwngIiKVCX8=; h=From:To:Cc:Subject:Date:From; b=SBMp+iF2GeioISKJzqX6W1GKqDsE4tVOwcxpw3lm2JUUYxI4zByqYuLKuxOpcGRGo ziDNZsKW+tWLEplnoG1nPSsYv7OxIHADPd6CSSx/vRYA1y7gYS4K2D7fKa54aM0R3r pIjf+Wl/9V2xXUklyEh7DjOASKTXhtpUw4j8QmnLDN0X91OZAv5LA7IEys1We4yUc2 htkRoQ5QX+9+K/V1B/NLI9iOXwJG3PLRPHbu1cxdm83rtIeIR7N4MSMSG5WUQRKt9S NZQrocND5GmwMIm5QKvHRlXhOPQ7dwO0dEiHY0bywKIR8oQ3xulfWfZjoVUu8KUzVD EqtmEX0FEUVNA== Received: from customer (localhost [127.0.0.1]) by submission (posteo.de) with ESMTPSA id 4NZkBm3ybjz6tnm; Sun, 18 Dec 2022 14:26:40 +0100 (CET) From: Ihor Radchenko To: Jean Louis Cc: Sterling Hooten , emacs-orgmode@gnu.org, hyperbole-users@gnu.org Subject: [Feature] Store heading properties remotely, outside the Org file (was: Completely hide properties drawer in 9.6) In-Reply-To: References: <4CC6A1F4-0B08-44E0-AE4D-60CA11636663@gmail.com> <87ilibsha7.fsf@localhost> <87bko3s7gy.fsf@localhost> Date: Sun, 18 Dec 2022 13:26:29 +0000 Message-ID: <87zgbk6dx6.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=185.67.36.66; envelope-from=yantar92@posteo.net; helo=mout02.posteo.de X-Spam_score_int: -43 X-Spam_score: -4.4 X-Spam_bar: ---- X-Spam_report: (-4.4 / 5.0 requ) BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, DKIM_VALID_EF=-0.1, RCVD_IN_DNSWL_MED=-2.3, RCVD_IN_MSPIKE_H2=-0.001, SPF_HELO_NONE=0.001, SPF_PASS=-0.001 autolearn=unavailable autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: emacs-orgmode-bounces+larch=yhetil.org@gnu.org X-Migadu-Country: US X-Migadu-Flow: FLOW_IN ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=SBMp+iF2; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" ARC-Seal: i=1; s=key1; d=yhetil.org; t=1671370055; a=rsa-sha256; cv=none; b=BEUeN8IoxSPL/wJM1g4O1g8/ehG/CuvIvTKs8vuNvHmjVbwkebD2BoIiXsr/DhSw3jCswM imdsLwi0Q15boCX6R0pXUqXK+BSDdG8Ti7xgEWhc0SQ8LFvDku9HbS0ntsP8lYTbOVETGf WbqIaU+ks5d2QbZOmxAbNVYXoEdW4F3qwYCJ+rXnQXNmsjsKuK22blN1p2ZEJqfhU+oaA3 qsct7BbgJsugDp2BfkcMW7DCQcMswWSMWQVKCO3pxwQV4YIi3YYZEt9CPtflbCJxhU60qD SOnbbvVo0xCehwzMf1QgDAY+zoT1KBvDbIFmBaFlmWy+F9hS2d5mAQV40cIYoA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1671370055; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type:in-reply-to:in-reply-to: references:references:list-id:list-help:list-unsubscribe: list-subscribe:list-post:dkim-signature; bh=Tq4VGxc2IKtjtN7TEX+UvEA/3CDzxEMUnbcgWACkJVA=; b=gIVul+AsSk2e+Q6xAT2h1BcktpJYUNNsbk4I1m4twtqzPqnbcnItWKf4dq7ThuTvHSJZhD ByGmxbw4wWy/khUk2uB/RKdj4wlnElED019C0BK7S3pM3Gy2zhn3SoI81tsFwtNq/LgP0g m4NG7KNdM+iCO+NCc+QhodKJFKne16L5a0tkSyCOJ8OYsTGGMiVlhSfSltyzKVBB1TB+Nd 1EZSV+E0Jr0qyhQ+sUgkm1bkpMwowg9aZoCaeYO4Q5TkbbKDxLJv9JzcaZfJZlO3CP8738 4Fv+kWCV7NGqUajPL3/8eZOLPHJYGcRWYbh8bDr0y9Cc4bMw93uca7+oGQdIPA== Authentication-Results: aspmx1.migadu.com; dkim=pass header.d=posteo.net header.s=2017 header.b=SBMp+iF2; dmarc=pass (policy=none) header.from=posteo.net; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Scanner: scn1.migadu.com X-Migadu-Spam-Score: -4.41 X-Spam-Score: -4.41 X-Migadu-Queue-Id: 5002C1BE63 X-TUID: tnqZUmBYvSSV Below is the idea how one can store heading properties in a separate file or even database. I think it might be of interest for users who hate property drawer clutter yet needed to store some metadata associated with Org headings. To be consistent with Org internal logic, we may, instead of using ID, use a separate :INCLUDE-PROPERTIES: heading property to define where the additional heading properties are stored. If a heading has :INCLUDE-PROPERTIES:, the properties will be calculated according to: (1) heading property drawer; (2) INCLUDE-PROPERTIES value; (3) parent headings, if property inheritance is enabled. The value of INCLUDE-PROPERTIES might be a file:/id: link that may point to another Org heading, or, potentially (maybe via third-party packages), to SQL database. Jean Louis writes: > To me it is very practical to have this simple heading with a drawer > that is completely hidden, which references by using UUID to a complex > set of properties. To somebody else, that may not be useful or is > abstract to understand. > > In my work I would not like having more properties for Org heading but > one, like this one: > > * My heading > :PROPERTIES: > :ID: 944334aa-acab-4e6a-8dd6-ebfd144eac6b > :END: > > And that alone would be a reference to any other property that I > personally may need. It is a link from heading to relations to many > different pieces of information. > ... > Emacs 29 has SQLite built-in, there is PostgreSQL module and also > rcd-hash-edit package that works in similar way as shown on > video. Hashes may easily be stored in text files and read from text files. > ... > And by thinking that, it is also possible to make Org functions that save properties in separate Org file automatically. > > In case of the heading like this: > > * My heading > :PROPERTIES: > :ID: 944334aa-acab-4e6a-8dd6-ebfd144eac6b > :END: > > One could have a separate Org file that is used only to write properties, and which could contain something like following: > > * 944334aa-acab-4e6a-8dd6-ebfd144eac6b > :PROPERTIES: > :DATE-CREATED: 2022-12-18 > :PERSON-RELATED: Ihor Radchenko > :END: > > There are many reasons why properties should be hidden or separate > from Org file, apart from aesthetics and readability. I have been > sharing Org files and headings too many times to staff members > (without export), and then why should other person see clocked or > scheduled properties if such are not meant for that person? > > The above eloboration demonstrates that properties could not only be > hidden from main view, but become structural and organized collection > of data. Storage is possible into PostgreSQL by using emacs-libpq > module or PostgreSQL packages, in Emacs 29 by using the built-in > SQLite or SQLite packages, or cdb database or key/value databases, or > by storing hashes into files, or by storing properties into separate > Org files. > > Implementation is close to fingertips. > > Generally, using properties and UUIDs as references to properties, > also liberates properties from Org mode and gives the power of > referencing to any kind of text or mode. > > That means, having Markdown file with commented UUID, could allow the > user to have the same properties as in Org mode, one could freely tag, > clock-in, clock-out, schedule, deadline, etc. any kind of Markdown > heading, whatabout Asciidoc, truly plain text, HTML pieces, Wiki, and > other formats and files. > > In normal text files, I would then make UUIDs invisible inside of > Emacs, when necessary: > > (defun rcd-uuid-reference-make-invisible () > "Make all UUIDs in buffer invisible." > (interactive) > (save-excursion > (goto-char (point-min)) > (while (search-forward-regexp thing-at-point-uuid-regexp nil t) > (when (thing-at-point 'uuid) > (facemenu-set-invisible (match-beginning 0) (match-end 0)))))) > > ;; df2c9f4d-77ab-4697-842e-d7aa31ffeee3 > > If UUIDs are disturbing in the output, then I would have a filter to > export the file without UUIDs, when necessary. -- Ihor Radchenko // yantar92, Org mode contributor, Learn more about Org mode at . Support Org development at , or support my work at