From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.io!.POSTED.blaine.gmane.org!not-for-mail From: Jean Louis Newsgroups: gmane.emacs.help Subject: Re: Integrating eev and org-capture/org-capture-set-target-location Date: Fri, 4 Jun 2021 09:00:51 +0300 Message-ID: References: Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Injection-Info: ciao.gmane.io; posting-host="blaine.gmane.org:116.202.254.214"; logging-data="38638"; mail-complaints-to="usenet@ciao.gmane.io" User-Agent: Mutt/2.0.7+183 (3d24855) (2021-05-28) Cc: help-gnu-emacs To: Eduardo Ochs Original-X-From: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Fri Jun 04 08:02:59 2021 Return-path: Envelope-to: geh-help-gnu-emacs@m.gmane-mx.org Original-Received: from lists.gnu.org ([209.51.188.17]) by ciao.gmane.io with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.92) (envelope-from ) id 1lp2v5-0009tp-3v for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 04 Jun 2021 08:02:59 +0200 Original-Received: from localhost ([::1]:43914 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1lp2v4-0007po-7a for geh-help-gnu-emacs@m.gmane-mx.org; Fri, 04 Jun 2021 02:02:58 -0400 Original-Received: from eggs.gnu.org ([2001:470:142:3::10]:36036) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp2ul-0007pf-1r for help-gnu-emacs@gnu.org; Fri, 04 Jun 2021 02:02:39 -0400 Original-Received: from stw1.rcdrun.com ([217.170.207.13]:45831) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1lp2ui-0007kJ-CN for help-gnu-emacs@gnu.org; Fri, 04 Jun 2021 02:02:38 -0400 Original-Received: from localhost ([::ffff:197.157.0.35]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000AE2D8.0000000060B9C1F9.00005BF1; Thu, 03 Jun 2021 23:02:32 -0700 Mail-Followup-To: Eduardo Ochs , help-gnu-emacs Content-Disposition: inline In-Reply-To: Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -3 X-Spam_score: -0.4 X-Spam_bar: / X-Spam_report: (-0.4 / 5.0 requ) BAYES_00=-1.9, RCVD_IN_SORBS_WEB=1.5, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=no autolearn_force=no X-Spam_action: no action X-BeenThere: help-gnu-emacs@gnu.org X-Mailman-Version: 2.1.23 Precedence: list List-Id: Users list for the GNU Emacs text editor List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: help-gnu-emacs-bounces+geh-help-gnu-emacs=m.gmane-mx.org@gnu.org Original-Sender: "help-gnu-emacs" Xref: news.gmane.io gmane.emacs.help:130538 Archived-At: * Eduardo Ochs [2021-06-04 06:41]: > I watched Prot's video about org-capture - > https://www.youtube.com/watch?v=qCdScs4YO8k - and I am trying to > implement a function that works as a sexp hyperlink to a "target" > structure like the ones that appear in org-capture-templates. These > target structures are documented here: > > (find-evardescr 'org-capture-templates) My opinion is that org-capture-templates are user unfriendly (see description of org-capture-templates). Since months I have stopped using it without regret. If I would need a template I would or could just add template column to the database type. It would be settings that is in the database for specific user among possibly many users. There is variety of templating options to be used. One templating option could be the Emacs library `skeleton' (setq name "John") (define-skeleton my-skel "Test" nil "Hello " some "") Other templating option could be my rcd-template.el package with some variables to be expanded on the fly and without limit. > (find-evardescr 'org-capture-templates "\ntarget") > (find-evardescr 'org-capture-templates "\ntarget" "file+headline") When capturing external text or information let us say from the browser, maybe from Xpdf viewer what one as a user needs is what? A simple click. Later user can sort or edit things. Keeping things simple. Capturing with Org is not quite simple. I can think of so many different ways to capture things in some more reasonable manner than what is Org capturing. Devising your own function is maybe better way to go. > (find-orgnode "Capture templates" "file+headline") > (find-orgnode "Template elements" "\ntarget") Those must be new eev functions. > In Prot's video he uses targets like these, > (file+headline "tasks.org" "Task list") > (file+headline "tasks.org" "Links to buffers/files") I have thousands of sets, which means parent nodes. So when I am capturing, I am capturing and have full text search access to anything. Then I can mark many nodes at once with single key and put nodes into a set or category. Imagine if I would now need to: - define the headline like "Task list" in the file, then go to org-capture-templates and again define the headline where stuff needs to be captured, then if I change the headline in the buffer to remember to go back to org-capture-templates and to define stuff to be captured and so on; too much; as I said I have 1000+ sets or categories where things could be captured; but WWW hyperlinks are captured in just one single set from where they could be fast-sorted in other sets; Capturing sessions are normally thematically related to a period of time on my side. If I am researching subject X, I may capture 20 items related to that subject in specific period of time. Moving over items by time shows me similar captured items. Then by pressing mmmmm I can mark 5 items or mmm 3 more, and "c p" change parent to a different set. I don't think about files, as I don't use them with any capture. I don't think about exact headings, and need not put any care to re-write such a heading. Yet categorizing is fast. Keeping links to buffers and files in one single file together with task lists does not seem sound. It implies that user has to make now even more efforts to find those links. Each task is separate object with separate type on my side, each link to buffer is separate object and type. They can be in one set, but still remain separate. They are not in the same file -- why? Because they are different types. Unique in their own. This is good concept, what makes it impractical with files is that opening or handling files is not integrated well in the system. Would it be better integrated people would store different types in different files and that those are different files it would not bother them, they would not even think of files, they would just think of editing, not even saving things. When working with a database, storing objects of different type separately is integral to the system. And yet different objects may appear "together" and can be used together. That is where I say that Org wants to be a database, but is not. A lot of programming has been done to make the Org more or less structured database where it is not. Keywords like TODO/DONE make the heading a task or completed task. Thus it is of one type. Accidental shift-left or shift-right and the type is already changed, now it is not anymore a type of a task, something to do, it is just a heading, maybe just a note. Type disappeared, gone. Cannot be found as the type of "task" any more. I find that too much low-level for users who need a higher level friendlier interface. It should be either of Task type or Note type or something else. Like is it a meeting? Then better have an exact meeting type, not easily changeable, it is a meeting, it had related date, time, related people to meet, an event in life. It should not be "Note" by a key press. It is an event that had to take place, did happen or maybe not, and as such should remain for future as it creates a background knowledge of all people involved. Same principle I would employ with capturing to files, I would keep things separate by their types in different files. Reason why people put everything in one file is rather to escape the effort of finding things in multiple files, not the fact that keeping variety of things in one file is comfortable in itself, it is not. Such files cannot be shared to other people easily, that is one good example, private research about explosives one does not want to print together with tax letters. Hyperlinks to dating sites one does not want to keep together with personal messages to the loved one which she/he could eventually see on user's computer. > and I am trying to write a function `find-orgctarget' such that > > (find-orgctarget '(file+headline "tasks.org" "Task list")) > would open the file > > (concat org-directory "/tasks.org") > > and then find the headline "* Task list" in it, and put the point in > the line following that headline. After a few very naive attempts I > got this definition for `find-orgctarget': > > (require 'org-capture) > > (defun find-orgctarget (target) > (org-capture-set-target-location target) > (org-capture-finalize t)) > > but when I run this > > (find-orgctarget '(file+headline "tasks.org" "Task list")) > > I get this error: > > org-capture-finalize: This does not seem to be a capture buffer > for Org mode It says in the function `org-capture-finalize': (unless (and org-capture-mode (buffer-base-buffer (current-buffer))) (error "This does not seem to be a capture buffer for Org mode")) Maybe it is not a real error that was just designated as "error". It asks you to be in `org-capture-mode' as it maybe wants to `finalize' something, I did not look into the obfuscation yet. What you want is to find a headling: (find-orgctarget '(file+headline "tasks.org" "Task list")) There is function: (org-find-exact-headline-in-buffer HEADING &optional BUFFER POS-ONLY) (defun my-org-find-exact-headline (file heading) ;; headline/heading???? (find-file file) ;; if extension is .org it would (let ((marker (org-find-exact-headline-in-buffer heading))) (goto-char marker))) And this works well: (my-org-find-exact-headline "~/tmp/new.org" "Something") with file: ---------- * Something Somet text * Here is more More text --------------- Thus finding works. But maybe you wish to use capture facility and that requires more thinking. To put a point after the headline you can do by adding `forward-line' function. Just that in Org files there are often properties, I would not recommend finding by exact heading as heading change. Using function `org-find-entry-with-id' is better, as it looks for property with exact value. I don't use Org files, but I can export information into Org files, each item has its ID number: ** TODO Data :PROPERTIES: :TABLE: hyobjects :COLUMN: hyobjects_text :ID: 37704 :CUSTOM_ID: 37704 :END: Maybe you wish to use other functions such as `org-forward-paragraph' as that one would move after the :END: above. But better is (org-end-of-meta-data t) as that would move you from heading to end of the meta data if any. That is the place where you wish to place new stuff. That would however mean that you are prepending, your newest items would appear just under the heading, not as last items. * My heading Newest Newer New Old Maybe is better to jump to headings by using ID number as headings would be changing, and ID would never change (unless it is changed). When working with the database then text is edited, some fundamental attributes are not edited. With files, anything can be edited. - My heading is text -- changeable. - Heading is attribute or place where it is stored, in the column: hyobjects_name (before it was hlinks_name) -- this is not changeable, it is fixed place. There are other "places" or columns, such as text, report, author, etc. - Heading has its ID number automatically assigned to specific entry. Same ID applies to other columns. - Because of those constraints it is trivial to capture for any change, the user who changed it, date modified, previous version of the heading, and so on. Then I can inspect how many times did I change headings in the `vc' version control table: SELECT count(1) FROM vc WHERE vc_column = 'hyobjects_name' OR vc_column = 'hlinks_name'; count ------- 649 Well 649 times? That is what I speak about. Would I change the heading anywhere the `org-capture-templates' would need to get changed as well, and that is manual work. So I don't agree with the design of `org-capture-templates' as it gives work to users. User view point at computer as something to minimize the work, not to increase the work. That is why we use editing modes, they help in minimizing the work. Obviously programmers may be so enthusiastic to forget about the basic principle and would like to program for the sake of program, not sake of the user. That is where troubled program parts such as `org-capture' and `org-capture-templates' get born: - M-x org-capture -- presents blocking interface to user, instead of allowing user to move from buffer to buffer. There is contradiction between the `org-capture-templates' that gives incentives to create so many templates and the blocking limited interface that disables user to verify buffers while using the menu. Solution: Providing a simple read-only Org type interface with Org hyperlinks to org-capture functions is trivial and non-blocking, but author of org-capture-template likes the blocking one. - Defining `org-capture-templates' is everything but user friendly. Many will consider Lisp not friendly, but this is not even Lisp. It is small langugage in itself. A surprising "Oh, not again" for users who anyway found it hard to understand Org. Instead, the templates should be definable in the Org file directly, not in the variable. If there is already plethora of `org-find...' functions then why not use Org to define itself in templates. Why not use any Org file and its heading as template. Then user could write Org file and use it as templates. entry type? There is no difference to me in the type of "entry" as Org node as a headline with template being: "* %? %a" with the "type" of "item" with template being "- %?" I don't see a clear "type" there, I just see different template. A "checkitem" type is yet another template "- [ ] %?" and not a type really. Then "plain" type is not a type it is just empty template. Oh mamma mia. Those "types" should be or are redundant as they are just a template. (defun my-org-find-exact-headline (file heading) "Jumps to exact headline first things after meta data" (find-file file) (let ((marker (org-find-exact-headline-in-buffer heading))) (goto-char marker) (org-end-of-meta-data t))) (my-org-find-exact-headline "~/tmp/new.org" "Something") Now I think you may wish to append it, not prepend it... -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns Sign an open letter in support of Richard M. Stallman https://stallmansupport.org/