Suggestions and questions

[alphapapa]

Matus, can you slow down a little? I can't keep up with all these great new projects of yours. :) Just the other day I thought about an alternative API for Org, and here you are already doing it!

Here's a quick suggestion: Instead of get and set, how about gv getters/setters that could be used with setf? So instead of:

(orgba-get-property "foo")
(orgba-set-property "foo" "bar")

It could be:

(orgba-property "foo")
(setf (orgba-property "foo") "bar")

What do you think?

Also, what are your long-term plans for this project? Is it experimental, or are you planning to make it super serious? :)

Thanks.

[kaushalmodi]

what are your long-term plans for this project?

I hope that this somehow culminates into being part of Org.

A new project trying to end all fragmentations is yet another fragmentation :)

[alphapapa]

A few other suggestions:

• orgba-time-as-timestamp : Could this be simply orgba-timestamp?
• orgba-agenda-is-task-p: The -p makes the -is redundant. :)
• orgba-agenda-is-task-p: More generally, this could be orgba-agenda-state or org-agenda-keyword, which should return the todo-state text property from the agenda. If it's nil, it's not a task; if it's non-nil, it is, and the keyword is returned.

[alphapapa]

About the heading functions, like orgba-next-heading: it might be worth considering returning nil if there are no more headings. That would save a lot accidental infinite loops, like:

(cl-loop while (orgba-next-heading)
         collect (orgba-heading-at))

That will loop forever, so the loop has to add a check for (eobp). If the function returned nil when there are no more headings, it would seem more intuitive.

[alphapapa]

About the drawer functions, like orgba-get-drawer: it seems strange to search downward, into children, rather than upward, into parents, from which properties could be inherited. Is there a use-case for that?

[alphapapa]

For property inheritance, I suggest doing it like this:

(cl-defun orgba-get-property (name &optional (inherit t))

i.e. inheritance is still on by default, but it avoids the confusing double-negative of putting dont in the variable name.

[Fuco1]

About the drawer functions, like orgba-get-drawer: it seems strange to search downward, into children, rather than upward, into parents, from which properties could be inherited. Is there a use-case for that?

This is not about the PROPERTIES drawer but any drawer. Say you want to log some special data of yours into a drawer called FOOBAR (for example on org-clock-out-hook). So you are now at the entry and you ask orgba-get-drawer-create FOOBAR, that gives you that drawer in the current entry.

I agree that it probably makes no sense to continue down into children but instead we should have the optional arg search upwards.

The next-heading returns point-max now because I used it to add new headlines, so I got the position and if there was no next headline it simply appended to the end. It should probably be called something else because this might be confusing in a loop indeed.

Good suggestion with the setf thing, can do.

Patches welcome also! :D

I hope that this somehow culminates into being part of Org.

Can do, I have the papers ready.

A new project trying to end all fragmentations is yet another fragmentation :)

My goal is not to end the fragmentation so much as to just make it faster for people (and me) to develop and get more convenient functions to do very simple things.

Also, what are your long-term plans for this project? Is it experimental, or are you planning to make it super serious? :)

I'm not sure what super serious means. I think I might rename it to org-hacks to correspond with dired-hacks... so in my mind this will be a grab-bag of cool functions, something like bbatsov's crux or my dired-hacks but for org mode.

[Fuco1]

TODO: split into multiple tickets