emacs-orgmode
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: One vs many directories


From: Jean Louis
Subject: Re: One vs many directories
Date: Thu, 26 Nov 2020 14:58:00 +0300
User-agent: Mutt/2.0 (3d08634) (2020-11-07)

* Ihor Radchenko <yantar92@gmail.com> [2020-11-26 06:34]:
> > Can I automated the execution of Babel code upon opening of the Org
> > file?
> 
> Adding to other suggestions, you can always add a custom function to
> org-mode-hook instead of playing with file-local variables.
> 
> > Then we comes to actual execution of tasks. How do we get
> > reminded?

Yes, that requires customization, file local variables customize
things without user's customization. In the end my use for that slowly
disappears as I am transitioning all tasks to HyperScope. Yesterday I
made simple hard-coded function here that I invoke inside of an Org
heading that captures the heading, date created, and its text and
stores it as a note in the database.

(defun hyperscope-capture-org-heading ()
  "Captures Org heading and stores it in the Hyperscope dynamic
  knowledge repository"
  (interactive)
  (let* ((body (org-copy-subtree nil nil nil t))
         (body (pop kill-ring))
         (body (org-no-properties body))
         (heading (org-get-heading))
         (created (org-property-values "CREATED"))
         (date (if created (substring (car created) 1 11) nil))
         (body (with-temp-buffer
                 (insert body)
                 (org-mode)
                 (org-back-to-heading)
                 (kill-line)
                 (delete-matching-lines ":PROPERTIES:")
                 (delete-matching-lines ":CREATED:")
                 (delete-matching-lines ":ID:")
                 (delete-matching-lines ":END:")
                 (buffer-string))))
    (hyperscope-add-note-to-set heading body date)))

The other use I had for users are tables as I have been writing
tables so much. 

But then I have to write that Joe Doe have paid money to Jane Dane in
the file of Jane Dane as only so I know how much money Jane Dane keeps
on behalf of business. And then I have to write by hand the same
transaction in the file of Joe Doe, as now he has less money. Tracking
it by head is definitely after some time error prone activity.

Database already has few tables for accounts and businesses, so I can
use database backed accounting which is already implemented as journal
package. 

Then if I am doing transaction from Joe Doe I would select Joe Doe
petty cash acccount transferring money to Jane Dane's petty cash
account. I would type less and be less worried about errors. Entries
are stored in the database. If account for Joe Doe is related to Joe
Doe (relations has to be assigned, not just named by person) then I
can invoke the creation of Org table for the Joe Doe's profile.

Majority of times I am creating Org file on the fly for the person
that contains:

* Tasks
* Transactions

Now I will be pushing tasks into meta level and edit them from there
and when Org file is opened that relates to one person then Tasks can
automatically appear in the list ordered by their status or other
attribute.

Transactions I will most probably slowly transition into the database
and they can also automatically appear in the Org table under
Transactions so to be sent easier by using nice Org exports. 

While this approach may not be common, it offers me more free time and
less worries.

> > Is the reminder only if I press {C-c a} for org-agenda? Do I need to
> > do action to get reminded?
> 
> You can always configure Emacs to run agenda on startup. Just add a
> command to your init file ;)

Thank you.

> For automatic reminders, there is built-in org-notify.el or external
> org-alert package (https://github.com/spegoraro/org-alert).

That is definitely good idea. Just little limited as it relates to
user on computer and not to users to which tasks are assigned to.

Think of that as the next and long forgotten enhancement for Org. 

I have this property in Org header:

#+PROPERTY: ASSIGNED_ALL Ezekiel Jean James Victor Dejan TeamTZ

TeamTZ is property of several people, when task is assigned to TeamTZ,
such task get sent to all people involved.

When I am assigning tasks the above list is using one of them to be
assigned.

When task is assigned to somebody notification of a deadline or alerts
are definitely useful for me. But they are are useful for those
conducting the tasks.

Thus integration to remind those *related* people to the assigned
tasks and their deadlines or schedules would be useful.

- org-send-task-by-email (shows some properties, schedules, ID)

- org-send-task-by-email-ascii (not same display in email)

- org-send-task-by-sms (using KDE connect, Termux, gnokii, Twilio, etc)

- org-send-task-by-fax (using email2fax providers or built-in fax modem)

Then think of reminders, they would need to run maybe in Emacs, but
maybe in Emacs that runs from cron job periodically, whatever is more
reliable. 

I also think that generic reminding database or one `reminders' table
would be usable on every system so that users may add to it anything,
be it task, birthday, anniversary, deadlines, etc. Such generic
database would be run as system service and remind not only user on
computer buy outside people by using various connections such as SMS,
email, fax, notifications on computer, notifications on mobile
devices, XMPP chat, social networking and so on. Generic separate
database would be fed by outside programs such as Org, calendar,
external calendars, and so on.

> > Personal problem is that tasks are sparse and separate in various Org
> > files and not centralized. I become dependent of org-agenda to do what
> > I need but it never does what I need.
> 
> I agree that org-agenda has many issues that cannot be easily solved
> because of its complexity. However, everything you describe (including
> multi-occur) can also be achieved with org-ql
> (https://github.com/alphapapa/org-ql) - analogue of SQL query language
> for org-mode (with more optimisations in comparison with org-agenda). 

Definitely good only too much low-level. Users need finished functions
that integrate stuff. To adopt myself to org-ql would mean to read
documentations, meanings, and starting with some functions, while this
may be possible for me that approach is not user friendly as users
need integration and accessible interfaces. 

Example of lack of integration would be to tell to user to simply
construct the link in the form: [[Here][Link]] and that alone would
require some thinking and learning. 

Example of medium integration is when users are advised to press C-c
C-l,then they can choose type of the link and extend it and describe
the link.

Example of high level, best type of integration is Org features to
capture hyperlinks for example from eww browser or from rmail mail
reader like message ID. I did not try those as I have my own, but I
did read that such packages exist in the Org distribution and I find
THAT ideal scene and how it should be. Another good example are
browser bookmarklets for org-capture.

So the package org-ql in my opinion requires something like code
generators and wizards. While great for author, by installing that
package user cannot begin with it practically or in straight manner.

Good integration for org-ql would be a wizard that can add to the list
of various queries and offers users various ways to search such as
searching by headline, tags, or having both tags involved, date,
deadlines and so on. Then such list can be displayed automatically as
a menu or as completing read. That would be good high level
integration for org-ql. Something like how M-x imenu-list works could
be good integration. Program can recognize already all the tags and
offer to user a checklist, user could choose 1 or 2 or more tags to
get a subset of various agenda choices, or the function
imenu-add-to-menubar that generates Emacs menu with references to all
functions in Emacs Lisp, probably in other languages. Then org-ql can
be used as underlying system but higher level helpful functions would
assist in generating various queries, for user not transparent and not
something to think of.





reply via email to

[Prev in Thread] Current Thread [Next in Thread]