Re: Stale IDs

[Colin Baxter]

I've convinced myself finally that this is a feature.

Re: Inconsistency between code and manual: org-lowest-priority or org-priority-lowest

[Kyle Meyer]

Daniele Nicolodi writes:

> Hello,
>
> I found an inconsistency between the manual and implementation: the
> Priorities section says that the range of valid priorities can be set
> modifying the `org-priority-highest', `org-priority-lowest' and
> `org-priority-default' variables. However, in the code the variables
> names are `org-highest-priority', `org-lowest-priority' and
> `org-default-priority'.
>
> In can submit a patch with a fix. However, in a case like this, should
> the code modified to match the documentation, or vice-versa?

The org-X-priority -> org-priority-X rename happened in v9.4, with
org-X-priority names retained as aliases.  So, it sounds like there are
some leftover bits in the code.

Thanks.

Re: worg changes

[Kyle Meyer]

ian martins writes:

> I've written some documentation for ob-java for worg. Should I submit a
> patch or is it fine to just push? it doesn't modify any existing files.

It's fine to just push.

Re: [PATCH] change the ob-java default back to scripting mode

[Kyle Meyer]

ian martins writes:

> If I make the same change to dozens of tests in the same file, should I
> list them as separate bullets, or put the list of function names in
> parentheses, or is it better to omit the list if it would be long?

The second or third.  I think it's a judgment call (and not worth
thinking too hard about), especially for mechanical and simple changes.
We're following Emacs here, so looking through their commit log in
addition to ours should give a pretty good feel for things.

Re: Org-Mode as DSL

[Tom Gillespie]

Hi Mauro,
Welcome! This is definitely not a crazy idea (or at least if it is
then you are in good company).
Org already has wide support as a markup language, and tools like
https://github.com/tecosaur/org-pandoc-import exist that leverage
this,
but the syntax is not standardized and as a result the elisp
implementation is the defacto standard.
Depending on what editors your colleagues use and the extent to which
features of Org they need to
use there might be an org-mode plugin that meets their needs (editing
Org as markup yes, using Org babel, no).
See the In Other Editors section of https://orgmode.org/install.html#org70be9a1.

Beyond its use as a markup language, there are efforts toward making
the more powerful parts of Org portable so that runtimes
beyond Emacs can correctly interpret and enable the dynamic nature of Org.

See for example this thread on formalizing org syntax
https://lists.gnu.org/archive/html/emacs-orgmode/2020-10/msg00344.html.
Parsers for org already exist in a variety of languages, but they vary
in their correctness and their support for org features.
In part this is because some of those features (such as footnotes)
look like they are easy to implement, but support syntactic variants
that parsers do not implement correctly or at all (e.g. the org-ruby
parser). Formalizing what it means to be a compliant parser could
help in those cases. There is also a need to specify some additional
underlying semantics about how to correctly construct trees
from the parsed elements and how to associate keywords to elements
etc. I am writing up an executable grammar for Org using Racket
and #lang brag that I will share in the mentioned thread.

Beyond surface syntax and basic semantics I see two key areas that
need attention in order for other full org implementations to be
viable.

The first obstacle is the fact that the semantics of org babel source
blocks are inconsistent and that it is hard to know what features a
particular ob-lang supports.
See https://lists.gnu.org/archive/html/emacs-orgmode/2020-10/msg00244.html
for a discussion of some of the challenges here.
I have been drafting an email on babel regularization for quite a
while, and it will show up on this list in the near future.

The second obstacle that I see is the fact that there are many places
where Org is deeply integrated with Emacs Lisp.
For example it is possible to include raw Emacs Lisp expressions in
certain areas of an Org file that will be evaluated
at a certain time (the time is not the same in all cases).
Supporting this functionality is something that other implementations
must be able to do
if we do not want Org files to be split into those that use elisp and
those that do not (somewhat like the current sorry state of markdown).
I have a couple of thoughts about how this could be addressed, but in
the absence of a portable implementation of elisp there would
be a divide between Org files that use elisp closures outside of src
blocks and those that do not.
In the event that other languages could someday be used in the top
level of an org file, it would be easier for the
reference elisp implementation of Org mode to run such files by
leveraging the ob-lang implementation for those languages.

A third area (of less immediate concern to me) that might need
standardization is the export backends.
Should different implementations of Org produce the same latex output?
Probably. How much trouble
would it be to specify? Probably quite a bit. So it might be easier to
just run Emacs behind the scenes
in those cases and not worry about trying to standardize.

Best!

Tom

Org-Mode as DSL

[Mauro Mandracchia]

Hi everybody 
This is my first message to the community, let me first state, I love
*org-mode.*Thanks to the authors and the contributors!
I use *org-mode* everyday, but I don't want to bore you with my stories
about how *org-mode* facilitates my life, just ask if you are interested.

I believe that *org-mode* is the most powerful toolset that can leverage
documentation and code.
I also love literate programming and I've found nothing like org-mode for
it.

I think that org-mode adoption is mainly found in academic and personal
context and rarely in commercial organizations.
Too often I see myself being forced to use Markdown for project
documentation and miss all the features that org-mode could have offered to
the entire project and not just the documentation.

The main reason why I can't use org-mode at work is that my
colleagues don't all use
*emacs.*
What I miss is an DSL for Org-Mode, like HTML does, and that other editors
or IDE would implement his functions, a bit like the browsers do.

If org-mode could be embeddable in different runtimes I could imagine HTTP
services implemented for *org-mode*, and I think of tools like Jupyter
 or Observable  could be
built on the org-mode standards.
I have many other implementation details and use cases that I would like to
share, but can be a bit too much for introducing the topic.

Is it a crazy idea if Org-Mode could become a DSL rather than a mode for
emacs?

Best Regards,
Mauro.

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Achim Gratz]

Berry, Charles" via "General discussions about Org-mode. writes:
> FWIW, it doesn't seem like an accident. You might ping the author of this 
> commit:

No, that change was to suppress an _additional_ confirmation that was
triggered by some internal implementation details.


Regards,
Achim.
-- 
+<[Q+ Matrix-12 WAVE#46+305 Neuron microQkb Andromeda XTk Blofeld]>+

SD adaptations for KORG EX-800 and Poly-800MkII V0.9:
http://Synth.Stromeko.net/Downloads.html#KorgSDada

Inconsistency between code and manual: org-lowest-priority or org-priority-lowest

[Daniele Nicolodi]

Hello,

I found an inconsistency between the manual and implementation: the
Priorities section says that the range of valid priorities can be set
modifying the `org-priority-highest', `org-priority-lowest' and
`org-priority-default' variables. However, in the code the variables
names are `org-highest-priority', `org-lowest-priority' and
`org-default-priority'.

In can submit a patch with a fix. However, in a case like this, should
the code modified to match the documentation, or vice-versa?

Thank you.

Cheers,
Dan

Re: Confusion about org-confirm-babel-evaluate's behavior while exporting lob calls

[Berry, Charles]

Just on a whim, I changed `org-babel-exp-results' by deleting


  (let (org-confirm-babel-evaluate-NOT)

and the matching right parenthesis.

Now I get a single prompt to confirm evaluation using Ruiyang's ECM.

HTH,

Chuck
> On Oct 28, 2020, at 8:16 PM, Kyle Meyer  wrote:
> 
> 吴锐扬 writes:
> 
>> The author explained his motivation for the commit in the mailing list 
>> before it got applied:
>> 
>>> That's because lob calls get wrapped internally in an anonymous
>>> emacs-lisp source block that then feeds through the result from the
>>> actual call as elisp.  The attached patch should suppress the
>>> confirmation for the wrapper call.  To the best of my knowledge nothing
>>> dangerous can happen with that evaluation and all confirmations for the
>>> call stack down from there have already taken place according to the
>>> users' setup.
> 
> Just for reference: it looks like that's
> 
>  
> https://urldefense.com/v3/__https://orgmode.org/list/87k3oaw7jz.fsf@Rainer.invalid__;!!LLK065n_VXAQ!29k-PVwb9XnRUW2w0NBea_sA5uaG3P1Ck0lJ_EyddjelOaIrJGxmvvR28RAyZpjHiQ$
>  
> 
>> If I understand correctly, executing a lob call would trigger two user
>> confirmations in the past, and this commit was meant to suppress one
>> of the two confirmations. (I may be wrong since I am a fairly new user
>> of org mode.)
> 
> Thanks for digging.  Indeed, if you go back to the parent of 56bf3d789
> (Babel: avoid superfluous confirmation for internal wrapper,
> 2013-04-10), there are two queries.  On that commit, there is one.
> 
>> Now there is no confirmation at all. IMHO, there should be exactly
>> one confirmation ideally.
> 
> It looks like the query went away with dbb375fdf (Simplify Babel calls
> evaluation, 2016-06-16), which was included in the 9.0 release.  Based
> on a quick glance at that commit, I don't think that was an intentional
> change.
> 
> I won't take a closer look at this until at least this weekend, though.
> I'd be very happy if someone beat me to it.

Re: Is reading nested simple lists into org-babel code blocks currently supported?

[Tom Gillespie]

Hi James,
I would file this along with other ob-lang dependent features such
as TRAMP remote execution support. For example, python works as in
your other examples, but only if you define :var unordered="unordered"
as another variable before the variable you pass the plain list to
because python tries to dereference the symbol. A global solution like
the one you propose breaks the semantics in cases where a language
does correctly deal with quoted lists (e.g. common lisp). As a result
each ob-lang will probably have to deal with this itself, or at least
they will have to define how to consume quoted elisp lists without
raising errors. That said, I'm not sure that org babel requires that
ob-lang implementations handle this. Maybe it should? I've added this
to my growing list of issues related to org babel regularization.
Best!
Tom

On Thu, Oct 29, 2020 at 7:25 AM James Boyle  wrote:
>
> Hi all,
>
> Since this is a bit of a long post, I've put my questions and summary
> comment at the top, with the detailed context below.
>
> 1. What is the level of support for reading nested simple lists into
>org-babel code blocks?
> 2. When the manual (see link below) says that they are not supported,
>is it known if it meant "not at all supported," or, that support is
>currently language-dependent?
> 3. Directionally, does the org-mode project care to support nested
>simple lists?
>
> I'm happy to submit patches for both code and manual in any event, but
> wanted to align on if there are goals for supporting reading nested
> lists, and if so, at what level.
>
> At a minimum, I think updating the manual to be more precise would be
> great.
>
> Thanks for your any assistance you can provide.
>
> Details:
>
> I was going through the manual on this page:
>
> https://orgmode.org/manual/Environment-of-a-Code-Block.html#Environment-of-a-Code-Block
>
> and testing out the example, "A simple named list."
>
> Contrary to this line in the manual:
>
> > Note that only the top level list items are passed along. Nested list items 
> > are ignored.
>
> It looks like the example org-babel block *does* work for nested
> lists, depending upon the language. I am using org-mode 9.4.
>
> Here is the org block verbatim from the manual, with the
> results that are supposed to occur:
>
> #+NAME: example-list
> - simple
>   - not
>   - nested
> - list
>
> #+BEGIN_SRC emacs-lisp :var x=example-list
>   (print x)
> #+END_SRC
>
> #+RESULTS:
> | simple | list |
>
>
> And here is the same block, when I evaluate it locally, with the
> actual results, showing that unordered, nested lists are not ignored.
>
> #+NAME: example-list
> - simple
>   - not
>   - nested
> - list
>
> #+BEGIN_SRC emacs-lisp :var x=example-list
>   (print x)
> #+END_SRC
>
> #+RESULTS:
> | simple | (unordered (not) (nested)) |
> | list   ||
>
>
> I thought this was a nice surprise, until I noticed that whether or
> not it works is language-dependent.
>
> In ruby, I get an error:
>
> #+begin_src ruby :var x=example-list
>   # This is the error I get:
>
>   # `main': undefined local variable or method `unordered' for
>   # main:Object (NameError)
>   puts x
> #+end_src
>
> #+RESULTS:
>
> And here is the equivalent error in js. Presumably other languages
> have variable support for this feature.
>
> #+begin_src js :var x=example-list
>   // Below is a partial error trace:
>
>   // 
> /private/var/folders/mc/jylgk04j5r1f96hcsd3ywm8hgn/T/babel-shSmEq/js-script-xzngmd:2
>   // var x=[["simple", [unordered, ["not"], ["nested"]]], ["list"]]; ^
>   // ReferenceError: unordered is not defined
>   return x
> #+end_src
>
> #+RESULTS:
>
> The error can be trivially "fixed" by some code like this, or making
> the equivalent change in the actual source line to output a string
> rather than a symbol. Changing L#2365 linked below to use "unordered"
> (string) rather than 'unordered (symbol) seemed to fix it, and
> produced no new test failures for me.
>
> #+begin_src emacs-lisp
>   ; See this line for where 'unordered is being spat out:
>   ; https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-core.el#L2365
>   (defun patch-get-vars-output (vars)
> "Substitute special Lisp symbols with a Lisp keyword.
>   This allows Ruby to not barf on an undefined variable error
>   for certain input structures like nested lists.
>   Argument VARS is a tree structure.  See above example format."
> (subst "unordered" 'unordered vars))
>
>   (advice-add 'org-babel--get-vars :filter-return #'patch-get-vars-output)
> #+end_src
>
> Thanks again for any help or direction you can provide.
>
> James Boyle
>

Re: Bug: Can’t assign to hline relative reference

[Maxim Nikulin]

2020-10-23  Dante Catalfamo wrote:

That seems to work for the most part, but now I'm experiencing a strange
difference when evaluating. If I use a formula like
  
#+TBLFM:@2$3..@23$3=if($2!=0,12*$2,$3);%.2f::@24$2=vsum(@I..@II);%.2f::@24$3=vsum(@I..@II);%.2f


The column gets evaluated first, then the sum at the bottom gets
evaluated, resulting in what I'd expect. But if I use a formula like

#+TBLFM:@<<$3..@>>$3=if($2!=0,12*$2,$3);%.2f::@24$2=vsum(@I..@II);%.2f::@24$3=vsum(@I..@II);%.2f

The sum gets calculated first, and the column after, meaning the sum
doesn't reflect any changes made before calculation. I find this pretty
strange considering the formulas are in the same order. Do formulas
involving relative references get calculated last for some reason?


Interesting... However my curiosity is not strong enough to find 
appropriate place in the code.


Either I never tried such combination of references (I use @>$2=... for 
the last row) or I have not expected reliable evaluation order and just 
hit C-c C-c several times.


It seems that single cell formulas are calculated later than ranges

| a | c | b |
|---+---+---|
| 2 |   |   |
| 3 |   |   |
| 4 |   |   |
| 5 |   |   |
| 6 |   |   |
| 7 |   |   |
|---+---+---|
|   |   |   |
#+TBLFM: @<<$3..@>>$3=$1*2 :: @<<$2..@<<<$2=$3*3 :: @5$2..@6$2=$3*4 :: 
@4$2=$3*5 :: @>>$2=$3*6


| a |  c |  b |
|---++|
| 2 |  0 |  4 |
| 3 |  0 |  6 |
| 4 |  0 |  8 |
| 5 |  0 | 10 |
| 6 |  0 | 12 |
| 7 | 84 | 14 |
|---++|
|   |||
#+TBLFM: @<<$3..@>>$3=$1*2 :: @<<$2..@<<<$2=$3*3 :: @5$2..@6$2=$3*4 :: 
@4$2=$3*5 :: @>>$2=$3*6


Notice zeroes for @<<..@<<< but not for @>>. Even more funny that 
@>>>$2..@>>$2=$3 instead of @<<$3..@<<<$3 give non-zero values 
for the second and third rows. Anyway I do not plan to memorize such rules.


By the way, I have noticed that @<<$3..@>>$3=... likely could be 
replaced by just $3=... and it is evaluated quite early in such form. 
Skimming through the manual previous times, I missed the point of 
"column formulas" https://orgmode.org/manual/Column-formulas.html or

[[info:org#Column formulas]] and have noticed the details just today.

Re: Default fold state of property drawers?

[Gustav Wikström]

Hmm, maybe.. Didn't consider that one.

But maybe my issue rather lies in how the visibility toggling with S-TAB 
functions. The file property drawer is open in OVERVIEW and CONTENT but hidden 
in SHOW ALL. My intuition says that the file-property drawer should be closed 
for all toggle-states. Thoughts?

/Gustav


From: Kyle Meyer 
Sent: Thursday, October 29, 2020 03:45
To: Gustav Wikström
Cc: emacs-orgmode@gnu.org
Subject: Re: Default fold state of property drawers?

Gustav Wikström writes:

> Hi,
>
> This may be a stupid question but I didn't find anything conclusive in
> the manual or online after a (albeit fairly quick) scan.
>
> Is there currently a way to declare that property drawers (and the
> file level property drawer in particular) should be hidden when
> opening a new Org file, no matter the startup keyword setting? I.e is
> it possible to control the open/closed state of the property drawer
> separate from the outline folding?

I may be missing something too, but I'm not aware of a way to do this
that's distinct from setting org-startup-folded and friends.  But
doesn't org-startup-folded's showall/showeverything distinction cover
your usecase?

Is reading nested simple lists into org-babel code blocks currently supported?

[James Boyle]

Hi all,

Since this is a bit of a long post, I've put my questions and summary
comment at the top, with the detailed context below.

1. What is the level of support for reading nested simple lists into
   org-babel code blocks?
2. When the manual (see link below) says that they are not supported,
   is it known if it meant "not at all supported," or, that support is
   currently language-dependent?
3. Directionally, does the org-mode project care to support nested
   simple lists?

I'm happy to submit patches for both code and manual in any event, but
wanted to align on if there are goals for supporting reading nested
lists, and if so, at what level.

At a minimum, I think updating the manual to be more precise would be
great.

Thanks for your any assistance you can provide.

Details:

I was going through the manual on this page:

https://orgmode.org/manual/Environment-of-a-Code-Block.html#Environment-of-a-Code-Block

and testing out the example, "A simple named list."

Contrary to this line in the manual:

> Note that only the top level list items are passed along. Nested list items 
> are ignored.

It looks like the example org-babel block *does* work for nested
lists, depending upon the language. I am using org-mode 9.4.

Here is the org block verbatim from the manual, with the
results that are supposed to occur:

#+NAME: example-list
- simple
  - not
  - nested
- list

#+BEGIN_SRC emacs-lisp :var x=example-list
  (print x)
#+END_SRC

#+RESULTS:
| simple | list |


And here is the same block, when I evaluate it locally, with the
actual results, showing that unordered, nested lists are not ignored.

#+NAME: example-list
- simple
  - not
  - nested
- list

#+BEGIN_SRC emacs-lisp :var x=example-list
  (print x)
#+END_SRC

#+RESULTS:
| simple | (unordered (not) (nested)) |
| list   ||


I thought this was a nice surprise, until I noticed that whether or
not it works is language-dependent.

In ruby, I get an error:

#+begin_src ruby :var x=example-list
  # This is the error I get:

  # `main': undefined local variable or method `unordered' for
  # main:Object (NameError)
  puts x
#+end_src

#+RESULTS:

And here is the equivalent error in js. Presumably other languages
have variable support for this feature.

#+begin_src js :var x=example-list
  // Below is a partial error trace:

  // 
/private/var/folders/mc/jylgk04j5r1f96hcsd3ywm8hgn/T/babel-shSmEq/js-script-xzngmd:2
  // var x=[["simple", [unordered, ["not"], ["nested"]]], ["list"]]; ^
  // ReferenceError: unordered is not defined
  return x
#+end_src

#+RESULTS:

The error can be trivially "fixed" by some code like this, or making
the equivalent change in the actual source line to output a string
rather than a symbol. Changing L#2365 linked below to use "unordered"
(string) rather than 'unordered (symbol) seemed to fix it, and
produced no new test failures for me.

#+begin_src emacs-lisp
  ; See this line for where 'unordered is being spat out:
  ; https://code.orgmode.org/bzg/org-mode/src/master/lisp/ob-core.el#L2365
  (defun patch-get-vars-output (vars)
"Substitute special Lisp symbols with a Lisp keyword.
  This allows Ruby to not barf on an undefined variable error
  for certain input structures like nested lists.
  Argument VARS is a tree structure.  See above example format."
(subst "unordered" 'unordered vars))

  (advice-add 'org-babel--get-vars :filter-return #'patch-get-vars-output)
#+end_src

Thanks again for any help or direction you can provide.

James Boyle

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

[Michael Heerdegen]

Kyle Meyer  writes:

> Going through each of the collection functions at the end of
> org-agenda-get-day-entries, it looks like they all set org-marker.
> Plus, I can spot places in org-agenda.el that rely on agenda entries
> having org-marker (e.g., org-agenda-goto and org-agenda-todo), so I
> think that assumption would be safe.

Great, thanks for checking, Kyle.

Michael.

Re: [PATCH] change the ob-java default back to scripting mode

[ian martins]

ok I will do that.

If I make the same change to dozens of tests in the same file, should I
list them as separate bullets, or put the list of function names in
parentheses, or is it better to omit the list if it would be long?

On Wed, Oct 28, 2020 at 9:36 PM Kyle Meyer  wrote:

> ian martins writes:
>
> > Subject: [PATCH] ob-java.el: Change the default back to scripting mode
> >
> > * lisp/ob-java.el: Change the default to scripting mode.  Add name to
> > authors.
>
> The changelog entry should explicitly list the variables/functions that
> are modified.  So in this case
>
> * lisp/ob-java.el (org-babel-default-header-args:java): ...
>
> > A recent commit added functional mode and made it default, but this
> > would break java source blocks for anyone that relied on the old
> > default.  This sets the default back to scripting mode.
>
> Thanks for restoring the behavior.
>
> > I missed a name when I put the authors of ob-C and ob-python as the
> > authors of ob-java.  Added it.
>
> Please move this unrelated change to a separate commit.
>

worg changes

[ian martins]

I've written some documentation for ob-java for worg. Should I submit a
patch or is it fine to just push? it doesn't modify any existing files.
I've seen this question come up on this list before but I haven't seen an
answer. Also I couldn't find the answer on worg [1].

one note: I tweaked the css a bit. I think it makes it easier to read, but
it also doesn't match the other pages.

[1] https://orgmode.org/worg/#orgeb00eb0

Re: New website - back to the old unicorn!

[Stefan Nobis]

TEC  writes:

> This seems very suspicious for one reason. I cannot see "Canvas"
> anywhere in the entire codebase of the website, or any loaded
> resources. So I have no idea where on earth the JS you're finding
> has come from - I'm guessing it's improperly injected by a
> extension. FWIW I also run Decentraleyes in Firefox and fail to see
> your issue.

Thanks for your response. So maybe a local error (I think I deactivate
all plugins bug Decentraleyes, but maybe its the combination of
Decentraleyes with Vivaldi or I made another mistake). I will
investigate further when I have a bit more time. For now please assume
this issue as resolved. :)

-- 
Until the next mail...,
Stefan.

Archiving repeated tasks under corresponding date tree for each repeated item

[Gerardo Moro]

Dear all,

I am resending this as I believe it's a useful concept to implement,
especially by those who track their tasks and do weekly/monthly reviews.

When I archive a repeated task (let's say, a learning project of 15 minutes
every Wednesday day for 2 months), the task gets archived in a date tree
all under the day it was closed (cancelled) as a whole. This means that all
the LOGGED individual instances of repetition are archived on the day the
project got completed. It would be great if each of these individual "task
happenings" were archived under the date and time they were completed
individually, and not just all as one block. This way I could get weekly
reviews that take those into account. Not sure if I made myself understood!
:))

Thanks!
G