Typo in Org Manual

[Sebastian Miele]

In an example for Org table range references it says:

‘@2$1..@4$3’   six fields between these two fields (same as ‘A2..C4’)

However, it are nine fields instead of six.

Re: Nested quote blocks?

[Tim Visher]

Thanks for responding, Eric. :)

On Wed, Mar 4, 2020 at 2:28 AM Fraga, Eric  wrote:

> On Tuesday,  3 Mar 2020 at 12:57, Tim Visher wrote:
> > Is there a way to get nested quotes blocks to work?
>
> What is your actual goal?  That is, what you do mean by "to work"?  I
> ask because although, as Nicolas has said, you cannot do this directly
> with org, you can achieve some specific goals with special blocks and/or
> drawers.  For instance, if your goal were to export to LaTeX, this code
> would do the job:
>
> #+begin_src org
>   ,#+latex_header: \let\myquote\quote
>   ,* testing nested blocks
>   Joe said:
>
>   ,#+begin_quote
>   This is the outer block.
>
>   ,#+begin_myquote
>   and this is the inner block
>   ,#+end_myquote
>
>   followed by the outer block.
>   ,#+end_quote
>
>   and that is all folks.
> #+end_src
>

I can demonstrate my goal with Markdown like so
. If
you view the raw file

you
can see how the quote level nests and yet all of Markdown's markup is
rendered as well. Thus each block quoting 'level' is a fully functional
Markdown context.

IIUC, your solution should work but it's necessarily tied to specific
export backends, right? I would be happy if it could be made to work for
the HTML because that's often my intermediary form these days for getting
text out of Org into something others find less intimidating. :)

Re: [PATCH]: org-attach.el: Use `force' arg everywhere in `org-attach-delete-all'

[Tim Visher]

Hi Kyle,

Thanks for feedback!

--

>From 626bd68a324cd65ba697dc1ccafdeff5808fd4c0 Mon Sep 17 00:00:00 2001
From: Tim Visher 
Date: Tue, 3 Mar 2020 09:14:44 -0500
Subject: [PATCH] org-attach.el: Use `force' arg everywhere in
 `org-attach-delete-all'
MIME-Version: 1.0
Content-Type: text/plain; charset=UTF-8
Content-Transfer-Encoding: 8bit

* lisp/org-attach.el (org-attach-delete-all): Use `force' arg
throughout function.

`org-attach-delete-all` advertised a `force` option but passing it
only forced its way past the initial "Really remove all…" query.  This
was unexpected and not properly documented.

This extends the use of the `force` argument to the `delete-directory`
call and documents its meaning in the docstring.

TINYCHANGE
---
 lisp/org-attach.el | 9 +++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lisp/org-attach.el b/lisp/org-attach.el
index 429d69021..57d1360fc 100644
--- a/lisp/org-attach.el
+++ b/lisp/org-attach.el
@@ -574,13 +574,18 @@ The attachment is created as an Emacs buffer."
 (defun org-attach-delete-all (&optional force)
   "Delete all attachments from the current outline node.
 This actually deletes the entire attachment directory.
-A safer way is to open the directory in dired and delete from there."
+A safer way is to open the directory in dired and delete from there.
+
+With prefix argument FORCE, directory will be recursively deleted
+with no prompts."
   (interactive "P")
   (let ((attach-dir (org-attach-dir)))
 (when (and attach-dir
   (or force
   (yes-or-no-p "Really remove all attachments of this
entry? ")))
-  (delete-directory attach-dir (yes-or-no-p "Recursive?") t)
+  (delete-directory attach-dir
+   (or force (yes-or-no-p "Recursive?"))
+   t)
   (message "Attachment directory removed")
   (run-hook-with-args 'org-attach-after-change-hook attach-dir)
   (org-attach-untag
--
2.19.1


0001-org-attach.el-Use-force-arg-everywhere-in-org-attach.patch
Description: Binary data

Re: Bug or not a bug? dot expansion in ob-shell

[Nick Dokos]

Hi Tim,

Tim Cross  writes:

> It seems to me that two separate issues have been mixed up and causing
> some confusion here. However, I think it is actually quite simple once
> we consider the issues separately.
>
> Issue 1: Defining the meaning of :result value and :result output
> Issue 2: Specifying what the default :result setting would be i.e.
> :result without a value/output specifier.
>
> Issue 1 seems the most straight-forward to me
> - output :: Whatever goes to stdout/stderr
> - value :: whatever would be returned by the execution of the code. This
> might be a return value (i.e. for some shell commands) or the value
> returned by a function (including shell functions i.e. bash function) or
> the last command executed etc. Essentially, anything returned (including
> nil) by the block. STDOUT/STDERR is never a return value (though some
> languages may send output to STDOUT/STDERR as well as returning it, in
> which case it would also be in :return value).
>
> Note that I don't agree that the only 'useful' result from shell blocks
> is output. You might have a complex shell script which uses source
> blocks to define shell functions
> that return values which you use via oweb expansion to include in other
> blocks etc.s
>
> With this definition, essentially :result value is essentially anything
> except whatever is sent to stdout/stderr.
>
> Issue 2 is a little more difficult. It is likely that a 'standard'
> default for :result that is the same for all languages is not
> possible/desired. The default will likely be a combination of what seems
> most natural for that language and what is most common usage for the
> majority of users. It could be that for some languages, the default for
> :result should be :result output and for others it should be :result
> value.
>
> Personally, I care less about issue 2 than issue 1. In the worst case, I
> will need to change my header arguments for some blocks and that would
> be easily automated. Far more critical is that :result value and :result
> output are clear, unambiguous and consistent. Any proposal to change
> these meanings because of different uses cases in languages is a bad
> idea. Instead, changing the 'default' would be preferable. Having shell
> source blocks return STDOUT/STDERR output for :result value is IMO a bad
> idea. Having shell blocks default to :result output when only specifying
> :result while having other languages, like python or clojure default to
> :result value seems far more preferable (provided differences are
> clearly documented of course).
> ...

Thanks for the (very clear) write-up. I can only nod my head
in violent agreement :-)

-- 
Nick

"There are only two hard problems in computer science: cache
invalidation, naming things, and off-by-one errors." -Martin Fowler

Re: [PATCH] org-eldoc: Use eldoc-documentation-functions when available

[Kyle Meyer]

Thank you.  Applied in 7454d2018.

How do I diff the outputs of two blocks in org-babel?

[Vladimir Nikishkin]

Support I have two blocks:

#+name: block1
#+begin_src shell
cat <<'ADDTEXT4'
#!/bin/bash
echo "This script creates a new file"
var1=10
var3=50
((result=$var1*$var2))
echo "The result = $result"
ADDTEXT4
#+end_src

#+name: block2
#+begin_src shell
cat <<'ADDTEXT4'
#!/bin/bash
echo "This script creates a new file"
var1=10
var2=50
((result=$var1*$var2))
echo "The result = $result"
ADDTEXT4
#+end_src

The first one has a bug in it.

At the moment I am diffing them like this:

#+begin_src shell :results output code :wrap src patch
  output1=$(
  cat <>
  EOF
  )

  output2=$(
  cat <>
  EOF
  )
  diff -s -u <(echo "$output1") <(echo "$output2")
#+end_src

But this looks a bit too complicated.

Any better solution?

-- 
Yours sincerely, Vladimir Nikishkin

Re: Nested quote blocks?

[Fraga, Eric]

On Wednesday,  4 Mar 2020 at 12:57, Tim Visher wrote:
> Thanks for responding, Eric. :)

You're very welcome!

> IIUC, your solution should work but it's necessarily tied to specific
> export backends, right? 

It is partly but the general concept of using special blocks works for
HTML also.  You end up with code that looks like this:

,
| 
| 
| and this is the inner block
| 
| 
| 
`

