Re: Hiding results using :post
My initial thoughts are that this is very possible. This might be an area where we could add a new defcustom on always hiding the results to allow the user to choose it. Without looking at the code, I think it would be pretty straight forward to make an excursion to the results line, toggle showing it, then going back to where the point was. I can take a crack at a patch in the next day or so if no one else wants to or gets there first. On 6/7/21 8:51 AM, Roger Mason wrote: Hello, I'd like to be able to hide results, for example when I expect the them to span many lines. I know I can hit =tab= on the #+RESULTS: line, but I'd like to be able to set this automatically. My most recent effort: #+name: hideresults #+begin_src emacs-lisp :results none :exports none (add-to-invisibility-spec '(org-babel-hide-result . t)) #+end_src run like this #+header: :engine postgresql :dbhost "localhost" :dbuser "rmason" :database "test" :colnames yes #+header: :post hideresults #+name: pgquery #+begin_src sql select timestamp,nempty0 from settings where timestamp like '%20210528%' #+end_src produces #+RESULTS: pgquery : nil I'm sure there is a way to do this, but I need some pointers as to how. Thanks for any help. Roger Org mode version 9.2.3 (release_9.2.3-390-gfb5091 @ /home/rmason/.emacs.d/org-git/lisp/) GNU Emacs 27.2 (build 1, amd64-portbld-freebsd11.4, X toolkit, cairo version 1.16.0, Xaw3d scroll bars)
Re: import xls(x) into org on MacOS
If you're looking to go the python route of importing an xls file, you
could try the xlrd package. It's actually just for xls. I'm not sure if
it converts to csv, but once you have the spreadsheet open in python
that should be a pretty trivial exercise.
Cheers,
Nick
On 5/31/21 7:18 AM, Uwe Brauer wrote:
Hi
I am usually using Ubuntu 16.04, but for the coming days, I have to use
a MacBook, running 10.15 and fink installed.
I usually convert xls(x) to org, using
'(org-odt-convert-process "gnumeric")
'(org-odt-convert-processes '(("gnumeric" "/usr/bin/ssconvert %i %o")))
But gnumeric does not exist in fink, does anybody know about an
alternative?
(Yes I know I should have used macports or homebrew, but now it is too
late).
Regards
Uwe Brauer
Re: URLs with brackets not recognised
I can confirm this as a bug. On 5/12/21 3:32 AM, Colin Baxter wrote: Hello, If a URL link in an org file contains a bracket then the link is not fully recognised and may be misdirected. For example, 1. emacs -Q 2. C-x C-f test.org 3. Insert the URL https://en.wikipedia.org/wiki/Cathedral_Basilica_of_St._John_the_Baptist_(Savannah,_Georgia) 4. Click on the link. 5. Link is not directed correctly. Best wishes, Colin.
Re: [bug] C-u org-update-statitics-cookies errors out with "Non-existent agenda file" if current file isn't saved
Thanks for the bug report, I can confirm this is happening. I encountered a similar bug where org-agenda-prepare-buffers was causing the same issue when the file hadn't been saved to disk, and I agree that the solution looks good. I've formatted this into a patch and attached it. Might be worth considering too if this is happening anywhere else too, since this is the second time it has come up. On 5/11/21 6:07 AM, m...@kisaragi-hiu.com wrote: * Reproduction 1. emacs -Q 2. C-x C-f /tmp/new.org RET 3. Type anything 4. Type C-u C-c # (C-u org-update-statistics-cookies) to try to update all statistics cookies in the buffer 5. Notice the "Non-existent agenda file /tmp/new.org." error. This doesn't happen if the file already exists. I first saw this reported in this reddit thread: https://www.reddit.com/r/orgmode/comments/n9g1yf/is_this_a_bug_with_orgupdatestatisticcookies/ (u/flyin1501 is me) * Expectation All statistics cookies in the buffer are updated no matter if the buffer's associated file is already created or not. * Why this is happening - `org-update-statistics-cookies` (C-c #) uses `org-map-entries` to update all cookies. - `org-map-entries` uses `org-agenda-prepare-buffers` to prepare the file when SCOPE is nil. Excerpt: (if (not scope) (progn (org-agenda-prepare-buffers (and buffer-file-name (list buffer-file-name))) (setq res (org-scan-tags func matcher org--matcher-tags-todo-only start-level))) - This function complains if the file does not exist, causing the error. * Solution (IMO) `org-map-entries` is quite complex because of its matching and scoping features; `org-update-statistics-cookies` only updates the current buffer and should use `org-map-region` instead. IMO it should go from (if all (progn (org-update-checkbox-count 'all) (org-map-entries 'org-update-parent-todo-statistics)) to: (if all (progn (org-update-checkbox-count 'all) (org-map-region 'org-update-parent-todo-statistics (point-min) (point-max))) >From 2081a1d2bd628dd8e5a1ad9fc4ffd58a4f951972 Mon Sep 17 00:00:00 2001 From: Nicholas Savage Date: Tue, 11 May 2021 06:59:14 -0400 Subject: [PATCH] lisp/org.el: Fix org-update-statistics-cookies error * lisp/org.el (org-update-statistics-cookies): Replace usage of `org-map-entries' with `org-map-region' to prevent bug where an error was thrown if the current buffer had not yet been saved to disk. Formatted from a patch proposal by m...@kisaragi-hiu.com Reported-by: m...@kisaragi-hiu.com --- lisp/org.el | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/lisp/org.el b/lisp/org.el index 6dbf33abc..fc5197642 100644 --- a/lisp/org.el +++ b/lisp/org.el @@ -9989,7 +9989,7 @@ all statistics cookies in the buffer." (if all (progn (org-update-checkbox-count 'all) - (org-map-entries 'org-update-parent-todo-statistics)) + (org-map-region 'org-update-parent-todo-statistics (point-min) (point-max))) (if (not (org-at-heading-p)) (org-update-checkbox-count) (let ((pos (point-marker)) -- 2.20.1
Re: bug#47088: org-w3m: handle w3m-image link information
I haven't opened up the code yet to take a look, but I likely will take a crack at some of these items in the future as low-hanging fruit refactoring project. On 5/6/21 6:05 PM, Boruch Baum wrote: (org-w3m-get-image-end): New function, for w3m-img links. 3] As mentioned in the patch, and in the commit message, there seem to be several functioned unused in the code base that could be candidates for removal... org-w3m-get-anchor-start org-w3m-no-prev-link-p org-w3m-get-prev-link-start 4] Additionally, in performing the merge I came across function org-string-nw-p, which seems to be an unnecessary duplicate of the emacs core function string-blank-p. It may be that historically you once needed your own home-made functions/macros, but now that emacs core has them, you may want to consider a refactor.
Re: babel output seems to drop anything before % (in session)
So I have a patch written that doesn't completely fix the problem, but
maybe makes enough progress that someone else can figure it out.
The issue is that comint-prompt-regexp is reading the "% " as a prompt,
and taking everyone off before it. I've added another parameter to
org-babel-comint-with-output in the "meta" to pass our own regexp to
replace comint-prompt-regexp, which works except when it doesn't. The
regexp I've added is just "\n" now, so the newline characters are removed.
The tests that Daniele added as a patch don't quite pass though with
this. The issue is that something in the way the output is posted in the
output buffer includes the prompt occasionally is included in a line and
occasionally not. It seems the first time the block of code is executed,
it is included (and therefore needs to be removed) and each other time
it is not, so it is only the first time that it is run is not working
properly.
This is obviously way too fragile to actually merge, but I was hoping
the work I've done so far is enough to help someone else make progress.
I'll probably take another stab at this tomorrow (since it's bugging
me), but thought I'd share what I have for now.
Cheers,
Nick
On 5/6/21 8:24 AM, Ihor Radchenko wrote:
"Nicholas Savage" writes:
I can confirm this too on the latest master.
I took a quick peek this morning, and my suspicion is that the problem is
somewhere within org-babel-comint-with-output in lisp/ob-comint.el, but I'm not
positive at this point.
I confirm as well. I also saw an anomaly in the comint buffer. Note that
all the output lines, except "five 0% six" are after the shell prompt.
As I remember, the code expects the result to be exactly at the prompt
line. So, for some reason the first command ("echo five 0% six") of the
second block does not get inserted at the empty line.
echo one 0% two
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ one 0%
two
echo tree 0% four
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ tree
0% four
echo 'org_babel_sh_eoe'
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $
org_babel_sh_eoe
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ echo
five 0% six
five 0% six
echo seven 0% eight
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $ seven
0% eight
echo 'org_babel_sh_eoe'
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $
org_babel_sh_eoe
yantar92@yantar92-laptop ~/.data/1e/90360c-ef36-4d20-8706-990ae2530cbf $
Best,
Ihor
>From 6c7d39bfb9be38b54d23fcffbb09f1fcb96751f4 Mon Sep 17 00:00:00 2001
From: Nicholas Savage
Date: Thu, 6 May 2021 19:17:33 -0400
Subject: [PATCH] ob-shell.el: Fix bug where shell output was incorrectly
truncated on special characters.
* lisp/ob-comint.el (org-babel-comint-with-output): Add fifth meta
optional argument for providing a custom prompt regexp.
lisp/ob-shell.el (org-babel-sh-evaluate): Implements using new
argument to prevent incorrect truncation on special characters.
If shell output included special characters that also occasionally are
included in shell prompts, such as "#" or "%", a regexp was tripping
up on them and cutting out part of the line. As ob-shell already cuts
out the shell prompts, this was not necessary and instead we can just
use \n as the separator. Original functionality was retained for other
ob-* files in case this was necessary.
---
lisp/ob-comint.el | 20
lisp/ob-shell.el | 2 +-
2 files changed, 13 insertions(+), 9 deletions(-)
diff --git a/lisp/ob-comint.el b/lisp/ob-comint.el
index 18d4f3c93..27ad6efd7 100644
--- a/lisp/ob-comint.el
+++ b/lisp/ob-comint.el
@@ -57,13 +57,14 @@ executed inside the protection of `save-excursion' and
(defmacro org-babel-comint-with-output (meta body)
"Evaluate BODY in BUFFER and return process output.
-Will wait until EOE-INDICATOR appears in the output, then return
-all process output. If REMOVE-ECHO and FULL-BODY are present and
-non-nil, then strip echo'd body from the returned output. META
-should be a list containing the following where the last two
-elements are optional.
+Will wait until EOE-INDICATOR appears in the output, then return all
+process output. If REMOVE-ECHO and FULL-BODY are present and non-nil,
+then strip echo'd body from the returned output. PROMPT-REGEXP is a
+filter that, if provided, overrides the default regexp that tries to
+filter out the shell prompt. META should be a list containing the
+following where the last three elements are optional.
- (BUFFER EOE-INDICATOR REMOVE-ECHO FULL-BODY)
+ (BUFFER EOE-INDICATOR REMOVE-ECHO FULL-BODY PROMPT-REGEXP)
This macro ensures that the filter is removed in case of an error
or user `keyboard-quit' during execution of body."
@@ -71,7 +72,10 @@ or user `keyboard-quit' during execution of body."
(let ((buffer (nth 0 meta))
(eoe-indicator (nth 1 meta))
(remove-echo (nth 2
[PATCH] Fix truncated output in ob-sqlite.el (Was: Bug: sqlite output truncated?)
I've attached a patch to address this. The issue is that ob-sqlite.el uses org-babel-string-read, which purposefully removes double-quotes. I think this is unintended behaviour, and it only seems to be used with ob-sqlite.el. I added a minor function to bypass the part of org-babel-string-read that was stripping out the double-quotes and use the rest of the function. I tried ob-sql with the mysql engine and didn't experience the same bug, so I'm pretty confident that this is an isolated issue. On 5/3/21 6:22 PM, learn orchids wrote: I am using Org mode version 9.4.5 (9.4.5-73-g4c7696-elpaplus and I have the following code snippet. Values in the 'sql' column of the second row is truncated. Am I missing something? #+begin_src sqlite :db /tmp/rip.db :colnames yes drop table if exists testtable; create table testtable(id int, sql varchar); insert into testtable values (1, "Select id from foo"); insert into testtable values (2, 'Select "id" from foo'); select* from testtable; #+end_src #+RESULTS: testsql | id | sql | |+| | 1 | Select id from foo | | 2 | id | >From 3dd868bcd798e6763ec67ba0d2661834e09bb6e9 Mon Sep 17 00:00:00 2001 From: Nicholas Savage Date: Tue, 4 May 2021 11:02:20 -0400 Subject: [PATCH] lisp/ob-sqlite.el: Prevent output from being incorrectly parsed if it contains double-quotes. * lisp/ob-sqlite.el (org-babel-sqlite--read-cell): New function. lisp/ob-sqlite.el (org-babel-sqlite-table-or-scalar): Use `org-babel-sqlite--read-cell' instead of `org-babel-string-read' to prevent data from being ignored if it contains double-quotes. Reported-by: learnorch...@gmail.com Link: https://orgmode.org/list/cak5xwica4i8h09obzcvpx2pe-t6b0_ju_mxiduriy7gh+pk...@mail.gmail.com/ --- lisp/ob-sqlite.el | 6 +- 1 file changed, 5 insertions(+), 1 deletion(-) diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el index c0c6f3c97..d227ba69d 100644 --- a/lisp/ob-sqlite.el +++ b/lisp/ob-sqlite.el @@ -125,7 +125,7 @@ This function is called by `org-babel-execute-src-block'." (mapcar (lambda (row) (if (eq 'hline row) 'hline - (mapcar #'org-babel-string-read row))) + (mapcar #'org-babel-sqlite--read-cell row))) result))) (defun org-babel-sqlite-offset-colnames (table headers-p) @@ -139,6 +139,10 @@ This function is called by `org-babel-execute-src-block'." Prepare SESSION according to the header arguments specified in PARAMS." (error "SQLite sessions not yet implemented")) +(defun org-babel-sqlite--read-cell (cell) + "Process CELL to remove unnecessary characters." + (org-babel-read cell t)) + (provide 'ob-sqlite) ;;; ob-sqlite.el ends here -- 2.20.1
Re: Bug: sqlite output truncated?
I can replicate this, it looks like a bug to me. Looks to me that there's something wrong with the way it is handling single quoted strings, since the output is only what is within the double quoted strings. I will take a stab at fixing this. On 5/3/21 6:22 PM, learn orchids wrote: I am using Org mode version 9.4.5 (9.4.5-73-g4c7696-elpaplus and I have the following code snippet. Values in the 'sql' column of the second row is truncated. Am I missing something? #+begin_src sqlite :db /tmp/rip.db :colnames yes drop table if exists testtable; create table testtable(id int, sql varchar); insert into testtable values (1, "Select id from foo"); insert into testtable values (2, 'Select "id" from foo'); select* from testtable; #+end_src #+RESULTS: testsql | id | sql | |+| | 1 | Select id from foo | | 2 | id |
[PATCH] Replace call in org-columns of org-map-entries with org-scan-tags
Hello all, I was trying to track down the source of a bug encountered when I was submitting my last patch about org-columns. I'm going to walk you through my thought process and summarize at the end. As part of my experimenting, I did the following: 1. emacs -Q 2. open a new buffer at "/tmp/test.org" 3. Add a headline (something like "* test"), and run org-columns only be greeted by an unexpected error: "Non-existent agenda file /tmp/test.org. [R]emove from list or [A]bort?" It's clear that /tmp/test.org is not part of the agenda since it's a brand new file, but I was surprised that org-columns cares at all. Pressing "R" to remove it from the list tells the user that it wasn't in the agenda list (as you'd expect) and then continues to display columns as expected, which made me wonder why it is doing that at all. This issue only appears though when /tmp/test.org is not saved to disk, which looks like expected behaviour as per the following. I looked into what's going on, and it relates to org-map-entries, which builds a list of what is in the buffer. org-map-entries calls org-agenda-prepare-buffers. This checks whether the given files are actual files or not and opens them up if they are. This makes sense I believe from an org-agenda perspective since it has to make sure all of the files are open in order to return a list of the headlines, but for org-columns it does not. org-columns is an interactive function that is only run on the current buffer, so the buffer should always be open. org-map-entries has a lot of different paths in it based on the parameters, but essentially the call from org-columns does two things: 1) call org-agenda-prepare-buffers and 2) sets "res" to the output of org-scan-tags. I believe that the former is unnecessary and that the latter is the only necessary code to run in this instance. To summarize: I've attached a patch to this that makes a change to this. It replaces org-map-entries with a call instead to org-scan-tags. This fixes the bug I noted above, and I believe (if I'm using the profiler correct), makes org-columns a bit faster since it's not calling a bunch of functions that doesn't matter to its output. As far as I can tell, my patch works as expected with no obvious behaviour changes. All of the tests continue to pass as well. I've tested it on my own files and it is working as expected as well. I'd appreciate any feedback on this, or if there are edge cases that the removed code breaks that I haven't been able to identify. Nick >From f8425ef6fe0ae59c9c4df0b71f3cb61c7bc7e975 Mon Sep 17 00:00:00 2001 From: Nicholas Savage Date: Mon, 3 May 2021 08:49:11 -0400 Subject: [PATCH] org-colview.el (org-columns): Replace org-map-entries with org-scan-tags * lisp/org-colview.el (org-columns): Replace call to `org-map-entries' to build cache with `org-scan-tags'. Simplifies `org-columns' to call `org-scan-tags' instead of `org-map-entries'. This is to fix a bug where an unexpected non-existent agenda file error was thrown if the buffer that `org-columns' was called on was not yet saved to disk. This also simplifies `org-columns' and prevents unnecessary agenda preparation functions from running. --- lisp/org-colview.el | 16 +++- 1 file changed, 7 insertions(+), 9 deletions(-) diff --git a/lisp/org-colview.el b/lisp/org-colview.el index 517bcdf1c..ac3fd9326 100644 --- a/lisp/org-colview.el +++ b/lisp/org-colview.el @@ -836,12 +836,11 @@ Also sets `org-columns-top-level-marker' to the new position." (defun org-columns ( global columns-fmt-string) "Turn on column view on an Org mode file. -Column view applies to the whole buffer if point is before the -first headline. Otherwise, it applies to the first ancestor -setting \"COLUMNS\" property. If there is none, it defaults to -the current headline. With a `\\[universal-argument]' prefix \ -argument, turn on column -view for the whole buffer unconditionally. +Column view applies to the whole buffer if point is before the first +headline. Otherwise, it applies to the first ancestor setting +\"COLUMNS\" property. If there is none, it defaults to the current +headline. With a `\\[universal-argument]' prefix \ argument, GLOBAL, +turn on column view for the whole buffer unconditionally. When COLUMNS-FMT-STRING is non-nil, use it as the column format." (interactive "P") @@ -867,9 +866,8 @@ When COLUMNS-FMT-STRING is non-nil, use it as the column format." (let ((cache ;; Collect contents of columns ahead of time so as to ;; compute their maximum width. - (org-map-entries - (lambda () (cons (point) (org-columns--collect-values))) - nil nil (and org-columns-skip-archived-trees 'archive + (org-scan-tags + (lambda () (cons (point) (org-columns--collect-values))) t org--matcher-tags-todo-only))) (when cache (org-columns--set-widths cache) (org-columns--display-here-title) -- 2.20.1
[PATCH]: org-columns does not respect global-visual-line-mode for long text within headlines
I've done some more research on https://orgmode.org/list/875z02si3g@nicolasgoaziou.fr/, and I believe the issue is that `org-columns' is setting `truncate-lines' as t, while `global-visual-line-mode' is expecting it to be set to nil. The interaction between the two causes the wrapping to not occur. `org-columns; also cleans up after itself and replaces truncate-lines with the original value, which is why the problem only occurs when `org-columns' is enabled it. The attached patch ensures the behaviour is correct when `global-visual-line-mode' is enabled and that there are no behaviour changes when it has not already been enabled. >From fbb91ddc2bc8b6f29651e3114754bcd8fcad30d0 Mon Sep 17 00:00:00 2001 From: Nicholas Savage Date: Sat, 1 May 2021 20:05:09 -0400 Subject: [PATCH] lisp/org-colview.el: Update org-columns to respect global-visual-line-mode * lisp/org-colview.el (org-columns): Prevent enabling truncate-lines when global-visual-line-mode is also enabled Fixing a bug where org-column overlays were disabling wrapping of lines when global-visual-line-mode was already activated, and so therefore expectation was that the lines would continue wrapping. This is because org-columns was setting truncate-lines to t, when global-visual-line-mode requires it to be set to nil. The interaction between the two caused the wrapping not to occur. --- lisp/org-colview.el | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/lisp/org-colview.el b/lisp/org-colview.el index 517bcdf1c..9dad8c7d9 100644 --- a/lisp/org-colview.el +++ b/lisp/org-colview.el @@ -879,7 +879,8 @@ When COLUMNS-FMT-STRING is non-nil, use it as the column format." (unless (local-variable-p 'org-colview-initial-truncate-line-value) (setq-local org-colview-initial-truncate-line-value truncate-lines)) - (setq truncate-lines t) +(if (not global-visual-line-mode) + (setq truncate-lines t)) (dolist (entry cache) (goto-char (car entry)) (org-columns--display-here (cdr entry) -- 2.20.1
Bug: org-columns does not respect global-visual-line-mode for long text within headlines
Hello everyone,
I'm filing a bug in relation to org-columns and its interactions with
global-visual-line-mode, which I do not think is expected behaviour.
1. Start `emacs -Q'
2. Create /tmp/test.org (or something like this)
3. Enable M-x global-visual-line-mode
4. Insert the following (or something like it, the purpose is to have a
line that wraps on your screen with global-visual-line-mode enabled, you
may need to add more characters if necessary)
* test headline
cc
5. Collapse headline, activate org-columns (C-c C-x C-c) on the headline.
6. Toggle visibility of headline, note that the line no longer wraps and
instead acts as if global-visual-line-mode was not enabled.
I am investigating now but I thought I would post this as a bug
regardless. The trace below is for the release of org-mode with 28.0.50,
but I can confirm that it is the same on the current master.
Emacs : GNU Emacs 28.0.50 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.5, cairo version 1.16.0)
of 2021-01-15
Package: Org mode version 9.4.4 (release_9.4.4 @
/usr/local/share/emacs/28.0.50/lisp/org/)
current state:
==
(setq
org-confirm-elisp-link-function 'yes-or-no-p
org-speed-command-hook '(org-speed-command-activate
org-babel-speed-command-activate)
org-occur-hook '(org-first-headline-recenter)
org-babel-pre-tangle-hook '(save-buffer)
org-cycle-hook '(org-cycle-hide-archived-subtrees
org-cycle-hide-drawers org-cycle-show-empty-lines
org-optimize-window-after-visibility-change)
outline-isearch-open-invisible-function 'outline-isearch-open-invisible
org-archive-hook '(org-attach-archive-delete-maybe)
org-agenda-loop-over-headlines-in-active-region nil
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer)
org-confirm-shell-link-function 'yes-or-no-p
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-mode-hook '(#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-show-all append local] 5]
#[0 "\300\301\302\303\304$\207" [add-hook
change-major-mode-hook org-babel-show-result-all append local] 5]
org-babel-result-hide-spec org-babel-hide-all-hashes)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-link-shell-confirm-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow
:complete org-attach-complete-link) ("id" :follow org-id-open)
("eww" :follow org-eww-open :store org-eww-store-link)
("rmail" :follow org-rmail-open :store org-rmail-store-link)
("mhe" :follow org-mhe-open :store org-mhe-store-link)
("irc" :follow org-irc-visit :store org-irc-store-link
:export org-irc-export)
("info" :follow org-info-open :export org-info-export
:store org-info-store-link)
("gnus" :follow org-gnus-open :store org-gnus-store-link)
("docview" :follow org-docview-open :export
org-docview-export :store org-docview-store-link)
("bibtex" :follow org-bibtex-open :store
org-bibtex-store-link)
("bbdb" :follow org-bbdb-open :export org-bbdb-export
:complete org-bbdb-complete-link :store
org-bbdb-store-link)
("w3m" :store org-w3m-store-link) ("file+sys")
("file+emacs") ("shell" :follow org-link--open-shell)
("news" :follow #[514 "\301\300\302Q\"\207" ["news"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("mailto" :follow #[514 "\301\300\302Q\"\207"
["mailto" browse-url ":"] 6 "\n\n(fn URL ARG)"])
("https" :follow #[514 "\301\300\302Q\"\207" ["https"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("http" :follow #[514 "\301\300\302Q\"\207" ["http"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("ftp" :follow #[514 "\301\300\302Q\"\207" ["ftp"
browse-url ":"] 6 "\n\n(fn URL ARG)"])
("help" :follow org-link--open-help) ("file" :complete
org-link-complete-file)
("elisp" :follow org-link--open-elisp) ("doi" :follow
org-link--open-doi))
org-export-before-parsing-hook '(org-attach-expand-links)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-link-elisp-confirm-function 'yes-or-no-p
org-tab-first-hook '(org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand)
)
[PATCH] ob-eval.el: Refactoring `org-babel-eval' to improve readability
Hello everyone,
I have attached a patch to refactor `org-babel-eval' and
`org-babel--shell-command-on-region' to improve readability and to make
local variables more consistent between functions.
This also removes two parameters from
`org-babel--shell-command-on-region', START and END. The function was
created as a simplified `shell-command-on-region' that does only part of
what it does. Those two parameters were included. As far as I can tell,
`org-babel--shell-command-on-region' is only ever called by
`org-babel-eval', and there is never any uncertainty over the contents
of START and END as they are only ever (point-min) and (point-max).
Given how specialized this function is, I believe it highly unlikely
this is called anywhere else. I searched github too and didn't find
anywhere where where code is calling this so I felt it was safe. I'm
happy to change it back if necessary.
Please let me know what you think.
Thanks,
Nick
>From ac0cdc66374f1c99aadd5f07e0c6d65eaaa158cc Mon Sep 17 00:00:00 2001
From: Nicholas Savage
Date: Wed, 28 Apr 2021 06:15:47 -0400
Subject: [PATCH] ob-eval.el: Refactoring `org-babel-eval' to improve
readability
* ob-eval.el (org-babel-eval): Improve documentation and rename local
variables to be consistent with `org-babel--shell-command-on-region'
* (org-babel--shell-command-on-region): Remove START and END as
parameters.
* (org-babel--shell-command-on-region): Refactored out parts of
function to `org-babel--write-temp-buffer-input-file' and `org-babel--get-shell-file-name'.
This removes two parameters from
`org-babel--shell-command-on-region'. It appears that START and END
were parameters only because shell-command-on-region has them. This
function is only called by org-babel-eval so it looks safe to remove
those parameters, since they are always (point-min) and (point-max)
and are never changed. Given the way the function works and that it
is, it is unlikely that any user code relies on it.
---
lisp/ob-eval.el | 87 -
1 file changed, 50 insertions(+), 37 deletions(-)
diff --git a/lisp/ob-eval.el b/lisp/ob-eval.el
index b0fca7bd9..cfde4f1ca 100644
--- a/lisp/ob-eval.el
+++ b/lisp/ob-eval.el
@@ -41,20 +41,22 @@
(display-buffer buf))
(message "Babel evaluation exited with code %S" exit-code))
-(defun org-babel-eval (cmd body)
- "Run CMD on BODY.
-If CMD succeeds then return its results, otherwise display
-STDERR with `org-babel-eval-error-notify'."
- (let ((err-buff (get-buffer-create " *Org-Babel Error*")) exit-code)
-(with-current-buffer err-buff (erase-buffer))
+(defun org-babel-eval (command query)
+ "Run COMMAND on QUERY.
+Writes QUERY into a temp-buffer that is processed with
+org-babel--shell-command-on-region. If COMMAND succeeds then return
+its results, otherwise display STDERR with
+`org-babel-eval-error-notify'."
+ (let ((error-buffer (get-buffer-create " *Org-Babel Error*")) exit-code)
+(with-current-buffer error-buffer (erase-buffer))
(with-temp-buffer
- (insert body)
+ (insert query)
(setq exit-code
(org-babel--shell-command-on-region
- (point-min) (point-max) cmd err-buff))
+ command error-buffer))
(if (or (not (numberp exit-code)) (> exit-code 0))
(progn
- (with-current-buffer err-buff
+ (with-current-buffer error-buffer
(org-babel-eval-error-notify exit-code (buffer-string)))
(save-excursion
(when (get-buffer org-babel-error-buffer-name)
@@ -71,26 +73,19 @@ STDERR with `org-babel-eval-error-notify'."
(with-temp-buffer (insert-file-contents file)
(buffer-string)))
-(defun org-babel--shell-command-on-region (start end command error-buffer)
+(defun org-babel--shell-command-on-region (command error-buffer)
"Execute COMMAND in an inferior shell with region as input.
+Stripped down version of `shell-command-on-region' for internal use in
+Babel only. This lets us work around errors in the original function
+in various versions of Emacs. This expects the query to be run to be
+in the current temp buffer. This is written into
+input-file. ERROR-BUFFER is the name of the file which
+`org-babel-eval' has created to use for any error messages that are
+returned."
-Stripped down version of shell-command-on-region for internal use
-in Babel only. This lets us work around errors in the original
-function in various versions of Emacs.
-"
(let ((input-file (org-babel-temp-file "ob-input-"))
(error-file (if error-buffer (org-babel-temp-file "ob-error-") nil))
- ;; Unfortunately, `executable-find' does not support file name
- ;; handlers. Therefore, we could use it in the local case
- ;; only.
- (shell-file-name
- (cond ((and (not (file-remote-p default-directory))
- (executable-find shell-file-name))
- shell-file-name)
- ((file-executable-p
- (concat (file-remote-p default-directory) shell-file-name))
- shell-file-name)
- ("/bin/sh")))
+ (shell-file-name
Re: Concerns about community contributor support
As a new contributor, I wanted to add my two cents. I've submitted a minor amount of patches (somewhere between 1 and 3, I can't remember exactly), and I feel that the other problems you raise, primarily the first one, are obstacles towards that though. Patches like that are obviously minor, since they aren't fixing bugs, so they're low priority. That drags out the process though, and it's a little discouraging to submit patches that don't receive responses, and make me less eager to submit more.For example, I submitted a tiny refactoring patch last month that hasn't received an answer yet. I'm not looking for special treatment of course, and think that review of patches is super important (especially for a new contributor like me) I think that the solutions you raise are great starts. I feel like the documentation that I've used has been pretty accurate, but it could always be better, and someone who is the point person for dealing with people like me would be a good idea. I would not like to volunteer for that myself. I don't feel comfortable enough with my abilities, or my experience with the community, to able to help others or give reasonable answers for patches other than something like "yes, I've seen this". I will try to help out more with verifying bugs though. On a side note, I'd like some guidance though on whether or not the community is interested in a refactoring project (done in pieces of course). I'm wondering if I should be attempting to submit minor (or larger) patches moving things around to make it easier to maintain, if there is a way to go about this (since submitting a bunch at a time, breaking them up, etc), certain things I should focus on or ignore, etc. I haven't done much since that mostly because work has consumed my free time, but I'm going to have a significant amount more free time starting in the next week or so, so I'm looking for somewhere to direct my energies! On 4/25/21 12:30 AM, Bastien wrote: Dear Timothy, thanks for raising this points so carefully, they are important. I see three distinct problems: 1. The lack of response and/or follow-up when people contribute by sending bug reports or patches on the list. 2. The lack of maintainance on documenting the contribution process and the correct expectations for future contributors. 3. The inherent difficulty to move the Org codebase forward. I won't comment on (3). For (1) and (2), I suggest appointing a "contributor steward" with these responsibilities: 1. Maintain updates.orgmode.org (i.e. make sure it is accurate.) 2. Maintain the documentation for contributors. 3. Help contributors enhancing their patches. 4. Try to reproduce bugs (and confirm them for updates.orgmode.org) 5. Make sure patch contributors are not left with no answer. You started (1), which is really appreciated. Tim and others mentioned (2), and that's certainly needed too. (3) has historically been the role of the maintainer and of the core contributors, but helping with this is very welcome: knowing the doc at https://orgmode.org/worg/org-contribute.html by heart, educating contributors on the commit messages, etc. This all helps. (4) is perhaps the most daunting task: I even think we could have someone only dedicated to this very important task. Just count the number of times Nicolas says "I cannot reproduce this." Each time, there is a real bug that is *not* fixed... (5) is not about systematically welcome patch submitters with a message (that would be annoying) but to monitor updates.orgmode.org and decide what to do with a patch that didn't receive feedback: either say thanks and ping the list for why you think the patch deserves more attention, or thanks and dismiss the patch, or another answer. What do you think? Would you be willing to take this role? If not, that's perfectly okay, I'll send a call for help. Thanks,
Re: Backwards compatability
On org-drill, I think someone has already taken it up here a while ago: https://gitlab.com/phillord/org-drill On 4/25/21 12:39 AM, Bastien wrote: Hi Bithov, we *do* care a lot about backward compatibility*. We cannot make a strong commitment for contributed libraries and external ones, though, otherwise Org would not evolve. org-drill.el was removed from the contrib/ directory 1 year ago: https://code.orgmode.org/bzg/org-mode/commit/2c8e8b4a Perhaps you can try to find someone who wants to maintain it. * https://bzg.fr/en/the-software-maintainers-pledge/
[PATCH] Improve code readability in org-set-font-lock-defaults
I'm not sure what the appetite is for small changes like this, but I
have attached a small patch to improve readability in
org-set-font-lock-defaults. I was trying to understand how org-emphasize
worked and came across some code that I thought could be simplified.
If small refactoring patches like this aren't recommended or if I should
wait until I have larger patches put together first before sending them
to the list, please let me know.
>From a7d5e226dd3b377edcc9c97dd83a8445ae67d952 Mon Sep 17 00:00:00 2001
From: Nicholas Savage
Date: Sun, 14 Mar 2021 21:47:57 -0400
Subject: [PATCH] Refactor org-set-font-lock-defaults to improve code
readability
* org.el (org-set-font-lock-defaults): Reduce number of local
variables to improve code readability.
---
lisp/org.el | 14 ++
1 file changed, 6 insertions(+), 8 deletions(-)
diff --git a/lisp/org.el b/lisp/org.el
index 28596558b..d3c043a0c 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -5614,9 +5614,7 @@ needs to be inserted at a specific position in the font-lock sequence.")
(defun org-set-font-lock-defaults ()
"Set font lock defaults for the current buffer."
- (let* ((em org-fontify-emphasized-text)
- (lk org-highlight-links)
- (org-font-lock-extra-keywords
+ (let ((org-font-lock-extra-keywords
(list
;; Call the hook
'(org-font-lock-hook)
@@ -5643,10 +5641,10 @@ needs to be inserted at a specific position in the font-lock sequence.")
'(org-fontify-drawers)
;; Link related fontification.
'(org-activate-links)
- (when (memq 'tag lk) '(org-activate-tags (1 'org-tag prepend)))
- (when (memq 'radio lk) '(org-activate-target-links (1 'org-link t)))
- (when (memq 'date lk) '(org-activate-dates (0 'org-date t)))
- (when (memq 'footnote lk) '(org-activate-footnote-links))
+ (when (memq 'tag org-highlight-links) '(org-activate-tags (1 'org-tag prepend)))
+ (when (memq 'radio org-highlight-links) '(org-activate-target-links (1 'org-link t)))
+ (when (memq 'date org-highlight-links) '(org-activate-dates (0 'org-date t)))
+ (when (memq 'footnote org-highlight-links) '(org-activate-footnote-links))
;; Targets.
(list org-radio-target-regexp '(0 'org-target t))
(list org-target-regexp '(0 'org-target t))
@@ -5690,7 +5688,7 @@ needs to be inserted at a specific position in the font-lock sequence.")
(list (concat "\\<" org-closed-string) '(0 'org-special-keyword t))
(list (concat "\\<" org-clock-string) '(0 'org-special-keyword t))
;; Emphasis
- (when em '(org-do-emphasis-faces))
+ (when org-fontify-emphasized-text '(org-do-emphasis-faces))
;; Checkboxes
'("^[ \t]*\\(?:[-+*]\\|[0-9]+[.)]\\)[ \t]+\\(?:\\[@\\(?:start:\\)?[0-9]+\\][ \t]*\\)?\\(\\[[- X]\\]\\)"
1 'org-checkbox prepend)
--
2.20.1
Re: Bug: Entries with 0 minutes logged triggers clocking overlap [9.5 (nil @ /home/eddie/.emacs.d/.local/straight/build-26.3/org-mode/)]
Hi Eddie,
Are you culling the 0 minute entries because they are not useful for you
and throw errors, or do you wish they could be included as part of your
workflow but they don't work properly?
Thanks,
Nick
On 3/5/21 8:48 PM, Eddie Drury wrote:
Hi,
Not uncommonly I will clock into a task that takes very little time,
so that 0 minutes is logged against it, before logging in to the next
task.
When I run agenda mode with show-clocking errors, it will mark these
two tasks as a clocking overlap, when in fact this was not the case.
Currently to resolve this, every week I have to cull all clocking
entries that are for 0 minutes.
I feel better behaviour would be, in this situation to not trigger the
clocking overlap.
Thanks very much for reviewing this, and for org mode in general. This
is a life changing software for me.
Regards,
- Eddie Drury
Emacs : GNU Emacs 26.3 (build 2, x86_64-pc-linux-gnu, GTK+ Version
3.24.14)
of 2020-03-26, modified by Debian
Package: Org mode version 9.5 (nil @
/home/eddie/.emacs.d/.local/straight/build-26.3/org-mode/)
current state:
==
(setq
org-duration-format 'h:mm
org-footnote-auto-label 'plain
org-src-mode-hook '(org-src-babel-configure-edit-buffer
org-src-mode-configure-edit-buffer
doom-modeline-set-org-src-modeline)
org-fontify-whole-heading-line t
org-link-shell-confirm-function 'yes-or-no-p
org-mode-local-vars-hook '(eldoc-mode)
org-babel-after-execute-hook '(org-redisplay-inline-images)
org-insert-heading-respect-content t
org-after-refile-insert-hook '(save-buffer)
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
org-refile-targets '((nil :maxlevel . 3) (org-agenda-files :maxlevel
. 4))
org-html-format-inlinetask-function
'org-html-format-inlinetask-default-function
org-enforce-todo-dependencies t
org-time-stamp-rounding-minutes '(0 1)
org-odt-format-headline-function
'org-odt-format-headline-default-function
org-special-ctrl-a/e t
org-imenu-depth 8
org-agenda-files '("~/orgnotes/transfer/transfer.org
" "~/orgnotes/casenotes.org ")
org-ascii-format-inlinetask-function 'org-ascii-format-inlinetask-default
org-reveal-start-hook '(org-decrypt-entry)
org-export-with-section-numbers nil
org-modules '(ol-bibtex)
org-startup-folded t
org-blocker-hook '(org-block-todo-from-children-or-siblings-or-parent)
org-mode-hook '(er/add-org-mode-expansions my/org-mode-hook
org-clock-load
+lookup--init-org-mode-handlers-h
(closure (t) ( _)
(add-hook (quote before-save-hook) (quote
org-encrypt-entries) nil t))
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook org-show-all
append local] 5]
#[0 "\300\301\302\303\304$\207"
[add-hook change-major-mode-hook
org-babel-show-result-all append local]
5]
org-babel-result-hide-spec org-babel-hide-all-hashes
#[0 "\301\211 \207" [imenu-create-index-function
org-imenu-get-tree] 2]
doom-disable-show-paren-mode-h
doom-disable-show-trailing-whitespace-h
+org-enable-auto-reformat-tables-h
+org-enable-auto-update-cookies-h
+org-make-last-point-visible-h evil-org-mode
toc-org-enable
embrace-org-mode-hook org-eldoc-load
+literate-enable-recompile-h)
org-clock-persist 'history
org-export-with-smart-quotes t
org-odt-format-drawer-function #[514 "\207" [] 3 "\n\n(fn NAME
CONTENTS)"]
org-outline-path-complete-in-steps nil
org-archive-hook '(org-attach-archive-delete-maybe)
org-agenda-finalize-hook '(+org-exclude-agenda-buffers-from-workspace-h
+org-defer-mode-in-agenda-buffers-h)
org-startup-indented t
org-reverse-note-order t
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300 \236A\207" [:title] 3
"\n\n(fn ENTRY)"]
org-latex-format-drawer-function #[514 "\207" [] 3 "\n\n(fn _ CONTENTS)"]
org-agenda-deadline-faces '((1.001 . error) (1.0 . org-warning)
(0.5 . org-upcoming-deadline)
(0.0 . org-upcoming-distant-deadline))
org-crypt-key nil
org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(+org-yas-expand-maybe-h +org-indent-maybe-h
org-babel-hide-result-toggle-maybe
org-babel-header-arg-expand
+org-cycle-only-current-subtree-h
+org-clear-babel-results-h)
org-hide-leading-stars t
org-export-initial-scope 'subtree
org-load-hook '(+org-init-org-directory-h +org-init-appearance-h
+org-init-agenda-h
+org-init-attachments-h +org-init-babel-h
Re: [PATCH] Reduce code duplication in ob-sql.el and ob-sqlite.el
Please see the attached updated patch with the changes requested. Nick On 3/4/21 12:25 AM, Kyle Meyer wrote: Nick Savage writes: Hi everyone, See the attached patch. It is a small change to reduce code duplication between ob-sql.el and ob-sqlite.el by reusing org-babel-sql-expand-vars as suggested by the FIXME in ob-sqlite.el. Thank you. Looks good, though I think it'd be nice to keep org-babel-sqlite-expand-vars around for a bit, marked as obsolete. Subject: [PATCH] Reduce code duplication in ob-sqlite.el and ob-sql.el * lisp/ob-sqlite.el (org-babel-sqlite-expand-vars): removed function to replace with ob-sql.el version * lisp/ob-sql.el (org-babel-sql-expand-vars): updated to support expanding sqlite vars Please capitalize the first word after ":" and end the entries with a period. https://www.gnu.org/prep/standards/html_node/Style-of-Change-Logs.html -(defun org-babel-sqlite-expand-vars (body vars) - "Expand the variables held in VARS in BODY." - ;; FIXME: Redundancy with org-babel-sql-expand-vars! - (mapc - (lambda (pair) - (setq body - (replace-regexp-in-string - (format "$%s" (car pair)) - (let ((val (cdr pair))) - (if (listp val) - (let ((data-file (org-babel-temp-file "sqlite-data-"))) -(with-temp-file data-file - (insert (orgtbl-to-csv val nil))) -data-file) -(if (stringp val) val (format "%S" val - body))) - vars) - body) - How about marking this with (declare (obsolete ...)) and keeping it around as a wrapper that calls org-babel-sql-expand-vars? That will give any third-party code that may have used this for whatever reason (perhaps unlikely) a chance to update. >From 1e2816c89a4fc87a8d01c20dfb5a3c4cf794b553 Mon Sep 17 00:00:00 2001 From: Nicholas Savage Date: Wed, 3 Mar 2021 07:47:15 -0500 Subject: [PATCH] Reduce code duplication in ob-sqlite.el and ob-sql.el * lisp/ob-sqlite.el (org-babel-sqlite-expand-vars): Marked function as obsolete. * lisp/ob-sql.el (org-babel-sql-expand-vars): Updated to support expanding sqlite vars. --- lisp/ob-sql.el| 15 +++ lisp/ob-sqlite.el | 23 +-- 2 files changed, 16 insertions(+), 22 deletions(-) diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el index 68d5ddd0a..b1c6920cb 100644 --- a/lisp/ob-sql.el +++ b/lisp/ob-sql.el @@ -350,8 +350,13 @@ SET COLSEP '|' (org-babel-pick-name (cdr (assq :rowname-names params)) (cdr (assq :rownames params -(defun org-babel-sql-expand-vars (body vars) - "Expand the variables held in VARS in BODY." +(defun org-babel-sql-expand-vars (body vars sqlite) + "Expand the variables held in VARS in BODY. + +If SQLITE has been provided, prevent passing a format to +`orgtbl-to-csv'. This prevents overriding the default format, which if +there were commas in the context of the table broke the table as an +argument mechanism." (mapc (lambda (pair) (setq body @@ -362,9 +367,11 @@ SET COLSEP '|' (let ((data-file (org-babel-temp-file "sql-data-"))) (with-temp-file data-file (insert (orgtbl-to-csv - val '(:fmt (lambda (el) (if (stringp el) + val (if sqlite + nil + '(:fmt (lambda (el) (if (stringp el) el -(format "%S" el))) +(format "%S" el data-file) (if (stringp val) val (format "%S" val body))) diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el index 6e21fa9fd..332a29872 100644 --- a/lisp/ob-sqlite.el +++ b/lisp/ob-sqlite.el @@ -27,6 +27,7 @@ ;;; Code: (require 'ob) +(require 'ob-sql) (declare-function org-table-convert-region "org-table" (beg0 end0 separator)) @@ -51,8 +52,8 @@ (defun org-babel-expand-body:sqlite (body params) "Expand BODY according to the values of PARAMS." - (org-babel-sqlite-expand-vars - body (org-babel--get-vars params))) + (org-babel-sql-expand-vars + body (org-babel--get-vars params) t)) (defvar org-babel-sqlite3-command "sqlite3") @@ -112,22 +113,8 @@ This function is called by `org-babel-execute-src-block'." (defun org-babel-sqlite-expand-vars (body vars) "Expand the variables held in VARS in BODY." - ;; FIXME: Redundancy with org-babel-sql-expand-vars! - (mapc - (lambda (pair) - (setq body - (replace-regexp-in-string - (format "$%s" (car pair)) - (let ((val (cdr pair))) - (if (listp val) - (let ((data-file
[PATCH] Reduce code duplication in ob-sql.el and ob-sqlite.el
Hi everyone, See the attached patch. It is a small change to reduce code duplication between ob-sql.el and ob-sqlite.el by reusing org-babel-sql-expand-vars as suggested by the FIXME in ob-sqlite.el. Thanks, Nick >From 849a1b7417b39abbf0aeb1b241e890470e4111cd Mon Sep 17 00:00:00 2001 From: Nicholas Savage Date: Wed, 3 Mar 2021 07:47:15 -0500 Subject: [PATCH] Reduce code duplication in ob-sqlite.el and ob-sql.el * lisp/ob-sqlite.el (org-babel-sqlite-expand-vars): removed function to replace with ob-sql.el version * lisp/ob-sql.el (org-babel-sql-expand-vars): updated to support expanding sqlite vars --- lisp/ob-sql.el| 15 +++ lisp/ob-sqlite.el | 24 +++- 2 files changed, 14 insertions(+), 25 deletions(-) diff --git a/lisp/ob-sql.el b/lisp/ob-sql.el index 68d5ddd0a..b1c6920cb 100644 --- a/lisp/ob-sql.el +++ b/lisp/ob-sql.el @@ -350,8 +350,13 @@ SET COLSEP '|' (org-babel-pick-name (cdr (assq :rowname-names params)) (cdr (assq :rownames params -(defun org-babel-sql-expand-vars (body vars) - "Expand the variables held in VARS in BODY." +(defun org-babel-sql-expand-vars (body vars sqlite) + "Expand the variables held in VARS in BODY. + +If SQLITE has been provided, prevent passing a format to +`orgtbl-to-csv'. This prevents overriding the default format, which if +there were commas in the context of the table broke the table as an +argument mechanism." (mapc (lambda (pair) (setq body @@ -362,9 +367,11 @@ SET COLSEP '|' (let ((data-file (org-babel-temp-file "sql-data-"))) (with-temp-file data-file (insert (orgtbl-to-csv - val '(:fmt (lambda (el) (if (stringp el) + val (if sqlite + nil + '(:fmt (lambda (el) (if (stringp el) el -(format "%S" el))) +(format "%S" el data-file) (if (stringp val) val (format "%S" val body))) diff --git a/lisp/ob-sqlite.el b/lisp/ob-sqlite.el index 6e21fa9fd..2ec9deb78 100644 --- a/lisp/ob-sqlite.el +++ b/lisp/ob-sqlite.el @@ -27,6 +27,7 @@ ;;; Code: (require 'ob) +(require 'ob-sql) (declare-function org-table-convert-region "org-table" (beg0 end0 separator)) @@ -51,8 +52,8 @@ (defun org-babel-expand-body:sqlite (body params) "Expand BODY according to the values of PARAMS." - (org-babel-sqlite-expand-vars - body (org-babel--get-vars params))) + (org-babel-sql-expand-vars + body (org-babel--get-vars params) t)) (defvar org-babel-sqlite3-command "sqlite3") @@ -110,25 +111,6 @@ This function is called by `org-babel-execute-src-block'." (org-babel-sqlite-offset-colnames (org-table-to-lisp) headers-p))) -(defun org-babel-sqlite-expand-vars (body vars) - "Expand the variables held in VARS in BODY." - ;; FIXME: Redundancy with org-babel-sql-expand-vars! - (mapc - (lambda (pair) - (setq body - (replace-regexp-in-string - (format "$%s" (car pair)) - (let ((val (cdr pair))) - (if (listp val) - (let ((data-file (org-babel-temp-file "sqlite-data-"))) -(with-temp-file data-file - (insert (orgtbl-to-csv val nil))) -data-file) -(if (stringp val) val (format "%S" val - body))) - vars) - body) - (defun org-babel-sqlite-table-or-scalar (result) "If RESULT looks like a trivial table, then unwrap it." (if (and (equal 1 (length result)) -- 2.20.1
Re: Please help by becoming a maintainer for an Org Babel file
Hi Bastien, I'm willing to volunteer to maintain ob-sqlite.el. I think like Andy, I have some work to do to get up to speed on my elisp but I'm comfortable enough with sqlite itself. As far as I'm aware my copyright process has been finalized as well. Thanks, Nick On 10/26/20 4:07 AM, Bastien wrote: Dear all, we are looking for more maintainers of individual Org Babel files. Jack and Ian are already in, I added myself to ob-clojure.el. If you feel like proposing yourself for maintaining an Org Babel language, that would be super helpful. Thanks a lot!
