Re: Completely hide properties drawer in 9.6

[Jean Louis <bugs@gnu.support>]

* Ihor Radchenko <yantar92@posteo.net> [2022-12-16 18:21]:
> I agree that your message is on topic. Just, as I pointed, I feel like
> it is a bit too broad to be useful. I may be wrong, of course.

You may take it personally, but you shouldn't, as people like me, and
others, may not always discuss exactly that what you would like it to
be.

You and people may wish to develp new Emacs packages and extend
features. What you extend is what you decide, some other people make
different packages, why then so much resistance and opposition just
because you personally don't like idea. If you don't like it, don't
engage in it. If you think it is wrong, than say why is it technically
wrong, and if there is intention to extend some features, let me do
it, what you don't like, you will not use anyway, and I did not tell
to inject any code into main Org.

When some proposal is not helpful, then feel free to give argumented
analysis why it would not be helpful, instead of generalizations,
personal antagonism and calling mob on me. Thanks for attention so
far. Better we stop here about it. 🛑

In my opinion, my proposals were either too abstract for you, or out
of your reality, and you cannot do nothing with it. Personally I use
UUIDs for quick references to whatever it may be. While majority of
people in many other software packages do not use UUIDs to reference
to things universally, it is already in Org mode when ID is
generated. It is not really new.

To me it is very practical to have this simple heading with a drawer
that is completely hidden, which references by using UUID to a complex
set of properties. To somebody else, that may not be useful or is
abstract to understand.

In my work I would not like having more properties for Org heading but
one, like this one:

* My heading
  :PROPERTIES:
  :ID: 944334aa-acab-4e6a-8dd6-ebfd144eac6b
  :END:

And that alone would be a reference to any other property that I
personally may need. It is a link from heading to relations to many
different pieces of information. 

If you have maybe followed some latest Hyperbole discussion, using
UUIDs with Hyperbole has been shown useful. UUID itself may decide to
what it is referenced. Simple click on UUID and one may be in whatever
object it can be.

Let us make it visual, here is the video how it works when Org
headline has only UUID. Video is mock up of how properties can be
removed from Org file, it uses package Hyperbole to quickly jump to
properties related to UUID:

https://gnu.support/images/2022/12/2022-12-18/2022-12-18-02:07:35.ogv

Instead of Hyperbole, one can simply use keybindings as usual on the
function which will show the properties.

Following the thought of separating properties, to add a property, one
would of course use a key, and add property in about the same manner
as usual. To delete a property, one jumps to property list and press
key like `d', to edit the property one uses either Org functions or
direct editing and selecting like shown in video.

Emacs 29 has SQLite built-in, there is PostgreSQL module and also
rcd-hash-edit package that works in similar way as shown on
video. Hashes may easily be stored in text files and read from text files. 

I use following functions to store data to file:

;;;; LISP DATA FUNCTIONS

(defun string-to-file-force (string file)
  "Prints string into file, matters not if file exists. Return FILE as file name."
  (with-temp-file file
    (insert string))
  file)

(defun file-to-string (file)
  "File to string function"
  (with-temp-buffer
    (insert-file-contents file)
    (buffer-string)))

(defun data-to-file (data file)
  "PRIN1 Emacs Lisp DATA to FILE"
  (string-to-file-force (prin1-to-string data) file))

(defun data-from-file (file)
  "Reads and returns Emacs Lisp data from FILE"
  (condition-case nil
      (car (read-from-string
	    (file-to-string file)))
    (error nil)))

Visual hash editing is one of options to store properties when
database is not available. Editing of the hash looks just the same as
on the video. Hash can store any kind of data.

Saving hash in text file goes like this:

(let ((my-hash (make-hash-table :test #'equal)))
  (puthash "SUMMARY" "This is my summary of the Org heading." my-hash)
  (data-to-file my-hash (concat (file-name-as-directory (getenv "HOME")) "my-hash.el")))

Then hash get saved:
#s(hash-table size 65 test equal rehash-size 1.5 rehash-threshold 0.8125 data ("SUMMARY" "This is my summary of the Org heading."))

And can be easily read back:

(let ((my-properties (data-from-file (concat (file-name-as-directory (getenv "HOME")) "my-hash.el"))))
  (gethash "SUMMARY" my-properties)) ➜ "This is my summary of the Org heading."

And by thinking that, it is also possible to make Org functions that save properties in separate Org file automatically. 

In case of the heading like this:

* My heading
  :PROPERTIES:
  :ID: 944334aa-acab-4e6a-8dd6-ebfd144eac6b
  :END:

One could have a separate Org file that is used only to write properties, and which could contain something like following:

* 944334aa-acab-4e6a-8dd6-ebfd144eac6b
  :PROPERTIES:
  :DATE-CREATED: 2022-12-18
  :PERSON-RELATED: Ihor Radchenko
  :END:

There are many reasons why properties should be hidden or separate
from Org file, apart from aesthetics and readability. I have been
sharing Org files and headings too many times to staff members
(without export), and then why should other person see clocked or
scheduled properties if such are not meant for that person?

The above eloboration demonstrates that properties could not only be
hidden from main view, but become structural and organized collection
of data. Storage is possible into PostgreSQL by using emacs-libpq
module or PostgreSQL packages, in Emacs 29 by using the built-in
SQLite or SQLite packages, or cdb database or key/value databases, or
by storing hashes into files, or by storing properties into separate
Org files.

Implementation is close to fingertips.

Generally, using properties and UUIDs as references to properties,
also liberates properties from Org mode and gives the power of
referencing to any kind of text or mode.

That means, having Markdown file with commented UUID, could allow the
user to have the same properties as in Org mode, one could freely tag,
clock-in, clock-out, schedule, deadline, etc. any kind of Markdown
heading, whatabout Asciidoc, truly plain text, HTML pieces, Wiki, and
other formats and files.

In normal text files, I would then make UUIDs invisible inside of
Emacs, when necessary:

(defun rcd-uuid-reference-make-invisible ()
  "Make all UUIDs in buffer invisible."
  (interactive)
  (save-excursion
    (goto-char (point-min))
    (while (search-forward-regexp thing-at-point-uuid-regexp nil t)
      (when (thing-at-point 'uuid)
	(facemenu-set-invisible (match-beginning 0) (match-end 0))))))

;; df2c9f4d-77ab-4697-842e-d7aa31ffeee3

If UUIDs are disturbing in the output, then I would have a filter to
export the file without UUIDs, when necessary.

And there is no need to go to property drawer to find properties, as
there is the function (org-property-values "ID") ➜
("944334aa-acab-4e6a-8dd6-ebfd144eac6b") which may be used in a
function and by using key binding one could quickly jump to properties
just as shown on the video, but without moving cursor to the UUID.

How to hide Org properties, I do not know, as the following function
can't work with font-lock in Org mode, that is something where you
could say how to make org-property-drawer-re invisible?

(defun rcd-org-drawer-make-invisible ()
  "Make Org property drawers invisible."
  (save-excursion
    (goto-char (point-min))
    (while (search-forward-regexp org-property-drawer-re nil t)
      (facemenu-set-invisible (match-beginning 0) (match-end 0)))))


-- 
Jean

Take action in Free Software Foundation campaigns:
https://www.fsf.org/campaigns

In support of Richard M. Stallman
https://stallmansupport.org/