Bug: org-encrypt-entry fails [9.4 (nil @ /home/silipwn/.emacs.d/.local/straight/build/org-mode/)]

2020-05-14 Thread silipwn
The org-encrypt-entry fails to encrypt an entry, with a wrong-type-argument. 
I am currently using doom-emacs, and created a corresponding issue 
(https://github.com/hlissner/doom-emacs/issues/3123),
where I was told to report the issue upstream.
As hlissner mentioned in the above issue, it seems to be that the issue is the 
org-encrypt-string function expects epa-file-encrypt-to to be a string, but 
epa-file-encrypt-to's documentation says 'May either be a string or a list of 
strings.'. 
Doom-emacs sets it to a list of strings. 

Backtrace:

Debugger entered--Lisp error: (wrong-type-argument stringp stringp)
format-message(stringp)
apply(format-message stringp)
error(stringp)
org-encrypt-entry()
funcall-interactively(org-encrypt-entry)
call-interactively(org-encrypt-entry record nil)
command-execute(org-encrypt-entry record)
counsel-M-x-action("org-encrypt-entry")
ivy-call()
ivy-read("M-x " ("org-encrypt-entry" "doom/toggle-debug-mode" 
"org-encrypt-entries" "org-decrypt-entry" "cd" "5x5" "amx" "arp" "dbx" "dig" 
"erc" "ert" "eww" "ftp" "gdb" "irc" "jdb" "man" "mpc" "pdb" "pwd" "rsh" "sdb" 
"xdb" "calc" "deft" "diff" "dirs" "ffap" "gnus" "grep" "help" "ielm" "info" 
"life" "lsp!" "mail" "mpuz" "ping" "pong" "talk" "term" "undo" "yank" "zone" 
"align" "chmod" "debug" "diary" "dired" ...) :predicate #f(compiled-function 
(x) #) :require-match t :history counsel-M-x-history 
:action counsel-M-x-action :keymap (keymap (67108908 . 
counsel--info-lookup-symbol) (67108910 . counsel-find-symbol)) :initial-input 
nil :caller counsel-M-x)
counsel-M-x()
funcall-interactively(counsel-M-x)
call-interactively(counsel-M-x nil nil)
command-execute(counsel-M-x)

Emacs  : GNU Emacs 26.3 (build 1, x86_64-pc-linux-gnu, GTK+ Version 3.24.10)
 of 2019-08-30
Package: Org mode version 9.4 (nil @ 
/home/silipwn/.emacs.d/.local/straight/build/org-mode/)



Bug: issue with babel and sqlite [9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)]

2020-05-14 Thread rrandresf


Remember to cover the basics, that is, what you expected to happen and
what in fact did happen.  You don't know how to make a good report?  See

 https://orgmode.org/manual/Feedback.html#Feedback

Your bug report will be posted to the Org mailing list.

Hi. I am testing the pretest. And I have try the snippet below on emacs -Q

