Re: Folding headings which contain only blank lines

[Kyle Meyer]

Dmitrii Korobeinikov writes:

>> Any chance you could provide a minimal reproducer for
>> your original issue so I can check on my end?
>
> Certainly, save this:
>
> ---cut
> * empty heading
>
>
>
> * another one
>
>
>
> ---cut end---
[...]
> Problem is: after unfolding "empty heading" you can't fold it back
> (barring the use of org-shifttab). One comorbid issue here, btw, is
> that "another one" isn't folded initially at all...

Thanks.  Okay, that matches closely the test case I tried in
.  As was the case
there, I can trigger the issue you reported both before and after
ee3c3b554.

So, given ee3c3b554 doesn't appear to resolve the initial issue and
introduces its own, I'm in favor of reverting ee3c3b554.  I'll plan to
do so in a day or two if I don't hear objections.

Re: LaTeX Headers not in partial export

[Michael Gauland]

On 25/10/20 3:45 pm, Kyle Meyer wrote:
> Michael Gauland writes:
>
>> --start of file--
>>
>> #+LATEX: \setminted{frame=single,framerule=1pt}
>>
>>
>> * Section
>>   #+begin_src sh :exports code
>>   echo "This is a code block
>>   #+end_src
>>
>> --end of file--
>>
>>
>> When I export the file to LaTeX, this line is inclued after
>> \begin{document}:
>>
>> \setminted{frame=single,framerule=1pt}
>>
>> When I export only the section--either by selecting it explicitly, or by
>> adding a "export" tag, that line is missing.
> Should that be #+LATEX_HEADER: instead of #+LATEX:?

Yes--that fixes it. Thanks for spotting that.

Re: LaTeX Headers not in partial export

[Kyle Meyer]

Michael Gauland writes:

> --start of file--
>
> #+LATEX: \setminted{frame=single,framerule=1pt}
>
>
> * Section
>   #+begin_src sh :exports code
>   echo "This is a code block
>   #+end_src
>
> --end of file--
>
>
> When I export the file to LaTeX, this line is inclued after
> \begin{document}:
>
> \setminted{frame=single,framerule=1pt}
>
> When I export only the section--either by selecting it explicitly, or by
> adding a "export" tag, that line is missing.

Should that be #+LATEX_HEADER: instead of #+LATEX:?

Re: [PATCH] ob-java

[Kyle Meyer]

ian martins writes:

> After making the changes, should I submit updated patches or is it fine to
> push?

Push away.  Thanks again.

Re: LaTeX Headers not in partial export

[Michael Gauland]

On 24/10/20 4:00 am, Eric S Fraga wrote:
> On Friday, 23 Oct 2020 at 15:22, Mike Gauland wrote:
>> I have a number of #+LATEX directives at the top of my org file, for
>> configuring the minted package.
> Could you maybe post a minimal example?
>
This file demonstrates the problem, at least on my systems:

--start of file--

#+LATEX: \setminted{frame=single,framerule=1pt}


* Section
  #+begin_src sh :exports code
  echo "This is a code block
  #+end_src

--end of file--


When I export the file to LaTeX, this line is inclued after
\begin{document}:

\setminted{frame=single,framerule=1pt}

When I export only the section--either by selecting it explicitly, or by
adding a "export" tag, that line is missing.

Re: [PATCH] ob-java

[ian martins]

Thanks for the feedback. In general, the changes are all intended to be
backwards compatible. Thanks for pointing out changes that weren't.

After making the changes, should I submit updated patches or is it fine to
push?

On Sat, Oct 24, 2020 at 1:05 PM Kyle Meyer  wrote:

