From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mp11.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by ms5.migadu.com with LMTPS id uF9PL5WtRGODKgEAbAwnHQ (envelope-from ) for ; Tue, 11 Oct 2022 01:41:09 +0200 Received: from aspmx1.migadu.com ([2001:41d0:2:4a6f::]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits)) by mp11.migadu.com with LMTPS id AJtYL5WtRGPmBwAA9RJhRA (envelope-from ) for ; Tue, 11 Oct 2022 01:41:09 +0200 Received: from lists.gnu.org (lists.gnu.org [209.51.188.17]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by aspmx1.migadu.com (Postfix) with ESMTPS id 3F4B1D1E7 for ; Tue, 11 Oct 2022 01:41:09 +0200 (CEST) Received: from localhost ([::1]:36886 helo=lists1p.gnu.org) by lists.gnu.org with esmtp (Exim 4.90_1) (envelope-from ) id 1oi2OR-0003XX-M7 for larch@yhetil.org; Mon, 10 Oct 2022 19:41:07 -0400 Received: from eggs.gnu.org ([2001:470:142:3::10]:59490) by lists.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi2Mw-0003XH-7g for emacs-orgmode@gnu.org; Mon, 10 Oct 2022 19:39:34 -0400 Received: from stw1.rcdrun.com ([217.170.207.13]:44111) by eggs.gnu.org with esmtps (TLS1.2:ECDHE_RSA_AES_256_GCM_SHA384:256) (Exim 4.90_1) (envelope-from ) id 1oi2Ms-0007f4-Ow for emacs-orgmode@gnu.org; Mon, 10 Oct 2022 19:39:33 -0400 Received: from localhost ([::ffff:154.227.225.142]) (AUTH: PLAIN admin, TLS: TLS1.3,256bits,ECDHE_RSA_AES_256_GCM_SHA384) by stw1.rcdrun.com with ESMTPSA id 00000000000BBD16.000000006344AD31.000065CF; Mon, 10 Oct 2022 16:39:29 -0700 Date: Tue, 11 Oct 2022 02:04:21 +0300 From: Jean Louis To: David Masterson Cc: rswgnu@gmail.com, Samuel Wales , emacs-org list Subject: Re: Org and Hyperbole Message-ID: Mail-Followup-To: David Masterson , rswgnu@gmail.com, Samuel Wales , emacs-org list References: <813D3F10-3E3C-497F-9FD8-FE0DA13C2970@gmail.com> <10960EC2-D614-4826-A277-79E963969345@gnu.support> Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: 7bit Content-Disposition: inline In-Reply-To: User-Agent: Mutt/2.2.7+37 (a90f69b) (2022-09-02) Received-SPF: pass client-ip=217.170.207.13; envelope-from=bugs@gnu.support; helo=stw1.rcdrun.com X-Spam_score_int: -18 X-Spam_score: -1.9 X-Spam_bar: - X-Spam_report: (-1.9 / 5.0 requ) BAYES_00=-1.9, SPF_HELO_PASS=-0.001, SPF_PASS=-0.001 autolearn=ham autolearn_force=no X-Spam_action: no action X-BeenThere: emacs-orgmode@gnu.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: "General discussions about Org-mode." List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: emacs-orgmode-bounces+larch=yhetil.org@gnu.org Sender: "Emacs-orgmode" X-Migadu-Flow: FLOW_IN X-Migadu-Country: US ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=yhetil.org; s=key1; t=1665445269; h=from:from:sender:sender:reply-to:subject:subject:date:date: message-id:message-id:to:to:cc:cc:mime-version:mime-version: content-type:content-type: content-transfer-encoding:content-transfer-encoding: in-reply-to:in-reply-to:references:references:list-id:list-help: list-unsubscribe:list-subscribe:list-post; bh=B2np5YMG/YEbFE2JXywa3oXx8P+FEhmc4DrRCi8hN6U=; b=ZRgy9ufQ8JaiI3ayMpuA0ivbgRu1HLRv1jXytbpHmzqglcYrvm0rvnbh8xJnEa+2BH08nQ 0+lR26hBkfY2iJAK2dYwlw2AvJc8EBQQQ3XrvgaBhe1X4yjL4MY1YqQ3dmifslMHI644nD cg5YIjVCD3oTXXlzRDh3ebtySe9t+uHSMPCuIFFLywr1g9WMO4+dT+BlOks1D7FG/KWlGO 1Bz6np1FfqO5reIXM8eif5xo8UjgLX2Y2VBJpOUrIcqlqV8A42ADNS1MRyRPi4yWAB11eq l3TjLRSnt0sJXYq/bFKxqCyj8n21zR6z1g1t0sOjpZ55C4JKvmnsEQluNJx2Zw== ARC-Seal: i=1; s=key1; d=yhetil.org; t=1665445269; a=rsa-sha256; cv=none; b=jfY6BGvf6fnCk4/An9cb5+MAaxh2wX4WgrwirYEW0nL2ycaw9z+6DDq2gEyoiH115RuACX YpeVY7j8JUKmb1AdpDhBAjJEM6HJAcgva5KfxIprU+/AKhmN5bigS7bMlS2LUxpC4TAjN/ u5+x3G8a8a6Qv/0im+w9jkJ3iI7hOw3Kb3TtTB94FhHnkKWjJQmftGXmZtnx9F4NC15wMM RSN64VzaIAgBWuDETogb4KqcgeqDS975FDf86zIeYpdOCudoD7G3nsLXoP7iOo61iZw5y+ YaWBd70Hccwy0jtyqFd0CAacZfn+Mtew4+PBiDPU8PnXAnp1QSEYFI9G1/8yEg== ARC-Authentication-Results: i=1; aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Spam-Score: -3.19 Authentication-Results: aspmx1.migadu.com; dkim=none; dmarc=none; spf=pass (aspmx1.migadu.com: domain of "emacs-orgmode-bounces+larch=yhetil.org@gnu.org" designates 209.51.188.17 as permitted sender) smtp.mailfrom="emacs-orgmode-bounces+larch=yhetil.org@gnu.org" X-Migadu-Queue-Id: 3F4B1D1E7 X-Spam-Score: -3.19 X-Migadu-Scanner: scn0.migadu.com X-TUID: irHl2kqyyO1t * David Masterson [2022-10-10 19:55]: > Jean Louis writes: > > > * Robert Weiner [2022-10-09 00:06]: > >> There are many reasons for this including limits in many > >> organizations of the file types that may be transferred through > >> common protocols and the difficulty of maintaining relational > >> database or structured file type schemas across time. > > > > I can't see how relational database is more difficult to maintain then > > for example Emacs itself. Emacs is master of difficulties for computer > > user. For example I have not touched configuration files for > > PostgreSQL since years, if not decades. I start wondering why. > > The issue here is distribution. Databases tend to be centralized and > heavy weight. What does it mean centralized in this context? Majority of Relational databases that I know have built-in collaboration features so that people may access them from any part of the world; many have replication features. I am not sure if "centralization" even fit into the context. > Here, we're simply looking for a standard way to capture an image > (or more) with a task/note and tranport it back to your main Org > file (a la Org Mobile or ...). Org is lightweight in this area > which is good and bad. Regarding sizes: ================ $ du -skh .emacs.d/elpa/org-20201216/ 11M .emacs.d/elpa/org-20201216/ Database like : sqlite3 Installed Size : 7.55 MiB Reference: Relational database - Wikipedia: https://en.wikipedia.org/wiki/Relational_database You have misconception of what is lightweight or what is not or what is difficult, I guess it comes simply from not trying it out. There is no "standard" way of taking notes, especially not in Org, neither in Emacs environment, or generally for people. Creating tables is pretty, new Emacs development has got SQLite built in: (defun my-create-table-notes () (rcd-sqlite "CREATE TABLE notes ( notes_id INTEGER NOT NULL PRIMARY KEY, notes_datecreated TEXT NOT NULL DEFAULT (datetime()), notes_datemodified TEXT NOT NULL DEFAULT (datetime()), notes_name TEXT NOT NULL DEFAULT '>>>EDIT<<<', notes_type INTEGER NOT NULL REFERENCES notetypes DEFAULT 1, notes_text TEXT)" rcd-people-sqlite-db)) Making a function to add a note is easy: (defun rcd-db-table-sqlite-notes-insert-new-row () "Add new note." (interactive) (let* ((name (read-string "Note name: ")) (prompt (format "Description about `%s': " name)) (note (string-edit "" "" 'ignore)) (sql (format "INSERT INTO notes (notes_name, notes_text) VALUES (%s, %s) RETURNING notes_id" (rcd-sqlite-escape-string name) (rcd-sqlite-escape-string note))) (id (rcd-sqlite-first sql rcd-people-sqlite-db))) id)) (defalias 'notes-add 'rcd-db-table-sqlite-notes-insert-new-row) Viewing, listing, getting it back, making agendas, all that works with so much less coding, works, less errors, and more speed. Exporting to Org is easy: (insert "\n\n" (rcd-sqlite-first "SELECT group_concat('** ' || notes_name || '\n\n' || notes_text,'\n\n') FROM notes ORDER BY notes_datecreated" rcd-people-sqlite-db)) ** Something My note #1 ** My other heading My note #2 ** Something I knew before My note #3 1 As Org users already wish and want to have structured properties, tags, headings, links, tables, then it is right way to think that with Emacs 29 and SQLite built-in, many things will become easier. Let us say keeping list of information such as accounting, expenses, invoices, tasks, notes, etc. for any type of information database has no ambiguity about structured information, errors are minimized, programming efforts minimized. Pitfall would be that we would not have much discussion like now, as with less bugs, there is less talk. Imagine Org heading like this: * My heading :PROPERTIES: :DB-ENTRY: :my-remote-host:my-database:my-org-table:id:1234 :END: Then imagine a pre-processor before saving the file or a hook for saving Org file. Each time that file is saved, the heading entry could be updated on remote host, database, table with ID 1234. It could be distributed, assigned, sent, easier shared, because data is better estructured, Or it could be updated in a local database. Or it could be used to keep any kind information related to Org heading. That is glue between the text file and well structured and non ambiguous database. If Org has mechanism to parse links in a file, a save hook could parse them and store in database table for backlinks. Sometimes URL change, imagine Org link like: dbid:1234 that remains immutable and which fetches the underlying dynamically updated URL. If some Org headings are stored in the database, they may be updated in Org file automatically. Linking to Org headings could become so much more deterministic, as one would link to unique ID in the database, no matter how heading is named or where is it stored. Collaboration door is open with networked databases. Concurrent access to Org headings, links, contacts, becomes possible. Wide range of options. -- Jean Take action in Free Software Foundation campaigns: https://www.fsf.org/campaigns In support of Richard M. Stallman https://stallmansupport.org/