which means you can customize its appearance using appropriate CSS code.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.3.6-354-g9d5880

[PATCH] Do not ignore org-odt-styles-file

[Eric Timmons]

:odt-styles-file was duplicated in ox-odt's org-export-define-backend
form. This lead to the org-odt-styles-file custom being completely ignored.
---
 lisp/ox-odt.el | 3 +--
 1 file changed, 1 insertion(+), 2 deletions(-)

diff --git a/lisp/ox-odt.el b/lisp/ox-odt.el
index 2723c60c9..d353a3a2e 100644
--- a/lisp/ox-odt.el
+++ b/lisp/ox-odt.el
@@ -96,7 +96,7 @@
  (if a (org-odt-export-to-odt t s v)
(org-open-file (org-odt-export-to-odt nil s v) 'system))
   :options-alist
-  '((:odt-styles-file "ODT_STYLES_FILE" nil nil t)
+  '((:odt-styles-file "ODT_STYLES_FILE" nil org-odt-styles-file t)
 (:description "DESCRIPTION" nil nil newline)
 (:keywords "KEYWORDS" nil nil space)
 (:subtitle "SUBTITLE" nil nil parse)
@@ -110,7 +110,6 @@
 (:odt-inline-formula-rules nil nil org-odt-inline-formula-rules)
 (:odt-inline-image-rules nil nil org-odt-inline-image-rules)
 (:odt-pixels-per-inch nil nil org-odt-pixels-per-inch)
-(:odt-styles-file nil nil org-odt-styles-file)
 (:odt-table-styles nil nil org-odt-table-styles)
 (:odt-use-date-fields nil nil org-odt-use-date-fields)
 ;; Redefine regular option.
-- 
2.25.1

Bug: org-html-export-to-html doesn't handle .gpg files properly [9.3.6 (9.3.6-17-g389288-elpa @ /home/adalricus/.emacs.d/elpa/org-20200224/)]

[Adalricus Ovicula]

Henlo,

- create a file called "test.org.gpg"
- run org-html-export-to-html

File gets exported as test.org.html, shouldn't it be test.html?

Emacs  : GNU Emacs 26.3 (build 1, x86_64-unknown-openbsd, GTK+ Version 2.24.32)
 of 2019-10-12
Package: Org mode version 9.3.6 (9.3.6-17-g389288-elpa @ 
/home/adalricus/.emacs.d/elpa/org-20200224/)


signature.asc
Description: PGP signature