> Hi ian,
>
> ian martins writes:
>
> >> * Changes
> >>
> >> - support for functional mode (~:results value~)
> >> - accept variables
> >> - don't require package, class, and main definitions
> >> - write source and result tempfiles to ~org-babel-temporary-directory~,
> >> but respects the ~:dir~ header
> >> - work with tramp
>
> Thanks for all the work you've put into this.  As someone that knows
> nothing about Java and hasn't touched ob-java, that sounds good :)
>
> I see this got a "feel free to install" elsewhere in this thread, so
> here are a few scattered and superficial remarks.
>
> > Subject: [PATCH] ob-java.el: Add support for variables, return values,
> tramp
> >
> > * lisp/ob-java.el: Add support for variables and return values.  Write
> > tempfiles to the org-babel-temporary-directory.  Make package, class,
> > and main method definitions optional.
> >
> > * testing/lisp/test-ob-java.el: Add tests.
>
> I think the changelog entry should technically have
> per-function/variable entries.
>
> More importantly from my perspective, it would be great for the message
> to explain what the current state is, why it is problematic, and what
> the patch's solution is.  For this patch, that'd probably be much too
> large, which is a good indication that it'd be better presented as a
> split up series.  But, at this point, that's not something I think you
> should do for this patch, especially given there doesn't seem to be a
> java/ob-java user with the bandwidth to provide a detailed review.
>
> > -(defcustom org-babel-java-command "java"
> > -  "Name of the java command.
> > -May be either a command in the path, like java
> > -or an absolute path name, like /usr/local/bin/java
> > -parameters may be used, like java -verbose"
> > +(defvar org-babel-default-header-args:java '()
> > +  "Default header args for java source blocks.")
> > +
> > +(defconst org-babel-header-args:java '((imports . :any))
> > +  "Java-specific header arguments.")
> > +
> > +(defvar org-babel-java-compiler-command "javac"
> > +  "Name of the command to execute the java compiler.")
> > +
> > +(defvar org-babel-java-runtime-command "java"
> > +  "Name of the command to run the java runtime.")
>
> Rather than dropping org-babel-java-command and org-babel-java-compiler
> entirely, can you make this change in a way that doesn't break for users
> that have already customized org-babel-java-command?
>
> Also, shouldn't org-babel-java-compiler-command and
> org-babel-java-runtime-command be user options rather than defvars?
>
> In general, are the changes here expected to be backwards compatible for
> current ob-java users?
>
> > +(defcustom org-babel-java-hline-to "null"
> > +  "Replace hlines in incoming tables with this when translating to
> java."
> >:group 'org-babel
> > -  :version "24.3"
> > +  :version "25.2"
> > +  :package-version '(Org . "9.3")
> >:type 'string)
> >
> > -(defcustom org-babel-java-compiler "javac"
> > -  "Name of the java compiler.
> > -May be either a command in the path, like javac
> > -or an absolute path name, like /usr/local/bin/javac
> > -parameters may be used, like javac -verbose"
> > +(defcustom org-babel-java-null-to 'hline
> > +  "Replace `null' in java tables with this before returning."
> >:group 'org-babel
> > -  :version "24.3"
> > -  :type 'string)
> > +  :version "25.2"
> > +  :package-version '(Org . "9.3")
> > +  :type 'symbol)
>
> For both these options, s/9.3/9.5/.  And please drop :version, letting
> it be handled by customize-package-emacs-version-alist.
>
> >  (defun org-babel-execute:java (body params)
> > -  (let* ((classname (or (cdr (assq :classname params))
> > - (error
> > -  "Can't compile a java block without a
> classname")))
> > -  (packagename (file-name-directory classname))
> > -  (src-file (concat classname ".java"))
> > +  "Execute a java source block with BODY code and PARAMS params."
> > +  (let* (;; if true, run from babel temp directory
> > + (run-from-temp (not (assq :dir params)))
> > + ;; class and package
> > + (fullclassname (or (cdr (assq :classname params))
> > +(org-babel-java-find-classname body)))
> > + ;; just the class name
> > + (classname (car (last (split-string fullclassname "\\."
> > + ;; just the package name
> > + (packagename (if (seq-contains fullclassname ?.)
>
> Please avoid seq- for compatibility with older versions of Emacs.
>
> > +(defun org-babel-java-evaluate (cmd result-type result-params
> result-file)
> > +  "Evaluate using an external java process.
> > +CMD the command to execute.
> > +
> > +If RESULT-TYPE equals 'output 

Re: [PATCH] ob-ruby.el: allow specification of ruby command w/header arg

[Aaron Madlon-Kay]

Brilliant! Thanks very much!

-Aaron


On Sat, Oct 24, 2020 at 20:39 Bastien  wrote:

> Hi Aaron,
>
> Aaron Madlon-Kay > writes:
>
> >   Using the :ruby header arg.
>
> Applied, thanks!
>
> --
>  Bastien
>

Re: Starting from 9.5, Org contrib will be distributed as a separate Org ELPA package

[stardiviner]

Bastien  writes:

> Hi all,
>
> "Org contrib" refers to the list of Emacs lisp files that you find
> in the contrib/ directory of Org's repository:
>
> https://code.orgmode.org/bzg/org-mode/src/master/contrib
>
> The idea of this directory was to have a place where to promote Org
> packages even if they are not part of Org's core (ie the files that go
> into Emacs core.)  It was also useful as a place to welcome packages
> from authors who don't sign the FSF copyright assignment.
>
> Both reasons are kind of obsolete nowadays: many, if not most useful
> Org contributions are published elsewhere.  Also, mixing authors who
> signed the FSF assignment and those who don't is never a good idea
> for a repo, even if the contributions happen in separate spaces.
>
> Org 9.5 will ship without the packages in the contrib/ directory.
>
> Emacs lisp files in contrib/ will be packaged as an Org ELPA package
> that you can install independentely from there.  The files will live
> in a new org-contrib.git repo on code.orgmode.org.
>
> In the long run, every Emacs file in org-contrib.git need to find a
> proper maintainer (who will decide where to maintain it) or to be
> listed in the list of Emacs orphan packages.
>
> If you use Org contrib/ files from git, you will have to clone a 
> new repository when the split is done, within the next weeks.
>
> If you use org-plus-contrib, you don't have anything to do before 
> Org 9.5 is released.  When it is, you will have add Org ELPA to
> your configuration and install org-contrib from there.
>
> If you have any question on this, please let me know!
>
> Best,

I agree with this solution. This is good idea. It will keep maintaining and
debugging Org Mode simpler.

Even though I just use local Git source code for Org Mode. (So don't need to
modify my config at all.)

-- 
[ stardiviner ]
   I try to make every word tell the meaning that I want to express.

   Blog: https://stardiviner.github.io/
   IRC(freenode): stardiviner, Matrix: stardiviner
   GPG: F09F650D7D674819892591401B5DF1C95AE89AC3

Re: [PATCH] ob-java

[ian martins]

This happened because the new ob-java wasn't based on the old ob-java. I
wrote ob-haxe based on ob-C and ob-python and then derived ob-java from
ob-haxe.  I went back and forth about who should be the author of ob-haxe.
I considered listing the authors of ob-C and ob-python, but I thought it
wouldn't make sense since they may not have heard of haxe, and they may not
like my code or want their names on it. I didn't really think about the
author of the new ob-java, since it came directly from ob-haxe.

But I want to follow your conventions. I will put the authors of ob-C and
ob-python (Eric Schulte and Dan Davison) as the authors of ob-java and
ob-haxe. The implementations are nearly the same. it wouldn't make sense
for them to have different authors.

On Sat, Oct 24, 2020 at 7:58 AM Bastien  wrote:

> Hi Ian,
>
> feel free to install the patch when you think it's ready.
>
> One minor nitpick:
>
> -;; Author: Eric Schulte
> -;; Maintainer: Ian Martins 
> +;; Author: Ian Martins 
>
> I suggest you leave Eric Schulte as the author while adding yourself
> as the maintainer, even if the "change" is a big rewrite.
>
> Thanks,
>
> --
>  Bastien
>

Re: official orgmode parser

[Tom Gillespie]

> which Ruby org-mode parser does Github use?

I'm pretty sure that github uses https://github.com/wallyqs/org-ruby.
It is ... not compliant, shall we say. I have making some fixes to the
footnote parsing section on my todo list, but I don't expect to get to
it any time in the near future.

Tom

Re: official orgmode parser

[Daniele Nicolodi]

On 23/09/2020 10:09, Bastien wrote:
> I disagree that a parser is too difficult to maintain because Org is 
> a moving target.  Org core syntax is not moving anymore, a parser can
> reasonably target it.  That's what is done with the Ruby parser, in
> use in this small project called github.com :)

(Just an aside: which Ruby org-mode parser does Github use? I sometime
find instances where Github does not render an org-mode file correclty
and I would be happy to file bugs to have them corrected).

> So I'd say:
> 
> - let's enhance Worg's documentation
> - yes, please go for enhancing parsing tools
> 
> I don't think we need official tools.  The official Org parser exists,
> it is Org itself.

Would it make sense to have one "official" (or a set of) org-mode test
files and the corresponding syntax tree as parsed by org-elements (maybe
in a format easier to read from other programming languages than
s-expressions, json maybe?) to make testing other parser against the
reference implementation easier?

Maybe the org-mode test suite already has something like this. I haven't
looked for it yet.

Cheers,
Dan

Re: [PATCH] org-plot abstractions and extension

[TEC]

Bastien  writes:


I'm not an org-plot.el user so I cannot test, but by reading the
patches, they look okay.

Let's go in "optimistic merging" mode and commit your patches?


Sounds good then. I don't expect the changes to compromise any 
existing

functionality.


Is https://orgmode.org/list/87lfhbhfhe@gmail.com/ the latest
version I should use?


I've smoothed a rough edge or two, and added a documentation 
entry.


I'll attach all the patches to this email, so there's no 
ambiguity.

(crosses fingers for attachments working as expected)

--
Timothy

>From 3743e507775b446f5f8188958c20f65861fac3fb Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 8 Jul 2020 18:34:46 +0800
Subject: [PATCH 01/15] org-plot.el: make indentation method consistent

* lisp/org-plot.el (org-plot/gnuplot): Make indentation consistent, by
replacing a few spaces with tabs.

Only 6 of 347 lines used spaces instead of tabs.
---
 lisp/org-plot.el | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index 0ff96af67..c08bc144e 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -325,12 +325,12 @@ line directly before or after the table."
   (with-temp-buffer
 	(if (plist-get params :script)	; user script
 	(progn (insert
-(org-plot/gnuplot-script data-file num-cols params t))
-   (insert "\n")
-   (insert-file-contents (plist-get params :script))
-   (goto-char (point-min))
-   (while (re-search-forward "\\$datafile" nil t)
- (replace-match data-file nil nil)))
+		(org-plot/gnuplot-script data-file num-cols params t))
+		   (insert "\n")
+		   (insert-file-contents (plist-get params :script))
+		   (goto-char (point-min))
+		   (while (re-search-forward "\\$datafile" nil t)
+		 (replace-match data-file nil nil)))
 	  (insert (org-plot/gnuplot-script data-file num-cols params)))
 	;; Graph table.
 	(gnuplot-mode)
-- 
2.28.0

>From c62e817b04dfbe624ee8b2090ebcde257bbd3f23 Mon Sep 17 00:00:00 2001
From: TEC 
Date: Wed, 8 Jul 2020 19:26:07 +0800
Subject: [PATCH 02/15] org-plot.el: add new option :transpose

* lisp/org-plot.el (org-plot/add-options-to-plist,
org-plot/add-options-to-plist): Add a new option :transpose, and a
shorter alias :trans. Transposition is performed if the argument is yes,
y, or t.  This treats the table as a matrix and performs matrix
transposition on it.  If an hline is present, it is assumed that it is a
marks a separation from a first header row.  The first row is then
treated as the new header by inserting a hline in the transposed data.
This is quite useful for some plots, where across multiple categories,
there are a large number of data points.  Without this, the data points
would be columns and the table can spread irritatingly wide.
---
 lisp/org-plot.el | 44 +---
 1 file changed, 29 insertions(+), 15 deletions(-)

diff --git a/lisp/org-plot.el b/lisp/org-plot.el
index c08bc144e..6ff633130 100644
--- a/lisp/org-plot.el
+++ b/lisp/org-plot.el
@@ -50,19 +50,21 @@
   "Parse an OPTIONS line and set values in the property list P.
 Returns the resulting property list."
   (when options
-(let ((op '(("type". :plot-type)
-		("script"  . :script)
-		("line". :line)
-		("set" . :set)
-		("title"   . :title)
-		("ind" . :ind)
-		("deps". :deps)
-		("with". :with)
-		("file". :file)
-		("labels"  . :labels)
-		("map" . :map)
-		("timeind" . :timeind)
-		("timefmt" . :timefmt)))
+(let ((op '(("type"  . :plot-type)
+		("script". :script)
+		("line"  . :line)
+		("set"   . :set)
+		("title" . :title)
+		("ind"   . :ind)
+		("deps"  . :deps)
+		("with"  . :with)
+		("file"  . :file)
+		("labels". :labels)
+		("map"   . :map)
+		("timeind"   . :timeind)
+		("timefmt"   . :timefmt)
+		("trans" . :transpose)
+		("transpose" . :transpose)))
 	  (multiples '("set" "line"))
 	  (regexp ":\\([\"][^\"]+?[\"]\\|[(][^)]+?[)]\\|[^ \t\n\r;,.]*\\)")
 	  (start 0))
@@ -289,8 +291,20 @@ line directly before or after the table."
 	(setf params (plist-put params (car pair) (cdr pair)
 ;; collect table and table information
 (let* ((data-file (make-temp-file "org-plot"))
-	   (table (org-table-collapse-header (org-table-to-lisp)))
-	   (num-cols (length (car table
+	   (table (let ((tbl (org-table-to-lisp)))
+		(when (pcase (plist-get params :transpose)
+			('y   t)
+			('yes t)
+			('t   t))
+		  (if (memq 'hline tbl)
+			  (setq tbl (apply #'cl-mapcar #'list tbl))
+			;; When present, remove hlines as they can't (currentily) be easily transposed.
+			(setq tbl (apply #'cl-mapcar #'list
+	 (remove 'hline tbl)))
+			(push 'hline (cdr tbl
+		tbl))
+	   (num-cols (length (if (eq (nth 0 table) 'hline) (nth 1 table)
+			   (nth 0 table)
   (run-with-idle-timer 0.1 nil 

Re: [PATCH] ob-java

[Kyle Meyer]

Hi ian,

ian martins writes:

>> * Changes
>>
>> - support for functional mode (~:results value~)
>> - accept variables
>> - don't require package, class, and main definitions
>> - write source and result tempfiles to ~org-babel-temporary-directory~,
>> but respects the ~:dir~ header
>> - work with tramp

Thanks for all the work you've put into this.  As someone that knows
nothing about Java and hasn't touched ob-java, that sounds good :)

I see this got a "feel free to install" elsewhere in this thread, so
here are a few scattered and superficial remarks.

> Subject: [PATCH] ob-java.el: Add support for variables, return values, tramp
>
> * lisp/ob-java.el: Add support for variables and return values.  Write
> tempfiles to the org-babel-temporary-directory.  Make package, class,
> and main method definitions optional.
>
> * testing/lisp/test-ob-java.el: Add tests.

I think the changelog entry should technically have
per-function/variable entries.

More importantly from my perspective, it would be great for the message
to explain what the current state is, why it is problematic, and what
the patch's solution is.  For this patch, that'd probably be much too
large, which is a good indication that it'd be better presented as a
split up series.  But, at this point, that's not something I think you
should do for this patch, especially given there doesn't seem to be a
java/ob-java user with the bandwidth to provide a detailed review.

> -(defcustom org-babel-java-command "java"
> -  "Name of the java command.
> -May be either a command in the path, like java
> -or an absolute path name, like /usr/local/bin/java
> -parameters may be used, like java -verbose"
> +(defvar org-babel-default-header-args:java '()
> +  "Default header args for java source blocks.")
> +
> +(defconst org-babel-header-args:java '((imports . :any))
> +  "Java-specific header arguments.")
> +
> +(defvar org-babel-java-compiler-command "javac"
> +  "Name of the command to execute the java compiler.")
> +
> +(defvar org-babel-java-runtime-command "java"
> +  "Name of the command to run the java runtime.")

Rather than dropping org-babel-java-command and org-babel-java-compiler
entirely, can you make this change in a way that doesn't break for users
that have already customized org-babel-java-command?

Also, shouldn't org-babel-java-compiler-command and
org-babel-java-runtime-command be user options rather than defvars?

In general, are the changes here expected to be backwards compatible for
current ob-java users?

> +(defcustom org-babel-java-hline-to "null"
> +  "Replace hlines in incoming tables with this when translating to java."
>:group 'org-babel
> -  :version "24.3"
> +  :version "25.2"
> +  :package-version '(Org . "9.3")
>:type 'string)
>  
> -(defcustom org-babel-java-compiler "javac"
> -  "Name of the java compiler.
> -May be either a command in the path, like javac
> -or an absolute path name, like /usr/local/bin/javac
> -parameters may be used, like javac -verbose"
> +(defcustom org-babel-java-null-to 'hline
> +  "Replace `null' in java tables with this before returning."
>:group 'org-babel
> -  :version "24.3"
> -  :type 'string)
> +  :version "25.2"
> +  :package-version '(Org . "9.3")
> +  :type 'symbol)

For both these options, s/9.3/9.5/.  And please drop :version, letting
it be handled by customize-package-emacs-version-alist.

>  (defun org-babel-execute:java (body params)
> -  (let* ((classname (or (cdr (assq :classname params))
> - (error
> -  "Can't compile a java block without a classname")))
> -  (packagename (file-name-directory classname))
> -  (src-file (concat classname ".java"))
> +  "Execute a java source block with BODY code and PARAMS params."
> +  (let* (;; if true, run from babel temp directory
> + (run-from-temp (not (assq :dir params)))
> + ;; class and package
> + (fullclassname (or (cdr (assq :classname params))
> +(org-babel-java-find-classname body)))
> + ;; just the class name
> + (classname (car (last (split-string fullclassname "\\."
> + ;; just the package name
> + (packagename (if (seq-contains fullclassname ?.)

Please avoid seq- for compatibility with older versions of Emacs.

> +(defun org-babel-java-evaluate (cmd result-type result-params result-file)
> +  "Evaluate using an external java process.
> +CMD the command to execute.
> +
> +If RESULT-TYPE equals 'output then return standard output as a
> +string.  If RESULT-TYPE equals 'value then return the value
> +returned by the source block, as elisp.
> +
> +RESULT-PARAMS input params used to format the reponse.
> +
> +RESULT-FILE filename of the tempfile to store the returned value in
> +for 'value RESULT-TYPE.  Not used for 'output RESULT-TYPE."

Convention nit: Prefer `symbol' to 'symbol (e.g., s/'output/`output'/).
I didn't check closely if this applies to other docstrings in this
patch.

> +  

Agenda buffer name after following a time stamp

[Garjola Dindi]

Hi,

Accidentally pressing  or  on an inactive time stamp in
an org mode buffer, I found myself in an agenda buffer with name "*Org
Agenda(a:2020-10-22)" corresponding to the agenda of the date of the
time stamp.

I understand that this is the expected behaviour (jumping to that date),
but I am puzzled by the buffer name. Most annoyingly, from this moment,
unless I restart emacs, most new agenda generations will create a buffer
with the same name, that is "*Org Agenda(a:2020-10-22)" in my example
independently of the date for which the agenda is generated.

Steps to reproduce:

1. Press  on [2020-10-22 Thu]. This generates the agenda for
   that date in a buffer named "*Org Agenda(a:2020-10-22)"
2. Close the agenda with "q" or "x"
3. invoke the org-agenda dispatcher, choose t (or any other view except
   "a"). This generates a buffer named "*Org Agenda(a:2020-10-22)"
   instead of "*Org Agenda*".

Using the interactive commands org-todo-list has the same behaviour.

However, using "a" in the agenda dispatcher or calling org-agenda-list
generates a buffer correctly called  "*Org Agenda*".

I have tried with "emacs -q" and the behaviour is the same.

Is this an expected behaviour? I have not been able to find the
information in the manual.

Thank you.

G.
- 

Re: [PATCH] babel latex headers and image generation commands

[Matt Huszagh]

Bastien  writes:

> sorry for the delayed answer.

No worries!

> Can you provide a patch against etc/ORG-NEWS announce this?

Attached. Let me know what you think.

Matt

>From 51fb3ef9843ae45884803142f150c5d2f4f4d4c9 Mon Sep 17 00:00:00 2001
From: Matt Huszagh 
Date: Sat, 24 Oct 2020 09:36:56 -0700
Subject: [PATCH] etc/ORG-NEWS: Describe new behavior of babel LaTeX SVG images

---
 etc/ORG-NEWS | 22 ++
 1 file changed, 22 insertions(+)

diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
index 7f935bf52..b9b0c1271 100644
--- a/etc/ORG-NEWS
+++ b/etc/ORG-NEWS
@@ -35,6 +35,28 @@ omit a file description was to omit the header argument entirely,
 which made it difficult/impossible to provide a default value for
 =file-desc=.
 
+*** New behavior for babel LaTeX SVG image files
+
+Org babel now uses a two-stage process for converting latex source
+blocks to SVG image files (when the extension of the output file is
+~.svg~). The first stage in the process converts the latex block into
+a PDF file, which is then converted into an SVG file in the second
+stage. The TeX->PDF part uses the existing infrastructure for
+~org-babel-latex-tex-to-pdf~. The PDF->SVG part uses a command
+specified in a new customization,
+~org-babel-latex-pdf-svg-process~. By default, this uses inkscape for
+conversion, but since it is fully customizable, any other command can
+be used in its place. For instance, dvisvgm might be used here. This
+two-part processing replaces the previous use of htlatex to process
+LaTeX directly to SVG (htlatex is still used for HTML conversion).
+
+Conversion to SVG exposes a number of additional customizations that
+give the user full control over the contents of the latex source
+block. ~org-babel-latex-preamble~, ~org-babel-latex-begin-env~ and
+~org-babel-latex-end-env~ are new customization options added to allow
+the user to specify the preamble and code that preceedes and proceeds
+the contents of the source block.
+
 ** New features
 *** =ob-python= improvements to =:return= header argument 
 
-- 
2.28.0

Re: Folding headings which contain only blank lines

[Dmitrii Korobeinikov]

> Any chance you could provide a minimal reproducer for
> your original issue so I can check on my end?

Certainly, save this:

---cut
* empty heading



* another one



---cut end---

Now, when opening this file, you will see:

---cut
* empty heading...

* another one



---cut end---

(use shift-tab if fold on startup is disabled)

Problem is: after unfolding "empty heading" you can't fold it back
(barring the use of org-shifttab). One comorbid issue here, btw, is
that "another one" isn't folded initially at all...

сб, 24 окт. 2020 г. в 08:43, Kyle Meyer :
>
> Dmitrii Korobeinikov writes:
>
> >> was trying to find an example of the issue fixed by ee3c3b55.  Dmitrii,
> >> did ee3c3b55 solve the issue on you reported?
> >
> > Hi, Kyle, I haven't checked it, but since several people reported that
> > it wasn't working for them, I decided to forego the trouble of
> > installing it myself (I am using the stock org mode).
>
> Okay, thanks.  Any chance you could provide a minimal reproducer for
> your original issue so I can check on my end?  As I mentioned in the
> referenced thread [*], I haven't been able to figure out which case, if
> any, was resolved by ee3c3b55.
>
> [*] https://orgmode.org/list/87tuviqyi4@kyleam.com

Re: Starting from 9.5, Org contrib will be distributed as a separate Org ELPA package

[Colin Baxter]

Hello Bastien,
> Bastien   writes:

> Org 9.5 will ship without the packages in the contrib/ directory.

> Emacs lisp files in contrib/ will be packaged as an Org ELPA

Oh no! I hate packages and never use ELPA. :-(

> package that you can install independentely from there.  The files
> will live in a new org-contrib.git repo on code.orgmode.org.

Phew! Saved! Oh well, another git repo to add to the list. :-)

Best wishes,



Colin Baxter
URL: http://www.Colin-Baxter.com
-
GnuPG fingerprint: 68A8 799C 0230 16E7 BF68  2A27 BBFA 2492 91F5 41C8
-
Since mathematicians have invaded the theory of relativity, I do not
understand it myself. A. Einstein

Re: [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient

[Adam Spiers]

On Sat, Oct 24, 2020 at 01:36:05PM +0200, Bastien wrote: 
Hi Adam, 

this looks good to me, thanks a lot. 


Thanks for the review :-) 

Does "WIP" means that you want to wait for other patches to complete 
this one or shall I apply this one already? 


The intention is for it to be a standalone patch, so I don't think 
there's any need to wait for other patches.  The "WIP" was coming more 
from the fact that I haven't done extensive testing to make sure I 
didn't break a single one of the many sorting criteria - especially 
this one:


+('category-keep   (if (org-cmp-category a b) +1 nil)) ;; FIXME: check this

Ideally there would already be unit and/or functional tests covering 
agenda sorting, but I can't see any and I imagine they would be 
non-trivial to add (although perhaps not too difficult either). 

Also, the previous behaviour was to silently ignore 
user-defined-{up,down} if org-agenda-cmp-user-defined was not defined, 
but that intuitively felt wrong to me (IMHO it kind of violates the 
Principle of Least Surprise) so I didn't bother to preserve that 
behaviour.  However I admit that is a pretty subjective choice, so if 
you think the existing behaviour should be preserved, I can tweak the 
code to do that.  In fact, even if you agree with me that it would be 
better to generate an error when user-defined-{up,down} is used with 
org-agenda-cmp-user-defined being nil, I just noticed that it currently 
generates the very unhelpful error: 


org-entries-cmp-1: Symbol’s function definition is void: nil

so we would want to explicitly catch that case and generate a more 
helpful error message, e.g. "org-agenda-sorting-strategy contains 
user-defined sorting but org-agenda-cmp-user-defined is nil". 

BTW, as you can partially see from the below link, I did some 
performance profiling relating to this change and it did indeed seem 
to shave a few milliseconds off org-entries-lessp, although in the 
grand scheme of things, that didn't make as much of a dent in 
org-agenda's running time as I'd hoped for ;-) 



https://gist.github.com/trishume/40bf7045a23412d4c016f5e8533437db#gistcomment-3494087

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Palak Mathur]

> On Oct 24, 2020, at 10:40 AM, Bastien  wrote:
> 
> Palak Mathur  writes:
> 
>> Yes, it is going to be some work. I will try to get something
>> started and share a draft.
> 
> Can you and Leo work together on this ?
> 
> Perhaps you can share a first draft (from the user point of view) that
> Leo can consolidate (from a generic parser point of view) ?
> 

Sure! 

> Thanks to both for your help!
> 





> -- 
> Bastien

Starting from 9.5, Org contrib will be distributed as a separate Org ELPA package

[Bastien]

Hi all,

"Org contrib" refers to the list of Emacs lisp files that you find
in the contrib/ directory of Org's repository:

https://code.orgmode.org/bzg/org-mode/src/master/contrib

The idea of this directory was to have a place where to promote Org
packages even if they are not part of Org's core (ie the files that go
into Emacs core.)  It was also useful as a place to welcome packages
from authors who don't sign the FSF copyright assignment.

Both reasons are kind of obsolete nowadays: many, if not most useful
Org contributions are published elsewhere.  Also, mixing authors who
signed the FSF assignment and those who don't is never a good idea
for a repo, even if the contributions happen in separate spaces.

Org 9.5 will ship without the packages in the contrib/ directory.

Emacs lisp files in contrib/ will be packaged as an Org ELPA package
that you can install independentely from there.  The files will live
in a new org-contrib.git repo on code.orgmode.org.

In the long run, every Emacs file in org-contrib.git need to find a
proper maintainer (who will decide where to maintain it) or to be
listed in the list of Emacs orphan packages.

If you use Org contrib/ files from git, you will have to clone a 
new repository when the split is done, within the next weeks.

If you use org-plus-contrib, you don't have anything to do before 
Org 9.5 is released.  When it is, you will have add Org ELPA to
your configuration and install org-contrib from there.

If you have any question on this, please let me know!

Best,

-- 
 Bastien

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Bastien]

Palak Mathur  writes:

> Yes, it is going to be some work. I will try to get something
> started and share a draft.

Can you and Leo work together on this ?

Perhaps you can share a first draft (from the user point of view) that
Leo can consolidate (from a generic parser point of view) ?

Thanks to both for your help!

-- 
 Bastien

[PATCH] org-table: Add mode flag to enable Calc units simplification mode

[Daniele Nicolodi]

Hello,

attached there are a few patches reworking the parsing of org-table
formula mode strings and introducing a new mode flag to enable Calc's
units simplification mode as discussed in a recent thread on the mailing
list. I haven't updated the documentation. I can do it once we agree
that this feature is a good idea.

I have already submitted the patches in another thread
https://orgmode.org/list/6d8c15c2-d1b0-d913-df39-c60381cff...@grinta.net/T/#m03a426dd8476b60019dfffecb8781a2126df690f
but it seems that woof did not pick them up, thus I am re-sending them.

Cheers,
Dan
From c7434974897d932fe3acd182f06a98a61719e208 Mon Sep 17 00:00:00 2001
From: Daniele Nicolodi 
Date: Tue, 20 Oct 2020 11:03:14 +0200
Subject: [PATCH 1/4] org-table: Fix table formula mode string handling

* lisp/org-table.el (org-table-eval-formula): Move mode lookup table
from org-table--set-calc-mode to here.

* lisp/org-table.el (org-table--set-calc-mode): Use plist-put instead
of the buggy open coded version.
---
 lisp/org-table.el | 24 ++--
 1 file changed, 10 insertions(+), 14 deletions(-)

diff --git a/lisp/org-table.el b/lisp/org-table.el
index 112b1e171..0790dc3ca 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -721,17 +721,8 @@ Field is restored even in case of abnormal exit."
 (org-table-goto-column ,column)
 (set-marker ,line nil)
 
-(defsubst org-table--set-calc-mode (var  value)
-  (if (stringp var)
-  (setq var (assoc var '(("D" calc-angle-mode deg)
-("R" calc-angle-mode rad)
-("F" calc-prefer-frac t)
-("S" calc-symbolic-mode t)))
-   value (nth 2 var) var (nth 1 var)))
-  (if (memq var org-tbl-calc-modes)
-  (setcar (cdr (memq var org-tbl-calc-modes)) value)
-(cons var (cons value org-tbl-calc-modes)))
-  org-tbl-calc-modes)
+(defsubst org-table--set-calc-mode (var value)
+  (plist-put org-tbl-calc-modes var value))
 
 
 ;;; Predicates
@@ -2476,9 +2467,14 @@ location of point."
(setq keep-empty t
  fmt (replace-match "" t t fmt)))
(while (string-match "[DRFS]" fmt)
- (setq org-tbl-calc-modes
-   (org-table--set-calc-mode (match-string 0 fmt)))
- (setq fmt (replace-match "" t t fmt)))
+ (let* ((c (string-to-char (match-string 0 fmt)))
+(mode (cdr (assoc c '((?D calc-angle-mode deg)
+  (?R calc-angle-mode rad)
+  (?F calc-prefer-frac t)
+  (?S calc-symbolic-mode t))
+   (setq org-tbl-calc-modes (org-table--set-calc-mode
+ (car mode) (cadr mode))
+ fmt (replace-match "" t t fmt
(unless (string-match "\\S-" fmt)
  (setq fmt nil
   (when (and (not suppress-const) org-table-formula-use-constants)
-- 
2.28.0

From fb8b62e5faabca2b6c6514e25bd306f7a5e8696f Mon Sep 17 00:00:00 2001
From: Daniele Nicolodi 
Date: Tue, 20 Oct 2020 15:13:40 +0200
Subject: [PATCH 2/4] org-table: Simplify mode string parsing

* org-table.el (org-table-eval-formula): Simplify mode string parsing
and reduce scope of local variables.
---
 lisp/org-table.el | 98 +--
 1 file changed, 43 insertions(+), 55 deletions(-)

diff --git a/lisp/org-table.el b/lisp/org-table.el
index 0790dc3ca..4baad2600 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -722,7 +722,7 @@ Field is restored even in case of abnormal exit."
 (set-marker ,line nil)
 
 (defsubst org-table--set-calc-mode (var value)
-  (plist-put org-tbl-calc-modes var value))
+  (setq org-tbl-calc-modes (plist-put org-tbl-calc-modes var value)))
 
 
 ;;; Predicates
@@ -2427,54 +2427,42 @@ location of point."
   (org-tbl-calc-modes (copy-sequence org-calc-default-modes))
   (numbers nil)   ; was a variable, now fixed default
   (keep-empty nil)
-  n form form0 formrpl formrg bw fmt x ev orig c lispp literal
+  form form0 formrpl formrg bw fmt ev orig lispp literal
   duration duration-output-format)
   ;; Parse the format string.  Since we have a lot of modes, this is
   ;; a lot of work.  However, I think calc still uses most of the time.
-  (if (string-match ";" formula)
- (let ((tmp (org-split-string formula ";")))
-   (setq formula (car tmp)
- fmt (concat (cdr (assoc "%" org-table-local-parameters))
- (nth 1 tmp)))
+  (if (string-match "\\(.*\\);\\(.*\\)" formula)
+ (progn
+   (setq fmt (concat (match-string-no-properties 2 formula)
+ (cdr (assoc "%" org-table-local-parameters)))
+ formula (match-string-no-properties 1 formula))
(while 

Re: org-table-sum

[Jeremie Juste]

Hello,

I have slightly improved the org-table-sum function.
It calls directly calc-eval and yield the same result as vsum.

It can not handle better floating points.
> | 171.00 |
> |   4.07 |
> |   4.44 |
> |   2.61 |
> |  12.21 |
> |   6.69 |
> |  19.72 |
> |  23.09 |
> |   6.23 |
> |  15.28 |
> | 250.00 |
> | 250.00 |
> | 250.00 |
> |  78.85 |
> ||
> ||
> #+TBLFM:@>$1=vsum(@1$1..@-1$1)


diff --git a/lisp/org-table.el b/lisp/org-table.el
index a3c49874c..ac237af2c 100644
--- a/lisp/org-table.el
+++ b/lisp/org-table.el
@@ -4728,6 +4728,18 @@ blank, and the content is appended to the field above."
  ((equal n 0) nil)
  (t n
 
+
+(defun org-table-cell-no-prop (x)
+  "remove property from org-table-cell. If cell is empty output nil. X is a 
string - a cell from org-table
+usage (org-table-cell-no-prop #(\"foo \" 0 2 (face default))) ==> foo
+"
+  (interactive)
+  (let ( (res (replace-regexp-in-string "\s+" "" 
+   (substring-no-properties x
+(when (not (equal res ""))
+  res)
+))
+
 ;;;###autoload
 (defun org-table-sum ( beg end nlast)
   "Sum numbers in region of current table column.
@@ -4769,9 +4781,9 @@ If NLAST is a number, only the NLAST fields will actually 
be summed."
   (t (setq items (reverse items))
  (setcdr (nthcdr (1- nlast) items) nil)
  (nreverse items
-(numbers (delq nil (mapcar #'org-table--number-for-summing
-   items1)))
-(res (apply '+ numbers))
+(numbers (delq nil (mapcar 'org-table-cell-no-prop  items1 )))
+(res (string-to-number (calc-eval
+(combine-and-quote-strings numbers  
"+" 


Best regards
Jeremie Juste

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Bastien]

Hi Leo,

Leo Vivier  writes:

> Bastien  writes:
>
>> Sorry, perhaps I was not clear: (1) and (2) do not need to be separate
>> documents.
>
> No, you were quite clear.  I just surmised that two documents would be
> required, but upon thinking about it some more, (1) and (2) would make
> for a cohesive whole.

Okay -- perhaps we'll decide otherwise when we can judge by the content.

>> Great, thanks for volunteering.  I think this is something you should
>> perhaps do with a long time Org user, ping-pong'ing with commits, not
>> alone.
>
> Sure, I’d be up for that.

Thanks!  Anyone else to work on this with Leo?

>> Would it be okay for you if we rename worg/dev/org-syntax.org to
>> something like worg/dev/org-elements-syntax.org or would that be
>> confusing?
>
> Since we already have worg/dev/org-element-api.org [1], I think the
> rename to worg/dev/org-element-syntax.org would be welcome.

(Just to be clear, since the quotation context suggests otherwise, I
was really asking Nicolas, as he's the author of this document.)

-- 
 Bastien

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Palak Mathur]

Sent from my iPhone

> On Oct 24, 2020, at 7:50 AM, Bastien  wrote:
> 
> Hi Palak,
> 
> Palak Mathur  writes:
> 
>> I am fairly new to Org. Let me see if I can use it as a markup in an
>> Editor other than Emacs. I will report on what syntax options are very
>> Emacs specific, what are general and what can be ported.
> 
> Thanks!  I think it is less a matter of *what* is described in
> https://orgmode.org/worg/dev/org-syntax.html rather than *how* it is
> described.
> 
> As the first paragraph says: 
> 
>  "This document describes and comments Org syntax as it is currently
>  read by its parser (Org Elements)"
> 
> while we need a description of Org's syntax from the point of view of 
> (1) a human writer and (2) any possible Org parser.
> 
I understand that. 

> I don't know how difficult it is, but I suspect it is quite a lot of
> work.
> 

Yes, it is going to be some work. I will try to get something started and share 
a draft. 


> -- 
> Bastien

Re: [PATCH] ob-python: Rename exec tmpfile handle to prevent conflict

[Bastien]

Hi Jack,

Jack Kamm  writes:

> Thanks Bastien, the Woof! tool looks interesting.

Thanks!  I'm working on a small woof.el package to make it more
useful for both maintainers (setting headers) and users (checking
upcoming changes or help requests).

> By the way, on seeing this thread again, I realized this patch
> probably should have been applied to the maint branch. So I've cherry
> picked it into there, and merged back into master.

Thanks for this!

-- 
 Bastien

Clarification of what to expect from major and minor releases after 9.5

[Bastien]

Hi all,

I've updated https://orgmode.org/worg/org-maintenance.html to clarify
a few points:

- we don't have a release schedule;

- after Org 9.5, x.y versions like 9.6, 9.7, etc. will be *minor
  versions*, not major versions.  So the next major after 9.5 is 10.

- we don't follow semantic versioning: that is, we use the familiar
  numbering sheme (x.y.z) but the distinction between major (x) and
  minor (y) is not about incompatible vs compatible changes.  

  Instead, we use what I'd call "Hear ye!" versioning: major Org
  versions request every users to read the release notes, and minor
  Org versions request Org contributors and power users to read the
  release notes.  We have no release notes for bugfix-only release.

Let me know if something is not clear!

All best,

-- 
 Bastien

Re: [PATCH] ob-python: Rename exec tmpfile handle to prevent conflict

[Jack Kamm]

Thanks Bastien, the Woof! tool looks interesting.

By the way, on seeing this thread again, I realized this patch probably should 
have been applied to the maint branch. So I've cherry picked it into there, and 
merged back into master.

Bastien  writes:

> Hi Jack and Adrian,
>
> Jack Kamm  writes:
>
>> Adrian Kummerländer  writes:
>>
>>> I noticed that after updating to Org 9.4 many of my Python-based Org
>>> files fail to execute with various `io.TextIOWrapper' related error
>>> messages. The reason for this is that opening the exec tmpfile as `f'
>>> shadows this possibly user-defined variable.
>>>
>>> The attached patch fixes this problem for me. As this is my first
>>> time contributing to Org I am especially open for any suggestions!
>>
>> The patch looks good.  I've pushed it to master, after making a couple
>> minor fixes to the commit message (adding a TINYCHANGE cookie and
>> adjusting some of the spacing).
>
> Thanks for applying the patch, I'm marking it as "applied" through
> Woof! adding "X-Woof-Patch: applied" in the headers.
>
> Best,
>
> -- 
>  Bastien

Re: Bug: org-plus-contrib freezes emacs when opening file [9.4 (9.4-19-gb1de0c-elpaplus @ /Users/gb4dt/.emacs.d/elpa/org-plus-contrib-20201019/)]

[Georgios Bakirtzis]

Hi Bastien,

I tried to figure out what you mean by that but I am drawing a blank.
I completely deleted my emacs folder and then did
=package-list-packages= and installed =org-plus-contrib= restarted
emacs and the problem showed up, while it wasn't there before.

How can I see the individual packages (or load them individually) from
org-plus-contrib?

Thank you,
Georgios

On Sat, Oct 24, 2020 at 7:53 AM Bastien  wrote:
>
> Hi Georgios,
>
> Georgios Bakirtzis  writes:
>
> > Org without contrib does not have the following issue.
>
> what part of your configuration loads contrib packages?
>
> Can you bisect and find what contributed package triggers the error
> you have?
>
> Thanks,
>
> --
>  Bastien

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Leo Vivier]

Bastien  writes:

> Sorry, perhaps I was not clear: (1) and (2) do not need to be separate
> documents.

No, you were quite clear.  I just surmised that two documents would be
required, but upon thinking about it some more, (1) and (2) would make
for a cohesive whole.

> Great, thanks for volunteering.  I think this is something you should
> perhaps do with a long time Org user, ping-pong'ing with commits, not
> alone.

Sure, I’d be up for that.

> Would it be okay for you if we rename worg/dev/org-syntax.org to
> something like worg/dev/org-elements-syntax.org or would that be
> confusing?

Since we already have worg/dev/org-element-api.org [1], I think the
rename to worg/dev/org-element-syntax.org would be welcome.

Notes :
[1] https://orgmode.org/worg/dev/org-element-api.html

-- 
Leo Vivier
Freelance Software Engineer
Website: www.leovivier.com | Blog: www.zaeph.net

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Bastien]

Hi Leo,

Leo Vivier  writes:

> Bastien  writes:
>
>> As the first paragraph says: 
>>
>>   "This document describes and comments Org syntax as it is currently
>>   read by its parser (Org Elements)"
>>
>> while we need a description of Org's syntax from the point of view of 
>> (1) a human writer and (2) any possible Org parser.
>
> I agree that (1) and (2) should be two different documents.  

Sorry, perhaps I was not clear: (1) and (2) do not need to be separate
documents. I think both can be described in a single document, my main
point was that the current org-syntax.org is from none of these points
of view.

> (2) would
> be especially interesting since there are quite a few projects afoot to
> parse Org documents outside of Emacs:
> - go-org (Go)
>   https://github.com/niklasfasching/go-org
> - orgize (Rust)
>   https://docs.rs/orgize/0.8.4/orgize/
>
> They are in various stages of advancement, but a design document would
> go a long way in federating those efforts.
>
>> I don't know how difficult it is, but I suspect it is quite a lot of
>> work.
>
> I assume that it would be, yes.  However, as someone with a vested
> interest in developing an efficient external parser for Org documents,
> I’d love to contribute.  I’ve been playing around lately with ox.el to
> write an exporter to Jupyter (more on that soon), and since it makes
> extensive use of org-element.el, I’d have a modicum of knowledge upon
> which I could initiate the effort.

Great, thanks for volunteering.  I think this is something you should
perhaps do with a long time Org user, ping-pong'ing with commits, not
alone.

Nicolas, what's your take on this?

Would it be okay for you if we rename worg/dev/org-syntax.org to
something like worg/dev/org-elements-syntax.org or would that be
confusing?

Would you have any advice on how to tackle worg/org-syntax.org in a
generic and useful way?

-- 
 Bastien

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Leo Vivier]

Hi there,

Bastien  writes:

> As the first paragraph says: 
>
>   "This document describes and comments Org syntax as it is currently
>   read by its parser (Org Elements)"
>
> while we need a description of Org's syntax from the point of view of 
> (1) a human writer and (2) any possible Org parser.

I agree that (1) and (2) should be two different documents.  (2) would
be especially interesting since there are quite a few projects afoot to
parse Org documents outside of Emacs:
- go-org (Go)
  https://github.com/niklasfasching/go-org
- orgize (Rust)
  https://docs.rs/orgize/0.8.4/orgize/

They are in various stages of advancement, but a design document would
go a long way in federating those efforts.

> I don't know how difficult it is, but I suspect it is quite a lot of
> work.

I assume that it would be, yes.  However, as someone with a vested
interest in developing an efficient external parser for Org documents,
I’d love to contribute.  I’ve been playing around lately with ox.el to
write an exporter to Jupyter (more on that soon), and since it makes
extensive use of org-element.el, I’d have a modicum of knowledge upon
which I could initiate the effort.

Best,

-- 
Leo Vivier
Freelance Software Engineer
Website: www.leovivier.com | Blog: www.zaeph.net

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Bastien]

Hi Palak,

Palak Mathur  writes:

> I am fairly new to Org. Let me see if I can use it as a markup in an
> Editor other than Emacs. I will report on what syntax options are very
> Emacs specific, what are general and what can be ported.

Thanks!  I think it is less a matter of *what* is described in
https://orgmode.org/worg/dev/org-syntax.html rather than *how* it is
described.

As the first paragraph says: 

  "This document describes and comments Org syntax as it is currently
  read by its parser (Org Elements)"

while we need a description of Org's syntax from the point of view of 
(1) a human writer and (2) any possible Org parser.

I don't know how difficult it is, but I suspect it is quite a lot of
work.

-- 
 Bastien

Re: [PATCH] babel latex headers and image generation commands

[Bastien]

Hi Matt,

sorry for the delayed answer.

Matt Huszagh  writes:

> Bastien  writes:
>
>> Prefer
>>
>>   * lisp/ob-latex.el (org-babel-latex-preamble): New option for LaTeX
>>   preamble customization.
>>
>> "New option" is quite standard, an "option" being a customizable
>> variable.  In this case, "New option" would probably be enough, given
>> the name of the option is quite self-explanatory.  Also, some find it
>> pedantic, but "LaTeX" is the correct spelling in a changelog I guess.
>
> Fixed in new patch (attached).

Applied as ae35a3459, thanks!

>> The first line of the docstring should contain a sentence, so you'd
>> need to have a new paragraph after "runtime to the LaTeX preamble."
>
> Also fixed. Making the first line a full sentence means that some lines
> are a little longer than 80 characters. Is this acceptable?
>
>> What for users who don't have inkscape?  
>
> This is just a default, but I could use a dvisvgm command as the default
> instead? Either way, converting a PDF to SVG will require an executable
> outside Emacs, but I guess dvisvgm is more likely to be installed for
> people using a texlive installation. My personal preference for inkscape
> is because it should handle all PDF inputs, whereas there are some cases
> where dvisvgm may fail (see
> https://github.com/mgieseki/dvisvgm/issues/139) due to changes in
> ghostscript. Still, dvisvgm generally does a very good job with PDF
> inputs. Let me know your thoughts, I'd be happy to set the default to a
> dvisvgm command instead.

Let's see what people think when they try it after 9.5.

Can you provide a patch against etc/ORG-NEWS announce this?

Thanks,

-- 
 Bastien

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Palak Mathur]

> On Oct 24, 2020, at 7:09 AM, Bastien  wrote:
> 
> Hi Wes,
> 
> Wes Hardaker  writes:
> 
>> Ok, I'll try to create a template we can fill out in github next week
>> (I'm swamped this week with a deadline).
> 
> If you manage to make any progress on this, please share it with the
> whole list so that interested people can possibly follow.
> 
> For the record, I think we should first enhance the Worg documentation
> on Org's syntax before applying to register Org as a MIME type.  
> 
> https://orgmode.org/worg/dev/org-syntax.html is useful but my feeling
> is that it describes Org "syntax" from the point of view of the Emacs
> parser -- we surely need something a bit more agnostic for registering
> Org as MIME type.
> 
> I'm adding this as a call for help on https://updates.orgmode.org.
> 
> Best,
> 

I am fairly new to Org. Let me see if I can use it as a markup in an Editor 
other than Emacs. I will report on what syntax options are very Emacs specific, 
what are general and what can be ported. 



> -- 
> Bastien
> 

Re: [PATCH] Fixed-pitch tables and code blocks that do not break variable-pitch-mode

[Bastien]

Hi Protesilaos,

sorry for the delay in replying.

Protesilaos Stavrou  writes:

> Please see the attached diff.  An explanation is offered below.

This looks good to me -- is this enhancement compatible with older
versions of Emacs?  I'd like to keep Org compatible with Emacs 25.

If so, can you provide a proper patch?

Thanks,

-- 
 Bastien

Re: [PATCH] Include missing files when sitemap style is tree

[Bastien]

Hi Anthony,

Anthony Carrico  writes:

> * ox-publish.el (org-publish-sitemap): Include files that have an 
> ancestor below base-directory with no published files and sitemap style 
> is tree.

thanks for the patch and sorry for the delay in replying.  I'm not
sure I understand the bug it fixes: can you briefly describe it or
provide a reproducible recipe?

> +(defun org-publish-dir-name-parent (dir-name)
> +  (file-name-as-directory (expand-file-name (concat dir-name ".."
> +
> +(defun org-publish-dir-name-and-parents (dir-name root-dir-name)
> +  (pcase dir-name
> + ("" nil)
> + ((or "./" "/" (pred (string= root-dir-name))) (list dir-name))
> + (_ (cons dir-name (org-publish-dir-name-and-parents
> + (org-publish-dir-name-parent dir-name) 
> root-dir-name)
> +
> +(defun org-publish-file-name-parents (file root)
> +  (org-publish-dir-name-and-parents (file-name-directory file)
> + (file-name-as-directory root)))
> +

You would need to add docstrings for each of the new functions.

Thanks,

-- 
 Bastien

Re: [PATCH] ob-gnuplot: handle remote input files

[Bastien]

Hi Ferdinand,

Ferdinand Pieper  writes:

> When passing a remote file like "/ssh:myserver:/myfile.txt" to a
> gnuplot block as variable the gnuplot process can not access the
> remote data.

Applied, thanks!

> An example:
>
> #+begin_src gnuplot :var data="/ssh:myserver:/myfile.txt"
> plot data u 1:2
> #+end_src
>
> Attached is a patch, which instead downloads remote files to a
> unique path and passes this new path to gnuplot.
>
> Please let me know if there's something to improve regarding the
> commit message or patch formatting.

The commit message and the changelog were perfect, thanks for taking
care of this.  I simply added "TINYCHANGE".

Best,

-- 
 Bastien

Re: Shower thought: submit an IETF RFC to register Org as a MIME type

[Bastien]

Hi Wes,

Wes Hardaker  writes:

> Ok, I'll try to create a template we can fill out in github next week
> (I'm swamped this week with a deadline).

If you manage to make any progress on this, please share it with the
whole list so that interested people can possibly follow.

For the record, I think we should first enhance the Worg documentation
on Org's syntax before applying to register Org as a MIME type.  

https://orgmode.org/worg/dev/org-syntax.html is useful but my feeling
is that it describes Org "syntax" from the point of view of the Emacs
parser -- we surely need something a bit more agnostic for registering
Org as MIME type.

I'm adding this as a call for help on https://updates.orgmode.org.

Best,

-- 
 Bastien

Re: Limitations on Tags ?

[Bastien]

Hi David,

David Masterson  writes:

> Just wondering -- what's the limit in the number of tags for a headline?
> What if I have a headline with lots of tags or some very long tags?

Please try and let us know what happens :)

-- 
 Bastien

Re: [PATCH] org: Fix a docstring typo

[Bastien]

Hi Kyle and Morgan,

Kyle Meyer  writes:

> morgan.j.sm...@outlook.com writes:
>
>> From: Morgan Smith 
>>
>> * lisp/org.el (org-check-before-invisible-edit): Fix a docstring typo.
>> ---
>>
>> Hello Org! This is my first patch so go easy on me. I'm planning on
>> doing more patches in the future. I already submitted the FSF
>> paperwork for emacs, so hopefully I don't have to do anything extra
>> there.
>
> Thank you for the patch.  Looks good.  Applied (84bfc688d).

Thanks for this, marking it as "applied" for Woof!.

Hint: adding "Applied" at the beginning of the message will close it
directly.

-- 
 Bastien

Re: [PATCH] ob-java

[Bastien]

Hi Ian,

feel free to install the patch when you think it's ready.

One minor nitpick:

-;; Author: Eric Schulte
-;; Maintainer: Ian Martins 
+;; Author: Ian Martins 

I suggest you leave Eric Schulte as the author while adding yourself
as the maintainer, even if the "change" is a big rewrite.

Thanks,

-- 
 Bastien

Re: [PATCH] ob-python: Rename exec tmpfile handle to prevent conflict

[Bastien]

Hi Jack and Adrian,

Jack Kamm  writes:

> Adrian Kummerländer  writes:
>
>> I noticed that after updating to Org 9.4 many of my Python-based Org
>> files fail to execute with various `io.TextIOWrapper' related error
>> messages. The reason for this is that opening the exec tmpfile as `f'
>> shadows this possibly user-defined variable.
>>
>> The attached patch fixes this problem for me. As this is my first
>> time contributing to Org I am especially open for any suggestions!
>
> The patch looks good.  I've pushed it to master, after making a couple
> minor fixes to the commit message (adding a TINYCHANGE cookie and
> adjusting some of the spacing).

Thanks for applying the patch, I'm marking it as "applied" through
Woof! adding "X-Woof-Patch: applied" in the headers.

Best,

-- 
 Bastien

Re: [PATCH] Review face for export dispatcher highlighted keys

[Bastien]

Hi Protesilaos,

Protesilaos Stavrou  writes:

> The export dispatcher's active keys are highlighted using the
> 'org-warning' face.  That face is applied in various contexts, including
> the agenda.
>
> Users who have difficulty reading the active keys of the export
> dispatcher are therefore forced to modify 'org-warning' throughout their
> setup, even though their problem is present only while viewing the
> dispatch UI (because highlighted keys are one or a few characters long).
>
> The attached patch is an attempt to address this issue by creating a new
> face that is specifically designed for the dispatch UI.

Applied, thanks a lot!

-- 
 Bastien

Re: ob-sql posgresql windows problems

[Bastien]

Hi Neil,

Neil Cherry  writes:

> I'm on a Windows 10 System, I'm using ob-sql.el and when I C-c C-c
> on the src block I get:

What version of Org are you using?  M-x org-version RET

Thanks,

-- 
 Bastien

Re: [PATCH] ob-ruby.el: allow specification of ruby command w/header arg

[Bastien]

Hi Aaron,

Aaron Madlon-Kay  writes:

>   Using the :ruby header arg.

Applied, thanks!

-- 
 Bastien

Re: [PATCH] [WIP] org-agenda.el: Make org-entries-lessp more efficient

[Bastien]

Hi Adam,

this looks good to me, thanks a lot.

Does "WIP" means that you want to wait for other patches to complete
this one or shall I apply this one already?

Best,

-- 
 Bastien

Re: [PATCH] org-agenda.el: Fix 'Maker' typo

[Bastien]

Applied, thanks!

-- 
 Bastien

Re: [PATCH] org-plot abstractions and extension

[Bastien]

Hi Timothy,

TEC  writes:

> I'm still hoping that someone might get back to me ... eventually,
> so here's another bump.

I'm not an org-plot.el user so I cannot test, but by reading the
patches, they look okay.

Let's go in "optimistic merging" mode and commit your patches?

Is https://orgmode.org/list/87lfhbhfhe@gmail.com/ the latest
version I should use?

-- 
 Bastien

Re: W3C violations in Org's HTML export

[Bastien]

Hi Timothy,

TEC  writes:

> In developing my take on the Org website and my coFig file, it has
> come to my attention that there seem to be a few W3C violations in
> the HTML export.

thanks for the careful tests and for reporting this.

> I always export with these settings,
> which may affect some of the items below.
>
> #+begin_src emacs-lisp
> (setq org-html-doctype "html5"
>   org-html-html5-fancy t)
> #+end_src

I suggest we first try to fix HTML errors that we have with the
default settings, then errors with fancy ones.

> That's all that I could see on a first glance. I'm hoping that
> documenting these issues here will be the first step to solving 
> them.

It surely does.  Can you provide a patch for each issue, opening 
a new thread so that we can discuss the solution?

Thanks!

-- 
 Bastien

Re: Bug: org-plus-contrib freezes emacs when opening file [9.4 (9.4-19-gb1de0c-elpaplus @ /Users/gb4dt/.emacs.d/elpa/org-plus-contrib-20201019/)]

[Bastien]

Hi Georgios,

Georgios Bakirtzis  writes:

> Org without contrib does not have the following issue.

what part of your configuration loads contrib packages?

Can you bisect and find what contributed package triggers the error
you have?

Thanks,

-- 
 Bastien