Structured searches about org-journal HOT 6 OPEN

Hm. My idea is that structured searches with an agenda-like resulting report can be slow... As long as results present useful stats and functionality.

For example, apart from basic stats I want to be able to do useful things with items found. One thing I'd especially love to add is being able to see older TODO's or tagged items - and be able to copy them en masse into the current day journal entry. This is useful when the user has IDEAs or NOTEs somewhere in the journal and wants to work on them immediately.

One thing we can try to do about the search speed is use the append-mostly nature of the journal. I am not sure about this but it might be possible to somehow cache parse results for older journal entries and invalidate the cache based on a timestamp or smth. But we'll have to see how slow is slow here first :-)

Any other features you might be interested in..?

from org-journal.

So we would need

• search for entries that match tags, properties, todos.
• search for text within entries that match tags, properties, todos.

We can use the agenda search language for this, using org-map-entries. This handily returns a list of org objects which we could re-use for displaying/acting upon the entries.

Search results could then be listed as full org entries, and not just single lines. The search results could link back to their original entry, and possibly include the original time stamp. This might be better left optional.

Come to think of it, if we include the full org entries, we might not even need special commands for acting on these entries, as the user could simply save the search result buffer however she pleases. Alternatively, C-u (or something) could insert the results in the current buffer instead of a temporary new buffer.

What are your thoughts on this?

from org-journal.

Could you explain those two points mentioned..? You want to unify plain text search and structured search and be able to search for both tags/todos/props and text at once?

But yes, surely, I want to use standard org-mode mechanism for searching.

One more question: you want to be able to edit the journal entries from the results buffer? My workflow is a bit different here, I don't normally edit anything in the history but sometimes want to move things from older journal entries to a current one. So, the idea is to be able to do that using the results buffer.

As much as I understand you want something like edit mode in occur buffers (as described in http://irreal.org/blog/?p=1173)?

from org-journal.

Just a followup thought on speeding up the search: I think it might be quite possible to generate a proper tag/property/todo index for all saved org-journal files (in case they are gonna be slow on my 500+ org-journal files), and update the index whenever the user edits/saves.

from org-journal.

Could you explain those two points mentioned..? You want to unify plain text search and structured search and be able to search for both tags/todos/props and text at once?

I might have confused a few concepts, there. Anyway, my idea essentially was (and I don't know if that is a good idea):

Essentially, a search would always return full subtrees. These subtrees would be copied to a new buffer, and possibly link back to the original files. Even plain text searches would return the full subtrees that contain the search text.

However, searches could be restricted to subtrees that match certain tags/todos/props. If no such restriction is given, all subtrees would be searched. There is a unified query language built into org-mode that we can use to find matching subtrees: http://orgmode.org/worg/org-tutorials/advanced-searching.html#searching-metadata

Come to think of it, this is pretty much equivalent to using regular agenda searches, but restrict the results to the journal files. Maybe the easiest implementation would be to use the actual agenda search mechanism, but overload org-agenda-files if the search was started from the calendar or org-journal.

from org-journal.

Not 100% sure if this is the same issue, but I am also interested in gathering the subtrees matching a search into a single buffer.

from org-journal.