Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
Hi, stardiviner writes: > I would like to be the maintainer of org-contacts.el. (I might > already replied this message? Sorry if duplicated.) You are already org-contacts.org's maintainer: https://git.sr.ht/~bzg/org-contrib/tree/master/item/lisp/org-contacts.el#L6 > I have separated and put org-contacts on > GitHub https://github.com/stardiviner/org-contacts.el. I've added this as the new homepage for org-contacts.el and listed org-contacts.el in the library to remove from next versions of org-contrib. > And I'm in the progress to put it on NonGNU ELPA or MELPA. Great, thank you very much! -- Bastien
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
I would like to be the maintainer of org-contacts.el. (I might already replied this message? Sorry if duplicated.) I have separated and put org-contacts on GitHub https://github.com/stardiviner/org-contacts.el. And I'm in the progress to put it on NonGNU ELPA or MELPA. [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Mon, Dec 14, 2020 at 2:06 PM Bastien wrote: > Hi stardiviner, > > what is the last state of your patch? Feel free to resend it, > I will apply it. > > Also, do you want to become the maintainer for org-contacts.el? > > Remember, elisp files in contrib/ will soon be extracted from > the repository: https://orgmode.org/list/87wnzfy60h@bzg.fr > > Still, it's useful to already know who will be in charge. > > Thanks, > > -- > Bastien >
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
Change an email is hard word for me. I use gmail address for many places. I started to use new email for new accounts recently. But switch email need to be later when I have time and desire. And thanks for your suggestion of mail services. :smile: [stardiviner] GPG key ID: 47C32433 IRC(freeenode): stardiviner Twitter: @numbchild Key fingerprint = 9BAA 92BC CDDD B9EF 3B36 CB99 B8C4 B8E5 47C3 2433 Blog: http://stardiviner.github.io/ On Tue, Nov 17, 2020 at 2:50 PM Jean Louis wrote: > * stardiviner [2020-11-16 13:21]: > :PROPERTIES: > :ID: e2c30814-b983-4391-869a-3c700d041467 > :END: > > > > First, thank your very much for suggestion. > > > > What really I have not found your email in my Gmail (in web > > browser), > > Maybe because it went to Spam/Junk folder. For privacy and safety > reasons I do not recommend using Gmail at all. > > I may recommend using your own email address, requires some money, or > https://posteo.de/ https://tutanota.de/ or https://protonmail.ch/ > > > I found it in mu4e (Emacs). Which I can't reply because I'm in > > China, sendmail to Gmail SMTP server is blocked. So I'm replying you > > in mu4e. Don't know whether you can receive my message. > > I wish I could understand, mu4e is only local system that searches > emails on your computer. How you send emails depends on your email > provider. Maybe you fetch mailing list to search for emails? > > > Using unique ID is the only solution to identity contact. I already > thought > > about this. But integrating org-id is hard for me. Have not spent that > time on > > it yet. But I will, if I want to improve this org-contacts. > > If I may just give idea. I am using this below function to > automatically get ID numbers for headings. Normally it is by > saving. Maybe you can do something to automatically insert such > number. I do not know if heading is contact, but if it is, it becomes > all easier. > > (defun rcd-org-add-ids-to-headlines-in-file () > "Add ID properties to all headlines in the current file which > do not already have one." > (interactive) > (org-map-entries 'org-id-get-create)) > > > > 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. > > Once you have decided how is contact referenced as now is referenced > by query, I could maybe figure how to obtain the reference. > > It should not be that hard: > > - find the current heading > > - find current ID number > > - how link should look like could be customizable, maybe heading as > visible part. That requires discussion. > > - prepare link into memory for pasting in other window or document. > > - it should also be possible to insert such into register. > > - the option to obtain link by query should be kept intact > > Maybe two keybindings or functions can be made: > > ** Proposal > :PROPERTIES: > :ID: a566d476-f478-44d8-8d91-53f6eccca10b > :END: > > 1. One that finds the current heading and obtains the link > > (defun capture-contact-by-query-to-heading () > (let* ((heading (org-get-heading)) > (link (format "[[org-contact:query#%s][%s]]" heading heading))) > (kill-new link))) > > (capture-contact-by-query-to-heading) > > => [[org-contact:query#Proposal][Proposal]] > > And such function should be expanded and be customizable: > > - maybe user wish to provide format string as maybe user wish to know > visually that link leads to contact like: > > => [[org-contact:query#John Doe][Contact: John Doe]] > > 2. One that finds currentheading by its ID and obtains the link: > > (defun capture-contact-by-id-to-heading-1 () > (let* ((heading (org-get-heading)) > (id (org-id-get)) > (link (format "[[org-contact:id#%s][%s]]" id heading))) > link)) > > (defun capture-contact-by-id-to-heading () > (kill-new (capture-contact-by-id-to-heading-1))) > > (capture-contact-by-id-to-heading) > > => [[org-contact:id#a566d476-f478-44d8-8d91-53f6eccca10b][Proposal]] > > These are design ideas only. You may expand and make checks on these > functions that such work properly. > > Additional functions that may be very usable is to quickly send links > to other window. User is collecting the database of contacts in one > file and one window and wishes to insert links into other window that > references such contacts. In that file where you need a link you would > arrive with cursor. Then you go to database of contacts and invoke a > key that sends the yanked org link into other window. > > (defun contact-yank-link-in-other-window () > (let ((link (capture-contact-by-id-to-heading-1))) > (kill-new link) > (other-window 1) > (yank) > (other-window 1) > (message "Yanked link: %s to other window" link))) > > It is up to you to expand or think on this as it is design > proposal. Not finalized function or feature. When we wish to > reference things we
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
Hi stardiviner, what is the last state of your patch? Feel free to resend it, I will apply it. Also, do you want to become the maintainer for org-contacts.el? Remember, elisp files in contrib/ will soon be extracted from the repository: https://orgmode.org/list/87wnzfy60h@bzg.fr Still, it's useful to already know who will be in charge. Thanks, -- Bastien
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
* stardiviner [2020-11-16 13:21]: :PROPERTIES: :ID: e2c30814-b983-4391-869a-3c700d041467 :END: > > First, thank your very much for suggestion. > > What really I have not found your email in my Gmail (in web > browser), Maybe because it went to Spam/Junk folder. For privacy and safety reasons I do not recommend using Gmail at all. I may recommend using your own email address, requires some money, or https://posteo.de/ https://tutanota.de/ or https://protonmail.ch/ > I found it in mu4e (Emacs). Which I can't reply because I'm in > China, sendmail to Gmail SMTP server is blocked. So I'm replying you > in mu4e. Don't know whether you can receive my message. I wish I could understand, mu4e is only local system that searches emails on your computer. How you send emails depends on your email provider. Maybe you fetch mailing list to search for emails? > Using unique ID is the only solution to identity contact. I already thought > about this. But integrating org-id is hard for me. Have not spent that time on > it yet. But I will, if I want to improve this org-contacts. If I may just give idea. I am using this below function to automatically get ID numbers for headings. Normally it is by saving. Maybe you can do something to automatically insert such number. I do not know if heading is contact, but if it is, it becomes all easier. (defun rcd-org-add-ids-to-headlines-in-file () "Add ID properties to all headlines in the current file which do not already have one." (interactive) (org-map-entries 'org-id-get-create)) > > 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. Once you have decided how is contact referenced as now is referenced by query, I could maybe figure how to obtain the reference. It should not be that hard: - find the current heading - find current ID number - how link should look like could be customizable, maybe heading as visible part. That requires discussion. - prepare link into memory for pasting in other window or document. - it should also be possible to insert such into register. - the option to obtain link by query should be kept intact Maybe two keybindings or functions can be made: ** Proposal :PROPERTIES: :ID: a566d476-f478-44d8-8d91-53f6eccca10b :END: 1. One that finds the current heading and obtains the link (defun capture-contact-by-query-to-heading () (let* ((heading (org-get-heading)) (link (format "[[org-contact:query#%s][%s]]" heading heading))) (kill-new link))) (capture-contact-by-query-to-heading) => [[org-contact:query#Proposal][Proposal]] And such function should be expanded and be customizable: - maybe user wish to provide format string as maybe user wish to know visually that link leads to contact like: => [[org-contact:query#John Doe][Contact: John Doe]] 2. One that finds currentheading by its ID and obtains the link: (defun capture-contact-by-id-to-heading-1 () (let* ((heading (org-get-heading)) (id (org-id-get)) (link (format "[[org-contact:id#%s][%s]]" id heading))) link)) (defun capture-contact-by-id-to-heading () (kill-new (capture-contact-by-id-to-heading-1))) (capture-contact-by-id-to-heading) => [[org-contact:id#a566d476-f478-44d8-8d91-53f6eccca10b][Proposal]] These are design ideas only. You may expand and make checks on these functions that such work properly. Additional functions that may be very usable is to quickly send links to other window. User is collecting the database of contacts in one file and one window and wishes to insert links into other window that references such contacts. In that file where you need a link you would arrive with cursor. Then you go to database of contacts and invoke a key that sends the yanked org link into other window. (defun contact-yank-link-in-other-window () (let ((link (capture-contact-by-id-to-heading-1))) (kill-new link) (other-window 1) (yank) (other-window 1) (message "Yanked link: %s to other window" link))) It is up to you to expand or think on this as it is design proposal. Not finalized function or feature. When we wish to reference things we need it quick and fast. Org mode in general needs these types of functions: - to automatically obtain ANY link from Org mode to the heading and not just for users to write the link by hand. Examples are: - link to specific line - link to query, when text is marked, that link may be constructed, and also if necessary quickly inserted in other window (we use links to reference from same buffer to same buffer or from other buffer and file to other files). Such query could be automatically minimized that it does not carry all the marked words. Few words could be enough. - link to any heading or subheading by its name - link to any heading by its ID or CUSTOM_ID - and so on, there shall be
Re: More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
First, thank your very much for suggestion. What really I have not found your email in my Gmail (in web browser), I found it in mu4e (Emacs). Which I can't reply because I'm in China, sendmail to Gmail SMTP server is blocked. So I'm replying you in mu4e. Don't know whether you can receive my message. Jean Louis writes: > * 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. Using unique ID is the only solution to identity contact. I already thought about this. But integrating org-id is hard for me. Have not spent that time on it yet. But I will, if I want to improve this org-contacts. > > 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
More on design of org-contacts.el - Re: [UPDATED PATCH] Re: add new link type "contact:" for org-contacts.el
* 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:
