Re: official orgmode parser

[Przemysław Kamiński]

I'm no expert in parsing but I would expect org's parser to be quite 
similar to the multitude of markdown or CommonMark [1] parsers. There 
isn't that much difference in syntax, except maybe org is more versatile 
and has more syntax elements, like drawers.


Searching for "EBNF Markdown" I stumbled upon [2].

[1] https://commonmark.org/
[2] http://roopc.net/posts/2014/markdown-cfg/

On 10/26/20 10:00 PM, Tom Gillespie wrote:

Here is an attempt to clarify my own confusion around the nested
structures in org. In short: each node in the headline tree and the
plain list tree can be parse using the EBNF, the nesting level cannot,
which means that certain useful operations such as folding, require
additional rules beyond the grammar. More in line. Best!
Tom


Do you need to? This is valid as an entire Org file, I think:

*** foo
* bar
* baz

And that can be represented in EBNF. I'm not aware of places where behavior is 
indent-level specific, except inline tasks, and that edge case can be 
represented.


You are correct, and as long as the heading depth doesn't change some
interpretation then this is a non-issue. The reason I mentioned this
though is
because it means that you cannot determine how to correctly fold an
org file from the grammar alone.

To make sure I understand. It is possible to determine the number of
leading stars (and thus the level), but I think that it is not
possible to identify the end of a section.
For example

* a
*** b
** c
* d

You can parse out a 1, b 3, c 2, d 1, but if you want to be able to
nest b and c inside a but not nest d inside a, then you need a stack
in there somewhere. You
can't have a rule such as

section : headline content
content : text | section

because the parse would incorrectly nest sections at the same level,
you would have to write

section-level-1 : headline-1 content-1
content-1 : text | section-level-2-n

but since we have an arbitrary number of levels the grammar would have
to be infinite.
This is only if you want your grammar to be able to encode that the
content of sections
can include other more deeply nested sections, which in this context
we almost certainly
do not (as you point out).


There is a similar issue with the indentation level in
order to correctly interpret plain lists.


list ::= ('+' string newline)+ sublist?
sublist ::= (indent list)+

I think this captures lists?


Ah yes, I see my mistake here. In order for this to work the parser
has to implement significant whitespace,
so whitespace cannot be parsed into a single token. I think everything
works out after that.


Definitely not able to be represented in EBNF, unless as you say {name} is a 
limited vocabulary.


Darn those pesky open sets!

Re: Folding headings which contain only blank lines

[Kyle Meyer]

Kyle Meyer writes:

> 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.

Done in e8070d71a.

Re: [PATCH] Re: Bug: org-cycle stops working on Org files with empty lines at end of buffer [9.4 (9.4-elpaplus @ /home/brentg/.emacs.d/elpa/org-plus-contrib-20200914/)]

[Kyle Meyer]

stardiviner writes:

> Bastien  writes:
>
>> stardiviner  writes:
>>
>>> Waited many days, seems no useful patch available. I suggest to revert that
>>> commit.
>>
>> I will have a look over the week-end, thanks.
>
> Thanks for taking time to look at this problem, Bastien.

As discussed at ,
this doesn't appear to have fixed the original issue.  Reverted in
e8070d71a.

Re: org-marker vs. org-hd-marker

[Kyle Meyer]

Michael Heerdegen writes:

> Hello,
>
> what's the difference between org-marker and org-hd-marker markers?

My reading (which could be very wrong) is that org-hd-marker is always
set to the start of the headline.  org-marker, on the other hand, is set
to some position in the entry that depends on who is setting it.

For example, with an agenda file like

  ** TODO a
  SCHEDULED: <2020-10-26 Mon>

and a buffer generated with org-agenda-list, org-marker for the entry
points to "<".  In a buffer generated with org-todo-list, it points to
the first "*" of the headline (i.e. the same position as org-hd-marker).

> What does "hd" stand for?

Headline, I guess.

Documentation suggestion: Mention async-bytecomp-package-mode in the installation section of the manual

[Gustavo Barros]

Hi All,

