From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp2 ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms11 with LMTPS id sJFHAwNLw18KfwAA0tVLHw (envelope-from ) for ; Sun, 29 Nov 2020 07:17:23 +0000 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp2 with LMTPS id kKyhOgJLw18aeAAAB5/wlQ (envelope-from ) for ; Sun, 29 Nov 2020 07:17:22 +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 0CA30940437 for ; Sun, 29 Nov 2020 07:17:21 +0000 (UTC) Received: from localhost ([::1]:55320 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1kjGxU-0001LZ-KP for larch@yhetil.org; Sun, 29 Nov 2020 02:17:20 -0500 Received: from eggs.gnu.org ([2001:470:142:3::10]:51286) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1kjGwi-0001LP-Ml for emacs-orgmode@gnu.org; Sun, 29 Nov 2020 02:16:32 -0500 Received: from mail-pg1-x532.google.com ([2607:f8b0:4864:20::532]:39172) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_128_GCM_SHA256:128) (Exim 4.90_1) (envelope-from ) id 1kjGwf-0007gj-Ic for emacs-orgmode@gnu.org; Sun, 29 Nov 2020 02:16:32 -0500 Received: by mail-pg1-x532.google.com with SMTP id f17so7796527pge.6 for ; Sat, 28 Nov 2020 23:16:27 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20161025; h=from:to:cc:subject:in-reply-to:references:date:message-id :mime-version; bh=0U0FHfSp+4coS5Cb9Lh54dnWi9KsvVE+oYItdqd7fTQ=; b=rNuR9Mbi1Krhsp3HNBhwH8+B2uEUycliGep391Hcac1FeFvxOn3BU4Ls5HJHzKfhaq zJhwWPx9vzBYPMJTeK9VshWOFCW50Q7fHlm4aagEoDGJrGT+KLKFHH88FtGzme/koArP kccGJAByPjc/LLTWsr/yYn2mVlp7zFrRxlM7wuShlFpUTjQ1VHmCFKYprZVATwC/QNBO V6hdSzVuZCHmnZszlNJ1t18BcJw8t7OIL9o9BqVc5yx1oRMCPEYMkTN7oW5Fe7sFxV1W CnlJDJCNEDta9u8ln6lhpQHpCwLsg1GM1pZL+K5BhtpRd5N22vxurnwmNHQ3fsjO5WtH DUCg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:from:to:cc:subject:in-reply-to:references:date :message-id:mime-version; bh=0U0FHfSp+4coS5Cb9Lh54dnWi9KsvVE+oYItdqd7fTQ=; b=N+x2lk8Gs82WtxPrCAnAcu1WMLBLUxX6HJqExna1PzJbUpfQbMUC4EF6Pglwa3gLag 0uh180pDaDSmV/ux1XGJrrj1FOSUeYM8YvkUiUmMUcUi5haj61zoPb8dE6R389gWjQ5L eg96iH5Gsw9Gvu5sA5ruuD1wKyrC0KMxZZcnlkFNH/l0aFxEoGRy4MLNEG/fPDb1gfNr cxmd/DdeNbXE6Tdca8SFcqzq3k5WWdgBJ3caap5AEPtBDPCECERJNqK22oLlbOmMTTkR RxAoFtUaCgHAC/2iArs5dewK/GmLRwwu6ZXhrKBls474CIzHiNoz7j7tJrv/CsCmscgi D3hg== X-Gm-Message-State: AOAM530MMtpJCGIKBPPNi6yjXX4jv5xMUxjkgooSw60vn8vSIiPjMT7U PsjIOM1a7TGiv93sIEU4sZc= X-Google-Smtp-Source: ABdhPJxylW8vG0czNL+BMLrhVqxhxfbx7+f72ixSGxtw9WviuLsTo+b59pUU2K338Syx9Ci9LSzoHA== X-Received: by 2002:a17:90a:2e04:: with SMTP id q4mr20234749pjd.37.1606634186512; Sat, 28 Nov 2020 23:16:26 -0800 (PST) Received: from localhost ([103.125.234.161]) by smtp.gmail.com with ESMTPSA id d3sm6946131pgd.72.2020.11.28.23.16.24 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Sat, 28 Nov 2020 23:16:25 -0800 (PST) From: Ihor Radchenko To: Jean Louis Subject: Re: Is Org really so simple? In-Reply-To: References: <878sauhhv1.fsf@web.de> <875z5ygwwr.fsf@web.de> <87r1olfvh4.fsf@web.de> <878sascg5j.fsf@localhost> <877dq8bysg.fsf@localhost> Date: Sun, 29 Nov 2020 15:20:12 +0800 Message-ID: <87r1oc634j.fsf@localhost> MIME-Version: 1.0 Content-Type: text/plain Received-SPF: pass client-ip=2607:f8b0:4864:20::532; envelope-from=yantar92@gmail.com; helo=mail-pg1-x532.google.com X-Spam_score_int: -17 X-Spam_score: -1.8 X-Spam_bar: - X-Spam_report: (-1.8 / 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, FREEMAIL_ENVFROM_END_DIGIT=0.25, FREEMAIL_FROM=0.001, RCVD_IN_DNSWL_NONE=-0.0001, SPF_HELO_NONE=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: "Dr. Arne Babenhauserheide" , Texas Cyberthal , "emacs-orgmode@gnu.org" Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Spam-Score: 1.83 X-Scanner: ns3122888.ip-94-23-21.eu Authentication-Results: aspmx1.migadu.com; dkim=fail (headers rsa verify failed) header.d=gmail.com header.s=20161025 header.b=rNuR9Mbi; dmarc=fail reason="SPF not aligned (relaxed)" header.from=gmail.com (policy=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-TUID: cJl/c+3Z6jqG Jean Louis writes: > Rather the query that is made by the user should be remembered as such > and be made available as a command, macro or similar that can be saved > for later. Users can explicitly define custom searches using org-agenda-custom-commands. Though format of that variable is indeed quite complex (similar to org-capture-templates). > Example is when I search for TODO entries with special TODO kwd, then > I may search for 3-4 keywords or 7-10 keywords during one > day. Then there would be repetition to search again for those > keywords. There is history value access in the minibuffer but that > does not remember searches for the next Emacs session. Having > rememberable customized searches for users would be useful. Take a look at savehist-mode. Enabling it should save all the minibuffer history by default. However, the history of your agenda searches will be mixed with global minibuffer history. If you do not like this behaviour, feel free to open feature request to make org-agenda keep history separately. Then, savehist can be configured to save that across Emacs sessions. > Other issue with the Agenda window is that I cannot move from the > minibuffer to other window, as if I wish to enter TODO I may wish in > the same time to open some fiels and look for references while in the > same time I am working with the Agenda options. It is hard for me to > understand why it was made that way, could it be because of read-char > approach? See my other reply. When you are actually entering TODO search, you can switch from minibuffer to other windows as usual. > - if text file is internally related to Joe Doe, then by clicking on > the text file such as Org file, I could automatically get various > hyperlinks to anything related to Joe Doe: Joe's emails list, Joe's > SMS list, Joe's contact information, I could click and initiate a > call with my mobile phone and just write notes without thinking on a > phone number, I could click in Org file and send SMS to Joe that > will be saved in computer without thinking on Joe's phone number, I > could see relatives of Joe and find his sister and again have all > the hyperlinks and relations to various other pieces of information > related to Joe. > > - and if I am in an Org file that has relation to other objects I > would not need to construct hyperlinks by hand, they would be or > could be constructed semi-automatically because the relation is > already known. What you are describing appears to be easy to achieve in org files if one wishes to: some_file.org: #+begin_src org Lorem ipsum dolor sit amet, consectetuer adipiscing elit. Donec hendrerit tempor tellus. Donec pretium posuere tellus. Proin quam nisl, tincidunt et, mattis eget, convallis nec, purus. Cum sociis natoque # clicking on the link with bring you to Joe Doe's heading in Joe Doe.org [[id:joe-id][Joe Doe]] penatibus et magnis dis parturient montes, nascetur ridiculus mus. Nulla posuere. Donec vitae dolor. Nullam tristique diam non turpis. Cras placerat accumsan nulla. Nullam rutrum. Nam vestibulum accumsan nisl. #+end_src Joe Doe.org: #+begin_src org # C-c C-o at the heading will show all the links and allow "clicking" # one of them # C-c C-j will allow free-hand selection of any sub-heading # C-s will allow free-hand search across the file ,* Joe Doe :person: :PROPERTIES: :ID: joe-id :END: Contact information: 100 Street, City, Country # Clicking the following link would start the phone/skype call Tel: [[call:11111111111][call to 11111111111]] [[sms:111111111][send sms to 111111111]] ,** SMS messages ,*** [[id:message1-id][Message 1]] ,*** [[id:message2-id][Message 2]] ,** Related ,*** [[id:antony-id][Antony Joe]] ,*** [[id:something][Something else]] ,*** [[id:yetmore][Yet another one]] #+end_src > When I work with the database and wish to edit something equivalent to > a headline than the unique ID is generated automatically and I do not > need to think of it. It is made by database design. Note that not all users would want this by default. But you can simply set org-id-link-to-org-use-id to 't and the unique ids will be created every time you create a link to heading. > Instead of customizing Emacs to insert IDs, customizing Org, > customizing specific files, It is an advantage for me. Not all the people need the specific workflow you like, but it can thankfully be changed. Same as any other part of Emacs. > ... going over specific files to find which > has unique ID which one does not have, having duplicates all over the > place, Why do you need to find it yourself? It is all handled by org. Duplicates are rare and mostly happen in archives/trash according to my experience. > ... having pretty ugly and not meaningfull unique ID always shown > on screen and more or less to a degree disturbing, org-custom-properties ;) > ... instead of having > them easily editable and changeable and error prone, Agree. This is the price of keeping everything in plain text. > ... instead of many > actions related to that unique ID, Sorry, I do not understand which actions you refer to. > ... I have the above one line that does > it for me as database does the work. I need not think any more and > since I created that table I did not think until today about the > unique IDs because they are very reliable, stable, forever, database > is thinking for me, computer is taking job from me, and I am not > working for my computer. So, database clearly works better for your specific workflow. I personally, do not mind text-based IDs all that much. > - last USER who ever modified the heading, note, task, URL, anything > related to that ID, I can find that last user. Hyperlink could be > automatically generated button that points to on the fly generated > Org buffer showing me such modification. I do not understand how you determine the user editing something in the database. Or do I misunderstand? > - There is DATE in the hlinks table, so it is possible to have date as > hyperlink button from where I can click to find other same date > related entries, or I could invoke list to find nearby dates. FYI. Clicking on timestamps in org automatically invokes agenda view listing all the headings containing timestamps from the same day. > That is my button. I never create those hyperlinks again. This > relates only to the tags, but hyperlinks can be for any other type > of relation. FYI. When you have multiple tags in your heading, clicking on the tags will automatically show agenda view listing all the headings with matching tags. > - the heading of meta Org can have a status defined by user anyhow and > I do not mean TODO/DONE but could be anything that changes later > actions of the user, or automatically generates hyperlinks. The keywords in org are not limited to TODO/DONE. One can create arbitrary set of keywords (representing the status) and even define them locally in buffer (see "5.2.5 Setting up keywords for individual files" in the manual). > - possible EXPIRATION entry is there, it could be automatically > hyperlinked to other expired items Generally, any database field can be represented in org using property drawers (note that you can even set global property drawer at the top of the org file before the first heading). For the expiration specifically, there is even a package in org - org-expity ;) > - HYPERLINK TYPE could be Message-ID to open up specific email > message, then I could get a hyperlink to open all Message-IDs by > that attribute Similarly, you can hyperlink anything from org-mode. Emails are no exception. > Discussion here is only there to give ideas to me and others to > lessen repetitive actions and help us in creating more useful > features. I am not sure if it is going to be useful for creating features. However, it indeed generated many insights how one can deal with personal information management using org-mode. Some things may not be very clear for an arbitrary reader though. For example, it took me quite a lot of time to wrap my head around the idea of using databases - I was thinking too much in terms of org-mode files. Would you consider making a blog post showing your workflows in more consistent way with examples and possibly gif demonstrations? > What if hyperlink points to specific PDF file on the system? Why > should I hard code in the sparse disconnected Org file a hyperlink to > specific file on the file system? Maybe this file changes its > position, then my hyperlink in Org file will not work, what if same > hyperlink has been used 10, 20 or 50 times in other Org files? I personally approach this by keeping my files as attachments to org headings. Then, the files can be references simply by referencing the relevant heading (equivalent of your record in the database). > - open Dired > - think where you wish to file > - press key to choose what you thought like "LISP" > - press enter Have you ever been in scenario when you want to file something to multiple locations? > c a - I am editing author's name in free text. If author is in the > database I would choose author. Author's name can be hyperlinked to > find other entries under same author. No need to type it by hand. Do you need to set the link to author every single time you create a new entry authored/related by/to that author? Or do you somehow create the link to the author automatically? > T - I am editing tags freely, I can enter: emacs lisp todo review; and > those words would become tags. After ENTER I can immediately see > hyperlinks to those tags. Are your tags also uniquely defined using relational database? Say, you want to change some tag name for some reason. Will changing the name automatically update all the tags in the entries marked with that tag? > If the task is assigned to Communication Officer or senior who has to > advise Joe how to do it, then on the next key press I could get > various hyperlinks because there is CID-1 that relates to Joe Doe: > > * Joe to purchase ticket in Kahama and travel on Saturday to Dar es Salaam :CID-1: > > [Joe's files] [Initiate call] [SMS to Joe] [Send this task to Joe] [Plain email to Joe] This is an interesting idea. You mentioned it in the past, but this example made it much more clear. Something similar is implemented in org-ref (https://github.com/jkitchin/org-ref). Instead of adding links like [Joe's files] directly into the text, org-ref shows various possibilities when one clicks on the link itself - there is a completion dialogue suggesting actions related to the link. Since org-ref is specifically designed for referencing scientific articles, it implements only a single set of suggestions like: (1) open pdf of the article; (2) show notes; (3) email article to someone; (4) open url page of the article, ... > Because specific paragraph referencing is now not easily possible I am > using database approach of editing chunks of the Org file where then > any piece of Org can become referential. It is actually possible to reference arbitrary chunks of text in org: "4.2 Internal Links" section of the manual: 1. one item 2. <>another item Here we refer to item [[target]]. Or using #+NAME: keyword #+NAME: My Target | a | table | |----+------------| | of | four cells | Unfortunately, it only works inside a single file. Though I imagine that org-id can be modified to support global referencing. You can send a feature request about this if you are interested. > Heading A can be one node, edited by user one time. It need not be > duplicated for other file, rather only a pointer to Heading A can be > included and the Heading then appears in a new Org file. That would be a great feature indeed. This idea is actually getting a lot of attention recently: https://github.com/alphapapa/transclusion-in-emacs Best, Ihor