1. M-x find-file ~/borrame.org
2. cp content below to borrame.org buffer:
--8<---cut here---start->8---
* on a terminal on your HOME evalute (C-c C-c) the blocks below sequentially 
from top to bottom
#+BEGIN_SRC emacs-lisp
(when (fboundp 'org-babel-do-load-languages)
(org-babel-do-load-languages
 (quote org-babel-load-languages)
 (quote ((emacs-lisp . t)
 (sqlite . t)
 )))
)
(shell-command-to-string "sqlite3 ~/my_timelines.sqlite3 'CREATE TABLE IF NOT 
EXISTS time_lines (id INTEGER PRIMARY KEY AUTOINCREMENT NOT NULL, title 
varchar(255));'")
#+END_SRC

** this subtree works as expected
#+BEGIN_SRC sqlite :db ~/my_timelines.sqlite3 :colnames yes
INSERT INTO time_lines values(1, 'simple tiny note' );
#+END_SRC

#+BEGIN_SRC sqlite :db ~/my_timelines.sqlite3 :colnames yes
select * from time_lines;
#+END_SRC

** this subtree create three colums
#+BEGIN_SRC sqlite :db ~/my_timelines.sqlite3 :colnames yes
INSERT INTO time_lines values(2, 'an issue|problem with table rendering' );
#+END_SRC

#+BEGIN_SRC sqlite :db ~/my_timelines.sqlite3 :colnames yes
-- note the three colums on the table
select * from time_lines;
#+END_SRC

** this subtree generates an errro
#+BEGIN_SRC sqlite :db ~/my_timelines.sqlite3 :colnames yes
INSERT INTO time_lines values(3, '{
"id": 0
"value": 1
}');
#+END_SRC

#+BEGIN_SRC sqlite :db ~/my_timelines.sqlite3 :colnames yes
-- this generates an "org-babel-read: End of file during parsing" because of 
the inserted json
select * from time_lines;
#+END_SRC
--8<---cut here---end--->8---

Best

Emacs  : GNU Emacs 27.0.91 (build 1, armv7l-unknown-linux-gnueabihf, X toolkit, 
Xaw3d scroll bars)
Package: Org mode version 9.3 (release_9.3 @ /usr/share/emacs/27.0.91/lisp/org/)

current state:
==
(setq
 org-cycle-hook '(org-cycle-hide-archived-subtrees org-cycle-show-empty-lines
  org-optimize-window-after-visibility-change)
 org-archive-hook '(org-attach-archive-delete-maybe)
 org-agenda-before-write-hook '(org-agenda-add-entry-text)
 org-link-elisp-confirm-function 'yes-or-no-p
 org-babel-pre-tangle-hook '(save-buffer)
 org-occur-hook '(org-first-headline-recenter)
 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-speed-command-hook '(org-speed-command-activate
  org-babel-speed-command-activate)
 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-confirm-shell-link-function 'yes-or-no-p
 org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
 org-link-shell-confirm-function 'yes-or-no-p
 org-tab-first-hook '(org-babel-hide-result-toggle-maybe
  org-babel-header-arg-expand)
 org-link-parameters '(("attachment" :follow org-attach-open-link :export