I've seen time and again folks get bitten by trying to install Org with 
`package.el' while having Org loaded.  The latest, but certainly not the 
first and not the last: 
https://www.reddit.com/r/orgmode/comments/jicj1k/how_to_use_org_version_from_orgpluscontrib/


This is well known, and indeed the manual states "important" in bold to 
say that "You need to do this in a session where no ‘.org’ file has been 
visited, i.e., where no Org built-in function have been loaded."


But it is not always easy to ensure that, even when you know what you 
are doing.  And certainly not trivial to users less acquainted with the 
package system and how library loading works, etc.


However, there is a very easy way to ensure that 
installation/byte-compilation is done in a clean environment in package 
`async', namely `async-bytecomp-package-mode'.  From my experience, I 
have a simple:


   (use-package async-bytecomp
 :ensure async
 :defer t
 :custom
 (async-bytecomp-allowed-packages 'all)
 (async-bytecomp-package-mode t))

in my init file.  My `initial-major-mode' is `org-mode' and I've never 
had an installation problem, even though I update `org-plus-contrib' 
carelessly at will on a live session.


`async' is by John Wiegley, and available both at ELPA and MELPA.

Wouldn't it be worth mentioning it in the manual and/or in the 
site/Worg?


Best regards,
Gustavo.

default :results

[ian martins]

The doc says functional mode (=:results value=) is the default for most
Babel libraries [1].  I haven't looked at many, but it is the default for
ob-python and ob-shell. Scripting mode (=:results output=) is the default
for ob-C, and the old ob-java (neither of these provided a functional mode).

When I added functional mode to ob-java, I made it the default since that
seemed correct.  But that change breaks anyone that relied on the old
default (the workaround is to add a =:results output= header).  I will
change the default in the short term to unbreak the experience, but what,
if anything, should be done long term?

And is this inconsistent behavior across languages something that should be
fixed? or is it intentional or at least not worth doing anything about?

[1]
https://orgmode.org/manual/Results-of-Evaluation.html#Results-of-Evaluation

Re: Fwd: [syl20bnr/spacemacs] Org mode column view columns misaligned (#14058)

[Kyle Meyer]

bob...@gmail.com writes:

> Hi,
>
> I raised a problem I am having with org mode to the spacemacs bug list. See
> issue and comments at https://github.com/syl20bnr/spacemacs/issues/14058.

Thanks for reporting here.  Could you provide a minimal example (e.g.,
Org content and column definitions) that can be used to trigger the
issue?

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

[Anthony Carrico]

On 10/24/20 8:21 AM, Bastien wrote:

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?


#!/run/current-system/sw/bin/emacs --script

(require 'org)
(require 'ox-publish)

;;; create a source directory tree:
(make-directory "test-export/src/level1/level2/level3" t)

;;; create two source files, with an empty directory between:
(with-temp-file "test-export/src/level1/one.org"
  (insert "#+TITLE one"))

(with-temp-file "test-export/src/level1/level2/level3/three.org"
  (insert "#+TITLE three"))

;;; create a destination directory trees:
(make-directory "test-export/dest" t)

;;; publish the test-export:
(setq org-publish-project-alist
  `(("test-export"
 :base-directory "test-export/src"
 :publishing-directory "test-export/dest"
 :publishing-function org-html-publish-to-html
 :sitemap-filename "index.org"
 :sitemap-title "test-export"
 :sitemap-style tree
 :auto-sitemap t
 :recursive t)))

;; ISSUE: Even with the force argument, org-publish still seems to 
generate a cache in ~/.org-timestamps which creates a sitemap with old 
titles and breaks reproducible builds. To avoid this problem delete the 
cache when publishing:

(defun org-publish-delete-cache-file (project-name)
(let* ((cache-file
(concat
 (expand-file-name org-publish-timestamp-directory)
 project-name ".cache"))
   (cexists (file-exists-p cache-file)))
  (when (file-exists-p cache-file)
(delete-file cache-file

(org-publish-delete-cache-file "test-export")
(org-publish "test-export" t)
(org-publish-delete-cache-file "test-export")

;; Now run:
;;
;; $ firefox test-export/dest/index.html
;;
;; You should see something like this:
;;
;;
;; test-export
;;
;; level1
;; one
;;

;; Now run again with my patch, and you will see something like this:
;;
;; test-export
;;
;; level1
;; one
;; level2
;; level3
;; three
;;
;; As you can see, without the patch, "three" is missing from the index.


+(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.


I've run out of time today. These /seem/ like they should be standard 
procedures in elisp, not something in org-publish, but I couldn't find 
them in the manual. I'm not very experienced with elisp though.


I've run out of time today. Tell me if you have trouble with the test 
case. Thank you Bastien.


--
Anthony Carrico

Re: Please help by becoming a maintainer for an Org Babel file

[Palak Mathur]

Hi Bastien,

  I have sent that form to the address listed on the form.

Regards,
Palak Mathur

On Mon, Oct 26, 2020 at 4:43 PM Bastien  wrote:
>
> Hi Palak,
>
> Palak Mathur  writes:
>
> > I am willing to take care of ob-groovy.el.
>
> thanks.  AFAIK you didn't assign your copyright to the FSF.
> This is needed to be able to commit to Org's core.
>
> Can you fill this form and report to me when this is done?
>
> https://orgmode.org/request-assign-future.txt
>
> Thanks!
>
> --
>  Bastien

Re: Force creation of org id in template

[Gustavo Barros]

On Mon, 26 Oct 2020 at 19:40, Gustavo Barros  wrote:

> On Mon, 26 Oct 2020 at 22:33, Michael Heerdegen  
> wrote:
>
>> I'm not sure.  I see that creating an id involves slightly more than
>> adding the property - see the `org-id-add-location' call in
>> `org-id-get'.  Calling the higher level `org-id-get' or the like in a
>> %() spec in a template fails however, since when it's called a temp
>> buffer not associated with a file is current.
>>
>> And then I'm also not sure if the above is always secure when something
>> else in the template spec wants to add a (different) property.  Do you
>> know?
>
> Not really.  `org-id' usually "just works" for me, so I never had to dig
> anything deeper there.  But, as far as I recall, this is meant to add
> the new ID on the IDs file.  Considering your capture template is likely
> to be on your agenda files, this is probably not going to be of
> concern (meaning here these files will eventually be scanned and the ID
> found).  But, if it is, you could then go with `%(org-id-get nil t)`,
> right?  It does seem to be more appropriate either way, I agree.
>
> I have stored here in my init file a message from the list describing
> the procedure Org uses to try to find an ID, you might find it useful:
> https://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg01195.html
>
> Regarding the second issue, of course, you should end up with a single
> properties drawer, and the template should ensure that.

Indeed, `%(org-id-get nil t)` fails.

But the following works:

(defun org-id-get-new-id ()
  (interactive)
  (let ((id (org-id-get nil t)))
id))

To my surprise, I had to make it interactive. Perhaps that's what made
the previous try fail.

Best,
Gustavo.

Re: Force creation of org id in template

[Gustavo Barros]

On Mon, 26 Oct 2020 at 22:33, Michael Heerdegen  
wrote:

> I'm not sure.  I see that creating an id involves slightly more than
> adding the property - see the `org-id-add-location' call in
> `org-id-get'.  Calling the higher level `org-id-get' or the like in a
> %() spec in a template fails however, since when it's called a temp
> buffer not associated with a file is current.
>
> And then I'm also not sure if the above is always secure when something
> else in the template spec wants to add a (different) property.  Do you
> know?

Not really.  `org-id' usually "just works" for me, so I never had to dig
anything deeper there.  But, as far as I recall, this is meant to add
the new ID on the IDs file.  Considering your capture template is likely
to be on your agenda files, this is probably not going to be of
concern (meaning here these files will eventually be scanned and the ID
found).  But, if it is, you could then go with `%(org-id-get nil t)`,
right?  It does seem to be more appropriate either way, I agree.

I have stored here in my init file a message from the list describing
the procedure Org uses to try to find an ID, you might find it useful:
https://lists.gnu.org/archive/html/emacs-orgmode/2009-11/msg01195.html

Regarding the second issue, of course, you should end up with a single
properties drawer, and the template should ensure that.

Best,
Gustavo.

Re: Please help by becoming a maintainer for an Org Babel file

[Justin Abrahms]

I'm happy to take over ob-mscgen and also ob-dot.

I've not got an account on code.org-mode.org, yet. I've emailed Bastien 
directly with my preferred username and have sent the requisite copyright 
assignment forms to the relevant gnu email.

Let me know if there are other things to take on there.

Thanks!
 -justin

On Mon, Oct 26, 2020, at 2:43 PM, Bastien wrote:
> Hi Palak,
> 
> Palak Mathur  writes:
> 
> > I am willing to take care of ob-groovy.el.
> 
> thanks.  AFAIK you didn't assign your copyright to the FSF.
> This is needed to be able to commit to Org's core.
> 
> Can you fill this form and report to me when this is done?
> 
> https://orgmode.org/request-assign-future.txt
> 
> Thanks!
> 
> -- 
> Bastien
> 
> 

Re: official orgmode parser

[Tom Gillespie]

Even if this did work for plain lists it won't work for headlines
because headlines have an arbitrary number of stars and thus it is not
possible for the grammar to know what is a sub-headline vs "the next
headline". For a similar reason I'm fairly sure that the sublist
approach will not work due to issues with relative indent. Here is the
quote from the current draft syntax.

> An item ends before the next item, the first line less or equally indented
> than its starting line, or two consecutive empty lines. Indentation of lines
> within other greater elements do not count, neither do inlinetasks boundaries.

The "the first line less or equally indented than its starting line"
section is what prevents your approach from working because you have
to know the relative indentation in order to figure out which list
contains a nested list. As written your grammar will parse a nested
list into a flat list. This is because there are an arbitrary number
distinct tokens that could be =indent= in your grammar and the EBNF
can't specify an ordering for them so that you can't say that one
indent is greater than another.

For list termination the rule seems to be two new lines followed by
not a list element. As a result of this, my inclination is to only
parse plain list elements and reconstruct the whole "list" only as an
internal semantic.

Check the behavior of
 1. to
1. see
  1. what
  1. I
   1. mean
   1.
1.
  1.

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Hi Palak,

Palak Mathur  writes:

> I am willing to take care of ob-groovy.el.

thanks.  AFAIK you didn't assign your copyright to the FSF.
This is needed to be able to commit to Org's core.

Can you fill this form and report to me when this is done?

https://orgmode.org/request-assign-future.txt

Thanks!

-- 
 Bastien

Re: official orgmode parser

[Ken Mankoff]

On 2020-10-26 at 14:00 -07, Tom Gillespie  wrote...
>> list ::= ('+' string newline)+ sublist?
>> sublist ::= (indent list)+
>>
>> I think this captures lists?
>
> Ah yes, I see my mistake here. In order for this to work the parser
> has to implement significant whitespace, so whitespace cannot be
> parsed into a single token. I think everything works out after that.

If we agree that the syntax above captures lists and sublists, then I think we 
could apply the same methods to the issue of headlines and sub-headlines?

  -k.

Re: Force creation of org id in template

[Michael Heerdegen]

gusbrs.2...@gmail.com writes:

> Untested, but how about adding something like the following to your
> template?
>
> :PROPERTIES:
> :ID: %(org-id-new)
> :END:

I'm not sure.  I see that creating an id involves slightly more than
adding the property - see the `org-id-add-location' call in
`org-id-get'.  Calling the higher level `org-id-get' or the like in a
%() spec in a template fails however, since when it's called a temp
buffer not associated with a file is current.

And then I'm also not sure if the above is always secure when something
else in the template spec wants to add a (different) property.  Do you
know?

Thanks,

Michael.

Re: Please help by becoming a maintainer for an Org Babel file

[Jeremie Juste]

Hello Bastien,

On Monday, 26 Oct 2020 at 10:52, Bastien wrote:
> Hi Jeremie,
>
> Jeremie Juste  writes:
>
>> I'm willing to take care of ob-R.el.
>
> You're in as of 36f4df892.  Thank you very much!
Got it! It might take my elisp skills to a new level. :-)

Thanks to you,
-- 
Jeremie Juste

Re: official orgmode parser

[Tom Gillespie]

Here is an attempt to clarify my own confusion around the nested
structures in org. In short: each node in the headline tree and the
plain list tree can be parse using the EBNF, the nesting level cannot,
which means that certain useful operations such as folding, require
additional rules beyond the grammar. More in line. Best!
Tom

> Do you need to? This is valid as an entire Org file, I think:
>
> *** foo
> * bar
> * baz
>
> And that can be represented in EBNF. I'm not aware of places where behavior 
> is indent-level specific, except inline tasks, and that edge case can be 
> represented.

You are correct, and as long as the heading depth doesn't change some
interpretation then this is a non-issue. The reason I mentioned this
though is
because it means that you cannot determine how to correctly fold an
org file from the grammar alone.

To make sure I understand. It is possible to determine the number of
leading stars (and thus the level), but I think that it is not
possible to identify the end of a section.
For example

* a
*** b
** c
* d

You can parse out a 1, b 3, c 2, d 1, but if you want to be able to
nest b and c inside a but not nest d inside a, then you need a stack
in there somewhere. You
can't have a rule such as

section : headline content
content : text | section

because the parse would incorrectly nest sections at the same level,
you would have to write

section-level-1 : headline-1 content-1
content-1 : text | section-level-2-n

but since we have an arbitrary number of levels the grammar would have
to be infinite.
This is only if you want your grammar to be able to encode that the
content of sections
can include other more deeply nested sections, which in this context
we almost certainly
do not (as you point out).

> > There is a similar issue with the indentation level in
> > order to correctly interpret plain lists.
>
> list ::= ('+' string newline)+ sublist?
> sublist ::= (indent list)+
>
> I think this captures lists?

Ah yes, I see my mistake here. In order for this to work the parser
has to implement significant whitespace,
so whitespace cannot be parsed into a single token. I think everything
works out after that.

> Definitely not able to be represented in EBNF, unless as you say {name} is a 
> limited vocabulary.

Darn those pesky open sets!

Re: official orgmode parser

[Ken Mankoff]

On 2020-10-26 at 10:59 -07, Tom Gillespie  wrote...
> You can identify headlines, but you can't identify nesting level;

Do you need to? This is valid as an entire Org file, I think:

*** foo
* bar
* baz

And that can be represented in EBNF. I'm not aware of places where behavior is 
indent-level specific, except inline tasks, and that edge case can be 
represented.

> There is a similar issue with the indentation level in
> order to correctly interpret plain lists.

list ::= ('+' string newline)+ sublist?
sublist ::= (indent list)+

I think this captures lists?

> Another example of something that requires a stack is the greater
> blocks, where you have #+begin_{name} and #+end_{name}, and the names
> must match.

Definitely not able to be represented in EBNF, unless as you say {name} is a 
limited vocabulary.

  -k.

Re: Force creation of org id in template

[gusbrs . 2016]

Hi Michael,

On Mon, 26 Oct 2020 at 19:26, Michael Heerdegen  
wrote:

> is it possible to tweak `org-capture-templates' entries so that the
> creation of an org id for an org entry created with `org-capture' is
> forced?

Untested, but how about adding something like the following to your template?

:PROPERTIES:
:ID: %(org-id-new)
:END:

HTH,
Gustavo.

Force creation of org id in template

[Michael Heerdegen]

Hello,

is it possible to tweak `org-capture-templates' entries so that the
creation of an org id for an org entry created with `org-capture' is
forced?

TIA,

Michael.

org code and error catching

[Michael Heerdegen]

Hello,

I had a hard time to debug some problem with the expansion of some
capture template because org catched the error even when I had set
`debug-on-error'.  Would it be possible to make some functions,
e.g. `org-eval' in my case (probably some more?), use
`condition-case-unless-debug' instead of `condition-case'?

Thanks,

Michael.

org-marker vs. org-hd-marker

[Michael Heerdegen]

Hello,

what's the difference between org-marker and org-hd-marker markers?
What does "hd" stand for?

TIA,

Michael.

Re: New website - back to the old unicorn!

[Scott Randby]

On 10/26/20 5:41 AM, Bastien wrote:
> Dear all,
> 
> thanks to the initiative and the patient efforts of Timothy, our
> website has been revamped: new contents, new look and... the old
> unicorn!

The new site is wonderful. The Features page is especially useful. Now my 
friends and students can easily see why Org is so great.

Scott Randby

Re: New website - back to the old unicorn!

[Tom Gillespie]

The image is a bit off center no?

On Mon, Oct 26, 2020 at 1:27 PM TEC  wrote:
>
>
> Eric S Fraga  writes:
>
> > On Monday, 26 Oct 2020 at 14:54, Daniele Nicolodi wrote:
> >> - (minor) I would add a background to the example in the home
> >> page to
> >> make it stand out more as an example org-mode syntax buffer
> >
> > This bothered me as well when I visited the site.  I think it
> > would help
> > to have something, however minor, to make it clear that the
> > image stand
> > is not part of the text, e.g. even a thin border around the
> > image would
> > do it.
>
> How does this look?
> https://i.imgur.com/peTajuN.png
>
> > Otherwise, the site looks great.
> > Thank you.
>
> Thanks for the kind words :)
>
> Timothy.
>
>

Re: official orgmode parser

[Tom Gillespie]

I started writing down Org's grammar as an EBNF (with Racket's #lang
brag) on Saturday. There is indeed a layer of Org grammar that can be
implemented via EBNF, but it is fairly minimal. You can identify
headlines, but you can't identify nesting level; the arbitrary nesting
depth means that you have to have a stack to keep track. There is a
similar issue with the indentation level in order to correctly
interpret plain lists. If the canonical representation of an org
document was required to used org-adapt-indentation: nil;
org-edit-src-content-indentation: 0 and there was a canonical
normalization function some of these issues would go away, but not all
of them, and I'm fairly certain that it is not possible to implement a
safe normalization function that won't mangle someones formatting.
Another example of something that requires a stack is the greater
blocks, where you have #+begin_{name} and #+end_{name}, and the names
must match. If there was a closed set of names you could sort of do it
by hand, but since name can be any string that does not contain
whitespace, you have to have a stack to track which block you are in.
So, you can identify things that are heads, you can identify things
that are block start lines and block end lines, but you need stacks to
keep track of heading level, indentation, plain list level, and block
name. I might be missing a few other places where stacks are required,
but those are the big ones. Best,
Tom

On Mon, Oct 26, 2020 at 12:48 PM Ken Mankoff  wrote:
>
>
> On 2020-10-26 at 09:24 -07, Nicolas Goaziou  wrote...
> > # This is a comment (1)
> >
> > #+begin_example
> > # This is not a comment (2)
> > #+end_example
> >
> > AFAICT, you cannot distinguish between lines (1) and (2) with EBNF.
>
> I agree. I think this is a better (correct?) example than the footnotes on 
> Org Syntax page.
>
>   -k.
>
>

Re: Babel->Latex export: how to set includegraphics scale?

[Mirko Vukovic]

On Fri, Oct 23, 2020 at 2:12 PM Mirko Vukovic 
wrote:

>
> On Thu, Oct 22, 2020 at 2:41 PM TEC  wrote:
>
>>
>> Hi Mirko
>>
>> Mirko Vukovic  writes:
>>
>> > Instead specifying the width, I'd like to use the parameter
>> > \scale.
>>
>> Have you tried #+attr_latex: :scale SCALE ?
>>
>>
> Your email triggered me to pay attention to settings of latex export, and
> not orb-babel.
> I found org-latex-default-image-scale customizable variable.
>
> I need to figure out how to set it in the file itself in the header.
>
> But at least for now, I set it in the Emacs' session and I get the desired
> result.
>

I solved my problem by placing #+attr_latex: scale scale just before the
#results like so:
#+begin_src ...
...
#+end_src
#+attr_latex: :width 1.0\linewidth
#+RESULTS:
...

Thanks,

Mirko

>

Re: New website - back to the old unicorn!

[Neil Cherry]

Wow, just learned a few new things about org-mode by a quick look at the new 
pages.
Now I have to learn more things. (I really hate you guys! ;-) )

--
Linux Home Automation Neil Cherry   nche...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/My HA Blog
Author of:  Linux Smart Homes For Dummies

Re: New website - back to the old unicorn!

[TEC]

Eric S Fraga  writes:


On Monday, 26 Oct 2020 at 14:54, Daniele Nicolodi wrote:
- (minor) I would add a background to the example in the home 
page to

make it stand out more as an example org-mode syntax buffer


This bothered me as well when I visited the site.  I think it 
would help
to have something, however minor, to make it clear that the 
image stand
is not part of the text, e.g. even a thin border around the 
image would

do it.


How does this look?
https://i.imgur.com/peTajuN.png


Otherwise, the site looks great.
Thank you.


Thanks for the kind words :)

