From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp1 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id pdLYGCfuq1/DDwAA0tVLHw (envelope-from ) for ; Wed, 11 Nov 2020 13:59:03 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp1 with LMTPS id oPwcFCfuq19rRwAAbx9fmQ (envelope-from ) for ; Wed, 11 Nov 2020 13:59:03 +0000 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 C4CBC9403A8 for ; Wed, 11 Nov 2020 13:59:02 +0000 (UTC) Received: from localhost ([::1]:37258 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kcqeK-0001ZV-O3 for larch@yhetil.org; Wed, 11 Nov 2020 08:59:00 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:54446) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcqdh-0001XV-F1 for emacs-orgmode@gnu.org; Wed, 11 Nov 2020 08:58:22 -0500 Received: from static.rcdrun.com ([95.85.24.50]:45729) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kcqdd-0000Tm-PE; Wed, 11 Nov 2020 08:58:21 -0500 Received: from localhost ([::ffff:197.157.34.177]) (AUTH: PLAIN admin, TLS: TLS1.2,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by static.rcdrun.com with ESMTPSA id 00000000002C0006.000000005FABEDF8.00003816; Wed, 11 Nov 2020 13:58:15 +0000 Date: Wed, 11 Nov 2020 16:57:35 +0300 From: Jean Louis To: stardiviner Subject: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el Message-ID: References: <874klwcmrk.fsf@gnu.org> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.0 (3d08634) (2020-11-07) Received-SPF: pass client-ip=95.85.24.50; envelope-from=bugs@gnu.support; helo=static.rcdrun.com X-detected-operating-system: by eggs.gnu.org: First seen = 2020/11/11 08:57:59 X-ACL-Warn: Detected OS = Linux 3.11 and newer [fuzzy] X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Cc: Bastien , julien@danjou.info, Org-mode , Jean Louis Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of emacs-orgmode-bounces@gnu.org designates 209.51.188.17 as permitted sender) smtp.mailfrom=emacs-orgmode-bounces@gnu.org X-Spam-Score: -0.51 X-TUID: kLp13iEWR1Fx * stardiviner [2020-11-11 15:05]: :PROPERTIES: :CREATED: [2020-11-11 Wed 16:57] :ID: 17d463d2-ff0c-4614-93da-06e3de8e6035 :END: > Thank you too. > I indeed want to extend org-contacts.el. So I would like to be it's > maintainer. > > Currently how many org-mode maintainer(mailing list manager)? > If patch need to wait a month. Because I spend less time on org-mode too > comparing before time. I agree with that, I might will add multiple PATCHes > together. Side notes: I have looked into contacts. It relies on a query to find a contact. I hope that I am right. Text based Org mode anyway may rely on built-in text searches like incremental Emacs's search. org-contact wishes to pin point to specific contact. It wants to create a hyperlink to one specific contact. It does not want to find 2 contacts with the same query or more of them. As I have 195000 contacts in PostgreSQL database I know from browsing them that many of them have same unique names. To reference to a specific contact by using name query would be useless as I could miss it and take other contact. Thus search involves narrowing contacts by maybe state, location and other filters. Each contact has its own uniquely assigned ID number. An integer assigned by the database automatically. By using the ID number I can easily capture the reference link to th contact from the database and insert such link into the Org file. As long as I do not change the ID number even if contact name is changed I would be able to pin point the specific number. Thus for org-contacts I recommend creation of unique IDs in the properties for headings for each contact so that contact may be referenced by the unique ID. Additional proposals: Each hyperdocument (within or without Emacs) that allows back linking to its specifical parts should have a function or key binding to quickly obtain the link reference. For example if user browses heading for *** John Doe anywhere within such heading user should be able to press a key to capture the link to the contact automatically. In the file my-contacts.org: *** John Doe :PROPERTIES: :ID: cc400d57-2adf-47af-90d9-c4d9fdd70d2b :CREATED: [2020-11-11 Wed 16:57] :END: DATA **** DATA :PROPERTIES: :CREATED: [2020-11-11 Wed 16:57] :ID: 19781b53-211b-4291-af48-5f3655dd7cec :END: **** DATA :PROPERTIES: :CREATED: [2020-11-11 Wed 16:57] :ID: e8eb6647-8d8e-4ec6-b759-43dcfd60d17b :END: Anywhere within the subtree for John Doe user should be able to obtain the reference to the contact. For example by clicking `C-x w'. Upon key press following link could then be stored into memory, or register, whatever is better design: [[org-contact:~/file/my-contacts.org#cc400d57-2adf-47af-90d9-c4d9fdd70d2b][John Doe]] Then user would go to other Org file and use `C-y' to yank the contact into the new file. One shall consider that obtaining the object reference should be on the fly customizable. As maybe I wish to have in the link: - Contact's first name only like when addressing friends - Contact's full name, with or without middle names - Contact's name plus city and country Having several ways to obtain quickly reference to the contact (to generate link in memory) is useful feature that shortens the time and makes it less error prone for the user. If only query is used with simple typo contact link will not work. What will follow is tedious browsing and opening of files to find the right contact. User can have many Org contact files and file reference should be included into the file. This assumes that files should be fixed in file system. This proposal follows the Doug Engelbart's Technology Template Project for Open Hyperdocument Systems (OHS) in relation to addressing: https://www.dougengelbart.org/content/view/110/460/#2b1 Global, Human-Understandable, Object Addresses Every object that someone might validly want/need to cite or otherwise access should have an unambiguous address, capable of being portrayed in a human readable and interpretable manner. Most common existing spreadsheet programs have provisions similar to this for cell addressibility And: Link Addresses That Are Readable and Interpretable by Humans https://www.dougengelbart.org/content/view/110/460/#2b1b It should be possible to display and specify the complete link address of any object in the global domain of the OHS. This human-readable description of the "address path" leading to the cited object should permit a transparent possibility for human understanding of the path including the possibility of reading, interpretation, and conceptually following the specification As Emacs already supports remote files, contact path can be automatically obtained. If I am editing contacts on remote VPS server, maybe users on the remote server and their details, then my local Org file should be able to point to remote server. Such link would look like: [[org-contact:/ssh:example.com/home/me/my-contacts.org#cc400d57-2adf-47af-90d9-c4d9fdd70d2b][John Doe]] That way the object to cite or access has: - unambiguious address by having unique ID - by showing literal links user can see WHERE the object is located, is it on localhost, remote server, could be even on https or various other locations. - contact's name remain very human readable Additionally I have been looking into contacts and have seen the structure and I think I did not see the group reference. Contact may belong to one or more groups which I call accounts: Contact may in in "My family" group, working in the "ABC Company" group and being member of "Heidelberger Sportverein" group. And each of those groups can be also a contact with or without individual names. Every contact management requires groups to satisfy basics of off-line contact management. People contact hospitals, network providers, government offices and need not have specific individual name. Thus Org contact need a switch or designation to say if the contact is a group or just individual. And for individuals it should ask in which group it belongs, while remembering that one contact may belong to multiple groups. Text is alright for contact management until it reaches certain size when it becomes unmanageable. Then it requires GNU GDBM database or other type of database which we sadly do not have as built-in. Jean