org-attach-export-link :complete
org-attach-complete-link)
   ("id" :follow org-id-open)
   ("eww" :follow eww :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 

Re: [bug] error on RET in read-only buffer with org-return-follows-link set to t

2020-05-14 Thread Nicolas Goaziou
Hello,

Kévin Le Gouguec  writes:

> Shouldn't the call to org-return be wrapped in (call-interactively …)
> though?

Indeed. Done. Thank you.

Regards,

-- 
Nicolas Goaziou



RE: [Bug] org-store-link should not insert a document level ID property

2020-05-14 Thread Gustav Wikström
Hi,

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 14 maj 2020 23:21
> To: Gustav Wikström 
> Cc: Matthew Lundin ; Org Mode List 
> Subject: Re: [Bug] org-store-link should not insert a document level ID
> property
> 
> [...]
> 
> Regenerating ".org-id-locations" is not magical. It looks into
> a predefined set of files. If the renaming moves the file out of this
> set, there is no way it can associate again the ID to that file.

The same argument could be made for ID on a heading, if that heading is refiled 
into a location outside of that predefined set of files.

> IOW, I wouldn't trust an ID more than a file name.

But I would. Not entirely unlikely for files to be renamed within my folders. 
Using ID's helps for that. Be it to a file or a heading. But of course, YMMW.

Kind regards
Gustav



Re: [bug] error on RET in read-only buffer with org-return-follows-link set to t

2020-05-14 Thread Kévin Le Gouguec
Nicolas Goaziou  writes:

> Hello,
>
> Gregor Zattler  writes:
>
>> with `org-return-follows-link` set to `t` in a read-only
>> buffer I now get a `Buffer is read-only: #> notmuch-startpage.org>` error when pressing ENTER/RETURN
>> with point on an org-mode link.
>
> Fixed. Thank you.

Thanks for fixing this Nicolas, and for adding a unit test.

Shouldn't the call to org-return be wrapped in (call-interactively …)
though?  Since the problem was with the interactive spec, org-return
will work (i.e. follow links) in read-only buffers if called
programmatically, so the test will fail to catch a regression if I'm not
mistaken.

IOW: if I revert the fix, the new test still passes.



Re: [bug] error on RET in read-only buffer with org-return-follows-link set to t

2020-05-14 Thread Kévin Le Gouguec
Gregor Zattler  writes:

> Dear Kévin, org-mode developers, 
>
> with `org-return-follows-link` set to `t` in a read-only
> buffer I now get a `Buffer is read-only: # notmuch-startpage.org>` error when pressing ENTER/RETURN
> with point on an org-mode link.

Oh, right, I added '*' to org-return's interactive spec because I was
mimicking newline's; I had not considered the link-following case.

Should be a simple matter of removing this '*' if I'm not mistaken:

diff --git a/lisp/org.el b/lisp/org.el
index be1d1c701..339418314 100644
--- a/lisp/org.el
+++ b/lisp/org.el
@@ -17702,7 +17702,7 @@ a timestamp or a link, call `org-open-at-point'.  However, it
 will not happen if point is in a table or on a \"dead\"
 object (e.g., within a comment).  In these case, you need to use
 `org-open-at-point' directly."
-  (interactive "*i\nP\np")
+  (interactive "i\nP\np")
   (let ((context (if org-return-follows-link (org-element-context)
 		   (org-element-at-point
 (cond

> I use this dozens of times a day and it would be convenient
> if it was possible to resurrect the old behaviour.

Right, terribly sorry for this blunder.  I'll try to followup with a
unit test to make sure such a regression doesn't creep in again.


Re: [bug] error on RET in read-only buffer with org-return-follows-link set to t

2020-05-14 Thread Nicolas Goaziou
Hello,

Gregor Zattler  writes:

> with `org-return-follows-link` set to `t` in a read-only
> buffer I now get a `Buffer is read-only: # notmuch-startpage.org>` error when pressing ENTER/RETURN
> with point on an org-mode link.

Fixed. Thank you.

Regards,

-- 
Nicolas Goaziou



Re: [Bug] org-store-link should not insert a document level ID property

2020-05-14 Thread Nicolas Goaziou
Hello,

Gustav Wikström  writes:

> I see some purposes. They maybe aren't for everyone, but they surely are 
> there. 
> 1) Attachments for the whole file without setting the DIR property.

OK. This makes sense, thank you.

> 2) Link targets, making the file name irrelevant for the links.

Again, the file name is relevant, so using id links instead of file
links in this situation doesn't buy us anything.

>> IIUC, currently, renaming the file breaks the association between the ID
>> and the file name. IOW, the ID is useless if you rename the file.
>
> As long as org-id-track-globally isn't set to nil I don't think what
> you write is true. And even if renaming the file would break the link
> it's just momentarily since regenerating the .org-id-locations file
> should make the link work again.

Regenerating ".org-id-locations" is not magical. It looks into
a predefined set of files. If the renaming moves the file out of this
set, there is no way it can associate again the ID to that file.

IOW, I wouldn't trust an ID more than a file name.

Regards,

-- 
Nicolas Goaziou



[bug] error on RET in read-only buffer with org-return-follows-link set to t

2020-05-14 Thread Gregor Zattler
Dear Kévin, org-mode developers, 

with `org-return-follows-link` set to `t` in a read-only
buffer I now get a `Buffer is read-only: #` error when pressing ENTER/RETURN
with point on an org-mode link.

This used to work (opening the org-mode link) till

d3e6b58004997c5a9eeea82f96723c0f74480ab8 is the first bad commit
commit d3e6b58004997c5a9eeea82f96723c0f74480ab8
Author: Kévin Le Gouguec 
Date:   Tue May 5 19:01:07 2020 +0200

Make RET and C-j obey `electric-indent-mode'

* lisp/org-compat.el (org-return-indent): Deprecate this command.
* lisp/org-keys.el (org-mode-map): Rebind C-j to a command emulating
`electric-newline-and-maybe-indent'.
* lisp/org.el (org-cdlatex-environment-indent): Stop using the now
obsolete function.
(org--newline): New helper function.
(org-return): Use it to transparently handle `electric-indent-mode'.
(org-return-and-maybe-indent): New command to emulate
`electric-newline-and-maybe-indent' while taking care of Org special
cases (tables, links, timestamps).
* testing/lisp/test-org.el (test-org/with-electric-indent,
test-org/without-electric-indent): New tests.
* testing/org-test.el (org-test-with-minor-mode): New helper to set a
minor mode to a specific state, and reset it afterward.

:04 04 85f261b701133d4be047c1a2e8872b25f3e0c7e7 
21fe88d69e48ac3d24d233cbf07fe0084cde853e M  etc
:04 04 a677d2134361d2b023f252c188aebdeef9826896 
4bdbb34abe7eaad343932d33a03c823b2cae0e24 M  lisp
:04 04 9ecba96d2748f0e7ff5430ec0fcf8c175875621f 
f6e7b54445ac19d1b7c59d4d54bd9b4a19126245 M  testing


I use this dozens of times a day and it would be convenient
if it was possible to resurrect the old behaviour.


Thanks for your attention and for developing org-mode,
Gregor 
-- 
 -... --- .-. . -.. ..--.. ...-.-




RE: [Bug] org-store-link should not insert a document level ID property

2020-05-14 Thread Gustav Wikström
Hi Matt,

> -Original Message-
> From: Matthew Lundin 
> Sent: den 7 maj 2020 23:41
> To: Gustav Wikström ; Org Mode List 
> Subject: RE: [Bug] org-store-link should not insert a document level ID
> property
> 
> [...]
>
> What I was thinking of in terms of configuration is being able to
> preserve path-based links (instead of IDs) if creating a link above the
> first headline. This is the behavior that existed in the past when
> org-id-link-to-org-use-id was set to t or
> 'create-if-interactive-and-no-custom-id.
> 
> I've attached a patch that implements this. However, I also know that we
> are trying to avoid configuration/feature creep in Org, so I'm
> submitting this here for comments. Is this a configuration other people
> want?

This is a very specific customization. If it was to be implemented I would 
probably rename it a bit for its purpose to be more clear. My personal opinion 
of course. Name could be something in the line of 
"org-id-inhibit-id-before-first-heading" and make it clear in the docstring 
that the customization really only takes effect if org-id-link-to-org-use-id is 
not nil. That way one won't wonder as much about the interplay between the 
functions.

What say you? :)

Kind regards
Gustav


RE: [Bug] org-store-link should not insert a document level ID property

2020-05-14 Thread Gustav Wikström
Hi,

> -Original Message-
> From: Nicolas Goaziou 
> Sent: den 13 maj 2020 18:45
> To: Matthew Lundin 
> Cc: Gustav Wikström ; Org Mode List 
> Subject: Re: [Bug] org-store-link should not insert a document level ID
> property
> 
> Matthew Lundin  writes:
> 
> > Nicolas Goaziou  writes:
> >>
> >> AFAIK, ID is associated to a file name, and possibly a location in it.
> >> In this case, the ID is strictly equivalent to the file name, so why
> >> bother?
> >
> > I'm not sure I understand the question. Are you asking: Why bother
> > generating IDs at the top level of a file (which was the change Gustav
> > introduced)? Or why bother turning off that behavior? I can't address
> > the former question but I will address the latter.
> 
> Sorry for not being clear. This was the first question. I don't
> understand why we are generating an ID for the whole file.

I see some purposes. They maybe aren't for everyone, but they surely are there. 
1) Attachments for the whole file without setting the DIR property.
2) Link targets, making the file name irrelevant for the links.

> > The main reason is that I find these IDs redundant and visually
> > distracting. I can see how file IDs would be useful if one is
> > constantly renaming files (or perhaps writing custom functions that
> > convert files to entries and vice versa).
> 
> IIUC, currently, renaming the file breaks the association between the ID
> and the file name. IOW, the ID is useless if you rename the file.

As long as org-id-track-globally isn't set to nil I don't think what you write 
is true. And even if renaming the file would break the link it's just 
momentarily since regenerating the .org-id-locations file should make the link 
work again.

Regards
Gustav


Re: Setting org-export-headline-levels depending on export backend

2020-05-14 Thread Nicolas Goaziou
Hello,

Rafael  writes:

> I would like to have an org document export nicely (including some
> subtleties like theorems) to a latex document and to a beamer
> presentation. I have been mostly successful using filters, but it would
> help me a lot if there was some way to declare to use the #+option H:2
> when exporting to beamer, and H:3 when exporting to latex. Thoughts?

Is there anything wrong in using the filters for that?

You can also set-up a publishing environment, and use different default
options.

As a side-note, I invite you to share your set-up, here, or on Worg, as
it sounds interesting.

Regards,

-- 
Nicolas Goaziou



[PATCH] Add margin option to float for figure in ox-latex.el

2020-05-14 Thread Pablo Palazon
Hi everyone!.

I've created a path to add a new option to float properties for figures on
latex. This is my first change for org-mode, and I don't really sure if
this is the correct way to do it.

This change add a new latex environment for showing figures in the margin.
It's useful when you are exporting to latex with tufte class.

Please see path files attached with my changes, and tell me what you think.

Thanks for you work on this.
From ccec09203159a46074cc38718b474a9720c6f30d Mon Sep 17 00:00:00 2001
From: Pablo Palazon 
Date: Thu, 14 May 2020 16:33:53 +0200
Subject: [PATCH 1/2] ox-latex.el: Add margin to float option for attr_latex in
 images

* lisp/ox-latex.el (org-latex--inline-image): Include margin option
to create marginfigure environment for figures. It's useful for tufte
latex class, where with this environment shows the figure in the margin.

TINYCHANGE
---
 lisp/ox-latex.el | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/lisp/ox-latex.el b/lisp/ox-latex.el
index 6535d59f8..4b9281e1a 100644
--- a/lisp/ox-latex.el
+++ b/lisp/ox-latex.el
@@ -2374,6 +2374,7 @@ used as a communication channel."
 		  (cond ((string= float "wrap") 'wrap)
 			((string= float "sideways") 'sideways)
 			((string= float "multicolumn") 'multicolumn)
+			((string= float "margin") 'marginfigure)
 			((and (plist-member attr :float) (not float)) 'nonfloat)
 			((or float
 			 (org-element-property :caption parent)
@@ -2494,6 +2495,15 @@ used as a communication channel."
 			(if center "\\centering" "")
 			comment-include image-code
 			(if caption-above-p "" caption)))
+  (`marginfigure (format "\\begin{marginfigure}%s
+%s%s
+%s%s
+%s\\end{marginfigure}"
+			placement
+			(if caption-above-p caption "")
+			(if center "\\centering" "")
+			comment-include image-code
+			(if caption-above-p "" caption)))
   (`figure (format "\\begin{figure}%s
 %s%s
 %s%s
-- 
2.26.2

From 01a6fb8b83f9f488d4c3224d5f58972d66f6b757 Mon Sep 17 00:00:00 2001
From: Pablo Palazon 
Date: Thu, 14 May 2020 16:55:19 +0200
Subject: [PATCH 2/2] ox-latex.el: Add documentation to margin option in float

* doc/org-manual.org: Add documentation
---
 doc/org-manual.org | 5 +
 1 file changed, 5 insertions(+)

diff --git a/doc/org-manual.org b/doc/org-manual.org
index a7bdbab5d..2e6882591 100644
--- a/doc/org-manual.org
+++ b/doc/org-manual.org
@@ -13561,6 +13561,11 @@ attribute to one of the following:
   For a new page with the image sideways, rotated ninety degrees, in
   a =sidewaysfigure= environment; overrides =:placement= setting.
 
+- =margin= ::
+
+  For use the =marginfigure= environment. This environment shows the imagen in
+  the margin
+
 - =nil= ::
 
   To avoid a =:float= even if using a caption.
-- 
2.26.2



Re: ‘org-test-with-temp-text’ fails weirdly

2020-05-14 Thread Nicolas Goaziou
Hello,

Göktuğ Kayaalp  writes:

> I was trying to have spurious indentation removed from Python source
> blocks before execution so that such blocks can be indented in Org mode
> buffers.

Removing indentation from Python blocks sounds like a bad idea. Do you
have an example demonstrating what you need?

> I think the cause is the modifications to the code blocks body (deletion
> of spurious indentation from an indented src block), but I’m not sure
> how exactly.
>
> This is weird because the in-buffer text doesn’t change.

Do you have a reproducer for this? Ideally, using Emacs Lisp instead of
Python.

> In any case I’m also proposing the attached patch as a new feature.
> Could start a new thread for it if necessary.

> +(defun org-babel-python--clean-spurious-indentation (body)
> +  (let* ((extra-indentation
> +   (save-match-data
> + (string-match "\\`\\([ \t]+\\)" body)
> + (match-string 1 body)))
> +  (xlen (length extra-indentation)))
> +(if (zerop xlen)
> + body
> +  (mapconcat
> +   (lambda (line) (if (<= (length line) xlen)
> +   line
> + (if (string= extra-indentation
> +  (substring line 0 xlen))
> + (substring line xlen)
> +   line)))
> +   (split-string body "\n")
> +   "\n"

I think `org-remove-indentation' does about the same. It does not
systematically use first line as reference, though.

Regards,

-- 
Nicolas Goaziou



Re: Customizable fixed indentation column

2020-05-14 Thread Nicolas Goaziou
Hello,

Panagiotis Vlantis  writes:

> This is my first time using the mailing list so please point out if
> I am going about this the wrong way.

Thank you for the patch.

> After searching a bit, I didn't find a way to specify a custom fixed
> indentation column in org sections; the current implementation
> automatically aligns content at the beginning of the line when
> `org-adapt-indentation' is set to nil, which I find somewhat
> restrictive (e.g., in this case, one should be careful when using
> lists beginning with '*' characters).

Starting list items with "*" is a terrible idea, indeed. However, it is
unlikely to break the document because list promotion commands handle
this case.

I'm not convinced the current implementation is restrictive. OOC, do you
know any text-related mode that allows indenting contents at any column?
Also please note that if your first line is indented, all indentation
below will follow.

> To that end, I modified the current implementation accordingly (and
> added some tests) in order to allow one to set the desired indentation
> column to something other than the 0th, where section contents will be
> aligned at if adaptive indentation is disabled.
>
> I don't know if others will find this feature useful but I'll go and
> include the patch here anyway. If you find this worth merging but
> should be modified somehow before that, I would be happy to do so.

Instead of creating a new variable, what about overloading
`org-adapt-indentation'? If it is a whole number, use it as indentation.
`nil' becomes an alias for 0.

WDYT?

Regards,

--
Nicolas Goaziou



Re: [RFC] Let Org Mode's completion support all Babel header arguments

2020-05-14 Thread Nicolas Goaziou
Hello,

stardiviner  writes:

> I attached the new patch.

Applied. Thank you.

Regards,

-- 
Nicolas Goaziou



Re: Bug - all org files open as if visibilty is set to "showeverything"

2020-05-14 Thread Charles Millar

Nicholas,
-- cut --


That is correct. It's been discussed in the list and Nicolas announced that it's
been merged into master on Tuesday. Look for the thread entitled

[RFC] Change default value for `org-startup-folded'?

It can also be found at 


C-h v org-startup-folded RET

You can get the previous default by setting it to t in your init file.



Thanks.

Before posting I searched the list and did not find the thread or, more 
likely, it was included in the search results and did not realize it.


Charlie