Timothy.

Bug: fill-paragraph in Org buffer [9.4 (9.4-19-gb1de0c-elpaplus @ /home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)]

[Gustavo Barros]

Hi All,

Calling `fill-paragraph' in an Org buffer may leak paragraph boundaries, 
and even heading boundaries, and break document structure.


I'm aware, of course, of `org-fill-paragraph'.  Indeed, `org-mode' both 
sets `fill-paragraph' function to `org-fill-paragraph' and remaps the 
`fill-paragraph' binding to `org-fill-paragraph'.  If I understand 
correctly, this is technically redundant, but (a guess) probably the 
remapping is kept for backwards compatibility reasons.


I don't know why this happens.  As far as I get, `fill-paragraph' should 
be calling `fill-paragraph-function', so I'd expect both to do the same 
thing.  But currently they don't.


Why would anyone call `fill-paragraph' instead of `org-fill-paragraph'? 
Well, if you have some paragraph filling tweak you like, you might.  For 
example, one such instance is that widespread "fill-or-unfill" function, 
which I think started with Artur Malabarba, and was eventually packaged 
by Steve Purcell in https://github.com/purcell/unfill (180k+ downloads 
at MELPA).


Either way, even when the binding for `fill-paragraph' is remapped to 
`org-fill-paragraph' it should be at least safe (I think...) to call 
`fill-paragraph' directly in an Org buffer, even when it might arguably 
be better to call `org-fill-paragraph'.



