Re: Integrating eev and org-capture/org-capture-set-target-location

[Jean Louis <bugs@gnu.support>]

* Eduardo Ochs <eduardoochs@gmail.com> [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/