An ECM to reproduce the issue is:

- Start 'emacs -Q'

- Do an initial setup:
 #+begin_src emacs-lisp
 (add-to-list 'load-path "~/.emacs.d/elpa/org-plus-contrib-20201019")
 #+end_src

- Visit file =test.org= with contents:
 #+begin_src org
 ,* Foo

 - Boo
   - Baz



 ,* Bar
   :PROPERTIES:
   :CATEGORY: home
   :CUSTOM_ID: Bar
   :END:
 #+end_src

- Place point in the "Baz" list item under heading "Foo", and call `M-x 
 org-fill-paragraph'.  As expected, the buffer is unchanged.


- Now call `M-x fill-paragraph'.  The result is:

- The result is:
 #+begin_src org
 ,* Foo

 - Boo
   - Baz



 ,* Bar
   :PROPERTIES:
   :CATEGORY: home :CUSTOM_ID: Bar
   :END:
 #+end_src

where `fill-paragraph' "filled" the contents of the properties drawer of 
the following heading, despite three whole blank lines and a heading 
along the way.



Best regards,
Gustavo.





Emacs  : GNU Emacs 27.1 (build 1, x86_64-pc-linux-gnu, GTK+ Version 
3.24.20, cairo version 1.16.0)

of 2020-08-11
Package: Org mode version 9.4 (9.4-19-gb1de0c-elpaplus @ 
/home/gustavo/.emacs.d/elpa/org-plus-contrib-20201019/)


current state:
==
(setq
org-src-mode-hook '(org-src-babel-configure-edit-buffer 
org-src-mode-configure-edit-buffer)

org-link-shell-confirm-function 'yes-or-no-p
org-metadown-hook '(org-babel-pop-to-session-maybe)
org-clock-out-hook '(org-clock-remove-empty-clock-drawer)
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-eldoc-load)

org-archive-hook '(org-attach-archive-delete-maybe)
org-confirm-elisp-link-function 'yes-or-no-p
org-agenda-before-write-hook '(org-agenda-add-entry-text)
org-metaup-hook '(org-babel-load-in-session-maybe)
org-bibtex-headline-format-function #[257 "\300\236A\207" [:title] 3 
"\n\n(fn ENTRY)"]

org-babel-pre-tangle-hook '(save-buffer)
org-tab-first-hook '(org-babel-hide-result-toggle-maybe 
org-babel-header-arg-expand)

org-agenda-loop-over-headlines-in-active-region nil
org-src-lang-modes '(("arduino" . arduino) ("redis" . redis) ("php" 
. php) ("C" . c) ("C++" . c++)
		  ("asymptote" . asy) ("bash" . sh) ("beamer" 
		  . latex) ("calc" . fundamental) ("cpp" . c++)
		  ("ditaa" . artist) ("dot" . fundamental) ("elisp" 
		  . emacs-lisp) ("ocaml" . tuareg)
		  ("screen" . shell-script) ("shell" . sh) ("sqlite" 
		  . sql))

org-occur-hook '(org-first-headline-recenter)
org-cycle-hook '(org-cycle-hide-archived-subtrees 
org-cycle-hide-drawers org-cycle-show-empty-lines

  org-optimize-window-after-visibility-change)
org-speed-command-hook '(org-speed-command-activate 
org-babel-speed-command-activate)

org-export-before-parsing-hook '(org-attach-expand-links)
org-confirm-shell-link-function 'yes-or-no-p
org-link-parameters '(("attachment" :follow org-attach-follow :complete 
org-attach-complete-link)
		   ("id" :follow org-id-open) ("eww" :follow 
		   org-eww-open :store org-eww-store-link)
		   ("rmail" :follow org-rmail-open :store 
		   org-rmail-store-link)
		   ("mhe" :follow org-mhe-open :store 
		   org-mhe-store-link)
		   ("irc" :follow org-irc-visit :store 
		   org-irc-store-link :export org-irc-export)
		   ("info" :follow org-info-open :export 
		   org-info-export :store org-info-store-link)
		   ("gnus" :follow org-gnus-open :store 
		   org-gnus-store-link)
		   ("docview" :follow org-docview-open :export 
		   org-docview-export :store

Re: New website - back to the old unicorn!

[Greg Newman]

It looks fantastic!!  Great work. The tools page is really nice.

I love seeing my revamp of the logo on the site.

Cheers,

Greg Newman

On Mon, Oct 26, 2020 at 12:56 PM Dante Catalfamo  wrote:

> Wow, this new website looks absolutely amazing!
>
> On 10/26/20 5:41 AM, Bastien wrote:
> > Dear all,
> >
> > thanks to the initiative and the patient efforts of Timothy, our
> > website has been revamped: new contents, new look and... the old
> > unicorn!
> >
> > Thanks very much to Timothy and to everyone who contributed with
> > feedback and ideas.
> >
> > This is a new basis that we will continue to polish and enhance.
> >
> > Enjoy :)
> >
> > https://orgmode.org
> >
>
>

Re: New website - back to the old unicorn!

[Dante Catalfamo]

Wow, this new website looks absolutely amazing!

On 10/26/20 5:41 AM, Bastien wrote:

Dear all,

thanks to the initiative and the patient efforts of Timothy, our
website has been revamped: new contents, new look and... the old
unicorn!

Thanks very much to Timothy and to everyone who contributed with
feedback and ideas.

This is a new basis that we will continue to polish and enhance.

Enjoy :)

https://orgmode.org

Re: official orgmode parser

[Ken Mankoff]

On 2020-10-26 at 09:24 -07, Nicolas Goaziou  wrote...
> # This is a comment (1)
>
> #+begin_example
> # This is not a comment (2)
> #+end_example
>
> AFAICT, you cannot distinguish between lines (1) and (2) with EBNF.

I agree. I think this is a better (correct?) example than the footnotes on Org 
Syntax page.

  -k.

Re: New website - back to the old unicorn!

[Diego Zamboni]

The new website looks great. Thanks Timothy for all your work!

--Diego


On Mon, Oct 26, 2020 at 10:42 AM Bastien  wrote:

> Dear all,
>
> thanks to the initiative and the patient efforts of Timothy, our
> website has been revamped: new contents, new look and... the old
> unicorn!
>
> Thanks very much to Timothy and to everyone who contributed with
> feedback and ideas.
>
> This is a new basis that we will continue to polish and enhance.
>
> Enjoy :)
>
> https://orgmode.org
>
> --
>  Bastien
>
>

Re: official orgmode parser

[Nicolas Goaziou]

Ken Mankoff  writes:

> Yes, I meant to write that I think Org syntax is maybe *not*
> context-free, and therefore EBNF can't capture all of it. But it could
> still be very helpful and capture most of it.

I'm not arguing about the usefulness of a partial EBNF description. I'm
merely pointing out that the syntax is not context-free. Here is an
example:

# This is a comment (1)

#+begin_example
# This is not a comment (2)
#+end_example

AFAICT, you cannot distinguish between lines (1) and (2) with EBNF.

Regards,

Re: official orgmode parser

[Ken Mankoff]

On 2020-10-26 at 07:21 -07, Nicolas Goaziou  wrote...
> Ken Mankoff  writes:
>
>> I question if this is possible because EBNF is for context-free
>> grammars, but I *think* Org syntax is context-free.
>
> It's not as explained in a footnote in the Org syntax document.

Yes, I meant to write that I think Org syntax is maybe *not* context-free, and 
therefore EBNF can't capture all of it. But it could still be very helpful and 
capture most of it.

But the more I think about it, the more I think Org may be context-free.

For the footnotes, I'm not sure that "(1) In particular, the parser requires 
stars at column 0 to be quoted by a comma when they do not define a headline" 
violates context. An "*" in the first column defines a header. It can be 
escaped by anything else too (" *" works too). If ",*" has a special meaning, 
that can be captured elsewhere in the syntax.

I'm also not sure (2) violates context-freeness, at least in the EBNF sense 
where a context can include a newline. See for example:

section ::= "*"+ string (tag+) newline (planning newline)? (property_drawer 
newline)?

planning ::= ("SCHEDULED:" "<" date_or_time ">")? ("DEADLINE:" "<" date_or_time 
">")?

property_drawer ::= ":PROPERTIES:" newline drawer_contents newline ":END:"

drawer_contents ::= ":" property ":" whitespace string

Where the first line, "section" is represented graphically as the attached 
image.

I guess I'm not 100% clear what "context-free" means. EBNF can represent a 
language where a for loop has an opening and closing brace. The closing brace 
is context-dependent, just as the planning or property drawers are.

I recently used EBNF to represent a CSV file with header, and I was unable to 
capture the requirement that the header column must have the same number of 
fields or commas as the data section. I think that is context-free. 



  -k.

Re: New website - back to the old unicorn!

[Jude DaShiell]

Unicorn is an old name for the modern day rhinoceros if what I read is
correct.

On Mon, 26 Oct 2020, Nick Dokos wrote:

> Date: Mon, 26 Oct 2020 11:02:04
> From: Nick Dokos 
> To: emacs-orgmode@gnu.org
> Subject: Re: New website - back to the old unicorn!
>
> Sounds good to me.
>
> And thanks for all the work to update the site!
>

-- 
United States has 633 Billionaires with only 10 doing any annual
significant giving.

Re: New website - back to the old unicorn!

[Nick Dokos]

Sounds good to me.

And thanks for all the work to update the site!
-- 
Nick

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

Re: New website - back to the old unicorn!

[Eric S Fraga]

On Monday, 26 Oct 2020 at 14:54, Daniele Nicolodi wrote:
> - (minor) I would add a background to the example in the home page to
> make it stand out more as an example org-mode syntax buffer

This bothered me as well when I visited the site.  I think it would help
to have something, however minor, to make it clear that the image stand
is not part of the text, e.g. even a thin border around the image would
do it.

Otherwise, the site looks great.

Thank you.
-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty

Re: New website - back to the old unicorn!

[TEC]

Daniele Nicolodi  writes:


On 26/10/2020 14:54, Daniele Nicolodi wrote:

On 26/10/2020 11:27, TEC wrote:


TEC  writes:

there are a few teething issues that have appeared when 
deploying the

site on orgmode.org.


These issues have now been fixed! Go wild :P

I've taken the liberty of making a post on reddit:
https://www.reddit.com/r/emacs/comments/jic3ww/the_org_website_has_been_revamped/

Once again, thanks to everyone who's helped out with this!

Timothy.


I like the new design. Thank you for your work!


By the way, what's the theme used to create the GIFs in the 
Features page?


I've just added a section on creating the Gifs/Svgs to the 
colophon:

https://orgmode.org/worg/org-site-colophon.html

How's that?

It would be good to re-record them as webm files, but making the 
Gifs
was enough for me  (also would be nice to see something happen 
with

https://gitlab.com/ambrevar/emacs-gif-screencast/-/issues/24).

All the best,

Timothy

Re: New website - back to the old unicorn!

[Daniele Nicolodi]

On 26/10/2020 15:26, TEC wrote:
> 
> Daniele Nicolodi  writes:
> 
>> I like the new design. Thank you for your work!
> 
> Thanks for the kind words!
> 
>> Two things:
> *cough, Three 

Indeed, I thought about the third one while writing the first two...

>> - in Firefox on a macOS machine, the colophon renders as "Made 
>> with XX
>> by TEC" with the XX being an Unicode replacement character. What 
>> is it
>> supposed to be?
> 
> Currently a brown heart, though I've actually had a better, less 
> tacky
> idea. You'll see it in a day or two ;)

Do you have any idea while it does not seem to be understood by Firefox
on macOS? It seem to be an emoji character... as the unicode replacement
char does not look that nice, what about replacing it with a more
commonly supported gliph? Or an embeeded SVG, maybe?

>> - (minor) I would add a background to the example in the home 
>> page to
>> make it stand out more as an example org-mode syntax buffer
> 
> Hmm, I've got mixed feelings about that. I kinda like how smoothly 
> it
> fits in at the moment, and I wouldn't want to jeopardise that. If 
> we can
> have it fit in smoothly, and more clearly be a example that would 
> be
> great though :)

IMHO a very light gray background would not compromise the design and
make the example stand out as such.

Cheers,
Dan

Re: New website - back to the old unicorn!

[Daniele Nicolodi]

On 26/10/2020 14:54, Daniele Nicolodi wrote:
> On 26/10/2020 11:27, TEC wrote:
>>
>> TEC  writes:
>>
>>> there are a few teething issues that have appeared when 
>>> deploying the
>>> site on orgmode.org.
>>
>> These issues have now been fixed! Go wild :P
>>
>> I've taken the liberty of making a post on reddit:
>> https://www.reddit.com/r/emacs/comments/jic3ww/the_org_website_has_been_revamped/
>>
>> Once again, thanks to everyone who's helped out with this!
>>
>> Timothy.
> 
> I like the new design. Thank you for your work!

By the way, what's the theme used to create the GIFs in the Features page?

Cheers,
Dan

Re: New website - back to the old unicorn!

[TEC]

Daniele Nicolodi  writes:


I like the new design. Thank you for your work!


Thanks for the kind words!


Two things:

*cough, Three 

- in Firefox on a macOS machine, the colophon renders as "Made 
with XX
by TEC" with the XX being an Unicode replacement character. What 
is it

supposed to be?


Currently a brown heart, though I've actually had a better, less 
tacky

idea. You'll see it in a day or two ;)

- (minor) I would add a background to the example in the home 
page to

make it stand out more as an example org-mode syntax buffer


Hmm, I've got mixed feelings about that. I kinda like how smoothly 
it
fits in at the moment, and I wouldn't want to jeopardise that. If 
we can
have it fit in smoothly, and more clearly be a example that would 
be

great though :)

- (very minor) why does the example on the home page need to be 
an SVG
file? It would be very cool if it could be copy and pasted, but 
right

now it is not possible (with Firefox, at least)


That sounds like a good idea! I'll see if I can do that 
(medium-term).

PRs welcome as usual of course 

Thanks for the feedback,

Timothy.

Re: official orgmode parser

[Nicolas Goaziou]

Hello,

Ken Mankoff  writes:

> I question if this is possible because EBNF is for context-free
> grammars, but I *think* Org syntax is context-free.

It's not as explained in a footnote in the Org syntax document.

Regards,
-- 
Nicolas Goaziou

Re: New website - back to the old unicorn!

[TEC]

Nick Dokos  writes:

One thing that I have done in the past (and I'm probably not the 
onlye
one) on the Emacs SE is refer people to the mailing list through 
the
old link: https://orgmode.ord/community.html which does not 
exist any
more, so we have a whole lot of broken links on Emacs SE at the 
moment:
can something be done to restore the functionality of those 
links?


Thanks!


A nginx redirect to 
https://orgmode.org/contribute.html#mailing-list or
https://orgmode.org/index.html#chatting is probably the best 
approach.


I'm not sure how Bastien feels about me adding redirects without 
asking,

so I'll talk to him about that.

How does that sound?

Timothy

Re: New website - back to the old unicorn!

[Nick Dokos]

One thing that I have done in the past (and I'm probably not the onlye
one) on the Emacs SE is refer people to the mailing list through the
old link: https://orgmode.ord/community.html which does not exist any
more, so we have a whole lot of broken links on Emacs SE at the moment:
can something be done to restore the functionality of those links?

Thanks!
-- 
Nick

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

Re: New website - back to the old unicorn!

[TEC]

gyro funch  writes:


The new site looks really great!


Thanks 

If we stumble upon minor issues (e.g., typos), what would be the 
best

way to notify you?


A quick email works fine for that :) and I'm also happy with 
github

issues: https://github.com/tecosaur/orgmode.org/issues/new

All the best,
Timothy

Re: New website - back to the old unicorn!

[Daniele Nicolodi]

On 26/10/2020 11:27, TEC wrote:
> 
> TEC  writes:
> 
>> there are a few teething issues that have appeared when 
>> deploying the
>> site on orgmode.org.
> 
> These issues have now been fixed! Go wild :P
> 
> I've taken the liberty of making a post on reddit:
> https://www.reddit.com/r/emacs/comments/jic3ww/the_org_website_has_been_revamped/
> 
> Once again, thanks to everyone who's helped out with this!
> 
> Timothy.

I like the new design. Thank you for your work!

Two things:

- in Firefox on a macOS machine, the colophon renders as "Made with XX
by TEC" with the XX being an Unicode replacement character. What is it
supposed to be?

- (minor) I would add a background to the example in the home page to
make it stand out more as an example org-mode syntax buffer

- (very minor) why does the example on the home page need to be an SVG
file? It would be very cool if it could be copy and pasted, but right
now it is not possible (with Firefox, at least)

Cheers,
Dan

Re: New website - back to the old unicorn!

[Jack Kamm]

Thank you Timothy! It looks great.

Bastien  writes:

> Dear all,
>
> thanks to the initiative and the patient efforts of Timothy, our
> website has been revamped: new contents, new look and... the old
> unicorn!
>
> Thanks very much to Timothy and to everyone who contributed with
> feedback and ideas.
>
> This is a new basis that we will continue to polish and enhance.
>
> Enjoy :)
>
> https://orgmode.org
>
> -- 
>  Bastien

Re: Please help by becoming a maintainer for an Org Babel file

[Palak Mathur]

I am willing to take care of ob-groovy.el. 

Sent from my iPhone

> On Oct 26, 2020, at 3:08 AM, Bastien  wrote:
> 
> Dear all,
> 
> we are looking for more maintainers of individual Org Babel files.
> 
> Jack and Ian are already in, I added myself to ob-clojure.el.
> 
> If you feel like proposing yourself for maintaining an Org Babel
> language, that would be super helpful.
> 
> Thanks a lot!
> 
> -- 
> Bastien
> 

Re: New website - back to the old unicorn!

[gyro funch]

On 10/26/2020 4:27 AM, TEC wrote:
> 
> TEC  writes:
> 
>> there are a few teething issues that have appeared when deploying the
>> site on orgmode.org.
> 
> These issues have now been fixed! Go wild :P
> 
> I've taken the liberty of making a post on reddit:
> https://www.reddit.com/r/emacs/comments/jic3ww/the_org_website_has_been_revamped/
> 
> 
> Once again, thanks to everyone who's helped out with this!
> 
> Timothy.
> 
> 

The new site looks really great!

If we stumble upon minor issues (e.g., typos), what would be the best
way to notify you?

-gyro




pEpkey.asc
Description: application/pgp-keys

Re: New website - back to the old unicorn!

[Detlef Steuer]

Thank you for your elegant work!

One observation: The text width on Features, Releases and Install is
different for each. If I may choose, I choose the width of "Install".

But great work anyway!

Detlef

Am Mon, 26 Oct 2020 17:44:16 +0800
schrieb TEC :

> Hi Everyone, just a quick note from me:
> 
> Regarding the intermediate state, there are a few teething issues 
> that
> have appeared when deploying the site on orgmode.org.*
> 
> If we could hold off from announcing this on some of the more
> high-traffic forums till these get sorted out that would be 
> appreciated
> :) We want people to get the best possible first impression of the
> revamp after all.
> 
> Timothy.
> 
> 
> *The favicon, font, and .gif files are not served properly ATM for 
>  example
> 

Re: ob-sql posgresql windows problems

[Neil Cherry]

On 10/24/20 7:41 AM, Bastien wrote:

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,



Org mode version 9.1.9 (release_9.1.9-65-g5e4542 @ 
c:/Users/NC1951/Documents/emacs-26.1/share/emacs/26.1/lisp/org/)

I did fix the issue by adding an if clause for Windows NT. It was caused by the
PGPASSORD being used before the command when it shouldn't have been there. I 
have
Postgres password file setup for the machine I want to access. Since the change 
it's
been working very well.

I think you're going to suggest that I upgrade my Windows machine to the latest.
I'll need to find that command after I backup my machine.

--
Linux Home Automation Neil Cherry   nche...@linuxha.com
http://www.linuxha.com/ Main site
http://linuxha.blogspot.com/My HA Blog
Author of:  Linux Smart Homes For Dummies

Re: official orgmode parser

[Ken Mankoff]

Hello,

On 2020-09-23 at 01:09 -07, 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 :)

Do you think it would be useful (or possible) to represent the current Org 
syntax in EBNF form so that people can use the EBNF to build parsers or 
graphically understand the form? I'm thinking of a nice page of railroad 
diagrams from this tool: https://github.com/GuntherRademacher/rr

I question if this is possible because EBNF is for context-free grammars, but I 
*think* Org syntax is context-free. Even if not, I think those railroad 
diagrams might be useful for parser-writers and can still describe 99 % of the 
syntax, even if a few extra sentences are needed to clarify some edge case.

  -k.

Re: New website - back to the old unicorn!

[Jude DaShiell]

Can orgmode when doing an html export that has images without alt= tags
filled in give an exporter an option to supply descriptions for those
images if not done earlier in the html creation process?  How would
someone earlier in the html creation process before export stage
correctly associate an alt= tag with description with an image?  I'm
asking these questions for #a11y purposes.  Unless subsequent
development changed, orgmode cannot make accessible pdf files.  So if
this question remains relevant inside of a pdf file created by orgmode
does some indicator exist stating this pdf file was created by orgmode?
If you know that and you need something accessible you can contact the
originator of the file and ask them to use adobe and make the pdf file
accessible once you find the orgmode indicator in the file.

On Mon, 26 Oct 2020, Carsten Dominik wrote:

> Date: Mon, 26 Oct 2020 06:19:49
> From: Carsten Dominik 
> To: Bastien 
> Cc: org-mode list , TEC 
> Subject: Re: New website - back to the old unicorn!
>
> On Mon, Oct 26, 2020 at 11:11 AM Carsten Dominik  wrote:
>
> > Hi,
> >
> > I like it!
> >
> > :)
> >
> > Carsten
> >
> > P.S.  One of the pages advertises that this
> >
> >[[
> > https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png
> > ]]
> >
> > should inline an image.  Does not do it yet for me.  What am I missing?
> >
>
> Never mind, it works in export, not tin the buffer.  Still, the text on the
> webpage is a bit confusing.
>
> Carsten
>
>
> >
> > Carsten
> >
> > On Mon, Oct 26, 2020 at 10:42 AM Bastien  wrote:
> >
> >> Dear all,
> >>
> >> thanks to the initiative and the patient efforts of Timothy, our
> >> website has been revamped: new contents, new look and... the old
> >> unicorn!
> >>
> >> Thanks very much to Timothy and to everyone who contributed with
> >> feedback and ideas.
> >>
> >> This is a new basis that we will continue to polish and enhance.
> >>
> >> Enjoy :)
> >>
> >> https://orgmode.org
> >>
> >> --
> >>  Bastien
> >>
> >>
>

-- 

Re: New website - back to the old unicorn!

[TEC]

Leo Vivier  writes:

I really like the new design.  You’ve done some fantastic work, 
Timoty,

as well as all the people who’ve contributed. :)


Thanks for the kind words! It means a lot to hear that the revamp 
is

going down well .


I especially like the new page for Tools:
https://orgmode.org/tools.html

The only nitpick I’d have on that page is that we’re grabbing 
the
picture from remote domains, which means that users of uMatrix 
have to
greenlight them before they can be displayed.  A solution could 
be to

host them ourselves, which should have a minimal footprint.


The plan is actually to move this page over to Worg, once the 
stylesheet
for Worg has been adjusted to allow for such column layouts. I'll 
bear

this in mind for when it's ported over :)

--
Timothy

Re: New website - back to the old unicorn!

[Leo Vivier]

Hi there,

TEC  writes:

> These issues have now been fixed! Go wild :P

I really like the new design.  You’ve done some fantastic work, Timoty,
as well as all the people who’ve contributed. :)

I especially like the new page for Tools:
https://orgmode.org/tools.html

The only nitpick I’d have on that page is that we’re grabbing the
picture from remote domains, which means that users of uMatrix have to
greenlight them before they can be displayed.  A solution could be to
host them ourselves, which should have a minimal footprint.

Best,

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

Re: New website - back to the old unicorn!

[Carsten Dominik]

On Mon, Oct 26, 2020 at 11:11 AM Carsten Dominik  wrote:

> Hi,
>
> I like it!
>
> :)
>
> Carsten
>
> P.S.  One of the pages advertises that this
>
>[[
> https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png
> ]]
>
> should inline an image.  Does not do it yet for me.  What am I missing?
>

Never mind, it works in export, not tin the buffer.  Still, the text on the
webpage is a bit confusing.

Carsten


>
> Carsten
>
> On Mon, Oct 26, 2020 at 10:42 AM Bastien  wrote:
>
>> Dear all,
>>
>> thanks to the initiative and the patient efforts of Timothy, our
>> website has been revamped: new contents, new look and... the old
>> unicorn!
>>
>> Thanks very much to Timothy and to everyone who contributed with
>> feedback and ideas.
>>
>> This is a new basis that we will continue to polish and enhance.
>>
>> Enjoy :)
>>
>> https://orgmode.org
>>
>> --
>>  Bastien
>>
>>

Re: New website - back to the old unicorn!

[Bastien]

Hi John,

John Herrlin  writes:

> "many others" on the landing page points to
> https://orgmode.org/org.html#History-and-Acknowledgments and returns
> 404.

Fixed, thanks!

-- 
 Bastien

Re: New website - back to the old unicorn!

[John Herrlin]

Looks awesome!

"many others" on the landing page points to
https://orgmode.org/org.html#History-and-Acknowledgments and returns
404.

Bastien  writes:

> Dear all,
>
> thanks to the initiative and the patient efforts of Timothy, our
> website has been revamped: new contents, new look and... the old
> unicorn!
>
> Thanks very much to Timothy and to everyone who contributed with
> feedback and ideas.
>
> This is a new basis that we will continue to polish and enhance.
>
> Enjoy :)
>
> https://orgmode.org

Re: New website - back to the old unicorn!

[TEC]

TEC  writes:

there are a few teething issues that have appeared when 
deploying the

site on orgmode.org.


These issues have now been fixed! Go wild :P

I've taken the liberty of making a post on reddit:
https://www.reddit.com/r/emacs/comments/jic3ww/the_org_website_has_been_revamped/

Once again, thanks to everyone who's helped out with this!

Timothy.

Re: New website - back to the old unicorn!

[Bastien]

Hi Carsten,

Carsten Dominik  writes:

> P.S.  One of the pages advertises that this
>
>    
> [[https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png]]
>
> should inline an image.  Does not do it yet for me.  What am I
> missing?

If you export a minimal .org file like the one attached and export it
to HTML with C-c C-e h h, it should create a HTML file with an inline
image*.  

Does it not on your side?

* https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png;
 alt="Konigsberg_bridges.png" />

-- 
 Bastien
#+title: Test inline image

[[https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png]]

Re: New website - back to the old unicorn!

[Carsten Dominik]

Hi,

I like it!

:)

Carsten

P.S.  One of the pages advertises that this

   [[
https://upload.wikimedia.org/wikipedia/commons/5/5d/Konigsberg_bridges.png]]

should inline an image.  Does not do it yet for me.  What am I missing?

Carsten

On Mon, Oct 26, 2020 at 10:42 AM Bastien  wrote:

> Dear all,
>
> thanks to the initiative and the patient efforts of Timothy, our
> website has been revamped: new contents, new look and... the old
> unicorn!
>
> Thanks very much to Timothy and to everyone who contributed with
> feedback and ideas.
>
> This is a new basis that we will continue to polish and enhance.
>
> Enjoy :)
>
> https://orgmode.org
>
> --
>  Bastien
>
>

Re: [PATCH] Async session eval (2nd attempt)

[Eric S Fraga]

On Monday, 26 Oct 2020 at 10:23, stardiviner wrote:
> This really is an good idea. Some other Babel languages like Ruby, JavaScript
> might benefit from this ob-comint async evaluation. Awesome!

Julia would benefit from this as well!  My Julia jobs usually take
minutes if not hours.  I usually tangle to run the code separately but
would love to simply C-c C-c and let it go.

-- 
: Eric S Fraga via Emacs 28.0.50, Org release_9.4-61-ga88806.dirty

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Hi Jeremie,

Jeremie Juste  writes:

> I'm willing to take care of ob-R.el.

You're in as of 36f4df892.  Thank you very much!

-- 
 Bastien

Re: org's elpa returns 404

[Bastien]

Hi,

lockyw...@gmail.com writes:

> I used to update org from org's elpa, as documented at:
> https://orgmode.org/elpa.html
> , by adding this address to the repos:
> https://orgmode.org/elpa/

A temporary glitch due to the switch to the new website.

Fixed, now.

Thanks!

-- 
 Bastien

Re: New website - back to the old unicorn!

[TEC]

Hi Everyone, just a quick note from me:

Regarding the intermediate state, there are a few teething issues 
that

have appeared when deploying the site on orgmode.org.*

If we could hold off from announcing this on some of the more
high-traffic forums till these get sorted out that would be 
appreciated

:) We want people to get the best possible first impression of the
revamp after all.

Timothy.


*The favicon, font, and .gif files are not served properly ATM for 
example

New website - back to the old unicorn!

[Bastien]

Dear all,

thanks to the initiative and the patient efforts of Timothy, our
website has been revamped: new contents, new look and... the old
unicorn!

Thanks very much to Timothy and to everyone who contributed with
feedback and ideas.

This is a new basis that we will continue to polish and enhance.

Enjoy :)

https://orgmode.org

-- 
 Bastien

Fwd: [syl20bnr/spacemacs] Org mode column view columns misaligned (#14058)

[bobf32]

Hi,

I raised a problem I am having with org mode to the spacemacs bug list. See
issue and comments at https://github.com/syl20bnr/spacemacs/issues/14058.

-- Forwarded message -
From: duianto 
Date: Sun, 25 Oct 2020 at 15:11
Subject: Re: [syl20bnr/spacemacs] Org mode column view columns misaligned
(#14058)
To: syl20bnr/spacemacs 
Cc: bobf32 , Author 


C-c C-x C-c calls org-columns which is defined in org-colview.el

There was a change to that file 6 days ago.
https://code.orgmode.org/bzg/org-mode/commit/90b14cb409adbd5529b8bbef32ad5239e5c85404

org-colview: Fix done keywords highlighting in agenda buffers

   - lisp/org-colview.el (org-agenda-columns): Populate
   org-done-keywords from org-done-keywords-for-agenda or the done keywords
   will use the same face as those not-done.

TINYCHANGE

This might be where the issue was discussed:
https://lists.gnu.org/archive/html/emacs-orgmode/2020-10/msg00104.html

The org-colview.el files commit history shows that the previous change
occurred 5 months ago:
https://code.orgmode.org/bzg/org-mode/commits/90b14cb409adbd5529b8bbef32ad5239e5c85404/lisp/org-colview.el

So the most recent change might be what caused the issue.

Org mode issues are reported by sending an email to: emacs-orgmode@gnu.org

—
You are receiving this because you authored the thread.
Reply to this email directly, view it on GitHub
,
or unsubscribe

.

org's elpa returns 404

[lockywolf]

Hello, everyone.

I used to update org from org's elpa, as documented at:
https://orgmode.org/elpa.html
, by adding this address to the repos:
https://orgmode.org/elpa/

Now it returns 404.
Has something changed?

-- 
Vladimir Nikishkin (MiEr, lockywolf)
(Laptop)

Re: Please help by becoming a maintainer for an Org Babel file

[Jeremie Juste]

Hello,

I'm willing to take care of ob-R.el.

Best regards,
Jeremie Juste

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

[stardiviner]

Bastien  writes:

> 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).
>

This is great and helpful! Thanks Bastien.

>> 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!


-- 
[ 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] Async session eval (2nd attempt)

[stardiviner]

This really is an good idea. Some other Babel languages like Ruby, JavaScript
might benefit from this ob-comint async evaluation. Awesome!

Jack Kamm  writes:

> This patch adds asynchronous evaluation for session blocks in
> Python. It also adds functionality to implement async session eval for
> other languages using ob-comint.el.
>
> To test the attached patch, add ":async" to a Python session block
> with a long computation (or "time.sleep") in it. Upon evaluation, your
> Emacs won't freeze to wait for the result -- instead, a placeholder
> will be inserted, and replaced with the true result when it's ready.
>
> I'll note how this is different from some related projects. ob-async
> implements asynchronous evaluation for Babel, but it doesn't work with
> sessions. emacs-jupyter, ein, and ob-ipython all implement
> asynchronous session evaluation, but only for Jupyter kernels. Jupyter
> is great for some cases, but sometimes I prefer to use the built-in
> org-babel languages without jupyter.
>
> The new functionality is mainly implemented in
> `org-babel-comint-async-filter', which I've defined in ob-comint.el,
> and added as a hook to `comint-output-filter-functions'.  Whenever new
> output is added to the comint buffer, the filter scans for an
> indicator token (this is inspired by
> `org-babel-comint-with-output'). Upon encountering the token, the
> filter uses a regular expression to extract a UUID or temp-file
> associated with the result, then searches for the appropriate location
> to add the result to.
>
> This is my 2nd attempt at this patch [0]. I have also ported it to an
> external package [1], but would like to have this functionality in Org
> proper, to permit better code reuse between async and sync
> implementations. The external package also includes an R
> implementation that I regularly use, as well as a Ruby implementation,
> but I've left these out to keep this initial patch smaller, and also I
> need to confirm copyright assignment on the Ruby implementation which
> was externally contributed.
>
> [0] 
> https://orgmode.org/list/87muj04xim.fsf@jaheira.i-did-not-set--mail-host-address--so-tickle-me/
> [1] https://github.com/jackkamm/ob-session-async
>
> From 8b7695a148d1831c916737650e115833cb7fc752 Mon Sep 17 00:00:00 2001
> From: Jack Kamm 
> Date: Sun, 25 Oct 2020 11:40:10 -0700
> Subject: [PATCH] ob-comint.el, ob-python.el: Async session evaluation
>
> Adds functionality to ob-comint.el to implement async session eval on
> a per-language basis.  Adds a reference implementation for ob-python.
>
> * lisp/ob-comint.el (org-babel-comint-with-output): Remove comment.
> (org-babel-comint-async-indicator, org-babel-comint-async-buffers,
> org-babel-comint-async-file-callback,
> org-babel-comint-async-chunk-callback,
> org-babel-comint-async-dangling): Add buffer-local variables used for
> async comint evaluation.
> (org-babel-comint-use-async): Add function to determine whether block
> should be evaluated asynchronously.
> (org-babel-comint-async-filter): Add filter function to attach to
> comint-output-filter-functions for babel async eval.
> (org-babel-comint-async-register): Add function to setup buffer
> variables and hooks for session eval.
> (org-babel-comint-async-delete-dangling-and-eval): Add helper function
> for async session eval.
>
> * lisp/ob-python.el (org-babel-execute:python): Check for async header
> argument.
> (org-babel-python-evaluate): Check whether to use async evaluation.
> (org-babel-python-async-indicator): Add constant for indicating the
> start/end of async evaluations.
> (org-babel-python-async-evaluate-session): Add function for Python
> async eval.
>
> *
> testing/lisp/test-ob-python.el (test-ob-python/async-simple-session-output):
> Unit test for Python async session eval.
> (test-ob-python/async-named-output): Unit test that Python async eval
> can replace named output.
> (test-ob-python/async-output-drawer): Unit test that Python async eval
> works with drawer results.
> ---
>  etc/ORG-NEWS   |  15 +++
>  lisp/ob-comint.el  | 172 +++--
>  lisp/ob-python.el  |  56 ++-
>  testing/lisp/test-ob-python.el |  61 
>  4 files changed, 294 insertions(+), 10 deletions(-)
>
> diff --git a/etc/ORG-NEWS b/etc/ORG-NEWS
> index 7f935bf52..9d5fbbe30 100644
> --- a/etc/ORG-NEWS
> +++ b/etc/ORG-NEWS
> @@ -88,6 +88,21 @@ package, to convert pandas Dataframes into orgmode tables:
>  | 2 | 3 | 6 |
>  #+end_src
>  
> +*** Async session evaluation
> +
> +The =:async= header argument can be used for asynchronous evaluation
> +in session blocks for certain languages.
> +
> +Currently, async evaluation is supported in Python.  There is also
> +functionality to implement async evaluation in other languages that
> +use comint, but this needs to be done on a per-language basis.
> +
> +By default, async evaluation is disabled unless the =:async= header
> +argument is present.  You can also set 

Re: Please help by becoming a maintainer for an Org Babel file

[Bastien]

Tim Cross  writes:

> Is there a list of org babel files which need maintainers?

You can check the list of ob-* files here:

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

If there is no "Maintainer:" in the header, then the file could
benefit from having an individual maintainer.  

-- 
 Bastien

Re: Please help by becoming a maintainer for an Org Babel file

[Tim Cross]

Is there a list of org babel files which need maintainers?

Bastien  writes:

> Dear all,
>
> we are looking for more maintainers of individual Org Babel files.
>
> Jack and Ian are already in, I added myself to ob-clojure.el.
>
> If you feel like proposing yourself for maintaining an Org Babel
> language, that would be super helpful.
>
> Thanks a lot!


--
Tim Cross

Please help by becoming a maintainer for an Org Babel file

[Bastien]

Dear all,

we are looking for more maintainers of individual Org Babel files.

Jack and Ian are already in, I added myself to ob-clojure.el.

If you feel like proposing yourself for maintaining an Org Babel
language, that would be super helpful.

Thanks a lot!

-- 
 Bastien

Re: How to restore old C-u C-c C-t behavior?

[Carsten Dominik]

On Mon, Oct 26, 2020 at 5:59 AM Piotr Isajew via General discussions about
Org-mode.  wrote:

> Hi,
>
> I've recently upgraded from version 8.2 to 9.3 and one change
> I've noticed is that the behavior of C-u C-c C-t is different.
>
> It used to prompt me for a desired target state to which the task
> is going to be set. Now it just advances to next state and
> captures the note on its way.
>

This is what C-c C-t does.  It prompts you for a key to select the secured
state.

Also take a look at the variable `org-use-fast-todo-selection'.

Carsten


>
> Is there an easy way to revert to the old behavior?
>
>
>
>